Denne artikel vil være af interesse for dem, der ligesom os står over for problemet med at vælge en passende specialist inden for test.
Mærkeligt nok stiger med stigningen i antallet af it-virksomheder i vores republik kun antallet af værdige programmører, men ikke testere. Mange mennesker er ivrige efter at komme ind i dette erhverv, men ikke mange forstår dets betydning.
Jeg kan ikke tale på vegne af alle it-virksomheder, men vi har tildelt rollen som QA/QC til vores kvalitetsspecialister. De er en del af udviklingsteamet og deltager i alle udviklingsstadier, fra forskning til udgivelsen af en ny version.
En tester i et team, selv på planlægningsstadiet, skal gennemtænke alle de funktionelle og ikke-funktionelle krav for at acceptere en brugerhistorie. Han skal forstå de operationelle egenskaber af produktet såvel som programmører, og endnu bedre, og hjælpe teamet med ikke at træffe forkerte beslutninger selv på planlægningsstadiet. Testeren skal have en klar forståelse af, hvordan den implementerede funktionalitet vil fungere, og hvilke faldgruber der kan være. Vores testere laver selv testplaner og testcases samt forbereder alle nødvendige testbænke. At teste i henhold til en færdiglavet specifikation som en abe-klikker er ikke vores mulighed. I teamet skal han hjælpe med at frigive et værdigt produkt og slå alarm i tide, hvis noget går galt.
Hvad vi stødte på, da vi ledte efter testere
På stadiet med at studere mange CV'er så det ud til, at der var specialister med passende erfaring for os, og der ville ikke være nogen problemer med at vælge en tester til vores team. Men under personlige møder stødte vi i stigende grad på kandidater, som faktisk var ret langt fra informationsteknologiens verden (for eksempel kunne de ikke fortælle principperne for interaktion mellem en browser og en webserver, det grundlæggende i sikkerhed, relationel og ikke- relationelle databaser, havde de ingen idé om virtualisering og containerisering), men vurderede samtidig sig selv på Senior QA-niveau. Efter at have gennemført snesevis af interviews kom vi til den konklusion, at antallet af specialister, der passer til os i regionen, er ubetydeligt.
Dernæst vil jeg fortælle dig, hvilke skridt vi tog, og hvilke fejl vi trådte på for at finde de længe ventede kæmpere for kvalitet.
Hvordan vi forsøgte at rette op på situationen
Efter at have opbrugt os selv med at finde færdige specialister begyndte vi at målrette mod nærliggende områder:
- Vi forsøgte at anvende vurderingspraksis til at identificere blandt de mange "leave-it"-personer, netop dem, som vi kan udvikle stærke specialister fra.
Vi bad en gruppe potentielle kandidater med omtrent samme viden om at udføre opgaver. Ved at observere deres tankeproces forsøgte vi at identificere den mest lovende kandidat.
Især kom vi med opgaver til at teste opmærksomhed, forståelse af teknologiens muligheder og funktionerne i multikulturalisme:
- Vi holdt meetups for testere for at udvide grænserne for forståelse af faget blandt det eksisterende kontingent.
Jeg vil fortælle dig lidt om hver af dem.
Ufa Software QA and Testing Meetup #1 er vores første forsøg på at samle dem, der interesserer sig for faget og samtidig forstå, om offentligheden vil være interesseret i det, vi ønsker at formidle til dem. Grundlæggende handlede vores rapporter om, hvor det er bedre at starte, hvis du har besluttet dig for at blive tester. Hjælp begyndere med at åbne øjnene og se på test som en voksen. Vi talte om de skridt, som nybegyndere testere skal tage for at blive en del af erhvervet. Om hvad kvalitet er, og hvordan man opnår det under virkelige forhold. Og også, hvad er automatisk test, og hvor det er mere hensigtsmæssigt at bruge det.
Derefter holdt vi to møder mere med et mellemrum på 1-2 måneder. Der var allerede dobbelt så mange deltagere. Ved "Ufa Software QA and Testing Meetup #2" dykkede vi dybere ned i emneområdet. De talte om fejlsporingssystemer, UI/UX-test, berørte Docker, Ansible og talte også om mulige konflikter mellem en udvikler og en tester og måder at løse dem på.Vores tredje møde, "Ufa Software QA and Testing Meetup #3," var indirekte relateret til testernes arbejde, men var nyttigt til rettidigt at minde programmører om deres tekniske og organisatoriske pligter: belastningstest, e2e-test, Selen i autotest, webapplikationssårbarheder .
Hele denne tid har vi lært at skabe normalt lys og lyd i udsendelser fra vores arrangementer:
→
→
→ - Og til sidst besluttede vi at prøve at afholde et hackathon for testere
Hvordan vi forberedte og gennemførte et hackathon for testere
Til at begynde med forsøgte vi at forstå, hvilken slags "dyr" dette er, og hvordan det normalt udføres. Som det viste sig, er begivenheder af denne art ikke blevet afholdt mange gange i Den Russiske Føderation, og der er ingen steder at låne ideer. For det andet ønskede jeg ikke umiddelbart at investere en masse ressourcer i en begivenhed, der virkede tvivlsom ved første øjekast. Derfor besluttede vi, at vi ville lave korte mini-hackathons, ikke for hele QA-arbejdscyklussen, men for individuelle etaper.
Vores største hovedpine er manglen på praksis blandt lokale testere i at skabe klare testkort. De bruger ikke tid på at undersøge præ-implementering af brugerhistorier og skabe acceptkriterier, der er klare for udviklere for funktionelle og ikke-funktionelle krav, UI/UX, sikkerhed, arbejdsbelastninger og spidsbelastninger. Derfor besluttede vi for første gang at gennemgå den mest interessante og kreative del af deres arbejde - analyse og kravdannelse under forprojektforskning.
Vi estimerede det potentielle antal deltagere og besluttede, at vi havde brug for mindst 5 efterslæb til MVP-udgivelser, 5 produkter og 5 personer, der ville fungere som produktejere, dechifrere forretningsbehov og træffe beslutninger om restriktioner.
Her er hvad vi fik: .
Hovedideen var at komme med emner, der lå så langt væk fra alle deltagernes daglige arbejde som muligt og give dem mulighed for en kreativ fantasiflyvning.
Hvilke fejl begik vi, og hvad kunne vi gøre bedre?
Brugen af vurderingspraksis, så populær inden for ansættelse af sælgere og ledere på lavere niveau, tog en enorm indsats, men tillod os ikke at være tilstrækkelig opmærksomme på hver deltager og evaluere hans evner. Generelt skaber denne valgmulighed et negativt billede af virksomheden, da ret mange mennesker modtager utilstrækkelig feedback og efterfølgende skaber i sig selv og andre virkningen af arbejdsgiverens tyranni (kommunikation i it-samfund er meget udviklet). Som et resultat står vi tilbage med bogstaveligt talt to potentielle kandidater med en meget fjern fremtid.
Møder er en god ting. Der skabes et omfattende grundlag for uddybning, og deltagernes generelle niveau stiger. Virksomheden bliver mere og mere genkendelig på markedet. Men arbejdsintensiteten i sådanne virksomheder er ikke lille. Du skal klart forstå, at det vil tage cirka 700-800 mandetimer om året at afholde møder.
Hvad angår test-hackathon. Den slags begivenheder er endnu ikke blevet kedelige, da de i modsætning til hackathons for udviklere afholdes meget sjældnere. Fordelen ved denne idé er, at du på en afslappet måde kan udveksle en stor mængde praktisk viden og ganske præcist bestemme niveauet for hver deltager.
Efter at have analyseret resultaterne af begivenheden, indså vi, at vi lavede en masse fejl:
- Den mest utilgivelige fejl var at tro, at 4-5 timer ville være nok for os. Som et resultat tog blot introduktionen og fortroligheden med efterslæbet næsten 2 timer.
Arbejdet med produktejere i den indledende fase og tid til at dykke ned i emneområdet tog samme tid. Så den resterende tid var tydeligvis ikke nok til en omfattende udvikling af testkortene. - Der var ikke tid og energi nok til detaljeret feedback på hvert kort, da det allerede var nat. Derfor fejlede vi klart denne del, men var oprindeligt beregnet til at være den mest værdifulde i hackathonet.
- Vi besluttede at evaluere kvaliteten af udviklingen ved en simpel afstemning blandt alle deltagere, idet vi tildelte 3 stemmer til hvert hold, som de kunne give for arbejdet af højeste kvalitet. Måske ville det være bedre at organisere en jury.
Hvad har du opnået?
Vi har delvist løst vores problem, og nu har vi 4 modige, smukke mænd, der arbejder for os, som dækker bagsiden af 4 udviklingsteams. En betydelig pulje af potentielle stærke kandidater og håndgribelige ændringer i niveauet af byens QA-fællesskab er endnu ikke blevet bemærket. Men der er nogle fremskridt, og det kan ikke andet end at glæde sig.
Kilde: www.habr.com