Persiapan wawancara

Apa yang sebenarnya sedang dinilai

Wawancara QA bukan kuis definisi. Seperti apa pun rupa pertanyaannya, seorang pewawancara sedang berusaha menuntaskan tiga hal:

1. Bisakah Anda menemukan masalah — secara sistematis, bukan karena kebetulan.
2. Bisakah Anda menjelaskan penalaran Anda — karena tester yang tidak bisa menjelaskan sebuah risiko tidak bisa membuatnya ditindaklanjuti.
3. Bisakah Anda berbeda pendapat dengan baik — dengan developer, dengan product owner, di bawah tekanan tenggat.

Hampir setiap pertanyaan baku adalah salah satu dari ketiganya yang memakai kostum. Mengetahui yang mana yang sedang ditanyakan kepada Anda adalah sebagian besar persiapannya.

Pertanyaan yang selalu datang

Pertanyaan	Yang sebenarnya ditanyakan
"Bagaimana Anda akan menguji halaman login?"	Apakah Anda sistematis, dan apakah Anda menyatakan asumsi
"Ceritakan bug yang Anda banggakan"	Bisakah Anda bercerita dengan bukti dan dampak
"Developer bilang itu bukan bug — apa yang Anda lakukan?"	Apakah Anda berdebat dengan bukti atau dengan otoritas
"Bagaimana Anda memutuskan apa yang diotomasi?"	Pertimbangan biaya-dan-nilai, bukan pengetahuan alat
"Kita kirim besok dan pengujiannya belum selesai. Apa kata Anda?"	Bisakah Anda memberi pernyataan risiko alih-alih ya atau tidak
"Bagaimana Anda menguji sesuatu tanpa kebutuhan?"	Apakah Anda tahu dari mana sebuah oracle berasal
"Bagaimana Anda menangani pengujian yang labil?"	Apakah Anda mengarantina dan memperbaiki, atau menjalankan ulang dan berharap

Setiap satunya punya pelajaran di baliknya di Academy ini. Wawancaranya sebagian besar adalah latihan memampatkan.

Jawaban "bagaimana Anda akan menguji X", dalam empat langkah

Ini struktur paling bisa dipakai ulang di seluruh pelajaran ini, karena versi tertentu dari pertanyaan itu muncul di hampir setiap wawancara QA.

1. Bertanyalah sebelum menjawab. Siapa yang memakai ini? Web saja, atau mobile juga? Adakah alur password manager, SSO, 2FA? Apa yang terjadi di hilirnya kalau ia gagal? Kandidat yang langsung mulai mendaftar case sudah memberi tahu pewawancaranya bahwa mereka juga tidak bertanya kepada product owner.

2. Nyatakan asumsi Anda terang-terangan: "Saya akan mengandaikan aplikasi web dengan login email-dan-kata-sandi dan tanpa SSO — beri tahu saya kalau itu keliru." Sekarang jawaban Anda tercakup batasnya alih-alih tidak lengkap.

3. Jalanlah per kategori, bukan per daftar. Kategori menunjukkan sebuah metode; daftar menunjukkan sebuah ingatan:

• Happy path fungsional, dan jalur kesalahan utamanya
• Batas dan negatif — kosong, panjang maksimum, unicode, spasi, input mirip-SQL dan mirip-skrip
• Data dan state — akun terkunci, email belum terverifikasi, sudah masuk di tempat lain
• Keamanan — rate limiting, apakah pesan kesalahannya membedakan "tidak ada pengguna itu" dari "kata sandi salah", apa yang terjadi pada sesinya setelah kata sandinya berubah
• Kompatibilitas — browser dan perangkat yang ditunjukkan analitik Anda, bukan grafik pangsa pasar
• Aksesibilitas — hanya keyboard, fokus yang terlihat, pesan kesalahan yang diumumkan ke pembaca layar
• Non-fungsional — waktu response di bawah beban, dan perilakunya ketika layanan auth-nya lambat
• Di produksi — apa yang akan Anda awasi setelah rilis

4. Sebutkan di mana Anda akan berhenti, dan kenapa. "Dengan dua hari saya akan mencakup tiga kelompok pertama sepenuhnya lalu mengambil sampel sisanya, karena penanganan kredensial adalah tempat kerusakannya berada." Kalimat itu adalah jawaban atas pertanyaan yang sebenarnya mereka ajukan.

Itu seluruh track T2 dalam sembilan puluh detik, dan itulah sebabnya track-nya ada.

Pertanyaan bercerita

Pakai STAR — situation, task, action, result — dengan satu tambahan yang dibutuhkan tester: akhiri dengan apa yang berubah setelahnya. Sebuah case regresi ditambahkan, sebuah proses diperbaiki, sebuah pemeriksaan dipindah lebih awal. Itu mengubah "saya menemukan sebuah bug" menjadi "saya memperbaiki sistem yang meloloskan bug", dan itu beda antara jawaban menengah dan jawaban senior.

Siapkan tiga cerita, dan latih sampai masing-masing dua menit alih-alih enam:

• Bug yang Anda temukan dan berarti, dengan dampaknya dinyatakan dalam mata uang bisnisnya — pendapatan, pengguna yang terdampak, data yang terancam. Bukan "sebuah bug critical".
• Perbedaan pendapat yang Anda tangani — idealnya yang ternyata Anda sebagian keliru. Pewawancara lebih memercayai cerita itu daripada cerita ketika Anda terbukti benar.
• Sesuatu yang Anda perbaiki — suite labil yang distabilkan, pemeriksaan rilis yang bergeser ke kiri, laporan yang mulai dibaca orang.

