Varför höll vi ett hackathon för testare?

Den här artikeln kommer att vara av intresse för dem som, som vi, står inför problemet med att välja en lämplig specialist inom testområdet.

Märkligt nog, med ökningen av antalet IT-företag i vår republik ökar bara antalet värdiga programmerare, men inte testare. Många människor är ivriga att komma in i detta yrke, men inte många förstår dess innebörd.

Jag kan inte tala för alla IT-företag, men vi har tilldelat rollen som QA/QC till våra kvalitetsspecialister. De är en del av utvecklingsteamet och deltar i alla utvecklingsstadier, från forskning till release av en ny version.

En testare i ett team måste, även på planeringsstadiet, tänka igenom alla funktionella och icke-funktionella krav för att acceptera en användarberättelse. Han måste förstå produktens operativa egenskaper såväl som programmerare, och ännu bättre, och hjälpa teamet att inte fatta felaktiga beslut även på planeringsstadiet. Testaren måste ha en klar förståelse för hur den implementerade funktionaliteten kommer att fungera och vilka fallgropar det kan finnas. Våra testare skapar själva testplaner och testfall, samt förbereder alla nödvändiga testbänkar. Att testa enligt en färdig specifikation som en apaklicker är inte vårt alternativ. Genom att arbeta inom teamet måste han hjälpa till att släppa en värdig produkt och slå larm i tid om något går fel.

Vad vi stötte på när vi letade efter testare

I stadiet av att studera många meritförteckningar verkade det som om det fanns specialister med lämplig erfarenhet för oss och det skulle inte vara några problem med att välja en testare för vårt team. Men under personliga möten stötte vi i allt högre grad på kandidater som faktiskt var ganska långt ifrån informationsteknologins värld (de kunde till exempel inte berätta principerna för interaktion mellan en webbläsare och en webbserver, grunderna för säkerhet, relationella och icke- relationsdatabaser hade de ingen aning om virtualisering och containerisering), men bedömde sig samtidigt på Senior QA-nivå. Efter att ha genomfört dussintals intervjuer kom vi till slutsatsen att antalet specialister som är lämpliga för oss i regionen är försumbart.

Därefter kommer jag att berätta vilka steg vi tog och vilka misstag vi trampade på för att hitta de efterlängtade fighters för kvalitet.

Hur vi försökte fixa situationen

Efter att ha utmattat oss med att hitta färdiga specialister började vi rikta in oss på närliggande områden:

1. Vi försökte tillämpa bedömningsmetoder för att identifiera bland de många ”leave-it”-personer, just de som vi kan utveckla starka specialister från.

   Vi bad en grupp potentiella kandidater med ungefär samma kunskapsnivå att utföra uppgifter. Genom att observera deras tankeprocess försökte vi identifiera den mest lovande kandidaten.

   I synnerhet kom vi på uppgifter för att testa uppmärksamhet, förståelse för teknikens möjligheter och funktionerna i mångkultur:

   
   

2. Vi höll möten för testare för att utöka gränserna för förståelse för yrket bland den befintliga kontingenten.

   Jag ska berätta lite om var och en av dem.

   Ufa Software QA and Testing Meetup #1 är vårt första försök att samla de som bryr sig om yrket och samtidigt förstå om allmänheten kommer att vara intresserad av vad vi vill förmedla till dem. I grund och botten handlade våra rapporter om var det är bättre att börja om du har bestämt dig för att bli testare. Hjälp nybörjare att öppna ögonen och se på att testa som en vuxen. Vi pratade om de steg som nybörjare testare måste ta för att gå med i yrket. Om vad kvalitet är och hur man uppnår det under verkliga förhållanden. Och även, vad är automatisk testning och var det är lämpligare att använda det.

   
   
   Sedan, med 1-2 månaders mellanrum, höll vi två möten till. Det var redan dubbelt så många deltagare. På "Ufa Software QA and Testing Meetup #2" kastade vi oss djupare in i ämnesområdet. De pratade om buggspårningssystem, UI/UX-testning, berörde Docker, Ansible och pratade även om möjliga konflikter mellan en utvecklare och en testare och sätt att lösa dem.

   Vårt tredje möte, "Ufa Software QA and Testing Meetup #3," relaterade indirekt till testarnas arbete, men var användbart för att i rätt tid påminna programmerare om deras tekniska och organisatoriska uppgifter: belastningstestning, e2e-testning, Selen i autotestning, webbapplikationssårbarheter .

   Hela den här tiden har vi lärt oss hur man skapar normalt ljus och ljud i sändningar från våra evenemang:

   → Första stegen i testning – Ufa Software QA och Testing Meetup #1
   → UI/UX-testning – Ufa Software QA och Testing Meetup #2
   → Säkerhetstestning, lasttestning och autotestning – Ufa QA och Testing Meetup #3

