Defekte livssyklus - Som du kanskje nå vet at testutførelse er den fasen hvor testeren faktisk skulle utføre testskriptene. Prosessen med utførelse av testskript varierer fra selskap til selskap og kan også være forskjellig i forskjellige prosjekter innen samme selskap.
Nå om dager er det verktøy tilgjengelig for testgjennomføring, verktøy som - Quality Center, Microsoft Visual Studio og så videre. Den faktiske utførelsesprosessen for å utføre hvert trinn for å sammenligne faktisk og forventet resultat forblir den samme for den funksjonelle testeren uavhengig av verktøy som brukes.
- Hva hvis faktisk atferd ikke er lik forventet atferd?
Når en tester finner ut at det faktiske testresultatet ikke er lik det forventede resultatet, logges en feil.
- Hvordan logge en feil?
Det er mange verktøy tilgjengelig nå om dagen, noen av verktøyene for feillogging er ClearQuest fra IBM, HPs kvalitetssenter, åpen kildekodeverktøy som defekt livssyklus i JIRA og så videre.
Det er noen av de obligatoriske feltene som er vanlige på tvers av de forskjellige defekte loggverktøyene, disse feltene er -
- Defekt livssyklus Beskrivelse
- Defekt livssyklus Sammendrag
- Defekt logget av
- Defekt Tilordnet
- Defekt alvorlighetsgrad
- Defekt prioritet
- Ytterligere øyeblikksbilder
- Utgivelsesnummer / navn
Defekt livssyklus
Defekt Livssyklus starter fra logging av en ny feil. Hver gang en feil blir logget, går den i "Ny" tilstand.
Tester - Ny defekt
Hvem skal tilordne en ny feil?
En tester kan tildele en mangel til en utvikler eller en utviklingsledning. Denne beslutningen om mangelfull tildeling varierer fra prosjekt til prosjekt. På noen arbeidsplasser er det en livssyklusprosess for å tilordne den direkte til en respektive utvikler, og noen steder blir feilen først tildelt en dev-leder, og dev-ledelsen tilordner den igjen til en utvikler.
Defect Assignment (New) - Defect Life Cycle Developer
Defect Assignment (Ny) - Dev Leadà Developer
Defektanalyse
Utvikler vil analysere feilen for å sjekke om den er reproduserbar. Her er det viktigste bidraget fra testeren å inkludere alle nødvendige detaljer i mangelen. Defektoppsummering, Defekt detaljert beskrivelse er feltene som hjelper interessentene til å forstå mangelen på en gang. Defektoppsummering skal alltid bare ha informasjon på høyt nivå om mangelen. Samtidig skal den ha tilstrekkelig informasjon til å beskrive oversikten over mangler på en linje.
Feilbeskrivelse er stedet der tester forventes å inkludere all nødvendig informasjon som Miljø, Scenario, Testdata brukt, Forventet resultat, Faktisk resultat, Henvisning til filer / data og referanse til øyeblikksbilde.
Her er den korte oversikten over forskjellige elementer i Defect detaljert beskrivelse -
Miljø
Testmiljø der feilen ble funnet. Ofte har prosjekter flere testmiljøer der testteamet utfører testing. For eksempel - AT (Forsamlingstestmiljø), PT (Produkttestmiljø), UAT (Brukermottaket Testmiljø) og så videre. Hensikten med å ha forskjellige miljøer er at det gir fleksibilitet i utviklings- og testteamet å få koden distribuert i et hvilket som helst av de tilgjengelige omgivelsene for å starte testingen i tide.
Det er tidspunkter hvor produkttesten (også kalt systemtest) og UAT-testing overlapper hverandre, og det å ha flere miljøer er et must for å fortsette testing parallelt.
Det er tilfeller når utviklingsteamet trenger et ekstra miljø for å feilsøke problemene rapportert av testteamet. Også utviklingsgruppen har et dedikert miljø for enhetstestingoppgave.
Derfor med flere miljøer, er det må nevne i feilen et bestemt miljø der problemet ble funnet.
scenario
Scenario er settet med trinn utført av testeren som førte til en feil. Her forventes en tester å nevne alle trinn som utvikleren kan utføre for å reprodusere feilen. Ofte er det tidspunkter der feilen rapporteres av testeren, men utvikleren ikke er i stand til å gjenskape den samme, og feilen blir derfor avvist. Dette kan skje på grunn av feil trinn / manglende trinn nevnt i beskrivelsen. Tydelige trinn hjelper alle til å forstå mangelen og gjenskape den uten å være avhengige av å nå ut til en tester for å få innspill. Et godt dokumentert scenario har enkle å lese, enkle å forstå og presise trinn som skal følges for å gjenskape feilen.
Testdata
En tester er ment å nevne dataene som ble brukt under teststrømmen som førte til et problem. Denne informasjonen gir utvikleren en sjanse til å bruke lignende data for å reprodusere feilen og finne årsaken til den samme.
Det er noen scenarier der en tester finner en feil ved bruk av spesifikke data, men det samme problemet kan ikke reproduseres ved bruk av lignende type data. Dette kan skje på grunn av datakorrupsjon, og dermed gir dataene en sjanse til å finne ut hva som er årsaken til feilen. En utvikler graver kanskje ikke ned til kodenivå hvis datakorrupsjon er tilfelle. Denne typen feil kan konverteres til datadefekt.
Forventet og faktisk resultat
Dette er høydepunktet i det detaljerte beskrivelsesfeltet der en tester beviser at feilen faktisk er en mangel. Å tydelig nevne det forventede resultatet gjør tingene klare for alle interessenter å anse feilen som en mangel. Se for deg at en feil er logget med alle detaljene, men den spesifiserer ikke det forventede utfallet av scenariet!
Vanligvis går en tester inn bare det forventede resultatet kan være i en linje eller to, men det er veldig viktig å nevne kilden til forventet resultat. Kilde her referanse til dokumentet der det forventede resultatet er nevnt. Dette kan være et kravdokument eller en storyboard-referanse.
Henvisning til filer / data
Noen ganger innebærer mangelen generering av fil eller input som en fil. I denne typen scenarier er det meningen at tester skal gi informasjon om filen som ble brukt og som forårsaket problemet i applikasjonen. Disse filene kan legges ved hjelp av defektstyringsverktøyet, eller referansen til det samme kan gis. Disse referanseplasseringene skal være tilgjengelige for alle interessenter.
Henvisning til øyeblikksbilde
Øyeblikksbilder spiller en veldig viktig rolle når du vil vise dem den nøyaktige feilmeldingen om sideskift som vist på skjermen, eller når du vil vise skjermnavigeringsdetaljene. Øyeblikksbilde gir en rask idé om feilen, skjermen som feilen ble funnet på, data som ble brukt på skjermen og så videre. Alle defektstyringsverktøy har bestemmelser for å knytte øyeblikksbildene. Noen ganger kan tester legge ved Excel-regneark eller orddokumenter også.
Dette var de forskjellige komponentene i feillogging og beste praksis for hver av dem. Kommer tilbake til defekt livssyklus, når feilen er tilordnet en utvikler, vil han / hun analysere den ved hjelp av dataene som er angitt i defektelementet. Hvis pr. Analyse analysen er at det loggførte problemet faktisk er en mangel, vil utvikleren "åpne" feilen for å fungere på den.
Anbefalte kurs
- Webtjenester i Java Training Bundle
- Opplæring i spillutvikling i C ++
- Fullstendig etisk hackingtrening
- Vegas Pro 13 treningskurs
Ny - Åpen
En feil i åpen status viser at den er i utviklingsplaten og utviklerne jobber med å fikse det. I tilfelle analysen finner ut at det loggede problemet ikke er en mangel, kan dette skje når det er forståelsesgap i systemets forventede atferd. Hvis analysen sier at mangelen er ugyldig, vil utvikler avvise mangelen. Terminologi er "Avvist" eller "Gå tilbake til test".
Ny - Gå tilbake til test.
Hvordan tester skal validere hvis mangelen virkelig var en ugyldig mangel?
Dette er scenariet der et presist kravdokument hjelper alle i teamet til å komme til konklusjonen om mangelen som er logget var ugyldig eller gyldig. Henvisning til kravdokumenter hjelper tester så vel som utvikler å komme til samme konklusjon og det letter virkelig diskusjonsprosessen.
Det er scenarier der korrektheten av design- og kravdokumenter blir stilt spørsmål ved mens du henviser disse dokumentene i tider med diskusjoner om mangler. I slike tider som å gå tilbake til Business Analyst, blir det sett på som det beste alternativet for å avklare spørsmålene.
Som beste praksis bør krav og designdokumenter alltid være oppdatert for å henvise dem uten tvetydigheter.
I “Åpen” -status jobber utviklingsgruppen med å fikse mangelen, når feilen er rettet endres status til “Klar for distribusjon”.
Åpen - klar for distribusjon
Distribusjon er prosessen der endringene lastes opp på serveren, slik at testteamet kan jobbe med den faste versjonen av koden. Vanligvis har hvert prosjekt et eget distribusjonsteam for denne oppgaven.
Så på høyt nivå består et programvareteam hovedsakelig av disse tre gruppene -
- Utvikling
- Defekte livssyklus i testing
- Distribusjon (eller noen ganger kalt som Build-team)
Når bygningen er distribuert og mangelen igjen er tilgjengelig for omprøving, tilordnes den til en passende tester for gjenprøvingsoppgaven.
Defect Tilordnet til - Test Lead.
Testleder - individuell tester.
Defekt tilordnet - individuell tester.
På noen arbeidsplasser blir feil først tildelt testledning, og han / hun tilordner den på sin side til den enkelte tester. Noen steder blir imidlertid feilen direkte tilordnet testeren som vil teste den eller den som hadde reist feilen.
Status her endres fra Ready for Deployment - Ready SIT Testing.
Nå er feilen i testerens plate. Testteamet vil validere mangelen, og det er to muligheter. Enten ville reparasjonen fungere riktig, eller det samme problemet oppstår igjen. Avhengig av utfallsdefekten kan du gå til følgende statuser -
Klar SIT-testing - lukket
Klar SIT-testing - Åpne på nytt
I begge scenariene ovenfor er tester pålagt å legge til kommentarene til utført testing. Dette inkluderer å nevne scenariene som ble testet og dataene som er brukt. Hvis feilen åpnes igjen, bør testeren oppgi de nøyaktige trinnene som ble utført, noe som igjen førte til feilen.
Åpningstatus er den samme som “Ny” defektstatus.
Når feilen er åpnet igjen, vil den følge den samme syklusen igjen.
Defekte livssyklusutfordringer
- Avgjøre om alvorlighetsgraden av feil - dette er et av de vanlige diskusjonstemaene (ofte kjemper) blant testere v / s utviklere.
- Defekten er ikke reproduserbar på utviklerens system.
- Feil reist på scenariet som ikke er nevnt i krav og designdokumenter.
- Det er funnet feil, men det samme kan ikke heves da forekomsten av scenariet på produksjonsmiljø ikke er mulig.
Hvordan en tester skal overvinne utfordringene ovenfor?
- Alvorlighetsgraden er direkte proporsjonal med påvirkningen mangelen forårsaker applikasjonen, hvis testeren ikke kan fortsette på grunn av feilen, er den sikkert merket med høyeste alvorlighetsgrad.
- Hvis det finnes en løsning for å fortsette testingen, bør den merkes som middels alvorlighetsgrad. I tillegg til å vurdere virkningen av ytterligere tester av livssyklustesting, kan alvorlighetsgraden også avgjøres med tanke på situasjonen der en hel modul svikter, i dette tilfellet selv om testingen av en annen modul kan utføres, men alvorlighetsgraden for den nåværende modulen er høy så feilen skal merkes med høyeste alvorlighetsgrad.
- Hvis en feil ikke er reproduserbar på utviklerens system, er det sjansene for at utviklings- og testmiljøet ikke er i synk. En feil som kan reproduseres på testsystemet blir alltid betraktet som en gyldig mangel.
- Det er situasjoner når en feil blir logget med tanke på det generelle virksomhetsscenariet, men det direkte scenariet er ikke nevnt i kravene eller designdokumentet. Det anses alltid som en god praksis å vurdere de faktiske forretningsscenariene i stedet for bare å følge testtrinnene. Kommunikasjon med forretningsanalytikere og andre produktinteressenter spiller en viktig rolle for å registrere slike feil.
- Det er scenarier når en tester finner ut et gap i forretningslogikken i testfasen. Å finne slike hull er igjen betraktet som et stort pluss for en tester. Designhull håndteres vanligvis via forbedringer.
- Forbedring - Hvis en atferd må endres under testfasen av programvarens livssyklus, opprettes en forbedring som kan tas i den nåværende eller neste utgave med tanke på tidslinjene og båndbredden til utviklings- og testteamene.
- Det er noen scenarier som en tester kan teste under ad-hoc-tester, som faktisk kan være ugyldige scenarier, med tanke på muligheten for at de forekommer i produksjonen.
Hvem er testerens beste venn?
Hvor skal en tester gå i tilfelle uklarhet? Svaret avhenger av type spørring. Hvis en spørring angår krav, anbefales det å først diskutere i teamet for å forstå forståelsen av systemet kan være ved å konsultere seniormedlemmer. Neste kontaktpunkt skal være forretningsanalytikere.
Hvis spørsmålet angår testprosessen, anbefales det å nå testleder eller testleder.
Hvis spørsmålet gjelder forståelse av applikasjonens tekniske egenskaper, kan utviklingsgruppemedlem være den rette personen å gå til.
Siden testing er en prosess som krever generell forståelse av systemet, hjelper kommunikasjon en tester med å få raskt svar på spørsmålene, det avhenger bare av å stille riktige spørsmål til rette individer. Å lure seg bort fra å stille spørsmål til rett tid kan føre til en mangel på lekkasje til produksjonsmiljø.
Hvor viktig er en testers rolle i bedriften i dag?
Det er prosjekter der testteamet er like viktig som utviklingsteamet, og i noen scenarier er det mer avhengighet av testteamet enn av utviklingsteamet. Det senere scenariet er sjeldent, men det eksisterer på noen arbeidsplasser. Dette har skjedd over tid og kan være i en bestemt periode hvor utviklingsgruppen ikke har mye erfaring sammenlignet med testteamet. Det er mennesker som forstår den generelle flyten og funksjonaliteten bedre enn de fleste av de andre teammedlemmene. Et slikt individ kan være en del av test / utviklingsteam. Dette er en av faktorene som avgjør avhengighet av et team / individ for det spesifikke prosjektet.
Hva er en karrierevei for en tester?
En person kan ta litt tid å forstå den generelle testprosessen, domenet og andre oppgaver som han / hun forventes å jobbe med i det daglige. Basert på denne forståelsen, er det tilrådelig å ta en beslutning om å utforske ytterligere områder som en tester kan ta opp. Det er alltid muligheter i prosessen til å automatisere forskjellige strømmer. Å lage små verktøy kan også hjelpe teamet på stor måte. Hvis en tester er god til å programmere, blir det sett på som et stort pluss. Dette åpner muligheter for automatiseringsroller. Prestasjonstesting er også et av karrieresporene for testere. Forretningsanalytiker er et annet alternativ. God domenekunnskap med gode kommunikasjonsevner er nødvendige ferdighetssett for å være forretningsanalytikere. Testing åpner mange muligheter for testerne til å jobbe på forskjellige domener, verktøy, prosesser og så videre. Det avhenger bare av en person å plukke opp og begynne å gå dypt inne i et av kjerneområdene for testing. Det er mange sertifiseringer som er spesifikke for forskjellige verktøy for å spesialisere seg innen et område innen testing. Å ha sertifisering fra standardleverandøren er en fordel å øke karrieren, men sertifikatet alene kan ikke hjelpe deg på lang sikt, hvis ikke kombinert med riktig arbeidserfaring.
Anbefalte artikler
Her er noen artikler som vil hjelpe deg med å få mer detaljert informasjon om programvaretesting, så bare gå gjennom lenken.
- 6 mest fantastiske programvaretesting intervjuet spørsmål
- Karrierer innen programvaretesting
- Hvordan få bedre karrierevekst i arbeid med programvaretester