Pengujian Perangkat Lunak Secara Sistematis:Menyatukan Proses,Orang,Dan Teknologi

Mengapa Pengujian Perangkat Lunak Itu Sulit?

Banyak orang menganggap bahwa pengujian hanyalah aktivitas sederhana: jalankan program, jika ada yang salah maka itu bug. Namun, kenyataannya jauh lebih kompleks. Beberapa alasan utama mengapa pengujian sulit adalah:

• Kebutuhan tidak jelas atau ambigu: Sering kali requirement ditulis secara samar, membuat pengujian jadi subjektif.

• Waktu terbatas: Testing sering "disisakan" di akhir proyek, mengakibatkan pengujian dilakukan tergesa-gesa.

• Lingkungan kompleks: Banyak software bekerja dalam ekosistem yang kompleks, seperti cloud, integrasi API, perangkat mobile, dll.

• Politik organisasi: Tester harus melaporkan hasil yang mungkin tidak disukai manajer atau developer.

Seperti kata salah satu case study dari buku: "Saya harus menguji dengan spesifikasi yang buruk, deadline mepet, dan tim yang belum terlatih---tapi produk tetap harus sempurna."

Preventive Testing: Ubah Testing dari Biaya Menjadi Investasi

Pengujian sistematis tidak hanya mendeteksi bug---tetapi menghindarinya sebelum muncul. Ini dikenal sebagai preventive testing, yang menempatkan pengujian sebagai proses rekayasa sejak tahap requirement.

Manfaat Preventive Testing:

• Menghindari rework yang mahal (perbaikan kode, redesign, dll.)

• Menemukan kesalahan dalam requirement sebelum masuk ke coding.

• Memberi umpan balik awal ke analis bisnis dan desainer.

• Membantu dokumentasi karena test case dibangun sejak awal.

Testware: Produk Nyata dari Proses Pengujian

Salah satu konsep penting dalam buku ini adalah testware. Testware adalah segala artefak yang dihasilkan selama proses pengujian, seperti:

• Test Plan (rencana pengujian)

• Test Case (kasus uji)

• Test Procedure (langkah eksekusi)

• Test Log (log hasil uji)

• Incident Report (laporan kejadian/bug)

• Test Summary Report (ringkasan hasil pengujian)

Testware adalah untuk testing seperti halnya kode untuk software.
Tanpa testware, proses pengujian tidak terstruktur dan sulit direplikasi atau dievaluasi.

 Pendekatan Berbasis Risiko (Risk-Based Testing)

Buku ini juga menekankan pentingnya Risk Analysis sebagai dasar dalam menyusun strategi pengujian. Pengujian tidak boleh dilakukan secara serampangan---semuanya harus didasarkan pada tingkat risiko yang dihadapi.

Langkah-langkah Risk-Based Testing:

1. Identifikasi risiko (kegagalan sistem, kerugian bisnis, ketidakpatuhan hukum, dll).

2. Nilai kemungkinan & dampaknya.

3. Prioritaskan area pengujian berdasarkan risiko.

4. Tentukan strategi pengujian berdasarkan ranking risiko.

"Jika tidak menyerang risiko secara aktif, maka risiko yang akan menyerang kita." -- Tom Gilb

Organisasi Tim Pengujian

Tidak hanya teknik, buku ini juga membahas struktur organisasi tim pengujian. Faktor manusia sangat penting dalam keberhasilan pengujian. Ditekankan adanya empat peran kunci dalam proses STEP:

tabel 1.1

Pada proyek kecil, satu orang bisa memegang semua peran ini. Namun, pada proyek skala besar, pemisahan peran sangat disarankan demi efisiensi dan kejelasan tanggung jawab.

Siklus Hidup Pengujian (Testing Lifecycle)

Dalam model STEP, pengujian memiliki daur hidup yang mirip seperti pengembangan software:

1. Planning -- Menyusun strategi pengujian

2. Analysis -- Mengumpulkan requirement dan tujuan pengujian

3. Design -- Mendesain test set dan arsitektur pengujian

4. Implementation -- Membangun test case, data, environment

5. Execution -- Menjalankan test case

6. Evaluation -- Mengevaluasi hasil dan proses pengujian

7. Maintenance -- Memperbarui testware untuk versi baru

Ini berbeda dengan model konvensional di mana testing baru dimulai setelah coding selesai.

Dokumentasi Berbasis IEEE

Penulis sangat menyarankan mengikuti IEEE Std. 829-1998 dalam membuat dokumen pengujian. Ini mencakup:

• Struktur dokumen standar

• Format log

• Cara melaporkan bug dan hasil uji

• Kriteria kelulusan

Dengan dokumentasi yang rapi dan standar, komunikasi antar tim menjadi lebih efektif dan profesional.

 Evaluasi Proses Pengujian

Bukan hanya hasil uji yang dievaluasi, tapi juga proses pengujian itu sendiri. Pertanyaan seperti:

• Apakah coverage sudah optimal?

• Apakah ada test case yang tumpang tindih?

• Apakah waktu testing terlalu mepet?

• Apakah bug ditemukan di fase yang seharusnya?

Melalui proses evaluasi ini, pengujian dapat terus ditingkatkan seiring waktu.

Buku Systematic Software Testing adalah peta jalan bagi siapa pun yang ingin membangun proses pengujian profesional. Dengan mengadopsi pendekatan STEP, organisasi dapat:

• Menemukan bug lebih awal dan murah.

• Menyusun test case yang efektif dan efisien.

• Meningkatkan dokumentasi dan komunikasi.

• Menjadikan pengujian sebagai proses rekayasa, bukan sekadar formalitas.

"Testing bukan hanya tentang mencari kesalahan---testing adalah seni membangun kepercayaan bahwa software kita benar."

Referensi 

Craig, Rick D., & Jaskiel, Stefan P. (2002).
Systematic Software Testing.
Artech House Publishers. ISBN: 1-58053-508-9.

Hetzel, Bill. (1988).
The Complete Guide to Software Testing (2nd Edition).
Wiley.

Gelperin, David, & Hetzel, Bill.
The Systematic Test and Evaluation Process (STEP): An Introduction and Summary Guide.
Software Quality Engineering.

IEEE Std 829-1998.
IEEE Standard for Software Test Documentation.
Institute of Electrical and Electronics Engineers.

IEEE Std 610.12-1990.
IEEE Standard Glossary of Software Engineering Terminology.
IEEE Computer Society.

McConnell, Steve. (1996).
Rapid Development: Taming Wild Software Schedules.
Microsoft Press.

Gilb, Tom. (1993).
Principles of Software Engineering Management.
Addison-Wesley.

Myers, Glenford J. (1979).
The Art of Software Testing.
Wiley.

Leveson, Nancy G., & Turner, Clark S. (1993).
An Investigation of the Therac-25 Accidents.
IEEE Computer, 26(7), 18--41.