Denne artikkelen vil være av interesse for de som, som oss, står overfor problemet med å velge en passende spesialist innen testing.
Merkelig nok, med økningen i antall IT-selskaper i vår republikk, øker bare antallet verdige programmerere, men ikke testere. Mange mennesker er ivrige etter å komme inn i dette yrket, men ikke mange forstår betydningen.
Jeg kan ikke snakke for alle IT-selskaper, men vi har tildelt rollen som QA/QC til våre kvalitetsspesialister. De er en del av utviklingsteamet og deltar i alle stadier av utviklingen, fra forskning til utgivelse av en ny versjon.
En tester i et team, selv på planleggingsstadiet, må tenke gjennom alle funksjonelle og ikke-funksjonelle krav for å akseptere en brukerhistorie. Han må forstå de operasjonelle egenskapene til produktet så vel som programmerere, og enda bedre, og hjelpe teamet til å ikke ta feil beslutninger selv på planleggingsstadiet. Testeren må ha en klar forståelse av hvordan den implementerte funksjonaliteten vil fungere og hvilke fallgruver det kan være. Våre testere lager selv testplaner og testcases, samt klargjør alle nødvendige testbenker. Testing i henhold til en ferdig spesifikasjon som en apeklikker er ikke vår mulighet. Når han jobber i teamet, må han hjelpe til med å gi ut et verdig produkt og slå alarm i tide hvis noe går galt.
Hva vi møtte da vi lette etter testere
På stadiet med å studere mange CVer, så det ut til at det var spesialister med passende erfaring for oss, og det ville ikke være noen problemer med å velge en tester for teamet vårt. Men under personlige møter møtte vi i økende grad kandidater som faktisk var ganske langt unna informasjonsteknologiens verden (for eksempel kunne de ikke fortelle prinsippene for interaksjon mellom en nettleser og en webserver, det grunnleggende om sikkerhet, relasjonelle og ikke- relasjonsdatabaser hadde de ingen anelse om virtualisering og containerisering), men vurderte seg samtidig på Senior QA-nivå. Etter å ha gjennomført dusinvis av intervjuer kom vi til den konklusjonen at antallet spesialister som passer for oss i regionen er ubetydelig.
Deretter vil jeg fortelle deg hvilke skritt vi tok og hvilke feil vi tråkket på for å finne de etterlengtede jagerflyene for kvalitet.
Hvordan vi prøvde å fikse situasjonen
Etter å ha tømt oss selv med å finne ferdige spesialister, begynte vi å målrette mot nærliggende områder:
- Vi prøvde å bruke vurderingspraksis for å identifisere blant de mange «la-det»-mennesker, nettopp de som vi kan utvikle sterke spesialister fra.
Vi ba en gruppe potensielle kandidater med omtrent samme kunnskapsnivå om å fullføre oppgaver. Vi observerte tankeprosessen deres og prøvde å identifisere den mest lovende kandidaten.
Spesielt kom vi på oppgaver for å teste oppmerksomhet, forståelse av teknologiens evner og funksjonene til multikulturalisme:
- Vi holdt møter for testere for å utvide grensene for forståelse av profesjonen blant den eksisterende kontingenten.
Jeg skal fortelle deg litt om hver av dem.
Ufa Software QA and Testing Meetup #1 er vårt første forsøk på å samle de som bryr seg om yrket og samtidig forstå om publikum vil være interessert i det vi ønsker å formidle til dem. I utgangspunktet handlet rapportene våre om hvor det er bedre å begynne hvis du har bestemt deg for å bli tester. Hjelp nybegynnere med å åpne øynene og se på testing som en voksen. Vi snakket om trinnene som nybegynnere testere må ta for å bli med i yrket. Om hva kvalitet er og hvordan man oppnår det under reelle forhold. Og også, hva er automatisk testing og hvor det er mer hensiktsmessig å bruke det.
Så, med 1-2 måneders mellomrom, holdt vi to møter til. Det var allerede dobbelt så mange deltakere. På "Ufa Software QA and Testing Meetup #2" stupte vi dypere inn i fagområdet. De snakket om feilsporingssystemer, UI/UX-testing, berørte Docker, Ansible, og snakket også om mulige konflikter mellom en utvikler og en tester og måter å løse dem på.Vårt tredje møte, "Ufa Software QA and Testing Meetup #3," var indirekte relatert til testernes arbeid, men var nyttig for å minne programmerere om deres tekniske og organisatoriske plikter: belastningstesting, e2e-testing, Selen i autotesting, sårbarheter i nettapplikasjoner .
Hele denne tiden har vi lært hvordan vi lager normalt lys og lyd i sendinger fra arrangementene våre:
→
→
→ - Og til slutt bestemte vi oss for å prøve å holde et hackathon for testere
Hvordan vi forberedte og gjennomførte et hackathon for testere
Til å begynne med prøvde vi å forstå hva slags "dyr" dette er og hvordan det vanligvis utføres. Som det viste seg, har arrangementer av denne typen ikke blitt holdt mange ganger i den russiske føderasjonen, og det er ingen steder å låne ideer. For det andre ville jeg ikke umiddelbart investere mye ressurser i en begivenhet som virket tvilsom ved første øyekast. Derfor bestemte vi oss for at vi skulle gjøre korte mini-hackathons, ikke for hele QA-arbeidssyklusen, men for individuelle etapper.
Vår viktigste hodepine er mangelen på praksis blant lokale testere i å lage klare testkart. De bruker ikke tid på å undersøke pre-implementering brukerhistorier og lage akseptkriterier som er klare for utviklere for funksjonelle og ikke-funksjonelle krav, UI/UX, sikkerhet, arbeidsbelastninger og toppbelastninger. Derfor bestemte vi oss for for første gang å gå gjennom den mest interessante og kreative delen av arbeidet deres - analyse og dannelse av krav under forprosjektforskning.
Vi estimerte det potensielle antallet deltakere og bestemte at vi trengte minst 5 etterslep for MVP-utgivelser, 5 produkter og 5 personer som ville fungere som produkteiere, tyde forretningsbehov og ta beslutninger om restriksjoner.
Her er hva vi har: .
Hovedideen var å komme opp med temaer som var så fjernt fra alle deltakernes daglige arbeid som mulig og gi dem rom for en kreativ fantasi.
Hvilke feil gjorde vi og hva kan vi gjøre bedre?
Bruken av vurderingspraksis, så populær innen ansettelse av selgere og ledere på lavere nivå, tok en enorm innsats, men tillot oss ikke å være tilstrekkelig oppmerksom på hver deltaker og evaluere evnene hans. Generelt skaper dette valgalternativet et negativt bilde av selskapet, siden ganske mange mennesker får utilstrekkelig tilbakemelding og deretter skaper i seg selv og andre effekten av tyranni til arbeidsgiveren (kommunikasjon i IT-samfunn er svært utviklet). Som et resultat sitter vi igjen med bokstavelig talt to potensielle kandidater med en veldig fjern fremtid.
Møter er en god ting. Det skapes et omfattende grunnlag for utdyping, og det generelle nivået på deltakerne øker. Selskapet blir mer og mer gjenkjennelig i markedet. Men arbeidsintensiteten til slike virksomheter er ikke liten. Du må tydelig forstå at det å holde møter vil ta omtrent 700–800 arbeidstimer per år.
Når det gjelder testing av hackathon. Slike arrangementer har ennå ikke blitt kjedelige, siden de, i motsetning til hackathons for utviklere, holdes mye sjeldnere. Fordelen med denne ideen er at du på en avslappet måte kan utveksle en stor mengde praktisk kunnskap og ganske nøyaktig bestemme nivået til hver deltaker.
Etter å ha analysert resultatene av arrangementet, innså vi at vi gjorde mange feil:
- Den mest utilgivelige feilen var å tro at 4-5 timer ville være nok for oss. Som et resultat tok bare introduksjonen og kjennskapen til etterslepet nesten 2 timer.
Arbeidet med produkteiere på den innledende fasen og tid for å dykke inn i fagområdet tok like lang tid. Så den resterende tiden var tydeligvis ikke nok til en omfattende utvikling av testkartene. - Det var ikke nok tid og energi til detaljert tilbakemelding på hvert kart, siden det allerede var natt. Derfor feilet vi helt klart denne delen, men var i utgangspunktet ment å være den mest verdifulle i hackathon.
- Vi bestemte oss for å evaluere kvaliteten på utviklingen ved en enkel avstemning av alle deltakerne, og tildelte 3 stemmer for hvert lag, som de kunne gi for arbeidet av høyeste kvalitet. Kanskje det er bedre å organisere en jury.
Hva har du oppnådd?
Vi har delvis løst problemet vårt, og nå har vi 4 modige, kjekke menn som jobber for oss, som dekker baksiden av 4 utviklingsteam. En betydelig pool av potensielle sterke kandidater og konkrete endringer i nivået på byens QA-fellesskap har ennå ikke blitt lagt merke til. Men det er en viss fremgang og dette kan ikke annet enn å glede seg.
Kilde: www.habr.com