is there any start stop boundary qa s role scrum
Vad är QA: s roll i Scrum: Scrum-aktiviteter för testarna
Den här artikeln är inte bara en handledning om vissa processer eller metoder eller instruktioner om hur man fungerar som en QA. Snarare är detta en artikel där jag vill dela min egen erfarenhet av att arbeta som Senior QA i SCRUM.
Min tidigare CTO brukade alltid säga det ”Med frihet kommer ansvar”. Om du får friheten att göra ditt arbete på ditt sätt är det bara du som är ansvarig för ditt arbete eller dina uppgifter eller aktiviteter.
Det här är vad Scrum handlar om !! Låt mig ge dig en grundläggande uppfattning om Scrum när vi går vidare.
Vad du kommer att lära dig:
Översikt över Scrum
Scrum är en delmängd av smidig metodik och är en lätt processram som används i stor utsträckning.
Scrum hjälper oss att hålla kunderna nöjda genom att ge dem produkten i små moduler, det håller också kunden medveten om att deras ofta förändrade krav kan sakta ner aktiviteterna. Släppningarna är korta och arbetet tas enligt kapaciteten hos det inblandade teamet, därför minskas risken för misslyckanden eller olyckliga kunder till stor del.
Å andra sidan är kraven (i det här fallet User Stories) slutförda innan Sprint startar för att undvika omarbetning och därmed resulterar det i försenad eller misslyckad Sprint (undantag finns alltid).
Men den största utmaningen för en kvalitetssäkring är att utgivningsperioden är kort, en Sprint är mestadels en 15 dagars cykel. För att leverera en 'gratis' produkt på max 4-5 dagar (tar ut utvecklingstiden) krävs därför mycket ansträngningar och smart tänkande.
Jag är mitt teams kvalitetssäkring:
Åh Ja, jag är mitt teams kvalitetsnivå och jag är en viktig spelare i mitt lag. Varför?? Eftersom kunderna, BA: erna, Scrum Master och alla andra är otydliga med kvaliteten, utseendet och känslan och applikationens eller produktens prestanda.
I Scrum, eftersom sprintlängden är kort, måste QA prestera på ett smart sätt och därför blir behovet från QA att vara involverad redan från början ”Planering” mycket viktigt. Det finns tillfällen när en kvalitetssäkring kan spela rollen som en proxyproduktägare när PO inte är tillgänglig, vilket hjälper BA med att skapa testscenarier / fall för acceptanskriterier.
Utvecklarna närmar sig också QA ibland när de möter problem med funktionaliteten eller affärsreglerna. I Scrum är fokus bara på att ha en smidig och framgångsrik Sprint-release och det handlar inte om 'Mitt arbete' eller 'Ditt arbete' för att ge en hjälpande hand när ditt team kontaktar dig för hjälp.
I Scrum-teambindning spelar hälsosamma relationer mellan teammedlemmarna en mycket viktig roll och att vara en kvalitetssäkring bör du vara mycket försiktig när du kommunicerar din åsikt om de användarberättelser som du testar. Din kommunikation bör handla om användarberättelsen eller funktionaliteten och inte om personen som arbetade med den.
I Scrum bedöms eller uppskattas inte QA för antalet buggar han / hon upptäcker utan också om hur han / hon interagerar med laget, hjälper laget och motiverar laget även i svåra tider.
Bortsett från att testa sprintuppgifterna, försöker skriva testplaner / testfall / släppdokument också att involvera mer eftersom sprintlängden för Sprint är kort och målet är detsamma för alla ”Att leverera en fungerande buggfri produkt framgångsrikt genom att hjälpa varandra”.
En kvalitetssäkring är involverad i nästan alla aktiviteter som utförs i en sprint och tekniskt sett finns det inga gränser för start eller stopp av kvalitetsaktiviteter. Till skillnad från den traditionella vattenfallsmodellen där QA bara är begränsad till att testa släppet, har QA här mycket mer ansvar. Så jag föreslår att du försöker göra fler av följande aktiviteter.
Aktiviteter som ska följas
Nedan följer några aktiviteter som jag föreslår att du ska följa som kvalitetsbedömning i Scrum.
etl testar intervjufrågor och svar för erfaren pdf
# 1) Dwell Deeper:
Med detta menar jag att när användarberättelserna och deras acceptanskriterier är redo, studera dem grundligt och tänka djupare på beroenden, dolda resultat och om det finns ett bättre sätt att göra det.
Kommunicera och samarbeta med BA och utvecklingsteamet om detta eftersom det kan hända att de inte kanske har tänkt på det här. Dela dina idéer och resultat med teamet.
Om du upptäcker att det finns dolda hinder eller negativa konsekvenser, då att höja dem med Scrum Master och dev folks kommer att ge dem tid att tänka och agera därefter. Denna aktivitet i Scrum blir mycket kritisk när projektet är i stor skala och när det finns moduler spridda över lagen.
Nu när man studerar om beroenden är en påverkan mycket viktig för en kvalitetsbedömning och det gör till och med utvecklingsgruppen medveten om detsamma. För att göra detta, diskutera med QA: erna från de andra lagen och ta insatser från dem.
# 2) involvera dig i uppskattningar:
Den vanliga praxis är att involvera en QA i uppskattningarna men många gånger på grund av den lilla sprinten, kanske QA inte blir ombedd att uppskatta för att testa uppgifterna och lämna dem med 3/4 / 5 dagar för testarbetet.
Acceptera aldrig detta. Höj din röst om du måste men se till att du tillhandahåller din testuppskattning som ska innehålla den tid du behöver för varje arbete.
Det kan inkludera tid för forskning, tid för inställningar, tid för insamling av historisk data etc., men vara strikt och specifik om den tid som krävs för att utföra testaktiviteterna och få dessa tidsvärden tillagda i användarberättelsen tillsammans med utvecklingsuppgifterna tid .
Detta är mycket viktigt, för om du försöker göra ditt arbete inom den tilldelade tiden och om du inte kan slutföra, är det bara du som är ansvarig för misslyckandet. När QA-tiden läggs till kommer Scrum Master, PO att vara medveten om de involverade QA-aktiviteterna och hur lång tid som krävs.
# 3) Dev QA-parning:
Idealiskt, i Scrum överlämnas Sprint User Stories för testning efter att utvecklingen har slutförts och när dev-testningen har gjorts, men problemet här är att när den överlämnas till QA för testning knappt 4-5 dagar till Demo eller recension kvar.
Om du som QA får reda på även fyra blockerare eller funktionsfel, måste du arbeta sent på kvällen eller på helgen för att uppfylla ditt släppdatum eftersom det kommer att göras funktionstester, regressioner etc. Detta verkar som den traditionella vattenfallsmodellen som inte är det bästa sättet att göra, i Scrum är det smartaste sättet ”Förhindra defekter snarare än att hitta defekter”.
Därför är lösningen att göra dev QA-parning och utföra en grundläggande testrunda på dev-installationen så snart utvecklarna är redo med berättelserna redan innan en formell release för testning.
Följande kriterier kan tas i beaktande för att göra en BVT på dev-installationen för användarberättelserna:
- Godtagningskriterier för varje användarberättelse: BVT av användarberättelserna i enlighet med acceptanskriterierna.
- Brist på förtroende för utvecklare: Ibland är utvecklarna inte säkra på vissa implementeringar och därför diskuterar de sådana implementeringar och gör en BVT för de som har samma dev-installation.
- Beroenden / slagprovning: BVT av beroenden eller påverkan på / av de andra modulerna i de nya implementeringarna.
- Enhetstestning: Gör en BVT med utvecklaren av enhetstesterna som de har skapat, hjälp dem vid behov genom att lägga till eller uppdatera enhetstesterna.
Detta kommer att hjälpa till att minska fram och tillbaka på buggar, spara allas tid som innan släppet till QA en majoritet av de kraschande eller funktionella buggarna är redan fixade. Kom ihåg att logga in dessa defekter i dina verktyg innan sprintgranskningen och få dem att flyttas till 'stängt' tillstånd.
# 4) QA på White Board:
Jag har alltid personligen uppmuntrat mitt team att inkludera QA-uppgifter på White Scrum-kortet inklusive buggarna också. Detta hjälper Scrum Master att räkna ut QA-statusen för en användarberättelse genom att helt enkelt titta på tavlan.
Nejet. av buggar i To-Do-listan, buggarna i listan In Progress, QA-aktiviteterna i To To Do, In Progress och Done-listan talar för sig själva. Jag tycker det är väldigt smärtsamt när någon kommer och frågar om statusen för att testa enskilda berättelser för en Sprint eftersom jag måste spendera extra tid på att ta ut min status från verktygssammanställningen och visa dem eller skriva ett mejl.
Jag föredrar helt enkelt att rikta personen till Scrum Board och låta dem göra det själv. Föredrar en ljus enastående färg för QA Sticky-slipsar.
# 5) Dokumentation:
Detta är en av nackdelarna med Scrum att på grund av den lilla storleken på Sprint finns det inte mycket tid för dokumentation och jag har aldrig sett en Technical Writer i ett Scrum-team. Scrum Master / BA kanske inte uppdaterar dokumenten om produktinformationen.
Problemet uppstår om nya medlemmar ansluter sig eller i värsta fall om affärsreglerna, funktionaliteten förändras och hur man kan hålla reda på dessa eftersom sökning i 'Klar' användarberättelser för information kommer att vara som att leta efter en nål i en höstack.
Lösningen är att skapa en separat uppgift i en sprint när det är möjligt (oftast i slaka tider eller när arbetsbelastningen är mycket mindre) för dokumentation så att du kan granska dokumenten och uppdatera eller göra Scrum Master eller BA uppdatera dem.
En kvalitetsbedömning är rätt person som hjälper till att uppdatera dokumenten eftersom det är du som testar, verifierar användarberättelserna och känner till funktionaliteten in och ut. Gör det själv om det inte finns någon BA och om din Scrum Master är upptagen med att uppdatera.
# 6) Sprint Review / Sprint Demo:
För det mesta händer det att QA är den som väljs för att ge demo till PO och intressenter. men om inte övertala din Scrum Master att göra det. En kvalitetssäkring är en rätt person att ge demo då han / hon har testat användarberättelsen in och ut.
En kvalitetssäkring kan demonstrera ur affärssynpunkt eftersom de känner till funktionerna, flödena och affärsreglerna. Förbered dig väl för demo och försök att svara på varje fråga som PO och intressenter har. Detta hjälper dig att bli kontaktpunkt för dem i frånvaro av Scrum Master och BA.
# 7) Uppför dig som en BA:
Det här är inte en vanlig uppgift och förväntas inte ens av en QA men försök att komma in i den här rollen när en chans kastas eftersom en QA är den bästa personen att vara BA. Försök till exempel att tänka och visualisera om flödena, funktionerna eller affärsreglerna kan ändras på ett sätt som gynnar kunden.
Tänk och sök efter de aktuella trenderna i användargränssnittet, se ut och känna applikationen och hur den kan bli bättre, göra den mer användarvänlig etc. lösning. Detta kommer att öka din roll och kommer att bidra till din karriärtillväxt.
Chanserna uppstår vid samtal med PO när vissa problem diskuteras eller i granskning / demo där du kan ge förslag.
Slutsats
Scrum är en väldigt annorlunda metod än den vanliga Waterfall-metoden, och Scrum Master är en facilitator. Förvänta dig därför inte att han / hon definierar dina aktiviteter för dig.
I Scrum finns det ingen start- och slutgräns för en QA-roll. QA behöver och måste vara involverad i varje aktivitet från början till slutet, från förplanering till sprintgranskning / demo och måste delta i alla aktiviteter.
Detta hjälper till att förstå produkten eller applikationen eftersom (som jag sa tidigare) det inte finns någon korrekt dokumentation när du arbetar i Scrum. Du förväntas vara ansvarig, motiverad och proaktiv. Vänta därför inte på att någon ska komma och berätta vad eller hur du ska göra.
Du bör ta initiativ på egen hand, hjälpa teamet på alla möjliga sätt, upprätthålla en hälsosam relation, hålla reda på de pågående sakerna i laget och viktigast av allt vara tydlig om dina uppgifter i en given sprint.
Här finns inga chefer som kommer att övervaka dig eller hålla reda på dina aktiviteter. Var alltid redo med en hjälpande hand för ditt team så får du det bästa av möjligheterna.
Uttryck gärna dina tankar / förslag om den här informativa artikeln i kommentarfältet nedan.
Rekommenderad läsning
- Affärsanalytikernas roll i SCRUM och varför är en kvalitetsbedömning bäst för denna roll?
- Agile Scrum Online Quiz: Testa din kunskap om Agile Scrum
- Installera din applikation på enheten och börja testa från Eclipse
- Kanban vs Scrum vs Agile: En detaljerad jämförelse för att hitta skillnader
- Hur man levererar högvärdiga programvarufunktioner på kort tid med Agile Scrum Process
- Agile Manifesto: Förstå agila värden och principer
- Defect Triaging In Scrum: Hur är det organiserat i en Scrum Setup
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)