KELOMPOK 04. Sistem Informasi Koperasi Karyawan STIKOM Surabaya. Test Plan. Version

KELOMPOK 04

Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version <1.0>

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Test Plan PRPLSAD/2011/X/1

Version: <1.0> Date: <13/10/11>

Revision History Date

Confidential

Version

Description

© Kelompok 04 PRPL, 2011

Author

Page 2


Version: <1.0> Date: <13/10/11>

Table of Contents 1.

Introduction

4

1.1 1.2 1.3 1.4

4 4 4 6

Purpose Background Scope Project Identification

2.

Requirements for Test

7

3.

Test Strategy

7

4.

3.1

Testing Types 3.1.1 Data and Database Integrity Testing 3.1.2 Function Testing 3.1.3 Business Cycle Testing 3.1.4 User Interface Testing 3.1.5 Performance Profiling 3.1.6 Load Testing 3.1.7 Stress Testing 3.1.8 Volume Testing 3.1.9 Security and Access Control Testing 3.1.10 Failover / Recovery Testing 3.1.11 Configuration Testing 3.1.12 Installation Testing 3.2 Tools

7 7 7 9 10 11 12 13 14 15 16 19 20 21

Resources

22

4.1 4.2

22 24

Workers System

5.

Project Milestones

24

6.

Deliverables

25

6.1 6.2 6.3

25 25 25

7.

Test Model Test Logs Defect Reports

Appendix A: Project Tasks

Confidential

26


Page 3


Version: <1.0> Date: <13/10/11>

Test Plan 1. Introduction Dokumen Test Plan ini menjelaskan tentang bagaimana software yang di buat dapat berjalan sesuai dengan rencana yang telah di tetapkan seelumnya. Uji coba tidak hanya dilakukan pada source code, namun pengujian juga di lakukan pada database,komponen,interface,keamanan,model bisnis dan performa dari software yang di bangun, serta konfigurasi antara client dan server 1.1 Purpose

