Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan...

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

Transcript of Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan...

Page 1: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

KELOMPOK 04

Sistem Informasi Koperasi Karyawan

“STIKOM Surabaya”

Test Plan

Version <1.0>

Page 2: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 2

Revision History Date Version Description Author

Page 3: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 3

Table of Contents

1. Introduction 4

1.1 Purpose 4 1.2 Background 4 1.3 Scope 4 1.4 Project Identification 6

2. Requirements for Test 7

3. Test Strategy 7

3.1 Testing Types 7 3.1.1 Data and Database Integrity Testing 7 3.1.2 Function Testing 7 3.1.3 Business Cycle Testing 9 3.1.4 User Interface Testing 10 3.1.5 Performance Profiling 11 3.1.6 Load Testing 12 3.1.7 Stress Testing 13 3.1.8 Volume Testing 14 3.1.9 Security and Access Control Testing 15 3.1.10 Failover / Recovery Testing 16 3.1.11 Configuration Testing 19 3.1.12 Installation Testing 20

3.2 Tools 21

4. Resources 22

4.1 Workers 22 4.2 System 24

5. Project Milestones 24

6. Deliverables 25

6.1 Test Model 25 6.2 Test Logs 25 6.3 Defect Reports 25

7. Appendix A: Project Tasks 26

Page 4: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 4

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

Page 5: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 5

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.

Page 6: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 6

1.4 Project Identification

sDocument

(and version / date)

Created or

Available

Received or

Reviewed

Author or

Resource

Notes

Requirements

Specification

Yes No Yes No

Functional Specification Yes No Yes No

Use Case Reports Yes No Yes No

ERD Reports Yes No Yes No

Project Plan Yes No Yes No

Design Specifications Yes No Yes No

Prototype Yes No Yes No

Users Manuals Yes No Yes No

Business Model / Flow Yes No Yes No

Data Model / Flow Yes No Yes No

Business Functions and

Rules

Yes No Yes No

Project / Business Risk

Assessment

Yes No Yes No

Page 7: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 7

2. Requirements for Test

Testing akan dilakukan pada Entity Relational Diagram(untuk mengidentifikasi table-

tabel 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

Page 8: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 8

Special

Considerations:

-

Page 9: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 9

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:

-.

Page 10: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 10

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:

-

Page 11: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 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:

Terjadi gangguan pada jaringan yang digunakan

Page 12: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 12

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.

Special Considerations: Adanya gangguan pada koneksi ke database.

Page 13: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 13

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.

Completion Criteria: 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).

Special Considerations: 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.

Page 14: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 14

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: 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.

Technique: 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.

Completion Criteria: All planned tests have been executed and specified system limits are reached /

exceeded without the software or software failing.

Special Considerations: What period of time would be considered an acceptable time for high volume

conditions (as noted above)?

Page 15: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 15

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

Mencoba hak akses setiap user dan mencoba berbuat

kecurangan dari hak akses yang di milikinya.

Completion Criteria: Software tidak dapat dibobol/digunakan oleh user yang

tidak memiliki hak akses

Special Considerations: -

Page 16: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 16

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: 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 17: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 17

Technique: 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.

Completion Criteria: 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 18: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 18

Special Considerations: 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).

Page 19: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 19

3.1.11 Configuration Testing

Test Objective: Hardware dan software dari requirement software dapat

berjalan sesuai dengan konfigurasi yang di inginkan

Technique: 1. 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

2. Melakukan instalasi aplikasi ke operating sistem yang

berbeda.

3. Melakukan instalasi aplikasi ke komputer dengan spesifikasi

yang berbeda

Completion Criteria: 1. Aplikasi mampu berjalan pada operating sistem yang berbeda

2. Aplikasi mampu berjalan pada computer dengan spesifikasi yang

berbeda

3. Kesesuaian data antara pengujian harware dengan software

Special Considerations: Data ini bersifat asumsi kelompok,karena keterbatasan alat

banchmark yang ada

Page 20: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 20

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 <Project Name>

Update machine previously installed <Project Name>, same

version

Update machine previously installed <Project Name>, older

version

Technique: Manually or develop automated scripts to validate the

condition of the target machine (new - <Project Name> never

installed, <Project Name> same version or older version

already installed).

Launch / perform installation.

Using a predetermined sub-set of function test scripts, run the

transactions.

Completion Criteria: <Project Name> transactions execute successfully without

failure.

Special Considerations: What <Project Name> transactions should be selected to

comprise a confidence test that <Project Name> application

has been successfully installed and no major software

components are missing?

Page 21: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 21

3.2 Tools

Tool Vendor/In-house Version

Test Management

Defect Tracking

ASQ Tool (functional

testing)

ASQ Tool (performance

testing)

Test Coverage Monitor or

Profiler

Project Management

DBMS tools Microsoft SQL Server 2005 Microsoft

Page 22: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 22

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

Recommended

(number of workers

allocated full-time)

Specific Responsibilities/Comments

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 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 23: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 23

Implementer 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 24: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 24

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 <Project Name> 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

Page 25: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 25

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.]

Page 26: Sistem Informasi Koperasi Karyawan · PDF fileKELOMPOK 04 Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” Test Plan Version

Sistem Informasi Koperasi Karyawan “Stikom Surabaya” Version: <1.0>

Test Plan Date: <13/10/11>

PRPLSAD/2011/X/1

Confidential © Kelompok 04 PRPL, 2011 Page 26

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