Untuk "developer bilang itu bukan bug": jawabannya adalah bukti, lalu kebutuhannya, lalu eskalasi dengan keputusannya didokumentasikan. Reproduksi dengan bersih, tunjukkan apa kata spesifikasinya atau harapan penggunanya, dan kalau ia masih disengketakan, serahkan keputusannya kepada siapa pun yang memiliki rilisnya dan catat bahwa keputusannya diambil. Itu pembagian pengamatan-versus-penilaian dari T2, dan itulah jawaban yang terbaca sebagai senior.

Take-home dan latihan langsung

Formatnya yang lazim: uji sebuah fitur yang dijabarkan, temukan bug di sebuah aplikasi demo, tulis satu pengujian otomatis kecil, atau tinjau test case orang lain.

Yang sebenarnya dinilai, kira-kira berurutan menurut bobotnya:

• Struktur — apakah Anda menata pekerjaannya, atau menghasilkan daftar tanpa pembeda.
• Asumsi yang dinyatakan — setiap take-home sengaja kurang spesifik. Menyebutkan kerancuannya mendapat nilai; menebak diam-diam tidak.
• Keterulangan — laporan bug yang tidak bisa direproduksi peninjaunya bernilai nol, terlepas dari nyata tidaknya bug-nya.
• Apakah kodenya jalan, dari clone yang bersih, dengan perintah yang Anda dokumentasikan.
• Prioritas — memberi tahu mereka apa yang akan Anda kerjakan berikutnya dengan waktu lebih adalah bukti pertimbangan, bukan alasan atas apa yang hilang.

Beri timebox dan sebutkan berapa timebox Anda. Kandidat yang menghabiskan empat belas jam untuk latihan empat jam sudah memperagakan sesuatu yang mengkhawatirkan alih-alih mengesankan.

Pertanyaan Anda untuk mereka

Anda akan ditanya apakah Anda punya pertanyaan. Ajukan yang jawabannya memang ingin Anda ketahui, karena ini juga bagian tempat Anda menyaring pekerjaannya:

• Seperti apa proses rilisnya, dari ujung ke ujung?
• Siapa yang memutuskan bahwa sesuatu siap dikirim?
• Berapa lama pipeline-nya, dan seberapa sering ia merah?
• Apa yang terjadi ketika sebuah cacat sampai ke produksi?
• Apakah QA ada di refinement, atau pekerjaannya tiba sudah diestimasi?
• Apa yang Anda inginkan sudah saya capai setelah tiga bulan?

Jawabannya memberi tahu Anda apakah perannya adalah pengujian atau sekadar cap stempel dengan gelar pekerjaan pengujian, dan itu lebih berharga bagi Anda daripada satu kesempatan tambahan untuk mengesankan.

Dua catatan yang jujur

Klaim tingkat yang bisa Anda pertahankan. Melamar sebagai senior berarti ditanya bagaimana Anda akan menstabilkan suite yang labil, menyusun framework untuk tim beranggota lima, atau menegosiasikan sebuah rilis. Menjadi kandidat tingkat menengah yang sangat baik mengalahkan menjadi senior yang tidak meyakinkan, dan tawaran yang datang dari gambaran yang akurat adalah yang selamat melewati tiga bulan pertama.

Penolakan itu berkeragaman tinggi. Kecocokan tim, kandidat internal, pembekuan anggaran, seseorang dengan domain yang persis — sebagian besar itu tidak ada hubungannya dengan Anda. Prosesnya adalah penjodohan alih-alih vonis. Jalani cukup sering dan kumpulkan umpan balik yang bisa Anda kumpulkan.

Bawa portofolionya

Semua di atas jadi lebih mudah ketika Anda bisa mengakhiri sebuah jawaban dengan "saya bisa tunjukkan." Proyek publik dari pelajaran sebelumnya mengerjakan lebih banyak dalam sebuah wawancara daripada kata sifat mana pun: case sungguhan, run sungguhan, kegagalan sungguhan yang Anda temukan, dan penjelasan tertulis tentang apa yang Anda pilih untuk tidak dicakup.

Ketika pertanyaannya "dari mana Anda tahu pengujian Anda bagus?", membuka sebuah riwayat run lalu menunjuk cacat yang tertangkap sebelum rilis adalah jawaban yang tidak bisa dibantah siapa pun.

Anda telah menyelesaikan Melampaui Fungsional

Performa dan keamanan sebagai pertanyaan seorang tester alih-alih sebagai alat seorang spesialis. Kontrak sebelum deploy dan observabilitas sesudahnya. AI diurutkan menurut bagaimana ia gagal alih-alih menurut apa yang dijanjikannya. Dan dua pelajaran yang mengubah semuanya menjadi sesuatu yang bisa dinilai orang asing.

Empat track, dari apa yang dikerjakan QA sampai bagaimana Anda dibayar untuk itu. Kalau sertifikasi adalah langkah Anda berikutnya, roadmap-nya punya satu track untuk itu — kuis per bab dan satu paket latihan penuh — dan ia menyebut skemanya di sana, dengan pemberitahuan yang semestinya menyertainya.

Pergilah dan uji sesuatu yang nyata. Hanya bagian itu dari semua ini yang memang akan mengajari Anda.