Defekt livscyklus - Som du måske ved nu, at testudførelse er den fase, hvor testeren rent faktisk vil udføre testskripterne. Processen med udførelse af test scripts varierer fra virksomhed til virksomhed og kan også være forskellig i forskellige projekter inden for samme virksomhed.
Nu om dagen er der værktøjer til rådighed til testudførelse, værktøjer som - Quality Center, Microsoft Visual Studio og så videre. Den faktiske udførelsesproces for at udføre hvert trin for at sammenligne det faktiske og forventede resultat forbliver den samme for den funktionelle tester uanset hvilke anvendte værktøjer.
- Hvad hvis faktisk adfærd ikke er lig med den forventede adfærd?
Når en tester finder ud af, at det faktiske testresultat ikke er lig med det forventede resultat, logges en defekt.
- Hvordan logger du en fejl?
Der er mange værktøjer tilgængelige nu om dagen, nogle af defektloggingsværktøjerne er ClearQuest fra IBM, HPs Quality Center, open source-værktøjer som defektens livscyklus i JIRA og så videre.
Der er nogle af de obligatoriske felter, der er almindelige på tværs af de forskellige værktøjer til fejlfinding, disse felt er -
- Defekt livscyklus Beskrivelse
- Defekt livscyklus Sammendrag
- Defekt logget af
- Defect Tillagt til
- Defekt alvorlighed
- Defekt prioritet
- Yderligere snapshots
- Udgivelsesnummer / navn
Defekter livscyklus
Defekt Livscyklus starter med at logge en ny defekt. Hver gang der registreres en defekt, går den i ”Ny” tilstand.
Tester - Ny defekt
Hvem tildeler en ny defekt?
En tester kan tildele en mangel til en udvikler eller en udviklingsledning. Denne beslutning om mangelfuld tildeling varierer fra projekt til projekt. På nogle arbejdspladser er der defekt livscyklusproces for at tildele den direkte til en respektive udvikler, og nogle steder tildeles defekten først til en dev-leder, og dev-ledningen tildeler igen den til en udvikler.
Defect Assignment (New) - Defect Life Cycle Developer
Defect Assignment (Ny) - Dev Leadà Developer
Defektanalyse
Udvikler vil analysere defekten for at kontrollere, om den er reproducerbar. Her er det vigtigste bidrag fra testeren at inkludere alle de nødvendige detaljer i defekten. Defektoversigt, Defekt detaljeret beskrivelse er de felter, der hjælper interessenterne med at forstå manglen på én gang. Defektoversigt skal altid kun have information på højt niveau om defekten. Samtidig skal det have tilstrækkelig information til at beskrive oversigten over defekter på en linje.
Defektbeskrivelse er det sted, hvor tester forventes at indeholde alle de nødvendige oplysninger som Miljø, Scenario, anvendte testdata, Forventet resultat, Faktisk resultat, Henvisning til filer / data og henvisning til snapshot.
Her er den korte oversigt over forskellige elementer i Defect Detaljeret beskrivelse -
Miljø
Testmiljø, hvor defekten blev fundet. Ofte har projekter flere testmiljøer, hvor testteamet udfører test. For eksempel - AT (forsamlingstestmiljø), PT (produkttestmiljø), UAT (brugeraccept-testmiljø) og så videre. Formålet med at have forskellige miljøer er, at det giver fleksibilitet inden for udviklings- og testteamet at få koden implementeret i et hvilket som helst af de tilgængelige omgivelser for at starte testen til tiden.
Der er tidspunkter, hvor produkttesten (også kaldet systemtest) og UAT-test overlapper hinanden, hvorfor det at have flere miljøer er et must for at fortsætte testen parallelt.
Der er tilfælde, hvor udviklingsholdet har brug for et ekstra miljø for at debugge de problemer, der er rapporteret af testteamet. Udviklingsholdet har også et dedikeret miljø til enhedstestopgave.
Derfor med flere miljøer er det nødvendigt at nævne i defekten et bestemt miljø, hvor problemet blev fundet.
Scenarie
Scenario er det sæt trin, der udføres af testeren, hvilket førte til en defekt. Her forventes en tester at nævne alle de trin, som udvikleren kan udføre for at gengive defekten. Ofte er der tidspunkter, hvor fejlen rapporteres af testeren, men udvikleren er ikke i stand til at gentage det samme, og defekten bliver derfor afvist. Dette kan ske på grund af forkerte trin / manglende trin, der er nævnt i beskrivelsen. Klare trin hjælper alle med at forstå defekten og gentage den uden at være afhængige af at nå ud til en tester for at få input. Et veldokumenteret scenario har let at læse, let at forstå og præcise trin, der skal følges for at gentage defekten.
Testdata
En tester skal nævne de data, der blev brugt under teststrømmen, som førte til et problem. Denne information giver udvikleren en chance for at bruge de lignende data til at gengive defekten og finde grundårsagen til den samme.
Der er nogle scenarier, hvor en tester finder en fejl ved hjælp af specifikke data, men det samme problem kan ikke reproduceres ved hjælp af lignende type data. Dette kan ske på grund af datakorruption, så indtastning af data giver derfor en chance for at finde ud af den grundlæggende årsag til fejl. En udvikler graver muligvis ikke ned til kodeniveau, hvis datakorruption er tilfældet. Denne type fejl kan konverteres til datadefekt.
Forventet & faktisk resultat
Dette er højdepunktet i det detaljerede beskrivelsesfelt, hvor en tester beviser, at den konstaterede fejl faktisk er en mangel. Ved at nævne det forventede resultat gør tingene tydelige for enhver interessent at betragte fejlen som en mangel. Forestil dig, at en defekt er logget med alle detaljerne, men den specificerer ikke det forventede resultat af scenariet!
Normalt indtaster en tester kun det forventede resultat i en linje eller to, men det er meget vigtigt at nævne kilden til det forventede resultat. Kilde her henvisning til det dokument, hvor det forventede resultat er nævnt. Dette kan være et kravdokument eller en storyboard-reference.
Henvisning til filer / data
Undertiden involverer defekten generering af fil eller input som en fil. I denne form for scenarier skal tester give oplysninger om den fil, der blev brugt, og som forårsagede problemet i applikationen. Disse filer kan vedhæftes ved hjælp af defektstyringsværktøjet, eller referencen til det samme kan findes. Disse referencepladser skal være tilgængelige for alle interessenter.
Henvisning til snapshot
Snapshots spiller en meget vigtig rolle, når du vil vise dem den nøjagtige fejlmeddelelse om sideskift, som vist på skærmen, eller når du vil vise skærmnavigeringsdetaljerne. Snapshot giver en hurtig idé om den konstaterede defekt, skærm, på hvilken defekten blev fundet, data brugt på skærmen osv. Hvert defektstyringsværktøj har mulighed for at vedhæfte snapshots. Nogle gange vedhæfter tester muligvis også Excel-regneark eller orddokumenter.
Dette var de forskellige bestanddele af defektregistrering og bedste praksis for hver af dem. Når man vender tilbage til defekt livscyklus, når defekten er tildelt en udvikler, analyserer han / hun den ved hjælp af de data, der er leveret i defektelementet. Hvis pr. Analyse, det loggede problem faktisk er en mangel, vil udvikleren "åbne" defekten for at arbejde med dens rettelse.
Anbefalede kurser
- Webtjenester i Java Training Bundle
- Træning i spiludvikling i C ++
- Komplet etisk hackingtræning
- Vegas Pro 13-træningskurser
Ny - Åben
En defekt i Åben-status viser, at den er i udviklingspladen, og udviklerne arbejder med dens rettelse. I tilfælde af at analysen finder ud af, at det loggede problem ikke er en mangel, kan dette ske, når der er forståelsesgap i systemets forventede opførsel. Hvis analysen siger, at defekten er ugyldig, afviser udvikleren manglen. Terminologi er "afvist" eller "vende tilbage til test".
Ny - Tilbage til test.
Hvordan tester skal valideres, hvis manglen faktisk var en ugyldig mangel?
Dette er scenariet, hvor et præcist kravdokument hjælper alle i teamet med at komme til konklusionen, hvis den loggede mangel var ugyldig eller gyldig. Henvisning til kravdokumenter hjælper både tester og udvikler med at komme til den samme konklusion, og det letter virkelig diskussionsprocessen.
Der er scenarier, hvor korrektheden af design- og kravdokumenter stilles spørgsmålstegn ved henvisning til disse dokumenter i tider med defektdiskussioner, på sådanne tidspunkter, der går tilbage til Business Analyst, betragtes som den bedste mulighed for at afklare spørgsmålene.
Som bedste praksis skal krav og designdokumenter altid være ajour for at henvise dem uden tvetydigheder.
I “Åben” -status arbejder udviklingsteam med at ordne defekten, når først defekten er rettet, ændres status til “Klar til implementering”.
Åben - Klar til implementering
Implementering er processen, hvor ændringerne uploades på serveren, så testteamet kan arbejde på den faste version af koden. Normalt har hvert projekt et separat implementeringsteam til denne opgave.
Så på højt niveau består et softwareteam hovedsageligt af disse 3 grupper -
- Udvikling
- Defekter livscyklus i test
- Implementering (eller undertiden kaldet Build-team)
Når build er installeret, og defekten igen er tilgængelig til genprøvning, tildeles den en passende tester til genprøvningsopgaven.
Defekt tildelt - Testleder.
Testleder - individuel test.
Defekt tildelt - individuel test.
På nogle arbejdspladser tildeles først defekt til testledning, og han / hun tildeler på sin side den til den enkelte tester, men nogle steder tildeles defekten direkte til testeren, der ville teste den eller den, der havde hævet manglen.
Status her ændres fra Klar til implementering - Klar SIT-test.
Nu er defekten i testers plade. Testteam validerer defekten, og der er 2 muligheder, enten vil rettelsen fungere korrekt, eller det samme problem opstår igen. Afhængigt af udfaldsdefekten kan gå til følgende status -
Klar SIT-test - lukket
Klar SIT-test - Åbn igen
I begge ovenstående scenarie kræves tester at tilføje kommentarer til udført test. Dette inkluderer at nævne de testede scenarier og anvendte data. Hvis fejlen åbnes igen, skal testeren give de nøjagtige trin, der blev udført, hvilket igen førte til fejlen.
Genåbnestatus er den samme som “Ny” defektstatus.
Når fejlen er åbnet igen, vil den følge den samme cyklus igen.
Defekte livscyklusudfordringer
- Beslutning om sværhedsgraden - dette er et af de almindelige diskussionsemner (ofte kampe) blandt testere v / s-udviklere.
- Manglen kan ikke reproduceres på udviklerens system.
- Defekt rejst på scenariet, som ikke er nævnt i krav og designdokumenter.
- Der findes en fejl, men det samme kan ikke hæves, da forekomsten af scenariet om produktionsmiljø ikke er mulig.
Hvordan en tester skal overvinde ovenstående udfordringer?
- Alvorligheden er direkte proportional med påvirkningen, som defekten forårsager applikationen, hvis testeren ikke kan fortsætte på grund af defekten, markeres den helt sikkert med den største alvorlighed.
- Hvis der findes en løsning på at fortsætte testen, skal den markeres som middel sværhedsgrad. Udover at overveje virkningen af yderligere defekter i livscyklusforsøg, kan sværhedsgraden også afgøres i betragtning af situationen, hvor et helt modul mislykkes, i dette tilfælde, selvom testningen af et andet modul kan udføres, men sværhedsgraden for det aktuelle modul er høj så defekten skal markeres med den største alvorlighed.
- Hvis en defekt ikke kan reproduceres i udviklerens system, er der chancer for, at udviklings- og testmiljøet ikke er synkroniseret. En defekt, der kan reproduceres på testsystemet, betragtes altid som en gyldig defekt.
- Der er situationer, hvor en defekt er logget i betragtning af det samlede forretningsforløb, men det direkte scenarie er ikke nævnt i kravene eller designdokumentet. Det betragtes altid som en bedste praksis at overveje de faktiske forretningsscenarier i stedet for bare at følge teststrinnene. Kommunikation med forretningsanalytikere og andre produktinteressenter spiller en vigtig rolle for at registrere sådanne mangler.
- Der er scenarier, når en tester finder ud af et hul i forretningslogikken i testfasen. At finde sådanne huller betragtes igen som et stort plus for en tester. Designhuller håndteres normalt via forbedringer.
- Forbedring - Hvis en adfærd skal ændres under testfasen af softwarens livscyklus, oprettes en forbedring, der kan tages i den aktuelle eller næste udgivelse i betragtning af tidslinjerne og båndbredden for udviklings- og testteamene.
- Der er nogle scenarier, som en tester kan teste under ad-hoc-test, som faktisk kan være de ugyldige scenarier, i betragtning af muligheden for, at de forekommer i produktionen.
Hvem er testers bedste ven?
Hvor skal en tester gå i tilfælde af tvetydighed? Svaret afhænger af typen af forespørgsel, hvis en forespørgsel angår krav, tilrådes det først at diskutere i teamet for at korrekt forståelse af systemet kan være ved at konsultere seniormedlemmer. Det næste kontaktpunkt skal være forretningsanalytikere.
Hvis forespørgslen angår testprocessen, anbefales det at nå ud til testledningen eller testmanageren.
Hvis forespørgslen angår forståelse af applikationens tekniske forhold, kan udviklingsholdmedlem være den rigtige person til at gå til.
Da test er en proces, der kræver generel forståelse af systemet, hjælper kommunikation en tester med at få hurtigt svar på spørgsmålene, afhænger det bare af at stille rigtige spørgsmål til rigtige personer. Hvis du ryster væk fra at stille spørgsmål til det rigtige tidspunkt, kan det føre til en mangel på lækage til produktionsmiljøet.
Hvor vigtig er en testers rolle i virksomheden i dag?
Der er projekter, hvor testteamet er lige så vigtigt som udviklingsholdet, og i nogle scenarier er der mere afhængighed af testteamet end af udviklingsholdet. Det senere scenario er sjældent, men det findes på nogle arbejdspladser. Dette er sket over tid og kan være i en bestemt periode, hvor udviklingsholdet ikke er meget erfarent sammenlignet med testteamet. Der er mennesker, der forstår den samlede strøm og funktionalitet bedre end de fleste af de andre teammedlemmer. En sådan person kan være en del af test / udvikling team. Dette er en af de faktorer, der bestemmer afhængigheden af et team / individ for det specifikke projekt.
Hvad er karrierevejen for en tester?
En person kan tage noget tid på at forstå den overordnede testproces, domæne og andre opgaver, som han / hun forventes at arbejde med i det daglige liv. Baseret på denne forståelse tilrådes det at tage beslutning om at udforske yderligere områder, som en tester kan tage op. Der er altid muligheder i processen til at automatisere forskellige strømme. Oprettelse af små værktøjer kan også hjælpe teamet på store måder. Hvis en tester er god til programmering, betragtes den som et stort plus. Dette åbner muligheder for automatiseringsroller. Performance-test er også et af karrieresporene for testere. Forretningsanalytiker er en anden mulighed. God domæne viden med gode kommunikationsevner er de krævede færdigheder, der skal være forretningsanalytikere. Testning åbner mange muligheder for testerne til at arbejde på forskellige domæner, værktøjer, processer og så videre. Det afhænger bare af en person at hente og begynde at gå dybt inde i et af testnings-kerneområderne. Der er mange certificeringer, der er specifikke for forskellige værktøjer til at specialisere sig inden for et af testningsområderne. At have certificering fra standardleverandøren er en fordel for at øge karrieren, men certifikatet alene kan ikke hjælpe dig i det lange løb, hvis ikke kombineret med den rigtige arbejdserfaring.
Anbefalede artikler
Her er nogle artikler, der hjælper dig med at få flere detaljer om softwaretestingen, så bare gå gennem linket.
- 6 mest fantastiske softwaretestintervjuespørgsmål
- Karrierer inden for softwaretestning
- Sådan får du en bedre karrierevækst inden for software-testerarbejde