Dokumen Test Plan ini dibuat untuk mendukung pembuatan Sistem Pakar untuk Mendiagnosa Ganguan-Ganguan pada Sifat dan Perilaku Anak, termasuk 1. Mengidentifikasi komponen software yang harus ditest 2. Membuat rekomendasi kebutuhan untuk Test 3. Membuat rekomendasi dan mendeskripsikan testing strategi yang akan dilakukan 4. Mengidentifikasi kebutuhan sumberdaya(dari database maupun komponen yang di gunakan 1.2 Background

Tahap pengujian pada software yang dibangun mutlak dibutuhkan agar kinerja dari software maupun database yang di gunakan dapat berjalan sesuai dengan yang diharapkan. Selain itu tahap ini juga dilakukan untuk menanggulangi maupun mengurangi terjadinya kesalahan(error) . Adapun lingkup testing yang akan dilakukan agar kinerja software dapat berjalan dengan baik meliputi : 1. Source Code, merupakan bagian dari software yang digunakan untuk mengatur jalannya program.pengujian pada bagian ini bertujuan untuk mengurangi kemungkinan adanya bug pada software yang kita bangun. Tools yang kami gunakan untuk mencari bug pada source code adalah dengan visual studio 2008. 2. Database(SQL Server 2005), adalah Sistem manajemen basis data relasional(RDBMS) produk Microsoft query utamanya adalah Transact-SQL yang merupakan implementasi dari SQL standar ANSI/ISO yang digunakan oleh Microsoft dan Sybase. Umumnya SQL Server digunakan di dunia bisnis yang memiliki basis data berskala kecil sampai dengan menengah, tetapi kemudian berkembang dengan digunakannya SQL Server pada basis data besar. Tujuan diadakannya pengujian pada fitur ini yaitu agar pencatatan record pada database yang digunakan dapat berjalan dengan baik. 3. Interface merupakan bagian dari software yang digunakan sebagai media Confidential


Page 4


Version: <1.0> Date: <13/10/11>

komunikasi antara user dengan sistem. Pengujian pada bagian ini dilakukan agar user dapat menggunakan software yang kami buat dengan mudah, selain itu pengujian pada bagian ini juga bertujuan agar fasilitas-fasilitas yang ada pada masing-masing form dapat bekerja sesuai dengan keinginan. 1.3 Scope

Dokumen ini hanya membahas tentang pengujian(testing) terhadap software yang dibangun . Ruang Lingkup yang akan diuji meliputi pengujian source code, performa, keamanan , dan keakurantan software yang akan dibuat.Selain itu pengujian juga akan di lakukan pada masing-masing form yang ada dalam software.Pengujian hanya dilakukan dengan tester.

Confidential


Page 5

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Test Plan PRPLSAD/2011/X/1 1.4

Version: <1.0> Date: <13/10/11>

Project Identification

sDocument (and version / date)

Created or Received or Author or Notes Available Reviewed Resource

Requirements Specification

 Yes  No  Yes  No

Functional Specification


Use Case Reports


ERD Reports


Project Plan


Design Specifications


Prototype


Users Manuals


Business Model / Flow


Data Model / Flow


Business Functions and  Yes  No  Yes  No Rules Project / Business Risk  Yes  No  Yes  No Assessment

Confidential


Page 6


Version: <1.0> Date: <13/10/11>

2. Requirements for Test Testing akan dilakukan pada Entity Relational Diagram(untuk mengidentifikasi tabletabel yang dibutuhkan) ,Data Flow Diagram(untuk mengidentifikasi alur bisnis) dan fungsi dari masing-masing form serta source code pada software yang dibangun 3. Test Strategy Strategi terdiri dari seluruh rencana yang dilakukan untuk melakukan testing pada software yang di bangun 3.1

Testing Types

3.1.1 Data and Database Integrity Testing

Test Objective:

Query dapat menghasilkan informasi yang di butuhkan

Technique:

Melakukan query select pada database Melakukan query DML pada database Mengecek relasi masing-masing table dengan melakukan bernagai macam query

Completion Criteria: Database dapat menjalankan tiap query yang dilakukan dengan baik Special Considerations:

Terjadi gangguan pada jaringan , sehingga proses tidak dapat di lakukan

3.1.2 Function Testing

Test Objective:

 Form Input(semua form yang membutuhkan input data) dapat melakukan input data untuk database atau untuk diproses  Form laporan dapat menghasilkan hasil transaksi sesuai dengan input dan proses yang ada

Technique:

 Menguji masing-masing tombol pada form  Menguji form inputan dengan berbagai kondisi input  Memastikan hasil laporan sesuai dengan inputan dan data yang ada pada master

Completion Criteria:  Tiap-tiap form input dapat melakukan input data kedalam database maupun input data untuk diproses dengna baik  Output yang dikeluarkan sesuai dengan input dan transaksi yang telah dibuat  Dapat menghasilkan laporan sesuai dengan yang diharapkan

Confidential


Page 7


Special Considerations:

Confidential

Version: <1.0> Date: <13/10/11>

-


Page 8


Version: <1.0> Date: <13/10/11>

3.1.3 Business Cycle Testing

Test Objective

Hasil Diagnosa dapat memberikan output yang sesuai dengan data input dan rule yang telah di berikan.

Technique:

 Menguji alur logika program  Menguji form dengan berbagai kondisi inputtan data  Menguji pencetakan laporan hasil diagnose

Completion Criteria:  Form dapat memberikan Hasil Diagnosa  Form dapat mencetak hasil diagnose Special Considerations:

Confidential

-.


Page 9


Version: <1.0> Date: <13/10/11>

3.1.4 User Interface Testing

Test Objective:

Memastikan semua komponen yang ada pada masing-masing form dapat bekerja dengan baik

Technique:

1. Form login: Input:-menginputkan karakter untuk melakukan sql injection. Melakukan brute force password Output:Form login hanya dapat menerima user yang memiliki hak akses. 2. Form laporan: Input: berbagai kondisi penyakit Output: form laporan dapat menghasilkan berbagai macam laporan sesuai dengan kondisi yang di inputkan. 3. Form master: Input: gangguan,gejala, basis pengetahuan Output: database dapat menyimpan input dari masing-masing form.

Completion Criteria: Tampilan dari aplikasi mudah di gunakan oleh user Special Considerations:

Confidential

-


Page 10


Version: <1.0> Date: <13/10/11>

3.1.5 Performance Profiling

Test Objective:

Waktu penyimpanan record,proses menghasilkan hasil diagnosa dapat dilakukan dengan cepat

Technique:

 Penyimpanan data dilakukan oleh beberapa user(computer) dalam waktu yang bersamaan.  Melakukan proses menghasilkan hasil diagnosa yang dilakukan oleh beberapa computer yang dilakukan sekaligus

Completion Criteria: Waktu yang dibutuhkan untk proses penyimpanan data maupun proses penghasilan hasil diagnose tetap berjalan normal walaupun dilakukan penyimpanann data uleh beberapa user sekaligus. Special Considerations:

Confidential

Terjadi gangguan pada jaringan yang digunakan


Page 11


Version: <1.0> Date: <13/10/11>

3.1.6 Load Testing

Test Objective:

Waktu akses database dan aplikasi

Technique:

Menggunakan query yang menghasilkan data dalam jumlah besar. Mengukur waktu load aplikasi dengan berbagai macam spesifikasi computer.

Completion Criteria:

Software dan database dapat di akses dengan cepat.


Adanya gangguan pada koneksi ke database.

Confidential


Page 12


Version: <1.0> Date: <13/10/11>

3.1.7 Stress Testing

[Stress testing is a type of performance test implemented and executed to find errors due to low resources or competition for resources. Low memory or disk space may reveal defects in the target-of-test that aren't apparent under normal conditions. Other defects might results from competition for shared resource like database locks or network bandwidth. Stress testing can also be used to identify the peak workload the target-of-test can handle.] [NOTE: References to transactions below refer to logical business transactions.] Test Objective:

Verify that the target-of-test functions properly and without error under the following stress conditions: 

little or no memory available on the server (RAM and DASD)



maximum (actual or physically capable) number of clients connected (or simulated)



multiple users performing the same transactions against the same data / accounts



worst case transaction volume / mix (see performance testing above).

NOTES: The goal of Stress test might also be stated as identify and document the conditions under which the system FAILS to continue functioning properly. Stress testing of the client is described under section 3.1.11, Configuration testing. Technique:

Use tests developed for Performance Profiling or Load Testing. To test limited resources, tests should be run on single machine, RAM and DASD on server should be reduced (or limited). For remaining stress tests, multiple clients should be used, either running the same tests or complementary tests to produce the worst case transaction volume / mix.


All planned tests are executed and specified system limits are reached / exceeded without the software or software failing (or conditions under which system failure occurs is outside of the specified conditions).


Stressing the network may require network tools to load the network with messages / packets. The DASD used for the system should temporarily be reduced to restrict the available space for the database to grow. Synchronization of the simultaneous clients accessing of the same records / data accounts.

Confidential


Page 13


Version: <1.0> Date: <13/10/11>

3.1.8 Volume Testing

[Volume Testing subjects the target-of-test to large amounts of data to determine if limits are reached that cause the software to fail. Volume testing also identifies the continuous maximum load or volume the target-of-test can handle for a given period. For example, if the target-of-test is processing a set of database records to generate a report, a Volume Test would use a large test database and check that the software behaved normally and produced the correct report.] Test Objective:

Technique:

Verify that the target-of-test successfully functions under the following high volume scenarios: 

maximum (actual or physically capable) number of clients connected (or simulated) all performing the same, worst case (performance) business function for an extended period.



maximum database size has been reached (actual or scaled) and multiple queries / report transactions are executed simultaneously.

Use tests developed for Performance Profiling or Load Testing. Multiple clients should be used, either running the same tests or complementary tests to produce the worst case transaction volume / mix (see stress test above) for an extended period. Maximum database size is created (actual, scaled, or filled with representative data) and multiple clients used to run queries / report transactions simultaneously for extended periods.


All planned tests have been executed and specified system limits are reached / exceeded without the software or software failing.


What period of time would be considered an acceptable time for high volume conditions (as noted above)?

Confidential


Page 14


Version: <1.0> Date: <13/10/11>

3.1.9 Security and Access Control Testing

Test Objective:

Software hanya dapat digunakan oleh user yang telah melakukan login (melalui form login).

Technique:

 Mencoba melakukan sql injection dengan mencari kesalahan logika dalam query dan code yang di gunakan

Completion Criteria: Special Considerations:

Confidential

 Mencoba hak akses setiap user dan mencoba berbuat kecurangan dari hak akses yang di milikinya. Software tidak dapat dibobol/digunakan oleh user yang tidak memiliki hak akses -


Page 15


Version: <1.0> Date: <13/10/11>

3.1.10 Failover / Recovery Testing

[Failover / Recovery testing ensures that the target-of-test can successfully failover and recover from a variety of hardware, software, or network malfunctions with undue loss of data or data integrity. Failover testing ensures that, for those systems that must be kept running, when a failover condition occurs, the alternate or backup systems properly “take over” for the failed system without loss of data or transactions. Recovery testing is an antagonistic test process in which the application or system is exposed to extreme conditions (or simulated conditions) to cause a failure, such as device I/O failures or invalid database pointers / keys. Recovery processes are invoked and the application / system is monitored and / or inspected to verify proper application / system / and data recovery has been achieved.]

Test Objective:

Confidential

Verify that recovery processes (manual or automated) properly restore the database, applications, and system to a desired, known, state. The following types of conditions are to be included in the testing: 

Power interruption to the client



Power interruption to the server



Communication interruption via network server(s)



Interruption, communication, or power loss to DASD and or DASD controller(s)



Incomplete cycles (data filter processes interrupted, data synchronization processes interrupted).



Invalid database pointer / keys



Invalid / corrupted data element in database


Page 16

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Test Plan PRPLSAD/2011/X/1 Technique:

Version: <1.0> Date: <13/10/11>

Tests created for Function and Business Cycle testing should be used to create a series of transactions. Once the desired starting test point is reached, the following actions should be performed (or simulated) individually: 

Power interruption to the client: power the PC down



Power interruption to the server: simulate or initiate power down procedures for the server



Interruption via network servers: simulate or initiate communication loss with the network (physically disconnect communication wires or power down network server(s) / routers).



Interruption, communication, or power loss to DASD and or DASD controller(s): simulate or physically eliminate communication with one or more DASD controllers or devices.

Once the above conditions / simulated conditions are achieved, additional transactions should executed and upon reaching this second test point state, recovery procedures should be invoked.

Testing for incomplete cycles utilizes the same technique as described above except that the database processes themselves should be aborted or prematurely terminated.

Testing for the following conditions requires that a known database state be achieved. Several database fields, pointers and keys should be corrupted manually and directly within the database (via database tools). Additional transactions should be executed using the tests from Application Function and Business Cycle Testing and full cycles executed.


Confidential

In all cases above, the application, database, and system should, upon completion of recovery procedures, return to a known, desirable state. This state includes data corruption limited to the known corrupted fields, pointers / keys, and reports indicating the processes or transactions that were not completed due to interruptions.


Page 17

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Test Plan PRPLSAD/2011/X/1 Special Considerations:

Version: <1.0> Date: <13/10/11>

Recovery testing is highly intrusive. Procedures to disconnect cabling (simulating power or communication loss) may not be desirable or feasible. Alternative methods, such as diagnostic software tools may be required. Resources from the Systems (or Computer Operations), Database, and Networking groups are required. These tests should be run after hours or on an isolated machine(s).

Confidential


Page 18


Version: <1.0> Date: <13/10/11>

3.1.11 Configuration Testing Test Objective:

Hardware dan software dari requirement software dapat berjalan sesuai dengan konfigurasi yang di inginkan 1.

Technique:

Memaksimalkan penggunaan memory(ram) terhadap sistem serta penggunaan ruang simpan data. Input : melihat penggunaan memory dengan menggunakan task manager. Proses : melakukan pencatatan dan analisa penggunaan memori dan sisa ruang simpan data Output : Investasi yang dilakukan atas hardware dan software sesuai dengan manfaat yang diberikan


1. 2. 3.


Confidential

2.

Melakukan instalasi aplikasi ke operating sistem yang berbeda.

3.

Melakukan instalasi aplikasi ke komputer dengan spesifikasi yang berbeda

Aplikasi mampu berjalan pada operating sistem yang berbeda Aplikasi mampu berjalan pada computer dengan spesifikasi yang berbeda Kesesuaian data antara pengujian harware dengan software Data ini bersifat asumsi kelompok,karena keterbatasan alat banchmark yang ada


Page 19


Version: <1.0> Date: <13/10/11>

3.1.12 Installation Testing

[Installation testing has two purposes. The first is to insure that the software can be installed under different conditions, such as a new installation, an upgrade, and a complete or custom installation, and under normal and abnormal conditions. Abnormal conditions include insufficient disk space, lack of privilege to create directories, etc. The second purpose is to verify that, once installed, the software operates correctly. This usually means running a number of the tests that were developed for Function testing.]

Test Objective:

Verify that the target-of-test properly installs onto each required hardware configuration, under the following conditions (as required): New Installation, a new machine, never installed previously with Update machine previously installed , same version Update machine previously installed , older version

Technique:

Manually or develop automated scripts to validate the condition of the target machine (new - never installed, same version or older version already installed). Launch / perform installation. Using a predetermined sub-set of function test scripts, run the transactions.

Confidential


transactions execute successfully without failure.


What transactions should be selected to comprise a confidence test that application has been successfully installed and no major software components are missing?


Page 20


Version: <1.0> Date: <13/10/11>

3.2 Tools

Tool

Vendor/In-house

Microsoft SQL Server 2005

Microsoft

Version

Test Management Defect Tracking ASQ Tool testing) ASQ Tool testing)

