TESTING 2

II. Test Plan


II. 1. Alasan menulis test plan yaitu :
 Usaha yang dibutuhkan dalam test proyek
 Memberikan budget
 Sebagai sumber komitmen dan jadwal
 Penjelasan dalam mengatur test proyek
 Perbedaan antara test plan dan test suite adalah pada soal perbedaan strategi dengan taktik.
 Strategi terdiri dari seluruh rencana untuk mencari dan mengidentifikasikan sebanyak mungkin bug-bug yang ada
 Taktik merupakan langkah spesifik yang bisa kita ambil untuk melakukan test pengujian.
II.2. Macam/Jenis Test Plan
 Different time periods.
* Jika perkembangan test dan eksekusi test untuk subproject awal dan akhir pada perbedaan tanggal
* Informasi dibutuhkan pada rencana subproject yang lebih awal sebelum informasi pada subproject berikutnya.
 Different Methodologis.
* Diskusi yang rinci dari pengubahan kode rata-rata
* Platform yang bebas diotomatiskan dengan alat tes GUI yang tidak bekerja bersamaan.
 Different Objectives
* Menyelesaikan 3 tujuan yang berbeda
* Tujuan tersebut yaitu
• Mencari bug-bug dalam unit fungsi
• Mengetes integrasi dari unit fungsi dan
• Mengecek fungsi bisnis dari integrasi keseluruhan.
 Different Audiences
* Test plan tidak hanya memberitahukan pada teman, penguji dan manajer dari visi, itu hanya kesempatan untuk menemukan kesempurnaan.
* Input ini khususnya berguna untuk memberikan ide bagaimana fokus pada test.
II.3. Penggunaan draft untuk menstimulasi diskusi
 Menggunakan penyangga pada perencanaan untuk mengindikasi pertanyaan dan membuka persoalan.
 Menggunakan “Copping Out”, identifikasi dan dokumentasi untuk membuka persoalan, lebih digunakan pada aspek perencanaan latihan.
 Menggunakan beberapa perkiraan waktu tentang masalah yang timbul.
 Test plan terdiri dari notasi yang luas dengan masalah yang dapat diputuskan atau persoalan yang menunggu resolusi.
II.4. Test Plan Tempelete
 Model yang digunakan bagi pengembangan test plan.
 Model ini bukan merupakan alat pemotongan dan penyalinan suatu test plan dalam waktu yang singkat.
 Suatu kumpulan rancangan logis dari topik-topik yang perlu dipertimbangkan dengan hati-hati dalam pengujian.
II.4.1. Overview
 Bagian keseluruhan dari sebuah test plan memungkinkan untuk memperkenalkan rencana pendekatan test.
 Menampilkan sebuah penjelasan yang jelas dari sasaran-sasaran, metodologi, dan tujuan-tujuan .
II.4.2. Bound, (mengatur batasan-batasan perencanaan test )
 Mendiskusikan apa yang akan atau tidak akan diujikan.
 Mendefinisikan istilah-istilah dan akronim (lawan kata) yang penting yang berhubungan dengan ujian.
 Menentukan dimana usaha-usaha tes yang berhubungan dengan pelaksanaan proyek pendukung test ini.
II.4.3. Scope
 Bila ingin menjelaskan secara terperinci ruang lingkup dari proyek, maka harus menggambar batasan yang memisahkan antara apa saja yang akan diperhatikan selama pelaksanaan proyek.



























Contoh Test Plan Tempelete
 Menggunakan tabel “Ya/Tidak” untuk mendefinisikan ruang lingkup pengetesan.






II.4.4. Definisi
 Tabel dapat membantu memperjelas istilah/terminologi bagi yang tidak berpengalaman dalam bidang testing.
 Membantu memastikan bahwa setiap orang dalam kelompok penguji bekerja dengan menggunakan kumpulan definisi yang sama.
II.4.5. Setting
 Bagian rencana test menjelaskan keinginan untuk melakukan testing, dan penjelasan tersebut sangat sederhana.
 Adanya pertimbangan untuk menampilkan tabel yang menunjukkan bagaimana pekerjaan yang akan dialokasikan.
 Misalnya : laboratorium test.
