Hari ini, dunia merayakan hari penguji. Pada kesempatan ini, kami memutuskan untuk membantu Anda melihat pekerjaan para spesialis ini dari sudut pandang yang berbeda, sehingga kerja sama akan membawa semua peserta manfaat maksimum dan stres minimum.
Kredit Foto: David Goehring CC BY
1. "Periksa lagi, pasti tidak ada bug"
Mari kita mulai dengan masalah mendasar. Forum Ars Technica memiliki utas lama di mana satu pengembang berbicara tentang kebencian mendalam terhadap penguji "pedantic". Dia sangat kesal karena beberapa ahli pengujian menghabiskan berjam-jam mencari bug terkecil. Dan apa yang paling tidak menyenangkan, mereka masih menemukannya.
Apa yang bisa salah : Tidak semua orang siap mengakui kesalahan mereka. Seseorang memulai lagu lama tentang "bukan bug, tetapi fitur", mencoba membuktikan bahwa semuanya dimaksudkan. Yang lain terus-menerus meminta untuk memeriksa ulang kode dan memastikan bahwa tidak ada bug. Penguji hanya mencoba melakukan pekerjaannya dengan baik, dan bukannya berterima kasih ia dikirim untuk pemeriksaan ulang.
Cara menjadi : Sederhana: jika penguji menemukan kesalahan dalam kode Anda dan Anda mengerti bahwa ia benar, lebih baik untuk mengakui fakta ini. Anda berdua memiliki satu dan tujuan yang sama - untuk merilis produk debugged dan berfungsi. Humor membantu untuk memahami masalah ini. Berikut adalah artikel di mana penguji mengumpulkan "dana emas" pernyataan oleh pengembang yang berusaha melindungi kode mereka. Kami menyarankan Anda untuk membahasnya dan bayangkan bagaimana ungkapan "klasik" ini terdengar dari sudut pandang penguji.
2. “Seminggu sebelum rilis. Saya harap Anda belum merencanakan hal-hal lain untuk dua hari ke depan. "
Terkadang kode datang ke penguji beberapa hari sebelum rilis. Kemudian mereka harus bekerja dengan tergesa-gesa. Beberapa ahli QA percaya bahwa kolega hanya meremehkan pekerjaan mereka. Diduga, mereka berpikir bahwa menemukan bug itu mudah dan cepat, jadi mereka menunda debugging pada saat terakhir.
Apa yang salah : Dalam keadaan darurat, penguji tidak hanya merasa terganggu, tetapi kehilangan kewaspadaan mereka. Kurangnya waktu adalah salah satu alasan utama penguji melewatkan bug.
Bagaimana menjadi : Ada beberapa model pengembangan. Dari sudut pandang QA, ada dua pendekatan utama: cascading dan Agile. Dalam kasus pertama, penguji menerima fragmen kode secara bertahap. Dalam kasus kedua, mereka menguji kode secara paralel dengan tulisannya.
Agile membantu melibatkan para profesional QA dalam proyek sejak dini. Berkat ini, Anda tidak perlu menguji "satu jam sebelum rilis". Selain itu, pendekatan ini memungkinkan untuk tidak menemukan bug, tetapi untuk mencegah terjadinya bug. Jika penguji Anda mengeluh tentang tekanan waktu yang konstan dan kehilangan bug, lihat metodologi ini.
Foto: Tim Regan CC BY
3. “Saya dengan cepat mengubah kode. Tolong lihat. "
Misalkan tim Anda bekerja pada model berjenjang dan tahu bagaimana merencanakan fase pengembangan dengan benar. Penguji mendapatkan kode, dan tampaknya ada cukup waktu untuk debugging. Tetapi pengembang memiliki kebiasaan membuat upaya minimum pada tahap ini. Mereka menerima laporan bug terperinci, membacanya di permukaan, dengan cepat menghilangkan kesalahan yang jelas dan mengirim kode ke siklus pengujian berikutnya.
Apa yang salah : Masalahnya adalah bahwa kode setelah perubahan dangkal sering kembali dengan bug lebih banyak lagi. Penguji menghabiskan waktu menyiapkan laporan terperinci, dan sebagai tanggapannya menerima semacam balasan. Dia harus melakukannya beberapa kali lagi hanya karena pengembang tidak ingin menghabiskan waktu untuk "bug minor".
Bagaimana menjadi : Jelas, jangan terburu-buru. Tetapi ini tidak cukup. Anda perlu mencari tahu mengapa Anda tidak memperhatikan laporan. Jika ini adalah kemalasan dangkal, hanya Anda yang bisa membantu diri Anda sendiri. Ada alasan lain. Misalnya, Anda berpikir bahwa teknisi QA membanjiri Anda dengan laporan bug yang tidak signifikan. Maka Anda perlu mengklarifikasi masalah ini di tingkat kepemimpinan - jika penguji mengalihkan Anda "dalam detail." Kemungkinan besar, jawabannya adalah ya. Beberapa manajer produk bahkan meminta pengembang untuk secara khusus menambahkan bug kecil ke kode sehingga penguji selalu waspada. Penting untuk mengambil pendekatan ini dan memperlakukan laporan bug dengan perhatian penuh.
4. “Sepertinya saya sudah menangani bug ini. Tapi saya tidak ingat persis ”
Terkadang pendekatan yang dangkal adalah masalah sistemik. Di beberapa tim, laporan bug hilang dalam waktu dan ruang. Tidak ada yang menanggapi laporan dengan benar, tidak menandai apakah masalah telah diselesaikan atau masih dalam kesulitan.
Apa yang bisa salah : Pengembang memperbaiki beberapa jenis bug, membuat apa yang mereka anggap sebagai perubahan "minor" pada kode, lupa untuk memberi tahu penguji tentang hal ini, dan mengirim kode ke rilis. Akibatnya, masalah muncul ketika sudah terlambat. Dan penguji sering kali yang "ekstrem".
Bagaimana menjadi : Masalah kekacauan perlu diselesaikan secara sistematis. Kekacauan merusak perkembangan, sehingga Anda harus sepenuhnya merestrukturisasi proses komunikasi dalam tim. Di sini ada baiknya menggunakan tip dasar untuk membangun komunikasi antara pengembang dan QA-engineer: untuk menentukan terminologi; merumuskan dengan jelas persyaratan; memperkenalkan hierarki prioritas untuk berbagai bug. Adapun kebingungan dengan bug, ada tips praktis yang baik: a) biarkan bug melaporkan semuanya; b) maka penting untuk memprioritaskannya; c) bug apa pun yang ditutup menyiratkan bahwa tes fungsional akan ditulis; d) status "diselesaikan" ditetapkan bukan oleh pengembang, tetapi oleh tester. Pendekatan ini memastikan bahwa masalahnya benar-benar terselesaikan.
Foto: Tim Regan CC BY
5. "Mengapa saya harus menguji ini? Saya bukan penguji! ”
Di beberapa tim, tanggung jawab untuk debugging sepenuhnya berada pada penguji. Pengembang tidak repot-repot membuang waktu untuk unit test yang paling jelas. Mereka yakin ini bukan pekerjaan mereka. Secara umum, memang, meskipun ada sudut pandang yang berbeda tentang masalah ini (dengan pandangan masyarakat dapat ditemukan di sini ).
Apa yang bisa salah : Penguji dalam situasi ini harus berurusan dengan semua kekurangan berturut-turut - bahkan dengan kesalahan paling primitif dan bodoh. Tentu saja, ini menyebalkan.
Bagaimana menjadi : Banyak pengembang menyukai tes independen sebelum dikirim ke departemen QA. Ini membantu tidak hanya untuk meringankan penguji, tetapi juga untuk belajar melihat produk dari sudut pandang kritik dan pengguna. Dipercayai bahwa ini bermanfaat bagi para profesional dan memiliki efek terbaik pada hasil akhirnya. Bagi mereka yang tidak ingin menyusahkan diri dengan cek, ada alat otomatis. Mereka membantu menemukan bug yang paling jelas. Bagaimanapun, bahkan jika tim memiliki insinyur QA, pemisahan yang ketat antara pengembang dan QA bukanlah pendekatan terbaik.
6. “Igor, hari ini kau bekerja bersama Oleg. Anda akan menyukainya
Manajer produk tidak terbatas pada pendekatan cascading dan Agile. Beberapa dari mereka suka bereksperimen. Misalnya, mengatur pemrograman pasangan dan sesi pengujian.
Apa yang salah : Ini adalah cara yang efektif untuk menangkap serangga, tetapi juga memiliki kelemahan - orang mungkin tidak antusias dengan inovasi. Seorang spesialis QA, yang terbiasa bekerja sendirian, di lantai lain dan di peralatannya, mungkin merasa tidak nyaman meninggalkan lingkungan yang akrab. Selain itu, ia mungkin tidak basi dengan pengalaman dan pengetahuan pasangannya. Akibatnya, alih-alih tes produktif, manajer produk mendapatkan dua karyawan yang tidak puas.
Bagaimana menjadi : Saran utama adalah jangan memenggal bahu Anda. Praktik lincah dan DevOps mungkin tampak menarik, tetapi tanpa persiapan yang tepat mereka tidak akan berhasil.
7. "Saya akan mengambil perangkat Anda untuk pengujian, apakah Anda keberatan?"
Pengembang memiliki waktu untuk memulai debugging, ia meminta tester untuk perangkat uji "secara harfiah selama 20 menit" dan meninggalkannya berjam-jam.
Apa yang salah : Paling sering, pengembang tidak mengembalikan perangkat ke tempatnya sama sekali, dan jika itu terjadi, itu benar-benar habis. Menimbang bahwa penguji dapat memiliki tugas paralel pada perangkat ini, ini tidak bisa tidak mengganggu.
Bagaimana menjadi : Tempatkan diri Anda pengingat, tempel stiker, lakukan apa saja, tapi tolong kembalikan barang-barang penguji ke tempat mereka dan tepat waktu.
Foto: Dave Allen CC OLEH
Dan saran utama untuk pengembang dan manajer produk, yang menyarankan dirinya dari semua yang sebelumnya: menghormati pekerjaan dan waktu orang lain, dan sesering mungkin menempatkan diri Anda di tempat penguji. Lagi pula, jika bukan karena dia, seluruh dunia akan tahu tentang bug Anda.