MATERI PERKULIAHAN - PERTEMUAN 1
Pengantar Verifikasi & Validasi (V&V) dan Siklus STLC
Dari pertanyaan kualitas menuju proses pengujian yang terstruktur
Program Studi Teknik Informatika (S1) | 2 SKS
Orientasi Pertemuan
| Gagasan utama: kualitas perangkat lunak tidak muncul hanya karena kode berhasil dijalankan. Kualitas dibangun melalui bukti bahwa produk dikembangkan dengan benar dan bahwa produk yang dihasilkan memang menyelesaikan kebutuhan pengguna. |
Pertemuan pertama menempatkan verifikasi, validasi, dan pengujian dalam satu kerangka kerja. Mahasiswa diajak melihat hubungan antara kebutuhan, desain, kode, aktivitas evaluasi, serta keputusan rilis. Kerangka ini menjadi fondasi bagi topik-topik selanjutnya, mulai dari inspeksi dan metrik defek sampai UAT, exploratory testing, otomasi, dan pemanfaatan Generative AI.
Capaian pembelajaran pertemuan
- Menjelaskan makna verifikasi dan validasi serta membedakan fokus keduanya.
- Menghubungkan aktivitas V&V dengan Waterfall, V-Model, Spiral, dan Agile/Scrum.
- Menguraikan fase Software Testing Life Cycle (STLC), artefak utama, serta kriteria masuk dan keluar.
- Menyusun alur STLC sederhana dan traceability awal menggunakan Draw.io atau kakas pemodelan UML.
- Menganalisis sebuah perubahan kebutuhan dan menentukan kapan verifikasi, validasi, serta pengujian ulang perlu dilakukan.
Posisi terhadap CPMK
Materi ini terutama mendukung CPMK 3 melalui kemampuan menilai proses konstruksi perangkat lunak, serta CPMK 4 melalui kemampuan memastikan solusi sesuai dengan kebutuhan pengguna. Penggunaan Draw.io/UML Modeling Tools menjadi pengantar keterampilan pemodelan yang mendukung CPMK 2.
1. Mengapa V&V Diperlukan?
Perangkat lunak dapat gagal dalam dua cara besar. Pertama, tim membangun produk secara ceroboh sehingga implementasi menyimpang dari spesifikasi. Kedua, tim membangun spesifikasi dengan sangat rapi, tetapi spesifikasi tersebut tidak mewakili kebutuhan nyata pengguna. V&V menangani kedua risiko itu secara saling melengkapi.
Defect (cacat): ketidaksempurnaan pada artefak, misalnya kebutuhan ambigu, rumus desain keliru, atau kondisi kode yang salah.
Failure (kegagalan): perilaku sistem yang teramati dan tidak sesuai dengan hasil yang diharapkan ketika perangkat lunak dijalankan.
Error (kesalahan manusia): tindakan manusia yang dapat memasukkan defect ke dalam kebutuhan, desain, kode, data, atau prosedur.
| Prinsip biaya kualitas: semakin awal ketidaksesuaian ditemukan, semakin kecil dampak perubahan terhadap artefak lain, jadwal, dan keputusan rilis. |
2. Verifikasi dan Validasi: Dua Pertanyaan Kunci
| Verifikasi | Validasi |
|---|---|
| Pertanyaan: Are we building the product right? | Pertanyaan: Are we building the right product? |
| Fokus pada kesesuaian artefak dengan spesifikasi, standar, dan aturan proses. | Fokus pada kesesuaian solusi dengan kebutuhan, konteks, dan harapan pengguna. |
| Objek: kebutuhan, desain, kode, konfigurasi, dokumentasi. | Objek: perilaku produk, alur bisnis, pengalaman dan penerimaan pengguna. |
| Contoh: review kebutuhan, inspeksi desain, static analysis, code review. | Contoh: pengujian sistem, UAT, prototipe, evaluasi usability. |
| Banyak aktivitas dapat dilakukan tanpa menjalankan perangkat lunak. | Sering memerlukan eksekusi produk atau representasi yang dapat dievaluasi pengguna. |
Perbedaan tersebut bukan berarti verifikasi selalu statis dan validasi selalu dinamis. Keduanya adalah tujuan evaluasi. Teknik yang dipakai dapat bervariasi, dan satu kegiatan kadang memberi bukti untuk keduanya. Sebagai contoh, demonstrasi sprint dapat memvalidasi kebutuhan pengguna sekaligus memverifikasi bahwa acceptance criteria telah dipenuhi.
Contoh terpadu: fitur batas transfer
Sebuah aplikasi perbankan memiliki kebutuhan: transaksi di atas Rp10.000.000 memerlukan otorisasi tambahan. Tim dapat melakukan:
- Verifikasi kebutuhan: apakah istilah 'di atas' berarti > Rp10.000.000, bukan >= Rp10.000.000? Apakah otorisasi tambahan didefinisikan?
- Verifikasi desain dan kode: apakah aturan bisnis dipetakan ke komponen yang tepat dan diterapkan konsisten?
- Validasi solusi: apakah mekanisme otorisasi dapat dipahami pengguna, sesuai alur operasional, dan memenuhi tujuan pengendalian risiko?
- Pengujian: jalankan kasus Rp9.999.999, Rp10.000.000, dan Rp10.000.001 untuk mengamati perilaku aktual.
3. V&V Sepanjang Siklus Hidup Perangkat Lunak
V&V bukan fase tunggal setelah coding. Aktivitasnya berubah mengikuti model pengembangan, tetapi prinsip dasarnya sama: setiap artefak penting perlu dinilai, dan setiap klaim kualitas perlu didukung bukti.
| Model | Implikasi bagi V&V dan pengujian |
|---|---|
| Waterfall | Artefak dan fase cenderung berurutan. Perencanaan pengujian perlu dimulai sejak kebutuhan, tetapi eksekusi besar sering terjadi setelah implementasi. |
| V-Model | Setiap tahap pengembangan dipasangkan dengan level pengujian: kebutuhan dengan acceptance test, desain sistem dengan system test, arsitektur dengan integration test, dan desain modul dengan unit test. |
| Spiral | Setiap putaran menekankan analisis risiko, prototipe, evaluasi, dan keputusan untuk melanjutkan. Strategi pengujian diprioritaskan berdasarkan risiko. |
| Agile/Scrum | V&V berlangsung dalam iterasi pendek. Acceptance criteria, automated tests, review, exploratory testing, dan feedback pengguna menjadi bagian dari setiap sprint. |
V-Model sebagai peta hubungan
V-Model membantu mahasiswa melihat bahwa rancangan pengujian dapat dimulai sebelum kode selesai. Sisi kiri mendefinisikan dan merinci sistem; dasar V berisi implementasi; sisi kanan mengintegrasikan dan menguji sistem terhadap artefak yang dipasangkan.
- User requirements <-> acceptance testing
- System requirements <-> system testing
- Architecture/design <-> integration testing
- Module design <-> unit testing
| Catatan penting: V-Model bukan alasan untuk menunda pengujian. Nilai utamanya adalah perencanaan test basis, test conditions, dan acceptance criteria sedini mungkin. |
4. Software Testing Life Cycle (STLC)
STLC adalah rangkaian aktivitas terstruktur untuk merencanakan, merancang, menyiapkan, melaksanakan, mengevaluasi, dan menutup pekerjaan pengujian. Nama dan jumlah fase dapat berbeda antarorganisasi, tetapi alur berikut cukup representatif untuk pembelajaran awal.
| Fase | Fokus aktivitas | Artefak utama |
|---|---|---|
| 1. Analisis kebutuhan | Menentukan test basis, risiko, jenis pengujian, bagian yang dapat diuji, dan pertanyaan klarifikasi. | Daftar kondisi uji awal; requirement issues; draft traceability. |
| 2. Perencanaan | Menetapkan ruang lingkup, pendekatan, sumber daya, jadwal, lingkungan, alat, metrik, serta entry/exit criteria. | Test plan; estimasi; strategi risiko. |
| 3. Desain & pengembangan | Menurunkan test conditions menjadi test cases, test data, expected results, dan kebutuhan otomasi. | Test cases; test data; RTM; scripts. |
| 4. Penyiapan lingkungan | Menyiapkan build, konfigurasi, akun, data, integrasi, serta smoke test untuk memastikan kesiapan. | Test environment; checklist kesiapan; hasil smoke test. |
| 5. Eksekusi | Menjalankan kasus uji, membandingkan hasil aktual dengan expected result, mencatat bukti, dan melaporkan defect. | Test log; evidence; defect reports. |
| 6. Re-test & regression | Memastikan perbaikan benar dan perubahan tidak merusak fungsi yang sebelumnya bekerja. | Re-test result; regression result; status defect. |
| 7. Evaluasi & penutupan | Menilai exit criteria, merangkum cakupan dan risiko tersisa, merekam lesson learned, serta memberi rekomendasi rilis. | Test summary report; sign-off; lessons learned. |
Entry criteria dan exit criteria
Entry criteria adalah kondisi minimum agar suatu aktivitas pengujian layak dimulai. Exit criteria adalah kondisi yang harus dipenuhi agar aktivitas dapat dinyatakan selesai atau risiko tersisa dapat diterima. Keduanya mencegah keputusan yang hanya mengandalkan perasaan 'sudah cukup diuji'.
| Contoh entry criteria | Contoh exit criteria |
|---|---|
| Kebutuhan dan acceptance criteria tersedia. | Semua pengujian prioritas tinggi telah dijalankan. |
| Build lolos smoke test dan dapat dipasang. | Tidak ada defect kritis terbuka. |
| Lingkungan, akun, serta data uji siap. | Cakupan yang disepakati tercapai dan risiko tersisa didokumentasikan. |
5. Traceability: Benang Merah dari Kebutuhan ke Bukti
Requirement Traceability Matrix (RTM) menghubungkan kebutuhan dengan kondisi uji, kasus uji, hasil, dan defect. Traceability membantu tim menjawab dua pertanyaan penting: apakah setiap kebutuhan sudah diuji, dan setiap kasus uji sebenarnya membuktikan kebutuhan yang mana?
| Elemen | Contoh untuk fitur batas transfer |
|---|---|
| Requirement ID | REQ-TRF-01 |
| Kebutuhan | Transaksi > Rp10.000.000 memerlukan otorisasi tambahan. |
| Test condition | Aturan otorisasi pada nilai di bawah, tepat, dan di atas batas. |
| Test case | TC-01: 9.999.999; TC-02: 10.000.000; TC-03: 10.000.001. |
| Expected result | Hanya TC-03 memicu otorisasi tambahan, sesuai definisi 'di atas'. |
| Evidence / defect | Tangkapan hasil, log, atau ID defect jika hasil aktual berbeda. |
6. Peran dan Kolaborasi
V&V adalah tanggung jawab tim, bukan hanya tester. Independensi tetap penting untuk sudut pandang kritis, tetapi kualitas terbaik muncul ketika kebutuhan dan risiko dibahas lintas peran sejak awal.
Product Owner / pengguna: menjelaskan nilai, konteks, kebutuhan, dan acceptance criteria; memberi feedback validasi.
Business/System Analyst: menjaga kejelasan, konsistensi, kelengkapan, dan traceability kebutuhan.
Developer: melakukan review, unit testing, analisis statis, perbaikan defect, dan menyediakan testability.
Tester / QA: merancang strategi berbasis risiko, menyiapkan data dan lingkungan, mengeksekusi, menyelidiki, serta melaporkan bukti kualitas.
Scrum Master / Project Manager: menghilangkan hambatan proses, menjaga transparansi risiko, dan memfasilitasi keputusan.
7. Ringkasan
- Verifikasi menilai apakah produk dibangun dengan benar terhadap spesifikasi dan standar.
- Validasi menilai apakah produk yang dibangun benar-benar sesuai kebutuhan dan konteks pengguna.
- Testing adalah salah satu teknik penting untuk menghasilkan bukti V&V, tetapi V&V juga mencakup review, inspeksi, analisis, prototipe, dan evaluasi pengguna.
- V&V berlangsung sepanjang siklus hidup; bentuk dan ritmenya menyesuaikan Waterfall, V-Model, Spiral, atau Agile/Scrum.
- STLC membuat pekerjaan pengujian dapat direncanakan, ditelusuri, diukur, dan ditutup secara bertanggung jawab.
- Traceability menghubungkan kebutuhan, kasus uji, bukti hasil, defect, dan keputusan rilis.
| Kalimat penutup: V&V bukan sekadar mencari bug; V&V adalah cara membangun kepercayaan yang dapat dipertanggungjawabkan terhadap proses dan produk perangkat lunak. |
Referensi
O'Regan, G. (2019). Concise Guide to Software Testing. Springer.
Mili, A., & Tchier, F. (2015). Software Testing: Concepts and Operations. Wiley.
Pezze, M., & Young, M. (2008). Software Testing and Analysis: Process, Principles, and Techniques. Wiley.
Jorgensen, P. C. (2014). Software Testing: A Craftsman's Approach (4th ed.). CRC Press.
Hambling, B., Morgan, P., et al. (2015). Software Testing: An ISTQB-BCS Certified Tester Foundation Guide. BCS.
Crispin, L., & Gregory, J. (2009). Agile Testing. Addison-Wesley.
Jenkins, N. (2008). A Software Testing Primer.