Kami mempekerjakan orang QA dan saya harus mengajukan beberapa pertanyaan wawancara. Yang benar adalah, saya tidak tahu banyak tentang apa yang harus diketahui oleh seorang insinyur QA yang baik, apalagi pertanyaan wawancara yang baik. Adakah yang punya saran?
Beberapa informasi: Lingkungan adalah dua aplikasi web yang terpisah (tetapi saling terkait) untuk tumpukan Microsoft (ASP.NET, SQL Server, IIS).
Jawaban:
Kecuali jika Anda memiliki banyak pengalaman bekerja dengan penguji, bacalah beberapa bab pertama dari "Pengujian Perangkat Lunak Komputer" Cem Kaner untuk mengetahui jenis-jenis istilah yang ingin Anda dengar: Pengujian batas, pengujian kesalahan, pengujian jalur bahagia, fungsional, kinerja, keamanan, integrasi, dll. Jika Anda tidak dapat berbicara bahasa tersebut, Anda tidak akan dapat melakukan wawancara yang baik.
Beri mereka spek untuk sepotong kecil sistem Anda. Minta mereka untuk mengujinya. Anda mencari organisasi pemikiran dan kemampuan mereka untuk menghasilkan tes yang menarik. Anda ingin melihat mereka memecah bidang pengujian secara berurutan, dan kemudian menelusuri ke dalam masing-masing bidang, menyusun lebih banyak kasus pengujian yang lebih menarik. Penguji yang benar-benar baik dapat melakukan ini selama berjam-jam dengan semua tetapi masalah yang paling sepele, jadi Anda mungkin perlu memotongnya dan meminta mereka pindah ke kategori lain untuk mendapatkan perasaan yang baik tentang bagaimana mereka berpikir.
Jelaskan perilaku yang disebabkan oleh bug nyata di sistem Anda yang agak sulit dimengerti. Tanyakan kepada mereka apa yang akan mereka lakukan jika mereka melihat bug ini saat pengujian. Di sini, Anda mencari pengurangan bug - kemampuan untuk menemukan rangkaian keadaan paling sederhana yang dapat mereproduksi bug. Ini membuat proses debug jauh lebih mudah bagi para devs, karena mereka memiliki perkiraan yang lebih baik tentang apa yang menyebabkan masalah, dan menunjukkan kemampuan yang jelas untuk menyelesaikan masalah dan pemahaman yang jelas tentang faktor-faktor apa yang dapat berinteraksi untuk menyebabkan bug. Dengan produk spesifik Anda, mendiskusikan kondisi lomba mungkin menyenangkan.
Beri mereka program baris perintah sederhana yang Anda retas bersama (mungkin diunggulkan dengan bug) dan spek sederhana, dan biarkan mereka duduk di depan komputer dan bermain dengannya, dengan tujuan menemukan masalah. Di sini Anda mencari kreativitas dan kemampuan untuk menargetkan area yang bermasalah. Mereka harus menguji hal-hal seperti input besar, input kecil, input aneh, input kosong. Jika mereka menemukan bug, minta mereka untuk mencoba dan mencari tahu kapan bug itu terjadi (lagi dengan pengurangan bug!).
Tanyakan kepada mereka apa yang akan mereka lakukan jika SDE merespons bug dengan "No Repro" atau "Won't Fix", jika mereka pikir bug itu penting. Di sini Anda mencari seseorang yang tidak hanya akan menjadi penurut, tetapi juga tidak akan bermusuhan. Tanggapan yang masuk akal termasuk menambahkan skenario contoh yang menunjukkan lebih jelas keparahan bug dan kemudian membuka kembali tiket, berbicara dengan dev untuk mencoba memahami mengapa segala sesuatunya diselesaikan dengan cara ini sebelum ditutup, dll.
Bicaralah dengan mereka tentang aplikasi Anda di tingkat tinggi. Tanyakan kepada mereka tes macam apa yang ingin mereka lakukan. Di sini Anda mencari area umum pengujian seperti pengujian komponen fungsional, pengujian integrasi, pengujian kinerja, pengujian keamanan.
Jika ini adalah seorang insinyur SDET / otomasi, berikan mereka beberapa pertanyaan wawancara untuk para devs dengan sekitar 1/3 hingga setengah dari total tahun pengalaman mereka.
Jika ini adalah orang QA pertama Anda, pastikan mereka dapat memulai sendiri. Tanyakan kepada mereka seperti apa rupa minggu pertama mereka hingga bulan kerja. Mereka harus mengatakan sesuatu tentang mengumpulkan persyaratan dan menyiapkan alat, kemudian menjelaskan pendekatan yang masuk akal untuk memulai pengujian. Anda mencari seseorang yang tidak membutuhkan bos untuk memberi tahu mereka cara memulai pengujian dan dapat mengatur sendiri. Jika Anda sudah memiliki staf QA, ini kurang penting.
Apa yang saya lakukan ketika saya telah mewawancarai kandidat QA adalah meminta mereka untuk membuat sketsa strategi pengujian untuk suatu aplikasi. Saya biasanya memberi mereka ponsel saya dan memilih aplikasi dengan fitur terbatas - atau membiarkan mereka memilih sesuatu yang lebih mereka kenal. Ketika mereka membuat daftar strategi tingkat tinggi (beberapa tidak bisa), saya mungkin meminta mereka untuk menelusuri dan mendaftar beberapa kasus uji.
Setelah selesai saya mungkin memberi mereka skenario di mana kita memiliki sumber daya yang terbatas dan melihat bagaimana mereka memprioritaskan.
Saya juga bertanya kepada mereka kapan perangkat lunak cukup baik untuk dikirim, bagaimana menangani situasi di mana PM atau dev tidak merasa bug itu penting tetapi mereka lakukan. Skenario pengembangan produk yang khas.
Ini untuk posisi QA nonkode. Coding posisi QA saya berikan mereka wawancara dev / test combo.
Tanyakan kepada mereka bagaimana mereka akan merancang rencana pengujian. Tanyakan kepada mereka apakah mereka berpengalaman dalam menggunakan pengujian regresi dan bagaimana mereka melakukannya jika demikian. Tanyakan kepada mereka bagaimana mereka menguji antarmuka pengguna. Tanyakan kepada mereka bagaimana mereka akan menguji impor data yang tidak melalui antarmuka pengguna (jika Anda melakukan hal-hal seperti itu). Tanyakan kepada mereka bagaimana mereka akan mengomunikasikan masalah mereka kepada pengembang dan bagaimana mereka akan memeriksa penyelesaian masalah. Saya akan bertanya kepada mereka tentang bug yang paling menarik (atau paling sulit ditemukan) yang mereka temukan dan bagaimana mereka menemukannya.
Sebelum Anda mulai mewawancarai, cari beberapa buku di luar sana tentang pengujian dan sedikit memahami apa yang harus dilakukan orang QA. Itu akan membantu Anda mengevaluasi jawaban mereka.
Selanjutnya Anda juga mencari kepribadian yang cocok. Anda tidak menginginkan orang yang QA mendorong Anda, tetapi Anda juga tidak menginginkan pelaku intimidasi atau brengsek. Tetapi Anda menginginkan seseorang yang akan menentang manajemen ketika ada sesuatu yang salah dan tidak hanya menyetujui semuanya karena manajemen ingin memenuhi tenggat waktu. Anda menginginkan seseorang yang akan bekerja dengan pengembang secara efektif dan yang memahami persyaratan apa yang mereka uji. Seseorang dengan latar belakang jenis aplikasi yang Anda uji mungkin baik. Seorang penguji dengan pengalaman perawatan kesehatan akan mengetahui hal-hal untuk menguji bahwa seseorang yang datang dari bidang lain mungkin tidak menyadarinya.
Saya kira Anda tidak dapat mengharapkan mereka memiliki pengetahuan teknologi yang serius - siapa pun yang memiliki kemungkinan besar akan menolak untuk bekerja sebagai penguji biasa.
Yang terbaik yang dapat Anda lakukan adalah mencari hal-hal umum seperti memperhatikan detail, pikiran ingin tahu, antusiasme untuk eksperimen dan sebagainya.