Napa kita nganakake hackathon kanggo penguji?

Artikel iki bakal dadi kapentingan kanggo wong-wong sing, kaya kita, ngadhepi masalah milih spesialis cocok ing lapangan testing.

Anehe, kanthi tambah akeh perusahaan IT ing republik kita, mung jumlah programer sing pantes mundhak, nanging dudu penguji. Akeh wong sing kepengin banget mlebu profesi iki, nanging ora akeh sing ngerti maknane.

Aku ora bisa ngomong kanggo kabeh perusahaan IT, nanging kita wis diutus peran QA / QC kanggo spesialis kualitas. Dheweke dadi bagean saka tim pangembangan lan melu ing kabeh tahap pangembangan, saka riset nganti rilis versi anyar.

Penguji ing tim, sanajan ing tahap perencanaan, kudu mikirake kabeh syarat fungsional lan non-fungsi kanggo nampa crita pangguna. Dheweke kudu ngerti karakteristik operasional produk uga programer, lan luwih apik, lan mbantu tim supaya ora nggawe keputusan sing salah sanajan ing tahap perencanaan. Penguji kudu duwe pangerten sing jelas babagan cara fungsi sing diimplementasikake lan apa sing bisa ditindakake. Penguji kita nggawe rencana tes lan kasus tes dhewe, uga nyiyapake kabeh bangku tes sing dibutuhake. Nguji miturut spesifikasi sing wis siap kaya klik monkey dudu pilihan kita. Makarya ing tim, dheweke kudu mbantu ngeculake produk sing cocog lan muni weker ing wektu yen ana masalah.

Apa sing ditemokake nalika nggoleki penguji

Ing tataran sinau akeh resume, misale jek ana spesialis karo pengalaman cocok kanggo kita lan ora bakal ana masalah karo milih tester kanggo tim kita. Nanging, sajrone rapat-rapat pribadi, kita tambah akeh ketemu calon sing bener-bener adoh saka jagad teknologi informasi (contone, dheweke ora bisa nyritakake prinsip interaksi antarane browser lan server web, dhasar keamanan, hubungan lan non- database relasional, padha ora idea bab virtualization lan containerization), nanging ing wektu sing padha kabiji piyambak ing tingkat Senior QA. Sawise nindakake puluhan wawancara, kita nyimpulake manawa jumlah spesialis sing cocog kanggo kita ing wilayah kasebut ora diabaikan.

Sabanjure, aku bakal menehi pitutur marang kowe apa langkah-langkah sing ditindakake lan kesalahan apa sing ditindakake kanggo nemokake para pejuang sing wis ditunggu-tunggu kanggo kualitas.

Carane kita nyoba kanggo ndandani kahanan

Sawise kesel banget karo spesialis sing wis siap, kita wiwit target wilayah sing cedhak:

1. Kita nyoba ngetrapake praktik penilaian kanggo ngenali ing antarane akeh wong sing "ninggalake", sing bisa nggawe spesialis sing kuwat.

   Kita takon klompok calon potensial kanthi tingkat kawruh sing padha kanggo ngrampungake tugas. Ngamati proses pamikirane, kita nyoba ngenali calon sing paling njanjeni.

   Utamane, kita entuk tugas kanggo nguji perhatian, pangerten babagan kemampuan teknologi lan fitur multikulturalisme:

   
   

2. Kita nganakake temu kanggo para penguji kanggo nggedhekake wates pangerten babagan profesi ing antarane kontingen sing ana.

   Aku bakal ngandhani sampeyan sethithik babagan saben wong.

   Ufa Software QA lan Testing Meetup #1 minangka upaya pertama kita kanggo ngumpulake wong-wong sing peduli karo profesi kasebut lan uga ngerti manawa masarakat bakal kasengsem karo apa sing arep kita aturakake. Sejatine, laporan kita babagan endi sing luwih apik kanggo miwiti yen sampeyan wis mutusake dadi tester. Mbantu pamula mbukak mata lan ndeleng testing kaya wong diwasa. Kita ngomong babagan langkah-langkah sing kudu ditindakake para penguji pemula kanggo gabung ing profesi kasebut. Babagan apa kualitas lan carane entuk ing kahanan nyata. Lan uga, apa tes otomatis lan ing ngendi luwih cocog kanggo nggunakake.

   
   
   Banjur, kanthi interval 1-2 sasi, kita nganakake rong pertemuan maneh. Wis ping pindho pesertane. Ing "Ufa Software QA and Testing Meetup #2" kita luwih jero menyang area subyek. Dheweke ngomong babagan sistem pelacakan bug, tes UI / UX, ndemek Docker, Ansible, lan uga ngomong babagan kemungkinan konflik antarane pangembang lan panguji lan cara kanggo ngatasi.

   Rapat katelu kita, "Ufa Software QA and Testing Meetup #3," ora langsung ana hubungane karo karya penguji, nanging migunani kanggo ngelingake programer kanthi tepat wektu babagan tugas teknis lan organisasi: testing load, testing e2e, Selenium ing autotesting, kerentanan aplikasi web .

   Kabeh wektu iki kita wis sinau carane nggawe cahya lan swara normal ing siaran saka acara kita:

   → Langkah pisanan ing testing - Ufa Software QA lan Testing Meetup #1
   → Pengujian UI/UX - Ufa Software QA and Testing Meetup #2
   → Tes keamanan, tes beban lan tes otomatis - Ufa QA lan Testing Meetup #3