(functional (performance

Test Coverage Monitor or Profiler Project Management DBMS tools

Confidential


Page 21


Version: <1.0> Date: <13/10/11>

4. Resources Disini di jelaskan tentang resource yang di rekomendasikan untuk melakukan testing pada Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” untuk melakukan transaksi transaksi yang ada pada Koperasi Karyawan “STIKOM Surabaya”. 4.1 Workers

Worker

Minimum Resources Specific Responsibilities/Comments Recommended (number of workers allocated full-time)

Test Manager / Test Project Manager

 Mengatasi semua kegiatan dalam proyek.  Mengetahui jalannya program  Memanajemen alur system

Test Designer

 Melakukan survey atas kebiasaan user

Tester

 Membuat test plan.  Membuat solusi atas eror yang terjadi

Test System Administrator

 Mengatur hak akses masing-masing user

Database Administration Database Manager

 Mengadministrasi data yang ada dalam database.

/

 Melakukan maintenance database  Melakukan backup pada periode tertentu

Designer

Confidential

Mengidentifikasi dan mendefinisikan operasi, atribut, dan relasi data uji. Rincian Tugas : 1. Mengidentifikasi dan mendefinisikan kelas-kelas uji 2. Mengidentifikasi dan mendefinisikan paket-paket data yang di uji.


Page 22


Implementer

Confidential

Version: <1.0> Date: <13/10/11>

Menerapkan dan menguji coba proyek yang di kembangkan Rincian Tugas : 1. Mencoba aplikasi sesuai dengan alur yang telah di buat. 2. Melakukan pencatatan atas segala kejadian yang terjadi selama penerapan


Page 23


Version: <1.0> Date: <13/10/11>

4.2 System

Berikut ini daftar tabel kebutuhan peralatan dari pelaksanaan testing. Ada beberpa bagian yang tidak terdefinisi dari pelaksanaan testing ini. Adapun yang akan di lakukan uji coba meliputis simulasi dari proses bisnis proyek, pengukuran skala proyek dan validasi data di dalam database. System Resources Resource

Name / Type

Database Server —Network/Subnet —Server Name —Database Name Client Test PC's —Include special configuration —requirements Test Repository —Network/Subnet —Server Name Test Development PC's

5. Project Milestones [Testing of should incorporate test activities for each of the test efforts identified in the previous sections. Separate project milestones should be identified to communicate project status and accomplishments.] Milestone Task

Effort

Start Date

End Date

Plan Test Design Test Implement Test Execute Test Evaluate Test

Confidential


Page 24


Version: <1.0> Date: <13/10/11>

6. Deliverables [In this section list the various documents, tools, and reports that will be created, by whom, delivered to who, and when delivered] 6.1 Test Model

[This section identifies the reports that will be created and distributed from the test model. These artifacts in the test model should be created or referenced in the ASQ tools.] 6.2 Test Logs

[Describe the method and tools used to record and report on the test results and testing status.] 6.3 Defect Reports

[In this section, identify the method and tool(s) used to record, track, and report on test incidents and their status.]

Confidential


Page 25


Version: <1.0> Date: <13/10/11>

7. Appendix A: Project Tasks Below are the test related tasks: Plan Test Identify Requirements for Test Assess Risk Develop Test Strategy Identify Test Resources Create Schedule Generate Test Plan Design Test Workload Analysis Identify and Describe Test Cases Identify and Structure Test Procedures Review and Access Test Coverage Implement Test Record or Program Test Scripts Identify Test-Specific functionality in the design and implementation model Establish External Data sets Execute Test Execute Test Procedures Evaluate Execution of Test Recover from Halted Test Verify the results Investigate Unexpected Results Log Defects Evaluate Test Evaluate Test-Case Coverage Evaluate Code Coverage Analyze Defects Determine if Test Completion Criteria and Success Criteria have been achieved

Confidential


Page 26

KELOMPOK 04. Sistem Informasi Koperasi Karyawan STIKOM Surabaya. Test Plan. Version

Recommend Documents