Mengapa kami mengadakan hackathon untuk penguji?

Artikel ini akan menarik bagi mereka yang, seperti kita, dihadapkan pada masalah dalam memilih spesialis yang sesuai di bidang pengujian.

Anehnya, dengan bertambahnya jumlah perusahaan IT di republik kita, hanya jumlah programmer yang layak yang bertambah, tetapi tidak ada penguji. Banyak orang yang ingin sekali menekuni profesi ini, namun tidak banyak yang memahami maknanya.

Saya tidak dapat mewakili semua perusahaan IT, namun kami telah menugaskan peran QA/QC kepada spesialis kualitas kami. Mereka adalah bagian dari tim pengembangan dan berpartisipasi dalam semua tahap pengembangan, mulai dari penelitian hingga peluncuran versi baru.

Seorang penguji dalam sebuah tim, bahkan pada tahap perencanaan, harus memikirkan semua persyaratan fungsional dan non-fungsional untuk menerima cerita pengguna. Dia harus memahami karakteristik operasional produk serta programmer, dan bahkan lebih baik lagi, dan membantu tim agar tidak membuat keputusan yang salah bahkan pada tahap perencanaan. Penguji harus memiliki pemahaman yang jelas tentang cara kerja fungsionalitas yang diterapkan dan kendala apa yang mungkin ada. Penguji kami membuat rencana pengujian dan kasus pengujian sendiri, serta menyiapkan semua tempat pengujian yang diperlukan. Menguji menurut spesifikasi yang sudah jadi seperti clicker monyet bukanlah pilihan kami. Bekerja dalam tim, dia harus membantu merilis produk yang layak dan membunyikan alarm tepat waktu jika terjadi kesalahan.

Apa yang kami temui saat mencari penguji

Pada tahap mempelajari banyak resume, tampaknya ada spesialis dengan pengalaman yang sesuai untuk kami dan tidak akan ada masalah dalam memilih penguji untuk tim kami. Namun dalam pertemuan tatap muka, semakin sering kita menjumpai kandidat-kandidat yang sebenarnya cukup jauh dari dunia teknologi informasi (misalnya, mereka belum bisa menjelaskan prinsip interaksi antara browser dan web server, dasar-dasar keamanan, relasional dan non- database relasional, mereka tidak tahu tentang virtualisasi dan containerization), namun pada saat yang sama menilai diri mereka sendiri di tingkat QA Senior. Setelah melakukan lusinan wawancara, kami sampai pada kesimpulan bahwa jumlah spesialis yang cocok untuk kami di wilayah ini dapat diabaikan.

Selanjutnya, saya akan memberi tahu Anda langkah apa yang kami ambil dan kesalahan apa yang kami lakukan untuk menemukan pejuang kualitas yang telah lama ditunggu-tunggu itu.

Bagaimana kami mencoba memperbaiki situasi

Setelah kehabisan tenaga dalam mencari spesialis yang siap pakai, kami mulai menargetkan area terdekat:

1. Kami mencoba menerapkan praktik penilaian untuk mengidentifikasi di antara banyak orang yang “tinggalkan saja”, orang-orang yang dapat kami kembangkan sebagai spesialis yang kuat.

   Kami meminta sekelompok kandidat potensial dengan tingkat pengetahuan yang kurang lebih sama untuk menyelesaikan tugas. Mengamati proses berpikir mereka, kami mencoba mengidentifikasi kandidat yang paling menjanjikan.

   Secara khusus, kami memberikan tugas untuk menguji perhatian, pemahaman tentang kemampuan teknologi dan ciri-ciri multikulturalisme:

   
   

2. Kami mengadakan pertemuan bagi para penguji untuk memperluas batas pemahaman profesi di antara kontingen yang ada.

   Saya akan bercerita sedikit tentang masing-masingnya.

   Ufa Software QA and Testing Meetup #1 merupakan upaya pertama kami untuk mengumpulkan pihak-pihak yang peduli dengan profesinya sekaligus memahami apakah masyarakat akan tertarik dengan apa yang ingin kami sampaikan kepada mereka. Pada dasarnya, laporan kami adalah tentang di mana sebaiknya memulai jika Anda telah memutuskan untuk menjadi penguji. Bantu pemula membuka mata mereka dan melihat ujian seperti orang dewasa. Kami berbicara tentang langkah-langkah yang perlu diambil oleh penguji pemula untuk bergabung dengan profesi ini. Tentang apa itu kualitas dan bagaimana mencapainya dalam kondisi nyata. Dan juga, apa itu pengujian otomatis dan di mana lebih tepat menggunakannya.

   
   
   Kemudian dengan selang waktu 1-2 bulan, kami mengadakan dua pertemuan lagi. Pesertanya sudah dua kali lebih banyak. Pada “Ufa Software QA and Testing Meetup #2” kami mendalami lebih dalam bidang subjek. Mereka berbicara tentang sistem pelacakan bug, pengujian UI/UX, menyentuh Docker, Ansible, dan juga berbicara tentang kemungkinan konflik antara pengembang dan penguji serta cara mengatasinya.

   Pertemuan ketiga kami, “Ufa Software QA and Testing Meetup #3,” secara tidak langsung terkait dengan pekerjaan penguji, namun berguna untuk mengingatkan pemrogram secara tepat waktu tentang tugas teknis dan organisasi mereka: pengujian beban, pengujian e2e, Selenium dalam pengujian otomatis, kerentanan aplikasi web .

   Selama ini kami telah mempelajari cara membuat cahaya dan suara normal dalam siaran acara kami:

   → Langkah pertama dalam pengujian – Ufa Software QA dan Testing Meetup #1
   → Pengujian UI/UX – QA Perangkat Lunak Ufa dan Pertemuan Pengujian #2
   → Pengujian keamanan, pengujian beban, dan pengujian otomatis – Ufa QA dan Testing Meetup #3