II.4.6. Quality Risk
 Menyimpan hasil proses test plan dalam bentuk referensi.
 Bila user ingin membaca outline kualitas resiko proses test plan atau diagram FMEA.
II.4.7. Proposed Schedule of Miliestones
 Rencana harus terdiri dari jadwal kegiatan yang akan dilakukan pada test proyek.
 Difokuskan pada kegiatan yang mempunyai level tinggi dan pengiriman yang visible pada manajemen.
 Misalnya : jadwal untuk Speedy Writer.
Milestone/effort Date
Test Deveolopment and Configurations
Test Plan Complete 8/9/2003
Test Lab Defined 8/12/2003
Test Lab Configured 8/26/2003
FMEA Complete 8/16/2003
Test Suite Complete 9/5/2003
Test Execution
System test entry 9/2/2003
Cycle 1 9/2/2003 - 9/16/2003
Cycle 2 9/19/2003 - 10/3/2003
Cycle 3 10/6/2003 - 10/13/2003
System test exit 10/13/2003
Skedul Test Sistem milestones

II.4.8. Transitions
 Untuk tiap fase, system dibawah test harus memenuhi minimal 1 set kualifikasi sebelum test organisasi mendapat keuntungan dalam test execution.
 Bagian test plan harus menunjukkan criteria yang esensial untuk permulaan dan kelengkapan fase test yang berbeda.
 Ada 3 set criteria yang biasa digunakan yaitu : Entry, Exit, Stopping criteria.
* Entry Criteria, Kriteria masukan memungkinkan system untuk pindah kedalam fase test khusus. Ada beberapa alamat pertanyaan dalam criteria ini yaitu :
• Apakah perlu ada dokumentasi, spesifikasi, dan syarat yang memungkinkan tester mengoperasikan system dan menilai kebenaran reaksi?
• Apakah system siap untuk pengiriman dan bentuk apa saja yang cocok untuk pertanyaan fase test?
• Apa ada kegunaan dukungan, aksesoris, dan prasyarat dalam bentuk tester yang digunakan?
• Apa system pada mutu level cocok? Tiap pertanyaan biasanya mengimplementasi beberapa atau semua fase test yang telah diselesaikan dengan sukses.
• Apa test environment_lab, hardware,software, dan system pendukung administrasi siap?
* Stopping criteria
• Kriteria penundaan memberikan kondisi atau event yang menunda test execution.
• Contohnya : test environment menjadi tidak siap, system mempunyai banyak bug, tidak bisa melanjutkan testing.
* Exit criteria, alamat criteria keluaran menunjukkan bagaimana menentukan kapan testing telah selesai dan lengkap.
II.4.9. Test Configurations & Environments
 Dokumen dimana hardware, software dan jaringan dan ruang lab akan menggunakan pekerjaan testing.
 Untuk aplikasi PC atau kegunaannya, task ini dapat menyederhanakan hardware maupun software dari waktu ke waktu.
 Sistem testing dengan element hardware yang signifikan (laptop baru atau server), 1 dengan banyak elemen hardware (jaringan system operasi atau jaringan aplikasi), atau 1 dengan elemen hardware yang mahal (mainframe, server cluster).
 Membentuk skema untuk alokasi hardware dalam sebagian lokasi, bagian test plan, atau pemisahan dokumen.
II.4.10. Test Execution
 Alamat test plan merupakan factor yang penting untuk mempengaruhi test execution.
 Menjalankan test cycle yang berbeda dalam tiap fase test.
 Dalam menjalankan test, kita dapat mengumpulkan data dan melacak dengan cara memperlihatkan pada team dan manajer.
