sistem informasi koperasi karyawan · pdf filekelompok 04 sistem informasi koperasi karyawan...
Post on 30-Jan-2018
227 Views
Preview:
TRANSCRIPT
KELOMPOK 04
Sistem Informasi Koperasi Karyawan
“STIKOM Surabaya”
Test Plan
Version <1.0>
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
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
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
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.
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
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
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:
-
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:
-.
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:
-
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
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.
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.
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)?
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: -
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
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.
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).
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
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?
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
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.
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
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
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.]
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
top related