is there any start stop boundary qa s role scrum
Wat is de rol van QA in Scrum: Scrum-activiteiten voor de testers
Dit artikel is niet alleen een tutorial over enkele processen of methoden of instructies over hoe je als QA kunt werken. Dit is eerder een artikel waarin ik mijn eigen ervaring met het werken als Senior QA in SCRUM wil delen.
Mijn vorige CTO zei dat altijd ‘Met vrijheid komt verantwoordelijkheid’. Als u de vrijheid krijgt om uw werk op uw manier te doen, bent u en alleen u verantwoordelijk voor uw werk of taken of activiteiten.
Dit is waar Scrum over gaat !! Laat me je een basisidee geven over Scrum terwijl we verder gaan.
Wat je leert:
Overzicht van Scrum
Scrum is een subset van de agile methodologie en is een lichtgewicht procesraamwerk dat veel wordt gebruikt.
Scrum helpt ons om de klanten tevreden te houden door hen het product in kleine modules te geven, het houdt de klant er ook van bewust dat hun vaak veranderende eisen de activiteiten kunnen vertragen. De releases zijn kort en er wordt gewerkt volgens de capaciteit van het betrokken team, waardoor de kans op storingen of ontevreden klanten in grote mate wordt verkleind.
Aan de andere kant worden de vereisten (in dit geval User Stories) afgerond voordat de Sprint begint om herwerk te voorkomen en het resulteert dus in een vertraagde of mislukte Sprint (uitzonderingen zijn er altijd).
Maar de grootste uitdaging voor een QA is dat de release-spanwijdte kort is, een Sprint is meestal een cyclus van 15 dagen. Daarom vereist het leveren van een bug ‘gratis’ product in maximaal 4-5 dagen (waardoor de ontwikkelingstijd wordt gehaald) veel inspanningen en slim denken.
Ik ben de QA van mijn team:
Oh ja, ik ben de QA van mijn team en ik ben een belangrijke speler van mijn team. Waarom?? Omdat de klanten, BA's, Scrum Master en alle anderen vaag zijn over de kwaliteit, de look & feel en de prestaties van de applicatie of het product.
In Scrum, omdat de sprintduur kort is, moet QA op een slimme manier presteren en daarom wordt de noodzaak van de QA om vanaf het begin betrokken te zijn ‘Planning’ erg belangrijk. Er zijn momenten waarop een QA de rol van Proxy Product owner kan spelen wanneer de PO niet beschikbaar is, en zo de BA helpt bij het creëren van de acceptatiecriteria testscenario's / cases.
De ontwikkelaars benaderen de QA ook op momenten dat ze problemen hebben met de functionaliteit of bedrijfsregels. In Scrum ligt de focus alleen op het hebben van een vlotte en succesvolle Sprint-release en het gaat niet om ‘Mijn werk’ of ‘Jouw werk’ om een helpende hand te bieden wanneer je team je om hulp vraagt.
Bij Scrum-teambinding spelen gezonde relaties tussen de teamleden een zeer cruciale rol en als QA moet je heel voorzichtig zijn bij het communiceren van je mening over de user stories die je aan het testen bent. Uw communicatie moet gaan over het gebruikersverhaal of de functionaliteit en niet over de persoon die eraan heeft gewerkt.
In Scrum wordt QA niet beoordeeld of gewaardeerd voor het aantal bugs dat hij / zij ontdekt, maar ook voor hoe hij / zij omgaat met het team, het team helpt en het team motiveert, zelfs in moeilijke tijden.
Behalve het testen van de sprinttaken, probeer je bij het schrijven van testplannen / testcases / releasedocumenten ook meer te betrekken omdat de releaseduur van de Sprint kort is en het doel voor iedereen hetzelfde is 'Om met succes een werkend foutvrij product af te leveren door elkaar te helpen'.
Bij bijna alle activiteiten die in een Sprint worden uitgevoerd is een QA betrokken en technisch is er geen grens voor het starten of stoppen van QA-activiteiten. In tegenstelling tot het traditionele Waterfall-model, waar de QA alleen beperkt is tot het testen van de release, heeft de QA hier veel meer verantwoordelijkheden. Dus ik zou willen voorstellen om meer van de volgende activiteiten te proberen en te doen.
Te volgen activiteiten
Hieronder staan enkele activiteiten die ik u zou aanraden te volgen als QA in Scrum.
software voor het downloaden van video's vanaf elke site
# 1) Blijf dieper:
Hiermee bedoel ik dat wanneer de gebruikersverhalen en hun acceptatiecriteria klaar zijn, ze grondig bestudeert en dieper nadenken over de afhankelijkheden, verborgen resultaten en of er een betere manier is om het te doen.
Communiceer en werk hier samen met de BA en het ontwikkelteam over want het kan voorkomen dat zij hier ook niet over nagedacht hebben. Deel uw ideeën en bevindingen met het team.
Als je merkt dat er verborgen hindernissen of negatieve effecten zijn, dan kun je deze bespreken met de Scrum Master en de ontwikkelaars zullen ze de tijd geven om na te denken en ernaar te handelen. Deze activiteit in Scrum wordt erg kritiek wanneer het project grootschalig is en wanneer er modules zijn verspreid over de teams.
Bij het bestuderen van de afhankelijkheden is impact erg belangrijk voor een QA en het maakt het ontwikkelteam daar zelfs van bewust. Om dit te doen, bespreekt u met de QA's van de andere teams en neemt u input van hen.
# 2) Betrek bij schattingen:
De gebruikelijke praktijk is om een QA te betrekken bij de schattingen, maar vaak vanwege de kleine sprint, wordt de QA vaak niet gevraagd om een schatting te maken voor het testen van de taken en ze 3/4/5 dagen over te laten voor het testwerk.
Accepteer dit nooit. Verhef uw stem als het moet, maar zorg ervoor dat u uw testschatting geeft, inclusief de tijd die u voor elk werk nodig hebt.
Het kan tijd voor onderzoek, tijd voor setups, tijd voor het verzamelen van historische gegevens enz. Omvatten, maar wees strikt en specifiek over de tijd die nodig is voor het uitvoeren van de testactiviteiten en laat deze tijdwaarden aan het gebruikersverhaal toevoegen, samen met de tijd voor ontwikkeltaken. .
Dit is erg belangrijk, want als u probeert uw werk binnen de gestelde tijd te doen en als u niet in staat bent om af te ronden, bent alleen u verantwoordelijk voor het falen. Wanneer de QA-tijd wordt toegevoegd, zal de Scrum Master en de PO op de hoogte zijn van de QA-activiteiten die ermee gemoeid zijn en de hoeveelheid tijd die nodig is.
# 3) Dev QA-koppeling:
Idealiter worden in Scrum de Sprint User Stories overhandigd om te testen nadat de ontwikkeling is voltooid en nadat de dev-tests zijn uitgevoerd, maar het probleem hier is dat tegen de tijd dat het aan de QA is overgedragen om te testen, nauwelijks 4-5 dagen naar de demo of recensie blijven.
Als je nu als QA zelfs maar 4 blokkerende of functionele defecten ontdekt, moet je 's avonds laat of in het weekend werken om je releasedatum te halen, aangezien er functionele tests, regressies enz. Moeten worden uitgevoerd. Dit lijkt het traditionele watervalmodel, wat niet de beste manier is om te doen, in Scrum wel de slimste manier “Voorkom defecten in plaats van defecten te vinden”.
Daarom is de oplossing om dev QA-koppeling uit te voeren en een basisronde testen uit te voeren op de dev-setup zodra de ontwikkelaars klaar zijn met de verhalen, zelfs vóór een formele release voor testen.
De volgende criteria kunnen in overweging worden genomen om een BVT uit te voeren op de dev-setup voor de gebruikersverhalen:
- Acceptatiecriteria voor elk gebruikersverhaal: BVT van de user stories in overeenstemming met de acceptatiecriteria.
- Gebrek aan vertrouwen in ontwikkelaars: Soms zijn de ontwikkelaars niet zeker van sommige implementaties en daarom bespreken ze dergelijke implementaties en doen ze een BVT voor degenen met dezelfde dev-setup.
- Afhankelijkheden / impacttesten: BVT van de afhankelijkheden of impact op / van de andere modules van de nieuwe implementaties.
- Testen van een eenheid: Voer een BVT uit met de ontwikkelaar van de Unit-tests die ze hebben gemaakt, help ze indien nodig door de unit-tests toe te voegen of bij te werken.
Dit zal helpen bij het verminderen van het heen en weer gaan van bugs, en bespaart iedereen tijd, want vóór de release voor QA zijn de meeste crashende of functionele bugs al verholpen. Vergeet niet om die defecten in uw tools te loggen voordat u de sprintreview uitvoert en laat ze verplaatsen naar de ‘gesloten’ staat.
# 4) QA op het witte bord:
Ik heb mijn team altijd persoonlijk aangemoedigd om QA-taken op het White Scrum-bord op te nemen, inclusief de bugs. Dit helpt de Scrum Master om de QA-status van een gebruikersverhaal te achterhalen door simpelweg naar het bord te kijken.
De nee. van bugs in de To Do-lijst, de bugs in de In Progress-lijst, de QA-activiteiten in de To Do, In Progress en de Done-lijst spreken voor zich. Ik vind het echt pijnlijk als iemand komt vragen naar de status van het testen van individuele verhalen voor een Sprint, omdat ik extra tijd moet besteden om mijn status uit de tools te halen en ze te laten zien of een e-mail op te stellen.
Ik geef er gewoon de voorkeur aan om de persoon naar het Scrumbord te wijzen en hem het zelf te laten uitzoeken. Geef de voorkeur aan een heldere, opvallende kleur voor de QA Sticky-slips.
# 5) Documentatie:
Dit is een van de nadelen of nadelen van Scrum dat vanwege de kleine omvang van Sprint er niet veel tijd is voor documentatie en ik nog nooit een technisch schrijver in een Scrum-team heb gezien. De Scrum Master / BA werkt mogelijk niet altijd de documenten over de productinformatie bij.
Het probleem doet zich voor als nieuwe leden toetreden of in het ergste geval als de bedrijfsregels, functionaliteiten veranderen en hoe u deze kunt bijhouden, omdat het zoeken naar informatie in ‘Klaar’ gebruikersverhalen zal zijn als het zoeken naar een speld in een hooiberg.
De oplossing is om waar mogelijk een aparte taak in een sprint te laten maken (meestal in slappe tijden of wanneer de werklast erg laag is) voor documentatie, zodat je de documenten kunt bekijken en kunt updaten of de Scrum Master of de BA kunt laten updaten.
Een QA is de juiste persoon om te helpen bij het bijwerken van de documenten, omdat jij degene bent die de user stories test, verifieert en de functionaliteit kent en kent. Doe het zelf als er geen BA is en als uw Scrum Master bezig is met updaten.
# 6) Sprint Review / Sprint Demo:
Meestal komt het voor dat de QA degene is die wordt gekozen om de demo aan de PO en de belanghebbenden te geven. maar zo niet, overtuig u uw Scrum Master om dit te doen. Een QA is de juiste persoon om de demo te geven, aangezien hij / zij het gebruikersverhaal in en uit heeft getest.
Een QA kan vanuit zakelijk oogpunt worden gedemonstreerd omdat ze de functionaliteiten, de stromen en de bedrijfsregels kennen. Bereid je goed voor op de demo en probeer elke vraag van de PO en de stakeholders te beantwoorden. Dit zal je helpen om het aanspreekpunt voor hen te worden bij afwezigheid van de Scrum Master en BA.
# 7) Gedraag je als een BA:
Dit is geen gewone taak en wordt zelfs niet verwacht van een QA, maar probeer deze rol in te nemen als de kans zich voordoet, want een QA is de beste persoon om BA te zijn. Probeer bijvoorbeeld na te denken en te visualiseren of de stromen, functionaliteiten of bedrijfsregels kunnen worden aangepast op een manier die de klant ten goede komt.
Denk en zoek naar de huidige trends in de gebruikersinterface, look & feel van de applicatie en hoe deze kan worden zalig verklaard, gebruiksvriendelijker gemaakt enz. Als het team vastzit aan een probleem, doe dan mee en probeer een eenvoudige en slimme oplossing. Dit zal je rol een boost geven en zal een factor zijn om bij te dragen aan je carrièregroei.
De kans bestaat tijdens gesprekken met de PO wanneer sommige problemen zijn besproken of in review / demo waar u suggesties kunt doen.
Gevolgtrekking
Scrum is een heel andere methodologie dan de normale de Waterfall-methode, en de Scrum Master is een facilitator. Verwacht daarom niet dat hij / zij uw activiteiten voor u definieert.
In Scrum is er geen begin- en eindgrens voor de rol van een QA. QA moet en moet bij elke activiteit betrokken worden vanaf het allereerste begin tot het einde, vanaf de pre-planning tot de sprint review / demo en moet deelnemen aan alle activiteiten.
Dit zal helpen om het product of de applicatie te begrijpen, aangezien (zoals ik al eerder zei) er geen goede documentatie beschikbaar is bij het werken in Scrum. Er wordt van je verwacht dat je verantwoordelijk, gemotiveerd en proactief bent. Wacht daarom niet tot iemand u komt vertellen wat of hoe u moet doen.
Je moet zelf initiatieven nemen, het team op alle mogelijke manieren helpen, een gezonde relatie onderhouden, een overzicht houden van de lopende zaken in het team en vooral duidelijk zijn over je taken in een bepaalde sprint.
Hier zijn geen managers die u zullen volgen of uw activiteiten zullen bijhouden. Sta altijd met een helpende hand voor uw team klaar en u krijgt de beste kansen.
Voel je vrij om je mening / suggesties over dit informatieve artikel te uiten in de comments hieronder.
Aanbevolen literatuur
- Rol van bedrijfsanalisten in SCRUM en waarom is een QA het beste voor deze rol?
- Agile Scrum Online Quiz: test uw kennis van Agile Scrum
- Installeer uw applicatie op het apparaat en begin met testen vanuit Eclipse
- Kanban versus Scrum versus Agile: een gedetailleerde vergelijking om verschillen te vinden
- Hoe u hoogwaardige softwarefuncties in een korte periode kunt leveren met behulp van Agile Scrum-proces
- Agile Manifesto: Agile waarden en principes begrijpen
- Defect Triaging in Scrum: hoe is het georganiseerd in een Scrum-opstelling
- Beste softwaretesttools 2021 (QA Test Automation Tools)