3. Och till slut bestämde vi oss för att försöka hålla ett hackathon för testare

Hur vi förberedde och genomförde ett hackathon för testare

Till att börja med försökte vi förstå vilken typ av "odjur" detta är och hur det vanligtvis utförs. Som det visade sig har evenemang av detta slag inte hållits många gånger i Ryska federationen, och det finns ingenstans att låna idéer. För det andra ville jag inte omedelbart investera mycket resurser i en händelse som vid första anblicken verkade tveksam. Därför bestämde vi oss för att göra korta minihackathon, inte för hela QA-arbetscykeln, utan för enskilda etapper.

Vår huvudsakliga huvudvärk är bristen på övning bland lokala testare för att skapa tydliga testkartor. De lägger inte ner tid på att undersöka pre-implementation user stories och skapa acceptanskriterier som är tydliga för utvecklare för funktionella och icke-funktionella krav, UI/UX, säkerhet, arbetsbelastningar och toppbelastningar. Därför bestämde vi oss för att för första gången gå igenom den mest intressanta och kreativa delen av deras arbete - analys och kravbildning under förprojektforskning.

Vi uppskattade det potentiella antalet deltagare och beslutade att vi behövde minst 5 eftersläpningar för MVP-releaser, 5 produkter och 5 personer som skulle fungera som produktägare, dechiffrera affärsbehov och fatta beslut om begränsningar.

Här är vad vi fick: eftersläpningar för hackathon.

Huvudtanken var att komma på ämnen som låg så långt borta från alla deltagares dagliga arbete som möjligt och ge dem utrymme för en kreativ fantasiflykt.

Vilka misstag gjorde vi och vad kan vi göra bättre?

Användningen av bedömningsmetoder, så populär inom området för att anställa säljare och chefer på lägre nivå, tog en enorm ansträngning, men tillät oss inte att ägna tillräcklig uppmärksamhet åt varje deltagare och utvärdera hans förmågor. I allmänhet skapar detta urvalsalternativ en negativ bild av företaget, eftersom ganska många människor får otillräcklig feedback och sedan skapar i sig själva och andra effekten av arbetsgivarens tyranni (kommunikationen i IT-samhällen är mycket utvecklad). Som ett resultat har vi bokstavligen två potentiella kandidater kvar med en mycket avlägsen framtid.

Möten är bra. Ett omfattande underlag för bearbetning skapas och den generella nivån på deltagarna ökar. Företaget blir mer och mer igenkännligt på marknaden. Men arbetsintensiteten i sådana företag är inte liten. Du måste tydligt förstå att det tar cirka 700-800 mantimmar per år att hålla möten.

När det gäller testande hackathon. Den här typen av evenemang har ännu inte blivit tråkiga, eftersom de, till skillnad från hackathons för utvecklare, hålls mycket mindre ofta. Fördelen med denna idé är att du på ett avslappnat sätt kan utbyta en stor mängd praktisk kunskap och ganska exakt bestämma nivån på varje deltagare.

Efter att ha analyserat resultaten av evenemanget insåg vi att vi gjorde många misstag:

1. Det mest oförlåtliga misstaget var att tro att 4-5 timmar skulle räcka för oss. Som ett resultat tog bara introduktionen och bekantskapen med eftersläpningarna nästan 2 timmar.
   Att arbeta med produktägare i inledningsskedet och tid för att dyka in i ämnesområdet tog lika lång tid. Så den återstående tiden räckte helt klart inte till för en omfattande utveckling av testkartorna.
2. Det fanns inte tillräckligt med tid och energi för detaljerad feedback på varje karta, eftersom det redan var natt. Därför misslyckades vi helt klart den här delen, men var från början tänkt att vara den mest värdefulla i hackathon.
3. Vi bestämde oss för att utvärdera kvaliteten på utvecklingen genom en enkel omröstning av alla deltagare, och tilldela 3 röster för varje lag, som de kunde ge för arbetet av högsta kvalitet. Kanske vore det bättre att organisera en jury.

Vad har du uppnått?

Vi har delvis löst vårt problem och nu har vi fyra modiga, stiliga män som arbetar för oss, som täcker baksidan av fyra utvecklingsteam. En betydande pool av potentiella starka kandidater och påtagliga förändringar i nivån på stadens QA-gemenskap har ännu inte uppmärksammats. Men det finns vissa framsteg och detta kan inte annat än glädjas.

Källa: will.com