Hur man övervinner agila testutmaningar

Vilka är de vanligaste agila testutmaningarna som programvarutestare eller QA står inför i agila projekt? Hur är det att vara QA i ett smidigt team?

Ända sedan agila utvecklingsmetoder introducerades i programvaruutveckling har QA: s roll i agila projekt förändrats avsevärt. Det finns inte längre ett QA-team sitter i ett hörn, borta från utvecklarna och formgivarna och väntar på att utvecklingsteamet ska lämna ut ett arbete för testning.

Ett av de viktigaste elementen för QA i agila projekt är att ha en god förståelse för de agila utvecklingsmetoderna och processerna. Många smidiga företag följer Scrum-ramverket för att leverera kvalitetsprogramvara, så se till att du är bekant med Scrum.




Agile Testing Utmaningar

Kärnan i smidig utveckling är levererar arbetsprogramvara ofta , varje gång du lägger till eller förbättrar en liten funktion som är värdefull för kunden. Det i sig utgör en stor utmaning inte bara för testare utan också för utvecklare och alla andra som är inblandade i leveransen av applikationen.

I den här artikeln listar jag några av de vanligaste agila testutmaningarna för QA i agila projekt och hur man kan övervinna dem.


Ändringskrav / Sista minuten-ändringar

Ändra krav eller släppa berättelser i mitten av sprinten är inte ovanligt i agila projekt. Detta kan vara en mardröm för hela teamet eftersom det innebär att det redan utförda arbetet kan skrotas helt eller att ändringar ska göras till det som redan är halvt gjort.

Dessa kravändringar och sista minuten-förfrågningar kan påverka testets omfattning vilket kan frustrera testare.

Hur man övervinner:

Testare bör kunna svara på förändringar, med vetskap om att förändringar är oundvikliga i agila projekt. När kraven ändras särskilt mot slutet av sprinten när det inte finns tillräckligt med tid för att testa tillräckligt, bör testare ge så mycket information som möjligt om vilka tester som har körts och vilken del av applikationen som inte har testats så att teamet kan fatta ett välgrundat beslut (eventuellt baserat på risk) om funktionen ska släppas eller inte.


Försök att få utvecklarna med i testningen också, eftersom testning och kvalitet borde vara hela teamansvaret.

Inte tillräckligt med information om historien

Det kommer att finnas tillfällen då en produktägare som skriver användarberättelser, har någon aning om en ny funktion men inte har alla detaljer för att skriva en bra uppsättning acceptanskriterier för att fullständigt definiera funktionens beteende. De ber utvecklingsteamet att skapa en prototyp så att de kan få fler idéer om funktionens och beteendet hos funktionen.

Detta skapar en utmaning för testare eftersom det saknas förståelse och krav, så att korrekta testfall inte kan konstrueras.

Hur man övervinner:


Du behöver inte särskilt detaljerade krav för att börja testa, så börja med att tänka på scenarier på hög nivå som testar historiens koncept, snarare än att vänta på att få fullständig förtydligande om funktionen. Genom att utarbeta testscenarier på hög nivå, även när detaljerna ändras, bör sammanhanget fortfarande vara detsamma.

Kontinuerlig testning

I agile är testning inte en fas, det är en aktivitet. Testningen börjar från början, redan innan utvecklingen startar.

För att få en smidig åktur under sprinten, skulle berättelserna i eftersläpningen ha utarbetats under berättelseprogrammen. Detta innebär att kvalitetssäkring ska samarbeta med produktägare för att lära sig detaljerna i historien och sedan hjälpa till att skriva bra acceptanskriterier.

Att ge tidig feedback till utvecklare är avgörande och utmanande för testare. Som testare måste vi inte bara se till att den nya funktionen fungerar som specificerad enligt dess acceptanskriterier, vi måste också se till att den nya koden inte har brutit mot befintlig funktionalitet, dvs vi har inte återgått, och vi har för att snabbt tillhandahålla denna information.


Hur man övervinner:

Se till att varje berättelse har adekvata acceptanskriterier och att historiens sammanhang är väl förstått av alla innan du börjar arbeta med utveckling.

Börja skapa tester (automatiserade eller manuella) så snart som möjligt så att när funktionen är tillgänglig för test kan du börja genast.

Testare bör uppmuntra utvecklare att tidigt synliggöra funktionen genom att regelbundet distribuera till en testmiljö där testare och / eller produktägare kan köra sina tester, snarare än att vänta på att funktionen ska vara komplett innan testning.


Automatisera regressionstester för att lindra en del av testinsatsen och frigör din tid för utforskande testning.

Tekniska färdigheter / testautomatisering

Att arbeta i en smidig miljö innebär att testarna ska vara tekniskt kompetenta för att hjälpa utvecklarna med Integration Testing och API Testing, samt skripta UI-automatiseringskontroller med Selenium eller liknande verktyg.

Om testarna kommer från en rent manuell eller utforskande bakgrund kommer de att ha svårt att hålla jämna steg med leveranshastigheten eftersom de behöver testa på en kontinuerlig testning.

Prestandatestning är också viktigt, särskilt för webbaserade applikationer, för att säkerställa att applikationen kan hålla hög belastning under topptider. Om ditt företag inte har en dedikerad prestandatestare förväntas funktionstestarna också vara delaktiga i prestandatest.

Hur man övervinner:

Börja med att lära dig några skripts- eller programmeringsspråk, som Ruby och Java - det här är de mest populära språken inom den tekniska testgemenskapen.

Om du redan känner till programmeringen och fastnar kan du få hjälp från utvecklare.

Selen-verktyget är det mest populära testverktyget för webbläsarautomation, så om projektet är webbaserat är det en stor tillgång att ha god kunskap om verktyget.

JMeter är också ett annat bra verktyg att ha kunskap om. Det är ett testverktyg med öppen källkod och relativt lätt att lära sig, så ladda ner det och börja spela med några av dess funktioner.

Flera webbläsare / flera enheter

Numera består arkitekturen på många webbplatser av en 'back-end' och en 'front-end'. Frontdelen är till stor del baserad på JavaScript och CSS som potentiellt kan fungera annorlunda när de ses från olika webbläsare eller enheter.

Att säkerställa att en webbplats fungerar som förväntat i alla större webbläsare och populära mobila enheter eller surfplattor är verkligen en topputmaning för testare i agila projekt.

Hur man övervinner:

Automation är nyckeln här. Att skriva ett test och köra det i flera webbläsare är vad automatisering gör bäst.

Du kan använda Selen Grid med Hamnarbetare för att hantera och köra dina automatiska tester parallellt i flera webbläsare.

Ett annat bra verktyg där ute för testning i flera webbläsare är BrowserSync .

Kommunikation

Oavsett hur bra processen är eller hur bra ovanstående artiklar utförs, om det saknas kommunikation mellan gruppmedlemmarna eller med produktägare, designers, etc, fungerar inget.

Hur man övervinner:

Se till att det finns effektiv kommunikation mellan teamet. Samarbeta med utvecklare och produktägare kontinuerligt.

Se till att det finns en process på plats och att varje teammedlem följer den processen. Ganska ofta identifieras inte stora problem eller buggar tidigt eftersom processen inte följdes och teamet misslyckades med att kommunicera med varandra.