Test Usage System Network When Where Other
Product Test
Component Interfaces/ Signal Quality Engr Proto [2] Novell, NFS, NT 9/15-10/15 Engr. Lab MS Mouse, MS Kbd, VGA Mon, USB Mouse, USB Mon, USB Kbd, 3COM LAN, USR Mdm, Epson Prn, Quantum HD, Oscilloscope
Mechanical Life Engr Proto [2] None 8/1-10/1 Engr. Lab None
Stress, Capacity, Volume Engr Proto [1] Novell, NFS, NT 9/15-10/15 Test Lab MS Mouse, VGA Mon
Performance Engr Proto [1] Novell, NFS, NT 9/15-10/15 Test Lab MS Mouse, MS Kbd, VGA Mon, Quantum HD, IBM HD
System Test
MTBF Demonstration Vld Proto [4] Novell 10/17-1/17 Engr. Lab MS Mouse, MS Kbd, VGA Mon, MUX
Functionality Vld Proto [2] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, MS Kbd, VGA Mon, USB Mouse, USB Mon, USB Kbd, USR Mdm, Epson Prn, ISDN T. Adptr
Stress, Capacity, Volume Vld Proto [1] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, VGA Mon
Performance Vld Proto [1] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, MS Kbd, VGA Mon, Quantum HD, IBM HD
Compatibility Vld Proto [3] N/A 10/24-12/1 System Cookers MS Mouse [3], MS Kbd [3], VGA Mon [3]
Environmental Vld Proto [2] N/A 10/24-12/1 System Cookers MS Mouse [2], MS Kbd [2], VGA Mon [2]
Contoh Alokasi dari Hardware

 Resources/Key Participans
* Mengganti alat, system, software, hardware, jaringan dan sumber lain yang dibutuhkan.
* Menemukan beberapa overlap dengan bagian rencana yang mencakup test organisasi.
 Tracking and management of Test and Bugs
* System membantu melacak dan menangani test execution dan bug yang ditemukan sebelum proses.
* Test tracking mengacu pada daftar yang digunakan untuk menangani semua test case dalam test dan cara meningkatkan dokumen pada pendaftaran (listing).
 Bug Isolation and Classification
* Test plan harus menjelaskan tingkatan perencanaan isolasi bug dan metode yang digunakan pada klasifikasi bug report.
* Isolasi bug report berarti percobaan dengan system undertest dengan upaya menemukan variable yang dihubungkan, causal dan hal lainnya.
* Klasifikasi bug report yaitu :
• Requirement Failure, bug report tentang kesalahan system pada persyaratan.
• Nonrequirement Failure, bug report tidak dipenuhi oleh system requirement, tetapi mencegah kegunaan system.
• Waiver Requested, bug report memang memberikan kesalahan, tetapi developer meminta waiver karena mereka percaya bahwa masalah tidak akan mencegah kegunaan system.
• External Failure, alamat bug report salah dibangun dari factor atau factor eksternal atau dibawah control system penanganan test.
• Internal Failure, developer percaya bahwa test dikembalikan dalam keadaan invalid error.
 Release Management
* Komponen software atau hardware baru harus mempunyai nomor revisi atau melampirkan identifikasi.
* Harus ada perhitungan pada penerimaan release baru dalam format yang pasti.
* Menunjukkan tiap fase test, proses khusus dan format pengiriman release baru.
* Software dan hardware akan menerima revisi baru dari pertengahan siklus test.
 Test Cycles
* Test cycle biasanya berhubungan dengan release dari system undertest, misalnya membangun sebuah software atau motherboard.
* Tiap-tiap bagian dari siklus biasanya melibatkan release baru dari satu atau lebih komponen dalam system.
* Bagian dari perencanaan test sebaiknya dikeluarkan dengan asumsi yang khusus.
II.4. 11. Risk And Contingencies
 Adanya penambahan perkembangan pendukung untuk debugging jika nomor yang diterima dari bug ditemukan.
 Memasukkan suatu informasi ketika mendiskusikan penundaan criteria.


II.4.12. Change History
 Bagian perubahan dokumen record dan revisi dibuat untuk perencanaan test.
 Menandai nomor revisi dan record dari pembuat perubahan, apa yang telah diubah dan kapan revisi telah direlease.
II.4.13. Referenced Docoment
Sebagai suatu aturan, perencanaan dari test yang ditunjukkan pada dokumen lain seperti spesifikasi, persyaratan, susunan test, beberapa dokumen analisis, dan kegunaan informasi lainnya.

II.5. Selling The Plan
 Menggunakan pendekatan pengambilan sebuah formal sign_off sheet pada perencanaan atau pendekatan yang memiliki rapat ulang dengan semua manajer yang terlibat.
 Menyediakan extra hard copy dari perencanaan untuk audience yang pelupa.
 Setelah review, membuat permintaan perubahan pada dokumen dan mensirkulasikannya lagi yang ditandai dengan “Release Execution” atau “Release 1.0”.