Dit artikel zal interessant zijn voor degenen die, net als wij, worden geconfronteerd met het probleem van het selecteren van een geschikte specialist op het gebied van testen.
Vreemd genoeg neemt met de toename van het aantal IT-bedrijven in onze republiek alleen het aantal waardige programmeurs toe, maar niet de testers. Veel mensen willen graag in dit beroep stappen, maar niet veel mensen begrijpen de betekenis ervan.
Ik kan niet voor alle IT-bedrijven spreken, maar we hebben de rol van QA/QC toegewezen aan onze kwaliteitsspecialisten. Ze maken deel uit van het ontwikkelteam en nemen deel aan alle stadia van de ontwikkeling, van onderzoek tot het uitbrengen van een nieuwe versie.
Een tester in een team moet, zelfs in de planningsfase, alle functionele en niet-functionele vereisten voor het accepteren van een gebruikersverhaal doordenken. Hij moet de operationele kenmerken van het product begrijpen, evenals de programmeurs, en nog beter, en het team helpen geen verkeerde beslissingen te nemen, zelfs niet in de planningsfase. De tester moet een duidelijk inzicht hebben in hoe de geïmplementeerde functionaliteit zal werken en welke valkuilen er kunnen zijn. Onze testers maken zelf testplannen en testgevallen en bereiden alle benodigde testbanken voor. Testen volgens een kant-en-klare specificatie zoals een apenclicker is niet onze optie. Binnen het team moet hij helpen een waardevol product op de markt te brengen en op tijd alarm slaan als er iets misgaat.
Wat we tegenkwamen bij het zoeken naar testers
In de fase van het bestuderen van veel cv's leek het erop dat er specialisten waren met geschikte ervaring voor ons en dat er geen problemen zouden zijn met het kiezen van een tester voor ons team. Maar tijdens persoonlijke ontmoetingen kwamen we steeds vaker kandidaten tegen die eigenlijk vrij ver verwijderd waren van de wereld van de informatietechnologie (ze konden bijvoorbeeld de principes van de interactie tussen een browser en een webserver, de basisprincipes van beveiliging, relationele en niet- relationele databases, ze hadden geen idee van virtualisatie en containerisatie), maar beoordeelden zichzelf tegelijkertijd op het Senior QA-niveau. Na het afnemen van tientallen interviews zijn wij tot de conclusie gekomen dat het aantal voor ons geschikte specialisten in de regio verwaarloosbaar is.
Vervolgens zal ik je vertellen welke stappen we hebben gezet en welke fouten we hebben gemaakt om die langverwachte vechters voor kwaliteit te vinden.
Hoe we probeerden de situatie op te lossen
Nadat we onszelf hadden uitgeput met het vinden van kant-en-klare specialisten, begonnen we ons te richten op nabijgelegen gebieden:
- We hebben geprobeerd beoordelingspraktijken toe te passen om onder de vele ‘leave-it’-mensen juist degenen te identificeren van wie we sterke specialisten kunnen ontwikkelen.
We vroegen een groep potentiële kandidaten met ongeveer hetzelfde kennisniveau om taken uit te voeren. Door hun denkproces te observeren, probeerden we de meest veelbelovende kandidaat te identificeren.
In het bijzonder hebben we taken bedacht om de aandacht, het begrip van de mogelijkheden van technologie en de kenmerken van het multiculturalisme te testen:
- We hielden bijeenkomsten voor testers om de grenzen van het begrip van het beroep onder het bestaande contingent te verleggen.
Ik zal je iets over elk van hen vertellen.
Ufa Software QA en Testing Meetup #1 is onze eerste poging om mensen te verzamelen die om het vak geven en tegelijkertijd te begrijpen of het publiek geïnteresseerd zal zijn in wat we hen willen overbrengen. Kortom, onze rapporten gingen over waar je beter kunt beginnen als je hebt besloten tester te worden. Help beginners hun ogen te openen en als volwassenen naar testen te kijken. We spraken over de stappen die beginnende testers moeten nemen om in het vak te komen. Over wat kwaliteit is en hoe je dit onder reële omstandigheden kunt bereiken. En ook, wat is automatisch testen en waar is het passender om het te gebruiken.
Vervolgens hielden we met een tussenpoos van één à twee maanden nog twee bijeenkomsten. Er waren al twee keer zoveel deelnemers. Bij “Ufa Software QA and Testing Meetup #1” zijn we dieper op het onderwerp ingegaan. Ze spraken over systemen voor het volgen van bugs, UI/UX-testen, raakten Docker en Ansible aan, en spraken ook over mogelijke conflicten tussen een ontwikkelaar en een tester en manieren om deze op te lossen.Onze derde bijeenkomst, “Ufa Software QA and Testing Meetup #3”, had indirect betrekking op het werk van testers, maar was nuttig om programmeurs tijdig te herinneren aan hun technische en organisatorische taken: belastingtesten, e2e-testen, Selenium bij autotesten, kwetsbaarheden in webapplicaties .
Al die tijd hebben we geleerd hoe we normaal licht en geluid kunnen creëren in uitzendingen van onze evenementen:
→
→
→ - En uiteindelijk besloten we om te proberen een hackathon voor testers te houden
Hoe we een hackathon voor testers hebben voorbereid en uitgevoerd
Om te beginnen probeerden we te begrijpen wat voor soort "beest" dit is en hoe het gewoonlijk wordt uitgevoerd. Het bleek dat dit soort evenementen in de Russische Federatie niet vaak zijn gehouden en dat er nergens ideeën kunnen worden geleend. Ten tweede wilde ik niet meteen veel middelen investeren in een evenement dat op het eerste gezicht twijfelachtig leek. Daarom besloten we dat we korte mini-hackathons zouden doen, niet voor de hele QA-werkcyclus, maar voor individuele fasen.
Onze grootste hoofdpijn is het gebrek aan oefening onder lokale testers bij het maken van duidelijke testkaarten. Ze besteden geen tijd aan het onderzoeken van gebruikersverhalen vóór de implementatie en het creëren van acceptatiecriteria die duidelijk zijn voor ontwikkelaars voor functionele en niet-functionele vereisten, UI/UX, beveiliging, werklasten en piekbelastingen. Daarom besloten we voor de eerste keer het meest interessante en creatieve deel van hun werk te doorlopen: analyse en vorming van vereisten tijdens pre-projectonderzoek.
We schatten het potentiële aantal deelnemers en besloten dat we minimaal vijf backlogs nodig hadden voor MVP-releases, vijf producten en vijf mensen die zouden optreden als producteigenaars, de bedrijfsbehoeften zouden ontcijferen en beslissingen zouden nemen over beperkingen.
Dit is wat we hebben: .
Het hoofdidee was om onderwerpen te bedenken die zo ver mogelijk verwijderd waren van het dagelijkse werk van de deelnemers en hen ruimte te geven voor een creatieve vlucht van de verbeelding.
Welke fouten hebben we gemaakt en wat kunnen we beter doen?
Het gebruik van beoordelingspraktijken, zo populair op het gebied van het inhuren van verkopers en managers op een lager niveau, kostte enorm veel moeite, maar stelde ons niet in staat voldoende aandacht aan elke deelnemer te besteden en zijn capaciteiten te evalueren. Over het algemeen creëert deze selectieoptie een negatief imago van het bedrijf, omdat nogal wat mensen onvoldoende feedback krijgen en vervolgens bij zichzelf en anderen het effect van tirannie van de werkgever creëren (de communicatie in IT-gemeenschappen is zeer ontwikkeld). Als gevolg hiervan blijven er letterlijk twee potentiële kandidaten over met een zeer verre toekomst.
Ontmoetingen zijn een goede zaak. Er ontstaat een uitgebreide basis voor uitwerking en het algemene niveau van de deelnemers stijgt. Het bedrijf wordt steeds herkenbaarder in de markt. Maar de arbeidsintensiteit van dergelijke ondernemingen is niet klein. U moet goed begrijpen dat het houden van bijeenkomsten ongeveer 700-800 manuren per jaar zal vergen.
Wat betreft de test-hackathon. Dit soort evenementen zijn nog niet saai geworden, omdat ze, in tegenstelling tot hackathons voor ontwikkelaars, veel minder vaak worden gehouden. Het voordeel van dit idee is dat je op een ontspannen manier een grote hoeveelheid praktijkkennis kunt uitwisselen en vrij nauwkeurig het niveau van elke deelnemer kunt bepalen.
Na analyse van de resultaten van het evenement realiseerden we ons dat we veel fouten hadden gemaakt:
- De meest onvergeeflijke fout was om te geloven dat 4-5 uur genoeg voor ons zou zijn. Hierdoor duurde alleen de introductie en het leren kennen van de achterstanden al bijna 2 uur.
Het werken met producteigenaren in de beginfase en de tijd om in het onderwerp te duiken, kostte evenveel tijd. De resterende tijd was dus duidelijk niet genoeg voor een uitgebreide ontwikkeling van de testkaarten. - Er was niet genoeg tijd en energie voor gedetailleerde feedback op elke kaart, omdat het al nacht was. Daarom hebben we duidelijk gefaald in dit onderdeel, maar het was in eerste instantie bedoeld als het meest waardevolle onderdeel van de hackathon.
- We besloten de kwaliteit van de ontwikkeling te evalueren door middel van een eenvoudige stemming onder alle deelnemers, waarbij we aan elk team drie stemmen toekenden, die ze konden geven voor werk van de hoogste kwaliteit. Misschien zou het beter zijn om een jury te organiseren.
Wat heb je bereikt?
We hebben ons probleem gedeeltelijk opgelost en nu werken er vier dappere, knappe mannen voor ons, die de achterkant van vier ontwikkelingsteams dekken. Een aanzienlijke pool van potentiële sterke kandidaten en tastbare veranderingen in het niveau van de QA-gemeenschap van de stad zijn nog niet opgemerkt. Maar er is enige vooruitgang en dit kan alleen maar verheugd zijn.
Bron: www.habr.com