3. Lan ing pungkasan kita mutusake kanggo nyoba nyekel hackathon kanggo penguji

Kepiye kita nyiapake lan nganakake hackathon kanggo penguji

Kanggo miwiti, kita nyoba kanggo ngerti apa jenis "kewan" iki lan carane iku biasane dileksanakake. Minangka ternyata, acara kaya iki ora dianakake kaping pirang-pirang ing Federasi Rusia, lan ora ana ngendi wae kanggo nyilih gagasan. Kapindho, aku ora pengin langsung nandur modal akeh sumber daya menyang acara sing katon ragu-ragu. Mulane, kita mutusake yen kita bakal nindakake mini-hackathon cendhak, ora kanggo kabeh siklus kerja QA, nanging kanggo tahap individu.

Sakit kepala utama kita yaiku kekurangan praktik ing antarane penguji lokal kanggo nggawe peta uji coba sing jelas. Dheweke ora mbuwang wektu kanggo nliti crita pangguna pra-implementasi lan nggawe kritéria panrima sing jelas kanggo pangembang kanggo syarat fungsional lan non-fungsi, UI / UX, keamanan, beban kerja lan beban puncak. Mulane, kita mutusake, kanggo pisanan, kanggo ngliwati bagean sing paling menarik lan kreatif saka karya - analisis lan pambentukan syarat sajrone riset pra-proyek.

Kita ngira jumlah potensial peserta lan mutusake yen kita butuh paling ora 5 backlogs kanggo rilis MVP, 5 produk lan 5 wong sing bakal dadi pamilik produk, decipher kabutuhan bisnis lan nggawe keputusan babagan watesan.

Punika ingkang kita pikantuk: backlogs kanggo hackathon.

Ide utama yaiku nggawe topik sing adoh saka kabeh karya saben peserta lan menehi ruang kanggo imajinasi kreatif.

Kesalahan apa sing kita lakoni lan apa sing bisa kita lakoni luwih apik?

Panggunaan praktik penilaian, sing populer banget ing bidang nyewa salespeople lan manajer tingkat ngisor, njupuk akeh gaweyan, nanging ora ngidini kita menehi perhatian sing cukup kanggo saben peserta lan ngevaluasi kemampuane. Umumé, pilihan pilihan iki nggawe gambar negatif saka perusahaan, amarga cukup akèh wong nampa saran ora cukup lan salajengipun nggawe ing awake dhewe lan liyane efek tirani juragan (komunikasi ing komunitas IT banget dikembangaké). Akibaté, kita ditinggalake kanthi rong calon potensial kanthi masa depan sing adoh banget.

Meetups iku apik. Basis ekstensif kanggo elaborasi digawe, lan tingkat umum peserta mundhak. Perusahaan kasebut dadi luwih dikenal ing pasar. Nanging intensitas tenaga kerja ing perusahaan kasebut ora sithik. Sampeyan kudu ngerti kanthi jelas manawa nganakake rapat bakal njupuk kira-kira 700-800 jam kerja saben taun.

Minangka kanggo testing hackathon. Acara kaya iki durung mboseni, amarga, ora kaya hackathon kanggo pangembang, luwih jarang dianakake. Kauntungan saka ide iki yaiku kanthi santai sampeyan bisa ngganti akeh kawruh praktis lan cukup akurat nemtokake level saben peserta.

Sawise nganalisa asil acara kasebut, kita nyadari manawa akeh kesalahan:

1. Kesalahan sing paling ora bisa diapura yaiku percaya yen 4-5 jam bakal cukup kanggo kita. Akibaté, mung introduksi lan familiarization karo backlogs njupuk meh 2 jam.
   Nggarap pamilik produk ing tahap wiwitan lan wektu kanggo nyilem menyang area subyek njupuk wektu sing padha. Dadi wektu sing isih ana jelas ora cukup kanggo pangembangan peta tes sing komprehensif.
2. Ora ana cukup wektu lan energi kanggo umpan balik rinci ing saben peta, amarga wis wengi. Mulane, kita jelas gagal bagean iki, nanging wiwitane dimaksudake dadi sing paling berharga ing hackathon.
3. We mutusaké kanggo ngira-ngira kualitas pembangunan dening voting prasaja kabeh peserta, allocating 3 votes kanggo saben tim, kang padha bisa menehi kanggo karya kualitas paling dhuwur. Mbok menawa luwih apik kanggo ngatur juri.

Apa sing wis digayuh?

Kita wis sebagian ditanggulangi masalah kita lan saiki kita duwe 4 wani, nggantheng wong makarya kanggo kita, panutup mburi 4 tim pembangunan. A blumbang pinunjul saka calon kuwat potensial lan owah-owahan nyoto ing tingkat masyarakat QA kutha kang durung ngeweruhi. Nanging ana sawetara kemajuan lan iki ora bisa nanging bungah.

Source: www.habr.com