Pertanyaan Interview Quality Assurance: Menyusun Test Case dan Menyelidiki Bug
Quick Overview
Kasus original software QA berbahasa Indonesia: klarifikasi timeout, susun test case status, bandingkan respons lama dan identitas percobaan, lalu tulis bug report. 18 observasi browser lokal membatasi kesimpulan UI dari dugaan backend.
Layar pembayaran sudah menampilkan SUCCEEDED. Beberapa saat kemudian, respons lama datang dan layar kembali menjadi PENDING. Jika ditanya “bagaimana Anda menguji ini?”, jawaban yang berguna dimulai dari urutan kejadian dan aturan status, bukan daftar panjang istilah testing.
Artikel ini membahas pertanyaan interview Quality Assurance untuk software melalui satu latihan: layar status dengan requirement yang bertentangan, batas waktu 30 detik, dan respons yang tiba tidak berurutan. Anda akan menyusun test case, membedakan observasi dari dugaan penyebab, lalu menulis laporan bug yang bisa diulang.
Batas bukti: konsep testing dirujuk ke sumber resmi. Kasus, aturan bisnis, dan rekomendasi di bawah adalah latihan original PracHub. Kami menjalankan 18 observasi pada antarmuka browser lokal; tidak ada transaksi uang, bank, gateway, atau database produksi. Ini bukan bocoran soal atau laporan kandidat tentang proses rekrutmen perusahaan tertentu.
Untuk pemanasan, jawab Resolve Ambiguous Requirements Before Building. Terapkan pertanyaan itu pada dua requirement berikut sebelum membuat test case.
1. “Requirement mana yang Anda klarifikasi lebih dahulu?”
Bayangkan Anda menerima spesifikasi layar pesanan DEMO-07:
| Catatan requirement | Masalah yang perlu diputuskan | Pertanyaan kepada pemilik produk |
|---|---|---|
A: hasil akhir hanya berasal dari respons SUCCEEDED atau FAILED | Menunggu tidak memberikan hasil akhir | Apa yang dilihat pengguna selama hasil belum diketahui? |
B: setelah 30 detik, tampilkan FAILED | Waktu tunggu diperlakukan sebagai bukti kegagalan | Apakah 30 detik berarti gagal, atau hanya perlu pesan lanjutan? |
| C: sediakan tombol “Coba ulang” saat gagal | “Gagal” bergantung pada A atau B | Bolehkah pengguna mencoba lagi ketika hasil lama belum diketahui? |
Jelaskan konflik A dan B sebelum merekomendasikan salah satunya. Tunjukkan bahwa A dan B menghasilkan ekspektasi berbeda untuk input yang sama. Jika satu kasus memakai A dan B sekaligus, Anda belum memiliki satu expected result yang dapat diperiksa.
Keputusan latihan: selama belum ada hasil akhir, status tetap PENDING. Pada usia logis 30 detik atau lebih, pesan berubah menjadi “Masih memverifikasi hasil.” Tombol “Coba ulang” tetap nonaktif. Hanya respons gagal yang diterima untuk percobaan aktif yang mengaktifkan tombol tersebut.
Ini adalah kebijakan UI untuk latihan, bukan ketentuan penyedia pembayaran. Di produk nyata, keputusan perlu disepakati bersama orang yang memahami kontrak layanan dan konsekuensi percobaan ulang. Simpan keputusan di kriteria penerimaan agar developer, QA, dan pemilik produk memakai ekspektasi yang sama.
Contoh jawaban: “Saya akan mengklarifikasi arti timeout sebelum menjalankan kasus gagal. Untuk sementara saya catat dua kemungkinan hasil, lalu meminta keputusan yang dapat dijadikan oracle. Setelah itu saya uji layar berdasarkan keputusan tersebut.” Oracle di sini berarti dasar untuk menentukan apakah hasil sesuai harapan.
2. “Tulis test case untuk batas 30 detik”
Mulai dengan kondisi awal yang eksplisit: percobaan A-01, revisi diterima 0, status PENDING, dan belum ada respons akhir. Ubah satu kondisi utama: usia logis. Jangan sekaligus mengganti status, jaringan, dan identitas percobaan; jika hasil berubah, penyebabnya akan sulit dipisahkan.
| ID | Usia logis | Ekspektasi berdasarkan keputusan latihan | Hasil Broken | Hasil Fixed |
|---|---|---|---|---|
| W29 | 29 detik | PENDING; pesan awal; retry nonaktif | Sesuai | Sesuai |
| W30 | 30 detik | PENDING; “Masih memverifikasi hasil.”; retry nonaktif | FAILED; retry aktif | Sesuai |
| W31 | 31 detik | Sama seperti W30 | FAILED; retry aktif | Sesuai |
Hasil observasi lokal: ketiga nilai dijalankan di kedua mode melalui kontrol browser. Jam fixture bergerak dalam satuan detik bulat dan tidak menunggu 30 detik waktu nyata. Karena itu, tabel ini menguji cabang aturan tampilan; belum menguji timer browser, tab di latar belakang, atau keterlambatan jaringan sesungguhnya.
Sumber resmi ISTQB CTFL v4.0.1 membahas pengujian nilai batas pada partisi berurutan. Pilihan 29/30/31 di sini mengikuti ambang spesifikasi dan resolusi fixture. Jangan menyebut tiga nilai tersebut sebagai bukti “semua boundary sudah tercakup”: aturan durasi maksimum, input pecahan, dan pembaruan timer belum masuk ruang lingkup ini.
Jika pewawancara mengubah batas menjadi 45 detik, revisi nilai dan oracle terlebih dahulu. Jika resolusi timer berubah menjadi milidetik, 29/30/31 detik belum tentu menjadi nilai tetangga yang tepat. Penjelasan pemilihan data lebih bernilai daripada menghafal tiga angka.
3. “Bagaimana Anda membuktikan status mundur?”
Untuk kasus kedua, jam bukan variabel utama. Anda mengendalikan urutan pengiriman dua respons sintetis untuk percobaan yang sama:
Awal: A-01, revisi 0, PENDING
1. Kirim A-01 v2 SUCCEEDED
2. Kirim A-01 v1 PENDING
Broken: SUCCEEDED v2 → PENDING v1
Fixed: SUCCEEDED v2 → SUCCEEDED v2
Di mode Broken, kedua respons langsung mengganti tampilan. Mode Fixed mempertahankan revisi yang sudah diterima dan mengabaikan revisi lebih kecil atau sama. Pengamatan ini menjelaskan cacat layar dengan contoh minimum: tidak perlu menjalankan seratus transaksi atau menebak adanya kerusakan database.
Aturan tambahan latihan: hasil akhir untuk satu percobaan tidak berubah menjadi hasil yang berbeda. Karena itu, setelah SUCCEEDED v2, fixture juga menolak FAILED v3 sebagai konflik hasil akhir. Aturan ini sengaja tertulis; angka revisi yang lebih besar saja tidak otomatis membuat semua perubahan sah. Produk nyata dapat memiliki model status lain yang harus Anda baca terlebih dahulu.
Pisahkan tiga pernyataan saat menjawab:
- Terlihat: setelah langkah kedua, teks layar Broken menjadi
PENDING, dengan revisi1. - Hipotesis: logika penerimaan respons mungkin belum memeriksa urutan revisi. Pada fixture original ini, implementasinya memang demikian; pada aplikasi asing, Anda masih perlu bukti tambahan.
- Belum terbukti: status di database berubah, pengguna dikenai biaya dua kali, atau layanan pembayaran rusak.
Jika Anda hanya memiliki screenshot akhir, Anda belum menunjukkan respons mana yang datang lebih dahulu. Lampirkan urutan langkah dan receipt yang memuat identitas, revisi, serta status. Dalam sistem nyata, gunakan data uji dan korelasi yang tersedia sesuai izin; hindari memasukkan data pelanggan ke laporan publik.
4. “Apa yang terjadi jika pengguna memulai percobaan baru?”
Revisi saja belum cukup. A-01 v9 tidak boleh mengubah layar yang sedang menampilkan A-02 v0. Angka sembilan berasal dari percobaan lain; membandingkannya langsung dengan nol akan menerima respons yang salah.
Urutan pengambilan keputusan fixture adalah: cocokkan identitas percobaan, periksa revisi, lalu periksa apakah perubahan status diizinkan. Memeriksa identitas lebih dahulu mencegah respons percobaan lama mengambil alih layar percobaan baru. Yang pertama menjawab “respons milik siapa?”, yang kedua “mana yang lebih baru dalam percobaan ini?”.
| Kejadian pada mode Fixed | Hasil yang diamati | Alasan yang dicatat |
|---|---|---|
A-01 v1 PENDING setelah A-01 v2 SUCCEEDED | Tetap SUCCEEDED v2 | Revisi lama |
A-01 v2 SUCCEEDED dikirim ulang | Tetap SUCCEEDED v2 | Revisi sama |
A-01 v3 FAILED setelah sukses | Tetap SUCCEEDED v2 | Konflik hasil akhir |
A-01 v9 SUCCEEDED saat layar aktif A-02 | Tetap A-02 PENDING v0 | Percobaan berbeda |
A-02 v1 FAILED saat layar aktif A-02 | Menjadi FAILED v1; retry aktif | Respons diterima |
Klik retry setelah kegagalan A-02 | A-03 PENDING v0; retry nonaktif | Percobaan baru |
Kami juga mengulang kegagalan A-01 v3, lalu klik retry: layar menjadi A-02 PENDING v0. Dua jalur ini memeriksa bahwa fixture tidak selalu memakai identitas baru yang sama. Receipt lokal menyimpan 18 observasi: enam nilai waktu lintas mode, dua respons Broken, empat respons Fixed, empat langkah jalur A-02, serta dua langkah kegagalan dan retry A-01. Angka itu menghitung titik observasi, bukan 18 test case independen.
Tombol nonaktif membantu membatasi tindakan di antarmuka. Ia tidak membuktikan backend mencegah permintaan ganda dari tab lain atau klien lain. Jika ditanya tentang API, jelaskan pengujian tambahan yang diperlukan dan pisahkan dari hasil UI yang sudah Anda lihat.
5. “Tulis bug report yang bisa dikerjakan developer”
Hindari judul “Pembayaran error kadang-kadang”. Judul berikut menyatakan pemicu dan akibat: Respons A-01 v1 menimpa SUCCEEDED v2 sehingga layar kembali PENDING.
Contoh laporan dari eksekusi lokal:
Build: STATUS-DEMO-01
Lingkungan: Chrome desktop; fixture lokal; mode Broken
Data: pesanan sintetis DEMO-07; percobaan A-01
Prasyarat: Reset data; PENDING revisi 0
Langkah:
1. Klik “Kirim A-01 v2 SUCCEEDED”.
2. Pastikan layar menunjukkan SUCCEEDED, revisi 2.
3. Klik “Kirim A-01 v1 PENDING”.
Expected: tetap SUCCEEDED, revisi 2.
Actual: menjadi PENDING, revisi 1.
Bukti: screenshot layar Broken dan receipt urutan dua respons.
Reproduksi: urutan terkendali pada fixture, bukan jaringan produksi.
Laporan ini memberi orang lain cara mencapai kegagalan yang sama. Hubungkan expected result ke keputusan “respons lama tidak menurunkan revisi diterima”, lalu tambahkan identitas build perbaikan ketika tersedia. Catat juga kondisi yang belum diuji agar laporan tidak dibaca sebagai hasil audit pembayaran menyeluruh.
ISTQB CTFL v4.0.1 mencakup pengelolaan defect dan informasi laporan seperti lingkungan, langkah, serta hasil yang diharapkan dan aktual. Template di atas adalah penerapan original untuk kasus ini, bukan formulir resmi yang wajib dipakai semua perusahaan.
Penilaian risiko editorial: pengguna yang baru melihat sukses lalu melihat pending kehilangan dasar yang jelas untuk memilih menunggu atau mencoba lagi. Namun, dampak aktual, jumlah pengguna terdampak, frekuensi kejadian, dan kontrol layanan masih belum diketahui. Saya akan mengusulkan triase segera bersama pemilik produk, sambil meminta bukti penggunaan dan dampak. Menetapkan “critical” hanya karena layar bertema pembayaran tidak menjelaskan risiko.
Jika developer tidak dapat mereproduksi, cocokkan build, mode, data awal, dan urutan respons. Bandingkan receipt sebelum menyimpulkan laporan salah. Screenshot mungkin berasal dari mode Broken sementara developer sedang menguji mode Fixed; itu adalah perbedaan konfigurasi yang dapat diperiksa.
6. “Setelah diperbaiki, apa yang Anda uji ulang?”
Mulai dengan urutan bug yang sama: reset, terima SUCCEEDED v2, lalu kirim PENDING v1. Hasil Fixed tetap SUCCEEDED v2. Itu mengonfirmasi perbaikan pada contoh reproduksi ini.
Setelah itu, periksa perilaku yang mungkin ikut berubah: pesan pada batas 30 detik, respons ulang, konflik hasil akhir, respons percobaan lain, kegagalan sah, dan pembuatan percobaan baru. ISTQB CTFL v4.0.1 membedakan confirmation testing untuk perubahan yang memperbaiki defect dari regression testing terhadap efek samping perubahan. Jumlah pengujian tidak menentukan kategorinya; tujuan pengujian yang menentukan.
Di luar eksekusi ini, saya akan menambahkan pengiriman respons melalui kontrak API yang sebenarnya, pemulihan setelah reload, serta perilaku tab latar belakang. Untuk aksesibilitas, fixture menyediakan role="status" dan tombol HTML disabled. WCAG 2.2, kriteria 4.1.3 membahas status yang dapat dikenali teknologi bantu tanpa harus memindahkan fokus. Keberadaan atribut saja belum membuktikan pengumuman terbaca dengan benar; sesi pembaca layar belum kami jalankan.
HTML Standard dari WHATWG mendefinisikan perilaku kontrol nonaktif. Saat menguji produk, periksa juga apakah alasan tombol nonaktif terlihat dan bisa dipahami. Bedakan pemeriksaan DOM yang dilakukan dari pengalaman keyboard dan pembaca layar yang masih perlu diuji.
Rekomendasi rilis yang dapat dipertanggungjawabkan berbunyi: “Pada fixture Fixed, urutan reproduksi dan observasi regresi yang tercantum cocok dengan oracle latihan. Saya belum menyimpulkan integrasi pembayaran siap rilis; bukti kontrak layanan dan perilaku lingkungan sasaran masih diperlukan.” Ini menyebut hasil, ruang lingkup, dan langkah yang dapat menutup ketidakpastian.
Latihan lanjutan dengan pertanyaan PracHub
Gunakan lima pertanyaan berikut untuk memperluas kasus yang sama. Jawab dengan kondisi awal, perubahan yang diuji, hasil yang dapat diamati, dan batas kesimpulannya.
| Pertanyaan PracHub | Terapkan pada layar status |
|---|---|
| Resolve Ambiguous Requirements Before Building | Selesaikan konflik timeout dan hasil akhir sebelum menetapkan expected result. |
| Contrast UI vs backend testing; design UI-change test cases | Pisahkan bukti layar dari keadaan layanan dan penyimpanan. |
| Reduce False Failures and Classify QA Outcomes | Bedakan defect, konfigurasi fixture yang keliru, dan oracle yang belum disepakati. |
| Investigate Recurring Bugs and Prevent the Same Failure from Returning | Pilih regresi untuk respons lama, identitas berbeda, dan retry sah. |
| Prioritizing QA Work Under Deadline Pressure | Jelaskan bukti minimum sebelum rekomendasi rilis dan risiko yang tersisa. |
Lanjutkan dengan Investigate Recurring Bugs and Prevent the Same Failure from Returning. Pertahankan satu contoh bug yang jelas, lalu jelaskan perubahan test suite yang akan menangkapnya kembali. Jawaban QA Anda menjadi lebih kuat ketika keputusan dapat ditelusuri ke bukti yang benar-benar tersedia.
Sources and Further Reading
- ISTQB — Certified Tester Foundation Level v4.0.1 syllabus: konsep nilai batas, pelaporan defect, confirmation, dan regression testing.
- W3C — WCAG 2.2, Status Messages, 4.1.3: kriteria normatif terkait status dan teknologi bantu.
- W3C — Understanding Status Messages: penjelasan pendukung; bukan tambahan persyaratan normatif.
- WHATWG — HTML Standard, disabled controls: semantik kontrol form yang dinonaktifkan.
Comments (0)