3. Dan pada akhirnya kami memutuskan untuk mencoba mengadakan hackathon untuk para penguji

Bagaimana kami mempersiapkan dan mengadakan hackathon untuk penguji

Untuk memulainya, kami mencoba memahami “binatang” macam apa ini dan bagaimana hal itu biasanya dilakukan. Ternyata, acara semacam ini sudah jarang diadakan di Federasi Rusia, dan tidak ada tempat untuk meminjam ide. Kedua, saya tidak ingin segera menginvestasikan banyak sumber daya ke dalam suatu peristiwa yang sekilas tampak meragukan. Oleh karena itu, kami memutuskan bahwa kami akan melakukan mini-hackathon singkat, bukan untuk seluruh siklus kerja QA, tetapi untuk tahapan individu.

Masalah utama kami adalah kurangnya latihan di antara penguji lokal dalam membuat peta pengujian yang jelas. Mereka tidak menghabiskan waktu untuk meneliti cerita pengguna pra-implementasi dan membuat kriteria penerimaan yang jelas bagi pengembang untuk persyaratan fungsional dan non-fungsional, UI/UX, keamanan, beban kerja, dan beban puncak. Oleh karena itu, kami memutuskan, untuk pertama kalinya, untuk menjalani bagian paling menarik dan kreatif dari pekerjaan mereka - analisis dan pembentukan persyaratan selama penelitian pra-proyek.

Kami memperkirakan potensi jumlah peserta dan memutuskan bahwa kami memerlukan setidaknya 5 simpanan untuk rilis MVP, 5 produk, dan 5 orang yang akan bertindak sebagai pemilik produk, menguraikan kebutuhan bisnis, dan membuat keputusan mengenai pembatasan.

Inilah yang kami dapatkan: simpanan untuk hackathon.

Ide utamanya adalah untuk memunculkan topik-topik yang jauh dari pekerjaan sehari-hari para peserta dan memberi mereka ruang untuk mengembangkan imajinasi kreatif.

Kesalahan apa yang kami buat dan apa yang bisa kami lakukan dengan lebih baik?

Penggunaan praktik penilaian, yang begitu populer di bidang perekrutan tenaga penjualan dan manajer tingkat bawah, membutuhkan banyak usaha, namun tidak memungkinkan kami untuk memberikan perhatian yang cukup kepada setiap peserta dan mengevaluasi kemampuannya. Secara umum, opsi seleksi ini menciptakan citra negatif perusahaan, karena cukup banyak orang yang menerima umpan balik yang tidak memadai dan kemudian menimbulkan efek tirani pemberi kerja pada diri mereka sendiri dan orang lain (komunikasi dalam komunitas TI sangat berkembang). Akibatnya, kita hanya mempunyai dua kandidat potensial dengan masa depan yang sangat jauh.

Pertemuan adalah hal yang baik. Basis ekstensif untuk elaborasi tercipta, dan tingkat umum peserta meningkat. Perusahaan ini menjadi semakin dikenal di pasar. Namun intensitas tenaga kerja dari usaha semacam itu tidaklah kecil. Anda perlu memahami dengan jelas bahwa mengadakan pertemuan akan memakan waktu sekitar 700-800 jam kerja per tahun.

Sedangkan untuk pengujian hackathon. Acara seperti ini masih belum membosankan, karena tidak seperti hackathon untuk developer, acara ini lebih jarang diadakan. Keuntungan dari ide ini adalah dengan cara yang santai Anda dapat bertukar banyak pengetahuan praktis dan menentukan level masing-masing peserta dengan cukup akurat.

Setelah menganalisis hasil acara, kami menyadari bahwa kami melakukan banyak kesalahan:

1. Kesalahan yang paling tidak bisa dimaafkan adalah percaya bahwa 4-5 jam sudah cukup bagi kami. Alhasil, pengenalan dan pengenalan backlog saja memakan waktu hampir 2 jam.
   Bekerja dengan pemilik produk pada tahap awal dan waktu untuk mendalami area subjek membutuhkan jumlah waktu yang sama. Jadi waktu yang tersisa jelas tidak cukup untuk pengembangan peta pengujian secara menyeluruh.
2. Tidak ada cukup waktu dan tenaga untuk mendapatkan masukan mendetail pada setiap peta, karena hari sudah malam. Oleh karena itu, kami jelas gagal dalam bagian ini, tetapi awalnya dimaksudkan untuk menjadi yang paling berharga dalam hackathon.
3. Kami memutuskan untuk mengevaluasi kualitas pengembangan dengan pemungutan suara sederhana dari semua peserta, mengalokasikan 3 suara untuk setiap tim, yang dapat mereka berikan untuk pekerjaan dengan kualitas terbaik. Mungkin akan lebih baik jika membentuk juri.

Apa yang telah Anda capai?

Kami telah menyelesaikan sebagian masalah kami dan sekarang kami memiliki 4 pria pemberani dan tampan yang bekerja untuk kami, bertugas di belakang 4 tim pengembangan. Sejumlah besar kandidat potensial yang kuat dan perubahan nyata pada tingkat komunitas QA di kota tersebut belum terlihat. Namun ada beberapa kemajuan dan ini merupakan kabar baik.

Sumber: www.habr.com