Introduktion till programvarutesterarbete
Vad är det första som tänker på dig när du funderar på ett program för testning av programvara? Ett icke-kodande arbete? Eller ett yrke som är väldigt lätt eftersom det ger dig möjligheter att hitta misstag i andras arbete (att hitta misstag när i andra är den enklaste uppgiften för oss alla)? Eller tänker du på det som yrket som handlar om att kontrollera produktens korrekthet? Alla dessa tankar är korrekta och är de dagliga aktiviteterna för ett programtestarbete. Men programvarutestning är inte bara begränsad till dessa aktiviteter.
Förstå applikationen
Applikationen kan komma från valfri domän - hälso- och sjukvård, försäkring, finans osv. Att lära sig applikationsdomänen är mycket viktigt för alla programvaror för att öppna dörrarna för att tänka ur olika vinklar och olika användarperspektiv när man testar applikationen. Att avslöja och validera de uppenbara och inte så uppenbara applikationsvägarna är alltid den främsta förväntningen på detta. Att ha en fördjupad kunskap om applikationen hjälper den att validera produkten effektivt samtidigt som testaren kan bli en tillgång till ett projekt där han / hon betraktas som en av de främsta källorna till kunskap om produktbeteende.
Även om inlärningsdomän och funktionalitet är en pågående process för alla andra viktiga faktorer är att ha kunskap om testprocessen.
Testprocess
Testprocessen kan variera från detta företag till företag eller till och med från ett projekt till ett annat. Idag har vi olika mjukvaruutvecklingsmodeller som V-modellen, prototypmodellen eller en helt annan metodik som Agile-strategin för mjukvaruutveckling. Med förändringen i utvecklingsmodellen varierar också testmetoden som ska följas. Att arbeta i en V-modell kommer att ha väldefinierade processer medan denna arbete i smidig metodik förväntas testa under ständigt föränderliga förhållanden.
Jobbet är ännu inte smidigt med att ha acceptabel domänkunskap och förståelse för testprocessen, nästa utmaning som kommer med livet är att lära sig olika verktyg.
Verktyg
Verktyg innebär testhanteringsverktyg, defektera loggningsverktyg, databashanteringsverktyg och så vidare.
Med olika felloggningsprogramvaror är det kvaliteter och verktyg, vissa öppen källkod och vissa licensierade, det är alltid en fördel att ha kunskap om mer än ett verktyg. Det hjälper det att enkelt övergå projekt eller team som följer olika verktyg. Med tillräcklig kunskap om domänen, processen och verktygen finns det mer i livet för Software Tester-arbete som gör hans / hennes arbetsdagar utmanande och spännande. Samarbete inom team är en av de viktiga faktorerna för framgången för alla projekt och för ett effektivt samarbete spelar kommunikation en mycket viktig roll.
Rekommenderade kurser
- Komplett J2EE omfattande kurs
- Online R-programmeringsträning
- Gå programmeringskurs
- Online-certifieringsutbildning i Haskell-programmet
Kommunikation
Kommunikation spelar en mycket viktig roll för programvara som den kvalificerar från och med de inledande faserna av mjukvaruutveckling, testning av teammedlemmar är involverade (som bästa praxis) i diskussionen av krav, ifrågasätter affärsanalytiker vid eventuella frågor eller brister i kravet. En tster med effektiv kommunikationsförmåga kan kommunicera riskerna effektivt, kan kommunicera effektivt med utvecklingsgruppen och kan kommunicera testresultat och testrapporter effektivt.
Planering av programvara Tester fungerar
Som namnet antyder är testplanering den fas där förberedelserna för testningen görs. Förberedelserna för en tster kommer att involvera olika typer av aktiviteter som en tster gör för att applicera den effektivt. Detta hjälper till att validera applikationen och avslöja bristerna i applikationen effektivt. För att starta planeringen går en test genom kraven för att förstå förväntningarna.
1. Krav
Krav kan ställas till testteamet i form av wireframes, storyboards, excel-ark. Syftet med alla dessa dokument är att presentera kundens krav på ett effektivt och lättförståeligt sätt. Wireframe-dokument är inget annat än ett dokument som kan vara i form av PowerPoint-presentation som visar klientkraven. På samma linjer avbildar storyboards vanligtvis det önskade utseendet / designen på skärmarna. Nuförtiden finns olika verktyg tillgängliga på marknaden som kan användas för att förbereda de nödvändiga dokumenten. Det är huvudsakligen ansvaret för en affärsanalytiker att skapa nödvändiga dokument. En smak förväntas förstå kraven noggrant. För att såväl tester som utvecklare ska förstå kraven korrekt håller affärsanalytiker forumet öppet för alla att ta upp och få frågorna besvarade på något av kraven. Plattformen för att diskutera och kommunicera öppna frågor och frågor varierar från projekt till projekt. Det kan vara kedjan av e-postmeddelanden eller ett konferenssamtal eller till och med en delad enhet som upprätthålls för att hålla reda på alla öppna frågor och deras svar som tillhandahålls av affärsanalytiker.
Tydlig kommunikation och rekord för kommunikation spelar en mycket viktig roll för ett bevis. Ett litet antagande i kravet kan ibland leda till en större defekt i produkten. I varje steg rekommenderas det att en mjukvara testar egenskaper för att hålla kommunikationen ren. Software Tester Work-kommunikation kan vara med affärsanalytiker eller till och med inom ett team. Tydlig kommunikation hjälper till att hålla antaganden borta under planering och genomförande. Samtidigt rekommenderas det att ha en register över kommunikation (helst e-postkommunikation). Att ha en skriftlig kommunikation om frågor i krav hjälper till i de senare stadierna av testutförandet där funktionaliteten kanske inte har utvecklats som bekräftat i den inspelade kommunikationen.
2. Scenario
När kraven har förstått börjar testaren att dokumentera scenarierna i testscenariedokumentet. Ett scenario som namnet antyder är ett flöde av funktionalitet som användaren följer för att utföra en uppgift.
Exempel på scenarier -
- Användaren ska kunna logga in framgångsrikt.
- Användaren ska kunna boka biljetter i systemet.
- Användaren ska kunna avbryta biljetter i systemet.
- Användaren ska kunna se / uppdatera profilinformationen.
Det här är de logiska uppgifterna som en användare utför i systemet. Dessa logiska uppgifter när de grupperas tillsammans hjälper prover att notera alla möjliga scenarier som en användare förväntas utföra. Dessa scenarier dokumenteras vanligtvis i Excel-bladen eller ibland med hjälp av vissa verktyg. En prover trivs med att extrahera alla sådana scenarier från kravdokumenten. Ett dokument som innehåller sådana scenarier kallas Test Scenario Document (eller någonstans som High-Scenario Document). Detta dokument fungerar som ett inmatningsdokument för utarbetande av testfall.
3. Ärende
Detta fall är den mer detaljerade versionen av Software Tester-arbetsscenariot där scenariot är uppdelat i mer detaljerade steg som användaren faktiskt kommer att utföra när han använder applikationen. Ett enkelt exempel baserat på ovanstående scenarier är:
Scenario - Användaren ska kunna logga in framgångsrikt.
Testfall:
- Kontrollera att användaren kan ange rätt användarnamn.
- Kontrollera att användaren kan ange lösenordet.
- Kontrollera när du klickar på knappen Logga in efter att du har angett rätt användarnamn och lösenord. Användaren kan logga in med framgång.
En sådan lista över dessa fall kan inkludera en valideringskontroll i varje fält, kontroll av negativa scenarier och så vidare.
Nedan är några av de ytterligare exemplen som dessa fall -
- Kontrollera att användarnamnet när det inte anges, systemet kastar ett lämpligt fel.
- Verifiera det lösenordet när det inte anges, systemet kastar ett lämpligt fel.
- Kontrollera att användarnamn och lösenord när det inte anges, systemet kastar ett lämpligt fel.
- Kontrollera att systemet innehåller ett felmeddelande om du anger fel lösenord.
- Kontrollera att systemet anger ett felmeddelande om du anger fel användarnamn.
4. Kravspårbarhetsmatris (RTM)
Kravets spårbarhetsmatris, som namnet antyder, hjälper till att kontrollera och införliva täckningen av de krav som tillhandahålls av Business i testdokumenten som scenarier och testfall.
Som bästa praxis är detta ett separat dokument som visar kartläggningen av kravnummer med det för scenarier / fall som innehåller det kravet.
Det här dokumentet kanske inte används av alla typer av projekt, men när det används hjälper det på det starka sättet att spåra kartläggningar på hög nivå till kraven. Det indikerar täckningen och kan användas för att kontrollera förekomsten av minst ett sådant fall mot varje krav. Att skapa och underhålla RTM-dokumentet betraktas som den bästa metoden, men inte alla typer av projekt (som Agile) använder programvara för att bevisa arbetsdokument. När kraven ändras mycket ofta kan underhållet av detta dokument höras. För att undvika denna omkostnad och samtidigt ha ett sätt att spåra krav, innehåller vissa projekt spårbarhetsdelen i Software Tester-arbetsfallet eller själva scenariedokumentet.
Den viktiga aspekten är att ha ett sätt att spåra scenarier / fall till krav och vice versa. Väl dokumenterade krav gör det lättare för Prover att skapa och underhålla dessa dokument. Tvetydiga krav, ständigt föränderliga krav gör livets livslängd mer utmanande och kan leda till att det finns inkonsekventa levererbara dokument som resulterar i att man missar någon validering och därmed en defekt i slutprodukten.
Resan hittills för en testare planerade och förberedde sig för testning. Eftersom förberedelse för krig är en del av kriget, gäller detta även här. Ju mer kortfattad dessa dokument skapas, desto lättare är det för att bevisa funktionaliteten och avslöja nästan alla fel. Nästa fas av testarens resa är Utförande.
Utförande av programvarutestare fungerar
Detta är den fas där alla ovan nämnda dokument tas i bruk. Krav användes för att skapa ett scenario, Scenario användes för att skapa det Fall. detta falldokument är det självtillräckliga dokumentet här för att börja validera ansökan. Prover börjar validera ansökan genom att utföra steg från detta ärendokument. Flera dessa fall kan användas för att validera ett enda scenario eller till och med ett enda testfall kan motsvara ett enda testscenario. Allt beror på komplexiteten i scenarierna eller ibland den standard som följs i testteamet. Därför kan ett enda testfallsdokument innehålla 20-50 testfall eller det kan ha 100-120 testfall. Dessa nummer är endast för förklaringsändamål, det kan variera mycket från projekt till projekt. Resultatet av denna fas är testdefekter. Antalet giltiga fel som uppstått i denna fas ger en god uppfattning om stabiliteten i applikationen, kvaliteten på testningen, kvaliteten på byggandet och många sådana faktorer som direkt påverkar produkten. Denna fas är den viktigaste fasen eftersom testaren trivs med att täcka alla testfall (validera nästan alla nödvändiga användarvägar) och samtidigt höja så många giltiga fel som möjligt. All förberedelse, kommunikationsförmåga, frågor som ställs för verksamheten kommer att agera i denna testfas.
Defekter av programvarutestaren fungerar
Vid genomförandet av detta fall höjs alla beteenden som inte är lika med det förväntade resultatet som defekten. Varje testfall har en beskrivning, förväntat resultat och en kolumn för faktiskt resultat. Medan dessa planeringsdokument för Software Tester Work har en beskrivning och förväntade resultat och en tom kolumn för faktiska resultat. Vid testningens fall ska testaren fylla i den verkliga resultatkolumnen. Samtidigt, om det faktiska inte är lika med det förväntade resultatet, loggas felet. Att logga in en fel betyder bara inte att informera utvecklaren om problemet. Det är återigen en formell process som vanligtvis görs med hjälp av ett verktyg. För närvarande finns det olika verktyg på marknaden, vissa öppen källkod och vissa licensierade. Varje felloggningsverktyg har följande fält -
- Projekt / utgivningsnamn
- Defektöversikt
- Defekt detaljbeskrivning
- Defekt Svårighetsgrad
- Defekter prioritet
- Fas hittades
- Tilldelats
- bilagor
Som vi kan se är syftet med alla dessa fält att ha en formell processmässig information om problemet. Detta hjälper utvecklare att reproducera defekten i sin miljö och fixa den. Nedan följer en kort beskrivning av alla dessa fält -
- Projekt / utgivningsnamn - Namnet på utgivningen där defekten hittades, vanligtvis har projektet flera utgåvor och samma projekt kan ha flera delprojekt. Det här fältet hjälper till att ta upp en fråga för en specifik utgåva.
- Sammanfattning av defekter - En kort beskrivning av en felaktig beskrivning av felet.
- Defect Detail Description - Detta är detaljbeskrivningen av defekten, den bör innehålla detaljer som miljö där felet hittades och testdata som använts, faktiska resultat förväntade resultatet och all ytterligare information som lägger till mer värdefull information för intressenterna att förstå defekt.
- Defect Severity - Det betyder hur allvarlig defekten är. Vanligtvis har det värden som liknar kritiska, höga, medelstora, låga eller numeriska värden som 4, 3, 2, 1.
- Defektprioritet - Det betyder hur brådskande det är att fixa felet.
- Fas defekten - eftersom det finns många faser när en defekt kan loggas, enhetstestfas, SIT (systemintegrationstest), UAT (användaracceptationstest) eller till och med produktionsfas.
- Tilldelad - Namn på utvecklaren eller utvecklingsledaren.
- Bilagor - Detta gav testaren ett alternativ att bifoga stillbilden på skärmen där problemet stötte på.
Testutförande och defektloggning är den fas där det finns många utmaningar som en testare kan möta. Några av dem kommunicerar effektivt med utvecklarna. Kan vi hävda att loggar en defekt med all nödvändig information som inte är tillräckligt för att utvecklarna kan förstå felet?
Det är och i vissa fall kräver det ytterligare förklaring / diskussion med utvecklarna. Det finns fall där en testare stöter på ett oväntat beteende som han / hon kanske inte är säker på om det är ett fel. Dessa omständigheter möter vanligtvis prover som är nya i teamet, som har begränsad domänkunskap eller har tvetydighet i kraven. Testaren ska inte skyllas här om det finns snäva tidsfrister och det finns ständigt föränderliga krav och i de flesta fall lär prover lära sig om domänen medan de faktiskt planerar och genomför testprov. Som vi kan se är en testares väg inte så lätt som den uppfattas. Det kräver ständigt lärande attityd, god kommunikationsförmåga, goda samarbetskunskaper och iver att anpassa sig själv under förhållanden där det förändras domäner, verktyg, processer som används. Medan vi talade om resan för manuella testare, gäller den övergripande processen också för Automation-testare. Automation, å andra sidan, har betydande förändringar i processen eftersom omfattningen av testning och planering, utförande varierar avsevärt.
Med tanke på proverens resa som diskuterats ovan kan vi fortfarande säga att jobbet med mjukvarutestare-egenskaper är enklare än för en utvecklare?
Det kan sägas att mer än att jämföra tester v / s utvecklarroller, kommer det att vara mer användbart att diskutera hur samarbetet mellan två kan leda till en stor framgång för produkten som helhet. Vi glömmer ibland att testarens uppgift är att hitta problem i applikationen och inte att peka på utvecklarens misstag. När vi glömmer själva idén om vårt jobb leder det ibland till onödig diskussion. Det har emellertid observerats att det finns lika bra testutvecklingsteam där alla förstår att slutändamålet är att få applikationen att fungera som förväntat. Låt oss hoppas för alla att se på den positiva sidan av testjobbet som en roll som hjälper till att rengöra produkten och inte som den som bara hittar misstag!
Rekommenderade artiklar
Detta har varit en guide för att avslöja och validera de uppenbara och inte så uppenbara applikationsvägarna är alltid den primära förväntningen från ett programvara testare arbete. Dessa är följande externa länk relaterad till mjukvara testare arbete.
- Defekter livscykeln vid mjukvarutestning
- 6 mest fantastiska programtestintervjuer
- Karriärer inom mjukvarutestning