Mengapa kami mengadakan hackathon untuk penguji?

Artikel ini akan menarik minat mereka yang, seperti kami, menghadapi masalah memilih pakar yang sesuai dalam bidang ujian.

Anehnya, dengan peningkatan bilangan syarikat IT di republik kita, hanya bilangan pengaturcara yang layak meningkat, tetapi bukan penguji. Ramai orang tidak sabar-sabar untuk menceburi profesion ini, tetapi tidak ramai yang memahami maksudnya.

Saya tidak boleh bercakap untuk semua syarikat IT, tetapi kami telah menugaskan peranan QA/QC kepada pakar kualiti kami. Mereka adalah sebahagian daripada pasukan pembangunan dan mengambil bahagian dalam semua peringkat pembangunan, daripada penyelidikan hingga pengeluaran versi baharu.

Penguji dalam pasukan, walaupun di peringkat perancangan, mesti memikirkan semua keperluan berfungsi dan tidak berfungsi untuk menerima cerita pengguna. Dia mesti memahami ciri-ciri operasi produk serta pengaturcara, dan lebih baik lagi, dan membantu pasukan tidak membuat keputusan yang salah walaupun di peringkat perancangan. Penguji mesti mempunyai pemahaman yang jelas tentang cara kefungsian yang dilaksanakan akan berfungsi dan apakah masalah yang mungkin ada. Penguji kami membuat rancangan ujian dan kes ujian sendiri, serta menyediakan semua bangku ujian yang diperlukan. Menguji mengikut spesifikasi sedia seperti monyet clicker bukanlah pilihan kami. Bekerja dalam pasukan, dia mesti membantu mengeluarkan produk yang layak dan membunyikan penggera tepat pada masanya jika berlaku masalah.

Perkara yang kami temui semasa mencari penguji

Pada peringkat mengkaji banyak resume, nampaknya ada pakar yang mempunyai pengalaman yang sesuai untuk kami dan tidak akan ada masalah untuk memilih penguji untuk pasukan kami. Tetapi, semasa mesyuarat peribadi, kami semakin menemui calon yang sebenarnya agak jauh dari dunia teknologi maklumat (contohnya, mereka tidak dapat memberitahu prinsip interaksi antara penyemak imbas dan pelayan web, asas keselamatan, hubungan dan bukan- pangkalan data hubungan, mereka tidak tahu tentang virtualisasi dan kontena), tetapi pada masa yang sama menilai diri mereka di peringkat QA Kanan. Selepas menjalankan berpuluh-puluh temu bual, kami membuat kesimpulan bahawa bilangan pakar yang sesuai untuk kami di rantau ini adalah kecil.

Seterusnya, saya akan memberitahu anda apa langkah yang kami ambil dan apakah kesilapan yang kami lakukan untuk mencari pejuang yang telah lama ditunggu-tunggu untuk kualiti.

Bagaimana kami cuba membetulkan keadaan

Setelah meletihkan diri dengan mendapatkan pakar siap sedia, kami mula menyasarkan kawasan berdekatan:

1. Kami cuba menggunakan amalan penilaian untuk mengenal pasti antara ramai orang yang "tinggalkan", mereka yang daripadanya kami boleh membangunkan pakar yang kuat.

   Kami meminta sekumpulan calon berpotensi yang mempunyai tahap pengetahuan yang lebih kurang sama untuk menyelesaikan tugasan. Memerhatikan proses pemikiran mereka, kami cuba mengenal pasti calon yang paling menjanjikan.

   Khususnya, kami menghasilkan tugas untuk menguji perhatian, pemahaman tentang keupayaan teknologi dan ciri-ciri kepelbagaian budaya:

   
   

2. Kami mengadakan pertemuan untuk penguji untuk meluaskan sempadan pemahaman profesion dalam kalangan kontinjen sedia ada.

   Saya akan memberitahu anda sedikit tentang setiap daripada mereka.

   Ufa Software QA and Testing Meetup #1 ialah percubaan pertama kami untuk mengumpulkan mereka yang mengambil berat tentang profesion dan pada masa yang sama memahami sama ada orang ramai akan berminat dengan perkara yang ingin kami sampaikan kepada mereka. Pada asasnya, laporan kami adalah mengenai tempat yang lebih baik untuk bermula jika anda telah memutuskan untuk menjadi penguji. Bantu pemula membuka mata mereka dan melihat ujian seperti orang dewasa. Kami bercakap tentang langkah yang perlu diambil oleh penguji pemula untuk menyertai profesion. Mengenai kualiti dan bagaimana untuk mencapainya dalam keadaan sebenar. Dan juga, apakah ujian automatik dan di mana lebih sesuai untuk menggunakannya.

   
   
   Kemudian, dengan selang 1-2 bulan, kami mengadakan dua lagi pertemuan. Jumlah peserta sudah dua kali ganda. Di "Ufa Software QA and Testing Meetup #2" kami terjun lebih dalam ke dalam bidang subjek. Mereka bercakap tentang sistem penjejakan pepijat, ujian UI/UX, menyentuh Docker, Ansible, dan juga bercakap tentang kemungkinan konflik antara pembangun dan penguji serta cara untuk menyelesaikannya.

   Mesyuarat ketiga kami, "Ufa Software QA and Testing Meetup #3," secara tidak langsung berkaitan dengan kerja penguji, tetapi berguna dalam mengingatkan pengaturcara tepat pada masanya tentang tugas teknikal dan organisasi mereka: ujian beban, ujian e2e, Selenium dalam autoujian, kelemahan aplikasi web .

   Selama ini kami telah mempelajari cara mencipta cahaya dan bunyi biasa dalam siaran daripada acara kami:

   → Langkah pertama dalam ujian – Ufa Software QA and Testing Meetup #1
   → Ujian UI/UX – Ufa Software QA and Testing Meetup #2
   → Ujian keselamatan, ujian beban dan ujian auto – Ufa QA dan Testing Meetup #3

