Pendekatan pengembangan selama sepuluh tahun terakhir telah mengalami perubahan besar, persyaratan untuk penguji (QA, QE, insinyur kualitas) juga telah berubah. Tetapi tidak semua penguji siap melangkah ke tingkat yang sama sekali baru. Kemarin adalah mungkin untuk datang dari jalan untuk masuk ke profesi. Untuk menjadi spesialis yang dicari hari ini, Anda harus menjadi insinyur.
Ketika memulai karier, sebuah presentasi ditunjukkan pada kursus-kursus yang mendukung perlunya pengujian. Tanda tangan ke slide berbunyi: "Semakin cepat Anda menemukan bug dalam siklus hidup produk, semakin murah untuk memperbaikinya." Tingkat tes lebih rendah daripada untuk programmer. Kami mempekerjakan penguji → memastikan kualitas dan menghemat pengembangan. Untung!
Penguji adalah pemburu serangga. Programmer menulis fitur, rilis sedang dipersiapkan, rilis melewati tahap QA. Pada saat itu, penguji "memakai topi" dari pengguna nyata dan mulai mengeksekusi skenario khas. Diyakini bahwa seseorang tanpa latar belakang teknis akan cocok untuk posisi ini.
Kecepatan pengembangan proyek modern telah meningkat. Konsep CI / CD muncul. Tidak ada yang terkejut dengan proyek rilis harian. Perusahaan menyadari bahwa pemeriksaan manual tidak dapat diskalakan. Penguji terlibat dalam otomatisasi pengujian penerimaan menggunakan Selenium atau kerangka kerja serupa. Perubahan bagian dalam tersembunyi, jika hanya bagian depan tetap dengan pelacak yang diperlukan.
Begitulah. Untuk manajer, otomatisasi uji dikaitkan dengan satu keterampilan: bekerja dengan Selenium. Dalam mengejar peluru perak, mereka melihat dalam dirinya jawaban atas semua pertanyaan. Pasar telah disesuaikan dengan permintaan.
Kami telah lama mencari otomatisasi QA untuk menguji layanan web. Saya melihat beberapa ratus resume dan melakukan puluhan wawancara. Jika untuk meringkas tayangan, tiga masalah utama dapat dibedakan, yang sering mencegah seseorang dari mempekerjakan seseorang.
1. Penguji tidak tahu tentang arsitektur proyek
Di sini, berdasarkan arsitektur, maksud saya deskripsi tingkat tinggi dari interaksi komponen sistem. Secara konvensional, melalui “pipa” data mengalir, di mana mereka disimpan dan bagaimana mereka digunakan.
Selama wawancara, kandidat mungkin keberatan, kata mereka, kita tidak perlu pengetahuan arsitektur. Kami bekerja dengan kotak hitam. Mengapa merawat struktur internal?
Saya tidak percaya bahwa dengan pendekatan seperti itu insinyur akan membuat semua skenario pengujian yang mungkin. Jika Anda mengetahui struktur internal produk dan membaca kodenya, Anda dapat menghindari duplikasi tes pada tingkat tinggi piramida pengujian.
Varian piramida oleh Martin Fowler
Dalam pengujian kotak hitam, ada jebakan yang sama seperti dalam keamanan melalui ketidakjelasan . Anda tidak bisa hanya mengandalkan jenis pengujian ini. Produk ini dapat memenuhi persyaratan yang dinyatakan, sambil menyertakan sejumlah besar bug tersembunyi. Kemudian, dengan analogi dengan keamanan melalui ketidakjelasan, satu-satunya jaminan kualitas adalah ketidaktahuan kita tentang bagaimana sistem diatur di dalam.
Keuntungan dari pengujian kotak hitam adalah bahwa tes tidak tergantung pada implementasi. Wow Tetapi pembatasan buatan ini seharusnya tidak mengganggu pemahaman bagian dalam. Saat penguji tahu cara kerja produk:
- Dihadapkan dengan bug, ia mampu melokalisasi masalah, dan tidak membangun hipotesis.
- Pada pembahasan fitur baru, dia siap memberikan umpan balik, karena dia mengerti bagaimana fitur baru terintegrasi dengan komponen yang ada.
Malevich gelisah untuk menguji kotak hitam
Mungkin cinta yang sama untuk kotak hitam menyebabkan masalah kedua.
2. Penguji tidak mengerti apa yang terjadi di dalam browser
Seringkali ada situasi di mana seorang kandidat yang Selenium-nya diindikasikan sebagai alat utama dalam resume tidak mengerti bagaimana browser dan protokol HTTP bekerja. Pengujian untuk automators tersebut terutama adalah pembuatan skrip dengan tindakan pengguna. Pendekatan superfisial yang menciptakan batasan yang tidak perlu.
Kebanyakan pelamar memberi contoh contoh kode HTTP dan jenis permintaan HTTP. Pertanyaan selanjutnya sering membingungkan.
Ada halaman login. Pengguna memasukkan data yang benar untuk otorisasi dan klik pada tombol masuk. Apa yang terjadi di browser saat ini? Mengapa tindakan selanjutnya dengan situs tidak memerlukan otorisasi ulang?
Jika penguji tidak menjawab pertanyaan ini, keraguan tentang kompetensinya merayap masuk. Ini menunjukkan bahwa kandidat:
- tidak dapat menguji produk tanpa UI;
- Tidak tahu cara menggunakan Alat Pengembang di browser;
- Saya tidak terbiasa mencari tahu penyebab bug (frontend atau backend).
Akan lebih mudah bagi pengembang untuk memperbaiki bug jika dijelaskan dengan detail teknis.
3. Sikap lalai terhadap kode tes
"Kode saya tidak akan masuk ke produksi, mengapa peduli kualitas?"
Saya melihat ini sebagai upaya untuk membagi kotak pasir. Biarkan para pengembang menjaga kebersihan kode, tapi kami bisa.
Ingat, dalam model kaskade setelah pengembangan ada tahap verifikasi? Selama metodologi Waterfall, tanggung jawab untuk kualitas dipindahkan ke departemen pengujian. Itu tidak menghasilkan sesuatu yang baik. Programmer tidak memikirkan kesiapan fitur, mengharapkan QA untuk melaporkan masalah. Ping-pong antar departemen menyebabkan perlambatan dalam pembangunan. Ini adalah harga untuk berbagi tanggung jawab.
Dengan munculnya Agile, tim telah bergabung. "Kami" dan "mereka" yang hilang. Tim bertanggung jawab atas hasil akhir. Dan karena praktik teknik sudah menjadi hal yang umum, maka persyaratan untuk kode uji harus diajukan sama dengan kode produk.
Untuk keluar dari kandidat, kami mengirim tugas uji tanpa batas waktu:
Java http://todomvc.com/examples/react/
Daftar Kesalahan Umum
Komplikasi ekstra
Tumpukan abstraksi, pembungkus di atas kelas dan kode boilerplate di dalam tes.
Metode pengujian sebaiknya dibuat sesingkat mungkin. Fungsi pembantu dan memisahkan pengaturan dari tindakan pada objek dan pemeriksaan akan membantu dalam hal ini.
Pelanggaran konvensi untuk penamaan kelas, metode, variabel
CamelCase bercampur dengan garis bawah. Jadi mereka tidak memakainya sekarang. Linter dan petunjuk IDE simpan.
Jalur Bantuan Hardcode
String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
Klasik "bekerja pada mesin saya."
Penyimpanan file biner di dalam repositori
Ada git-lfs untuk menyelesaikan masalah ini.
Kurangnya konsistensi dalam metode
Dalam satu solusi, kandidat menggambarkan metode untuk menghapus dan menandai "selesai" seperti ini:
public void DeleteTask(String task) ... public void CompleteTask(int taskno)
Dalam metode pertama, teks tugas ditransmisikan, yang kedua, indeks dalam daftar. Menggunakan API semacam itu menyakitkan.
System.out.println() untuk logging
Itu tidak memberikan informasi pendukung di kelas mana peristiwa itu terjadi.
Menggunakan Thread.sleep
Untuk mengatasi masalah ini ada perpustakaan awaitility . Ini membantu untuk menambahkan umpan balik ke harapan pemenuhan kondisi yang diperlukan.
Pengecualian umum bukan asert
Contoh: tes menambahkan beberapa item ke daftar tugas dan menandai semua item sebagai selesai. Idenya adalah bahwa jika ada masalah, metode findElement akan mengembalikan NoSuchElementException dan tes akan NoSuchElementException . Jika nanti Anda melihat hasil uji coba, NoSuchElementException akan menyesatkan: tidak jelas apakah tes benar-benar jatuh atau kode kurva tes. Penting untuk menggunakan asert dengan pesan kesalahan yang jelas jika terjadi kegagalan pengujian.
Penyalahgunaan Bertic Acerts
assertTrue atau assertFalse digunakan untuk semuanya dalam satu baris:
assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
Lebih baik menggunakan assertEquals di sini untuk memiliki konteks ketika tes macet.
Tidak ada parameterisasi untuk menjalankan tes
Contoh: URL situs untuk pengujian dipaku dalam kode.
Kami juga harus menyebutkan bekerja dengan git . Paling sering, tugas dikirim dalam satu komit. Menulis pesan komit yang dapat dimengerti dan memecah tugas besar menjadi beberapa yang terpisah adalah keterampilan yang diperlukan, terutama dalam kerja tim.
Kesimpulan
Masalah yang dijelaskan di atas adalah pengalaman dan kesan pribadi saya setelah wawancara. Menurut pengamatan, pengalaman kandidat tidak berkorelasi dengan jumlah kesenjangan. Hindari penguji homeopati, menginvestasikan waktu dalam memompa keterampilan teknis karyawan. Penguji memiliki sesuatu untuk dipelajari dari pengembang dan sebaliknya. Semoga kekuatan datang bersama mereka yang membangun budaya rekayasa dan berenang melawan arus.
Saya akan senang keliru dan senang jika semuanya berbeda di perusahaan Anda yang disewa.
UPD 11/02/20 : Di webinar “Portrait of a tester”, saya membagikan pendapat saya tentang bagaimana saya melihat profesi dari dalam.
- Mengapa bisnis membutuhkan penguji?
- Peran penguji dalam tim
- Pengujian manual VS otomatis
- Aspek yang menarik dari profesi dan harga pengalaman
- Diperlukan keterampilan keras / lunak
- Kesalahan dalam resume profesional pemula
- Devops dalam pengujian
- Pertumbuhan karir