Bukan algoritma atau framework yang paling sering membuat presentasi informatika tersendat. Justru Bab IV: ketika tabel pengujian terlihat rapi, tetapi alasan di baliknya tidak pernah benar-benar dipertahankan.
Kalau mencari pertanyaan sidang skripsi informatika, kamu akan banyak menemukan daftar seperti “apa itu black-box testing?” atau “kenapa memakai metode waterfall?” Daftar itu berguna untuk mengingat istilah, tapi tidak membantu saat penguji menunjuk satu baris di tabel test case-mu dan meminta kamu menjelaskan keputusan yang kamu ambil.
Pola di artikel ini disusun dari penelitian pengembangan sistem yang memakai pengujian fungsional/black-box: fitur diuji lewat skenario masukan dan keluaran, lalu hasil “sesuai” diringkas sebagai bukti sistem berjalan. Detail kasusnya digeneralisasi; yang dibedah bukan satu aplikasi atau kampus tertentu, melainkan celah yang berulang pada laporan sejenis.
Bayangkan aplikasi layanan kampusmu sudah didemokan, semua tombol tampak bekerja, dan Bab IV terbuka di layar. Dosen penguji tidak perlu mencari bug yang rumit. Ia cukup membaca apa yang kamu sendiri tulis tentang pengujian.
1. Skenario yang selalu membuat sistem terlihat berhasil
Kamu baru selesai menunjukkan proses login. Sistem menerima email dan kata sandi yang benar, lalu berpindah ke dashboard. Dosen penguji mengangguk, tetapi tidak langsung beralih ke fitur berikutnya. Ia melihat tabel test case yang semua kolom hasilnya bertuliskan “valid”.
Dosen penguji bertanya: “Di tabel ini saya melihat login diuji dengan akun yang benar. Masukan salah, akun yang belum terdaftar, dan percobaan berulangnya diuji di mana?”
Kamu sadar “login berhasil” hanya membuktikan satu jalur yang paling ramah bagi sistem.
Yang sebenarnya diuji: validitas data & argumen. Penguji ingin tahu apakah skenario pengujian mewakili perilaku pengguna yang nyata, termasuk input yang keliru atau kondisi batas. Black-box testing bukan ritual mencentang fitur. Kalau test case hanya memotret happy path, kesimpulan “fitur login berjalan baik” jauh lebih besar daripada bukti yang tersedia.
2. Test case ada, asalnya tidak jelas
Halaman berikutnya memuat sepuluh skenario pengujian. Angkanya tampak meyakinkan karena tersusun rapi. Dosen penguji menunggu beberapa detik, lalu menunjuk kolom pertama: “Skenario.”
Dosen penguji bertanya: “Kenapa sepuluh skenario ini yang dipilih? Apa hubungannya dengan kebutuhan fungsional yang Anda tulis di Bab III?”
Kamu ingin menjawab bahwa itu fitur-fitur utama. Tetapi “utama” belum menjelaskan dasar pemilihannya.
Yang sebenarnya diuji: justifikasi metodologi. Penguji tidak meminta daftar yang lebih panjang; ia menguji jejak antara kebutuhan, risiko fitur, dan test case. Kamu perlu bisa menunjukkan bahwa tiap skenario datang dari requirement atau aturan bisnis tertentu—bukan dipilih setelah aplikasi jadi karena paling mudah didemokan.
3. Hasil “100% valid” yang terlalu cepat menjadi klaim kualitas
Di slide kesimpulan, kamu menyebut seluruh pengujian berhasil. Dosen penguji membuka kembali Bab IV dan mendapati bahwa pengujian dilakukan oleh kamu sendiri pada satu perangkat dan satu peramban.
Dosen penguji bertanya: “Anda menyimpulkan sistem layak digunakan karena seluruh test case valid. Dengan pengujian oleh satu pengembang pada satu lingkungan, batas kesimpulan itu sampai di mana?”
Kalimat “100% berhasil” yang tadi terasa kuat sekarang terdengar seperti klaim tanpa batas.
Yang sebenarnya diuji: konsistensi logika. Persentase keberhasilan test case menjelaskan hasil pada skenario dan lingkungan yang diuji; ia tidak otomatis membuktikan usability, keamanan, performa, atau kompatibilitas seluruh pengguna. Jawaban yang matang menyebut cakupan pengujian secara jujur, bukan memperluasnya menjadi sertifikat kualitas sistem.
4. Data kosong yang lolos karena belum pernah dicoba
Penguji membuka formulir pendaftaran. Kamu menjelaskan bahwa data akan tersimpan setelah pengguna menekan tombol kirim. Lalu ia membaca satu aturan di kebutuhan sistem: nomor telepon wajib diisi.
Dosen penguji bertanya: “Pada requirement Anda, nomor telepon wajib. Tunjukkan test case saat kolom ini dikosongkan, atau jelaskan bagaimana Anda memastikan aturan itu tidak bisa dilewati.”
Tiba-tiba pengujian tidak lagi soal tombol bekerja, melainkan soal sistem menolak keadaan yang seharusnya tidak boleh ada.
Yang sebenarnya diuji: validitas data & argumen. Validasi input adalah bagian dari perilaku fungsional. Jika requirement mengatakan sebuah batasan ada tetapi pengujiannya hanya mengecek penyimpanan data lengkap, hubungan antara spesifikasi dan implementasi belum terbuktikan.
5. Metode yang dipilih karena “paling umum dipakai”
Di Bab III kamu menyebut black-box testing, tanpa teknik pemilahan yang lebih spesifik. Dosen penguji tidak mempersoalkan pilihan itu, tetapi meminta alasan.
Dosen penguji bertanya: “Kenapa black-box testing sesuai untuk sistem Anda? Risiko atau kebutuhan apa yang ingin Anda cek dengan pendekatan itu?”
Menjelaskan definisinya tidak menjawab pertanyaan tersebut.
Yang sebenarnya diuji: justifikasi metodologi. Metode perlu terhubung ke tujuan. Untuk aplikasi yang dinilai dari perilaku fitur terhadap masukan pengguna, pengujian fungsional dapat masuk akal; tetapi kamu tetap perlu menerangkan apa yang memang diperiksa dan apa yang tidak. “Sering dipakai” bukan alasan penelitian.
6. Fitur yang diuji sendiri-sendiri, alurnya belum pernah ditempuh
Kamu punya test case untuk membuat data, mengubah data, dan mencetak laporan. Masing-masing lulus. Dosen penguji lalu meminta satu urutan yang lebih panjang: buat data, ubah statusnya, lalu lihat apakah laporan ikut berubah.
Dosen penguji bertanya: “Ketiga fungsi ini lulus secara terpisah. Apakah alur pengguna dari awal sampai laporan akhir pernah diuji sebagai satu rangkaian?”
Di sini, bug sering muncul bukan di tombol tunggal, tetapi di sambungan antarfungsi.
Yang sebenarnya diuji: konsistensi logika. Sistem adalah alur, bukan kumpulan layar. Kalau klaimmu mencakup proses layanan dari awal hingga akhir, bukti pengujian juga harus menyentuh transisi data antarfitur.
7. Batas sistem yang menghilang di bagian kesimpulan
Menjelang akhir, kamu menyebut aplikasi “siap diterapkan”. Dosen penguji melihat bahwa pengguna uji hanyalah data simulasi, sementara integrasi dengan layanan eksternal belum dikerjakan.
Dosen penguji bertanya: “Siap diterapkan untuk konteks yang mana? Bagian mana yang sudah dibuktikan oleh pengujian Anda, dan bagian mana yang masih asumsi?”
Ini bukan pertanyaan untuk menjatuhkan demo. Ini momen untuk menunjukkan bahwa kamu memahami batas pekerjaanmu sendiri.
Yang sebenarnya diuji: pertahanan di bawah tekanan. Penguji menilai apakah kamu bisa mengecilkan klaim ke ukuran bukti tanpa panik. Sistem yang terbukti menjalankan fitur inti dalam lingkungan uji tetap bisa menjadi hasil yang sah; yang bermasalah adalah kesimpulan yang melampaui pengujian.
Polanya
Tujuh pertanyaan ini berubah bentuk tergantung aplikasi yang kamu buat—sistem akademik, marketplace, layanan administrasi, atau aplikasi mobile. Namun sumbunya sama: kebaruan pada alasan solusi dibangun, justifikasi metodologi pada pilihan uji, validitas pada cakupan buktinya, konsistensi logika antara requirement dan kesimpulan, serta kemampuan bertahan ketika klaim dipersempit.
Persiapan yang kepakai bukan menghafal definisi testing. Buka lagi requirement-mu, pasangkan satu per satu dengan test case, lalu tanyakan: input buruk apa yang belum dicoba, alur mana yang belum ditempuh, dan klaim mana yang belum punya bukti? Di situlah pertanyaan penguji biasanya dimulai.
Tujuh momen di atas adalah gambaran dari sesi TAKKA, dosen penguji AI di Qritis yang menyerang berdasarkan apa yang benar-benar tertulis di draf skripsimu—bukan dari daftar pertanyaan generik. Skripsimu perlu diuji. Bukan dipuji.