3. Dan akhirnya kami memutuskan untuk cuba mengadakan hackathon untuk penguji

Cara kami menyediakan dan menjalankan hackathon untuk penguji

Sebagai permulaan, kami cuba memahami jenis "binatang" ini dan bagaimana ia biasanya dijalankan. Ternyata, acara seperti ini tidak diadakan berkali-kali di Persekutuan Rusia, dan tidak ada tempat untuk meminjam idea. Kedua, saya tidak mahu segera melaburkan banyak sumber ke dalam acara yang kelihatan meragukan pada pandangan pertama. Oleh itu, kami memutuskan bahawa kami akan melakukan mini hackathon pendek, bukan untuk keseluruhan kitaran kerja QA, tetapi untuk peringkat individu.

Sakit kepala utama kami ialah kekurangan latihan dalam kalangan penguji tempatan dalam mencipta peta ujian yang jelas. Mereka tidak meluangkan masa untuk menyelidik cerita pengguna pra-pelaksanaan dan mencipta kriteria penerimaan yang jelas kepada pembangun untuk keperluan berfungsi dan tidak berfungsi, UI/UX, keselamatan, beban kerja dan beban puncak. Oleh itu, kami memutuskan, buat kali pertama, untuk melalui bahagian yang paling menarik dan kreatif kerja mereka - analisis dan pembentukan keperluan semasa penyelidikan pra-projek.

Kami menganggarkan potensi bilangan peserta dan memutuskan bahawa kami memerlukan sekurang-kurangnya 5 tunggakan untuk keluaran MVP, 5 produk dan 5 orang yang akan bertindak sebagai pemilik produk, menguraikan keperluan perniagaan dan membuat keputusan mengenai sekatan.

Inilah yang kami dapat: tunggakan untuk hackathon.

Idea utama adalah untuk menghasilkan topik yang sejauh mungkin dari semua kerja harian peserta dan memberi mereka ruang untuk penerbangan kreatif imaginasi.

Apakah kesilapan yang kita lakukan dan apa yang boleh kita lakukan dengan lebih baik?

Penggunaan amalan penilaian, yang begitu popular dalam bidang pengambilan jurujual dan pengurus peringkat rendah, mengambil banyak usaha, tetapi tidak membenarkan kami memberi perhatian yang mencukupi kepada setiap peserta dan menilai kebolehannya. Secara umum, pilihan pemilihan ini mewujudkan imej negatif syarikat, kerana agak ramai orang menerima maklum balas yang tidak mencukupi dan seterusnya mewujudkan dalam diri mereka dan orang lain kesan kezaliman majikan (komunikasi dalam komuniti IT sangat maju). Akibatnya, kita ditinggalkan dengan dua calon berpotensi dengan masa depan yang sangat jauh.

Pertemuan adalah perkara yang baik. Asas yang meluas untuk penghuraian dibuat, dan tahap umum peserta meningkat. Syarikat itu semakin dikenali di pasaran. Tetapi keamatan buruh usaha sedemikian bukanlah kecil. Anda perlu memahami dengan jelas bahawa mengadakan pertemuan akan mengambil masa kira-kira 700-800 jam kerja setahun.

Bagi ujian hackathon pula. Acara seperti ini belum lagi menjadi membosankan, kerana, tidak seperti hackathon untuk pembangun, ia diadakan dengan lebih jarang. Kelebihan idea ini ialah dengan cara yang santai anda boleh bertukar-tukar sejumlah besar pengetahuan praktikal dan dengan agak tepat menentukan tahap setiap peserta.

Selepas menganalisis keputusan acara itu, kami menyedari bahawa kami melakukan banyak kesilapan:

1. Kesilapan yang paling tidak boleh dimaafkan ialah mempercayai bahawa 4-5 jam sudah cukup untuk kita. Akibatnya, hanya pengenalan dan membiasakan diri dengan tunggakan mengambil masa hampir 2 jam.
   Bekerja dengan pemilik produk pada peringkat awal dan masa untuk menyelami bidang subjek mengambil masa yang sama. Jadi masa yang tinggal jelas tidak mencukupi untuk pembangunan komprehensif peta ujian.
2. Tiada masa dan tenaga yang mencukupi untuk maklum balas terperinci pada setiap peta, kerana hari sudah malam. Oleh itu, kami jelas gagal bahagian ini, tetapi pada mulanya bertujuan untuk menjadi yang paling berharga dalam hackathon.
3. Kami memutuskan untuk menilai kualiti pembangunan dengan undian mudah semua peserta, memperuntukkan 3 undian untuk setiap pasukan, yang boleh mereka berikan untuk kerja berkualiti tinggi. Mungkin lebih baik untuk menganjurkan juri.

Apa yang telah anda capai?

Kami telah menyelesaikan sebahagian masalah kami dan kini kami mempunyai 4 lelaki yang berani dan kacak bekerja untuk kami, meliputi bahagian belakang 4 pasukan pembangunan. Sekumpulan besar calon yang berpotensi kuat dan perubahan ketara dalam tahap komuniti QA bandar masih belum disedari. Tetapi terdapat sedikit kemajuan dan ini tidak boleh tidak bergembira.

Sumber: www.habr.com