Hasil Kerja Tim Pengujian Perangkat Lunak

Hasil kerja pengujian berupa dokumen yang dibagikan kepada pemangku kepentingan selama pengembangan perangkat lunak. Bagian ini membahas hal berikut.

Buka Diagram Ukuran Penuh ↗

Hasil Kerja Tim Pengujian Perangkat Lunak

• Strategi Pengujian Perangkat Lunak
• Rencana Pengujian Perangkat Lunak
• Skenario dan Kasus Uji Perangkat Lunak
• Metrik Pengujian Perangkat Lunak
• Metrik Produk
• Metrik Proses
• Dokumentasi Pengujian Perangkat Lunak
• Laporan Pengujian Perangkat Lunak
• Laporan Status Pengujian Harian
• Laporan Insiden
• Laporan Akhir Penutupan Pengujian

Strategi Pengujian Perangkat Lunak

Strategi pengujian memberikan arah bagi kegiatan pengujian proyek. Bagi pekerjaan menjadi proses yang lebih kecil dan didefinisikan dengan jelas. Strategi membantu tim memperkirakan waktu, upaya, dan sumber daya yang diperlukan, serta mendukung perencanaan, pengelolaan, dan pemantauan kemajuan.

Rencana Pengujian Perangkat Lunak

Rencana pengujian menetapkan strategi umum, lingkungan, dan tingkat pengujian. Rencana itu menjelaskan cara menganalisis hasil dan metrik yang akan digunakan. Rencana juga mencatat kriteria penyelesaian setiap tahap serta perkiraan upaya dan biaya pengujian.

Buka Diagram Ukuran Penuh ↗

Rencana Pengujian Perangkat Lunak

Skenario dan Kasus Uji Perangkat Lunak

Skenario pengujian menggambarkan situasi hipotesis untuk menilai perangkat lunak secara terstruktur. Skenario dapat serumit sebuah cerita. Kasus uji langsung menjelaskan tindakan yang harus dilakukan, masukan yang harus diberikan, dan keluaran yang diharapkan. Kasus uji biasanya berupa pernyataan satu baris, sedangkan skenario memberi penguji situasi yang lebih luas untuk ditelusuri.

Buka Diagram Ukuran Penuh ↗

Skenario dan Kasus Uji Perangkat Lunak

Pada 2003, Cem Kaner menjelaskan pengujian berbasis skenario sebagai cara untuk menelusuri situasi yang realistis. Kasus uji terperinci tetap mencatat langkah, data masukan, dan hasil yang diharapkan. Memelihara rincian tersebut dapat membutuhkan lebih banyak upaya.

Kasus uji memberi tahu penguji secara langsung apa yang harus dilakukan dan bagaimana menguji perangkat lunak.

Buka Diagram Ukuran Penuh ↗

Skenario dan Kasus Uji Perangkat Lunak

Metrik Pengujian Perangkat Lunak

Metrik perangkat lunak adalah satuan pengukuran untuk menilai suatu karakteristik perangkat lunak. Metrik pengujian menilai kualitas dan menunjukkan kesiapan sistem selama pengembangan. Mengapa perlu mengukur? Kita hanya dapat memperbaiki hal yang dapat diukur karena hal itu bisa dikendalikan. Keputusan pada setiap tahap pengembangan dibuat setelah meninjau metrik tahap sebelumnya. Metrik pengujian terbagi menjadi dua kelompok.

1. Ukuran langsung, atau metrik dasar, adalah data mentah yang dikumpulkan analis pengujian untuk menunjukkan status proyek, misalnya jumlah kasus uji yang dibuat atau dijalankan.
2. Ukuran tidak langsung, atau metrik terhitung, mengubah data dasar menjadi informasi proyek yang lebih berguna, misalnya persentase pekerjaan yang selesai atau persentase cakupan pengujian.

Metrik Produk

Metrik produk mengarahkan peningkatan kualitas. Evaluasi berkala membantu tim menemukan karakteristik produk yang perlu diperbaiki pada waktunya. Metrik ini mengukur aspek berikut.

• Ukuran
• Kompleksitas
• Aspek desain
• Kinerja
• Kualitas

Metrik Proses

Metrik proses menunjukkan peluang memperbaiki cara kerja untuk menghemat waktu dan tenaga. Bandingkan hasil dengan target proses untuk menilai kemajuan. Pemantauan kegiatan pengujian dapat meningkatkan efisiensi dan efektivitas proyek. Dalam pengembangan perangkat lunak, metrik proses mencakup bidang berikut.

• Pengembangan Perangkat Lunak
• Pemeliharaan Perangkat Lunak
• Pengujian Perangkat Lunak

Dokumentasi Pengujian Perangkat Lunak

Dokumentasi pengujian mencatat kegiatan sebelum atau selama pengujian. Dokumen penting meliputi hal berikut.

• Rencana Pengujian
• Skenario Pengujian
• Kasus Uji
• Matriks Ketertelusuran

Laporan Pengujian Perangkat Lunak

Laporan berikut mendukung pekerjaan pengujian.

• Laporan Status Pengujian Harian
• Laporan Insiden
• Laporan Akhir Penutupan Pengujian

Laporan Status Pengujian Harian

Laporan status harian memberi informasi kepada tim pengujian serta pemangku kepentingan proyek dan program. Manajer proyek dapat melihat jumlah cacat harian, kasus yang dijalankan, dan pekerjaan setiap penguji. Jawab pertanyaan berikut.

1. Berapa banyak kasus uji yang direncanakan untuk hari itu?
2. Berapa banyak yang dijalankan?
3. Berapa banyak cacat yang dilaporkan tim?
4. Berapa banyak cacat yang bersifat kritis?
5. Di mana laporan terperinci, termasuk lembar cacat dan pelaksanaan pengujian, dapat ditemukan?

Laporan Insiden

Laporan insiden membantu mengoordinasikan pengujian dan pengembangan. Pengelolaan insiden mencatat hal berikut.

• Perbandingan antara hasil aktual dan hasil yang diharapkan
• Alasan penyimpangan pada pengujian yang gagal, seperti otomatisasi yang rusak, kasus uji yang tidak tepat, atau kegagalan perangkat lunak yang nyata

Jika terjadi kegagalan nyata, siapkan laporan insiden. Sertakan rincian berikut.

• Identifikasi
• Apa ID setiap laporan?
• Apa objek yang diuji?
• Versi Aplikasi Perangkat Lunak yang Diuji
• Rincian lingkungan pengujian, termasuk perangkat keras dan perangkat lunak
• Nama pengembang yang perlu menilai dan menyelesaikan insiden
• Kapan kegagalan diamati?
• Klasifikasi
• Status
• Tingkat Keparahan
• Prioritas
• Persyaratan
• Penyebab
• Deskripsi Masalah
• Uraian masalah
• Rincian kasus uji
• Komentar penguji
• Komentar pengembang setelah perubahan
• Referensi jika ada

Laporan Akhir Penutupan Pengujian

Pemimpin pengujian membuat laporan penutupan proyek ketika kriteria penyelesaian terpenuhi atau pengujian selesai. Pemangku kepentingan dan klien kemudian meninjaunya. Sertakan kasus uji yang berhasil dijalankan dan cacat yang masih terbuka serta dijadwalkan untuk diperbaiki setelah penerapan.