Introduktion til softwaretesterarbejde
Hvad er den første ting, der kommer ind i dit sind, når du tænker på et softwaretestjob? Et ikke-kodende arbejde? Eller et erhverv, der er meget let, da det giver dig muligheder for at finde fejl i andres arbejde (at finde fejl, når du er i andre, er den nemmeste opgave for os alle)? Eller tænker du på det som det erhverv, der beskæftiger sig med at kontrollere produktets rigtighed? Alle disse tanker er korrekte og er de daglige aktiviteter for et software-testerarbejde. Softwaretest er dog ikke kun begrænset til disse aktiviteter.
Forståelse af applikationen
Applikationen kan være fra ethvert domæne - Healthcare, Insurance, Finance, etc. At lære applikationsdomænet er meget vigtigt for ethvert softwarearbejde for at åbne dørene til at tænke fra forskellige vinkler og forskellige brugerperspektiver, mens man tester applikationen. At afsløre og validere de åbenlyse og ikke så åbenlyse anvendelsesveje er altid den primære forventning herfra. At have en indgående kendskab til applikationen hjælper med at validere produktet effektivt, samtidig med at testeren kan blive et aktiv for et projekt, hvor han / hun betragtes som en af de primære kilder til viden om produktadfærd.
Selvom indlæring af domæne og funktionalitet er en løbende proces for enhver anden, er den anden vigtige faktor at have viden om testprocessen.
Testproces
Testprocessen kan variere fra dette firma til firma eller endda fra et projekt til et andet. I dag har vi forskellige softwareudviklingsmodeller som V-modellen, Prototyping-modellen eller en helt anden metode, som Agile-tilgangen til softwareudvikling. Med ændringen i udviklingsmodellen varierer den testmetode, der skal følges, også. Arbejde i en V-model vil have veldefinerede processer, mens denne arbejde i agile metodologi forventes at teste under stadigt skiftende forhold.
Jobbet er endnu ikke glat med at have acceptabel domæne-viden og forståelse af testprocessen, den næste udfordring, der følger med livet, er at lære forskellige værktøjer.
Værktøj
Værktøjer antyder Teststyringsværktøjer, Defekte logningsværktøjer, databasestyringsværktøjer og så videre.
Med forskellige defekte loggingssoftware er det kvaliteter og værktøjer, nogle open source og nogle licenserede, det er altid en fordel at have kendskab til mere end et værktøj. Det hjælper det med let at overføre projekter eller teams efter forskellige værktøjer. Med tilstrækkelig viden om domænet, processen og værktøjerne er der levetiden til Software Tester-arbejde mere, hvilket gør hans / hendes arbejdsdage udfordrende og spændende. Samarbejde inden for teams er en af de vigtige faktorer for succes for ethvert projekt, og for effektivt samarbejde spiller kommunikation en meget vigtig rolle.
Anbefalede kurser
- Komplet J2EE omfattende kursus
- Online R-programmeringstræning
- Gå i programmeringskursus
- Online certificeringstræning i Haskell-programmet
Meddelelse
Kommunikation spiller en meget vigtig rolle for software, som den kvalificerer fra de indledende faser af softwareudvikling, testteammedlemmer er involveret (som en bedste praksis) i drøftelsen af krav, stillet spørgsmål til forretningsanalytikere i tilfælde af forespørgsler eller huller i kravet. En tster med effektive kommunikationsevner kan kommunikere risici effektivt, kan kommunikere effektivt med udviklingsholdet og kan kommunikere effektivt testresultaterne og testrapporterne.
Planlægning af softwaretesterværker
Som navnet antyder, er testplanlægning den fase, hvor forberedelse til testen udføres. Forberedelse til en tster vil involvere forskellige typer aktiviteter, som en tster udfører for effektivt at anvende. Dette vil hjælpe med at validere applikationen og afdække manglerne i applikationen effektivt. For at starte planlægningen gennemgår en test gennem kravene for at forstå forventningerne.
1. Krav
Der kunne stilles krav til testteamet i form af wireframes, storyboards, excel sheets. Formålet med alle disse dokumenter er at præsentere klientkravene på en effektiv og letforståelig måde. Wireframe-dokument er intet andet end et dokument, der kan være i form af PowerPoint-præsentation, der viser klientkravene. På de samme linier skildrer storyboards normalt det krævede udseende / design af skærmene. I dag findes forskellige værktøjer på markedet, som kan bruges til at forberede de krævede dokumenter. Oprettelse af nødvendige dokumenter er en forretningsanalytikers hovedansvar. En smag forventes at forstå kravene grundigt. For at testen såvel som udviklerne skal forstå kravene korrekt, holder forretningsanalytikere forummet åbent for alle at rejse og få spørgsmålene besvaret på et af kravene. Platformen til at diskutere og kommunikere de åbne spørgsmål og forespørgsler varierer fra projekt til projekt. Det kan være kæden af e-mails eller et konferenceopkald eller endda et delt drevlager, der vedligeholdes for at holde styr på alle åbne spørgsmål og deres svar, som leveret af forretningsanalytikeren.
Klar kommunikation og kommunikation optegnet spiller en meget vigtig rolle for et bevis. En lille antagelse i kravet kan undertiden føre til en større mangel i produktet. På hvert trin anbefales det en softwaretesterkvalitet at holde kommunikationen ren. Software Tester Arbejdskommunikation kan være med forretningsanalytikere eller endda i et team. Klar kommunikation hjælper med at holde antagelser væk under planlægning og udførelse. Samtidig anbefales det at have en fortegnelse over kommunikation (helst e-mail-kommunikation). At have en skriftlig meddelelse om forespørgsler i krav hjælper i de senere faser af testudførelse, hvor funktionaliteten muligvis ikke er blevet udviklet som bekræftet i den optagede kommunikation.
2. Scenario
Når kravene er forstået, begynder testeren at dokumentere scenarierne i Test Scenario-dokumentet. Et scenarie, som navnet antyder, er en strøm af funktionalitet, som brugeren følger for at udføre en opgave.
Eksempler på scenarier -
- Brugeren skal kunne logge ind med succes.
- Brugeren skal kunne booke billetter i systemet.
- Brugeren skal være i stand til at annullere billetter i systemet.
- Brugeren skal kunne se / opdatere profiloplysningerne.
Dette er de logiske opgaver, som en bruger udfører i systemet. Disse logiske opgaver, når de grupperes sammen, hjælper med at gøre opmærksom på alle de mulige scenarier, som en bruger forventes at udføre. Disse scenarier dokumenteres normalt i Excel-arkene eller nogle gange ved hjælp af nogle værktøjer. En prover trives med at udtrække alle sådanne scenarier fra kravdokumenterne. Et dokument, der indeholder sådanne scenarier kaldes Test Scenario Document (eller et eller andet sted som High Level Scenario Document). Dette dokument fungerer som et inputdokument til udarbejdelse af testtilfælde.
3. Sag
Denne sag er den mere detaljerede version af Software Tester-arbejdsscenariet, hvor scenariet er opdelt i mere detaljerede trin, som brugeren rent faktisk vil udføre, mens han bruger applikationen. Et simpelt eksempel baseret på de ovennævnte scenarier er:
Scenario - Brugeren skal kunne logge ind med succes.
Testtilfælde:
- Kontroller, at brugeren er i stand til at indtaste det rigtige brugernavn.
- Kontroller, at brugeren er i stand til at indtaste adgangskoden.
- Bekræft, når du klikker på knappen Login efter indtastning af rigtigt brugernavn og adgangskode, brugeren er i stand til at logge ind.
En sådan liste over disse sager kan fortsætte med at inkludere en valideringskontrol på hvert felt, kontrol af negative scenarier og så videre.
Nedenfor er nogle af de yderligere eksempler, disse sager -
- Kontroller, at brugernavnet, når det ikke er indtastet, kaster systemet en passende fejl.
- Kontroller, at adgangskoden, når den ikke er indtastet, kaster systemet en passende fejl.
- Kontroller, at brugernavn og adgangskode, når de ikke er indtastet, kaster systemet en passende fejl.
- Kontroller, at indtastning af forkert kodeord kaster systemet en passende fejlmeddelelse.
- Kontroller, at indtastning af forkert brugernavn kaster en passende fejlmeddelelse.
4. Kravsporbarhedsmatrix (RTM)
Krav til sporbarhedsmatrix, som navnet antyder, hjælper med at bevise og kontrollere og indarbejde dækningen af kravene, som er leveret af Business, i testdokumenterne, som scenarier og testsager.
Som bedste praksis er dette et separat dokument, der viser kortlægningen af kravnummeret med det for scenarier / sager, der inkorporerer dette krav.
Dette dokument bruges muligvis ikke af alle slags projekter, men når det bruges hjælper det på den stærke måde at spore kortlægning af scenarier på højt niveau til kravene. Det angiver dækningen og kan bruges til at kontrollere tilstedeværelsen af mindst en af disse sager mod hvert eneste krav. Oprettelse og vedligeholdelse af RTM-dokumentet betragtes som den bedste praksis, men ikke alle former for projekter (som Agile) bruger Software bevis for Arbejdsdokument. Når kravene ændres meget ofte, kan vedligeholdelse af dette dokument overhøres. For at undgå denne omkostning og på samme tid har en måde at spore krav på, indarbejder nogle projekter sporbarhedsdelen i Software Tester-arbejdscase eller selve scenariedokumentet.
Det vigtige aspekt er at have en måde at spore scenarier / sager til kravene og vice versa. Godt dokumenterede krav gør opgaven for Prover lettere at oprette og vedligeholde disse dokumenter. Tvetydige krav, stadigt skiftende krav gør proverens levetid mere udfordrende og kan føre til at have inkonsekvente leverbare dokumenter, som resulterer i at gå glip af en eller anden validering og dermed en mangel i slutproduktet.
Hidtil rejste en tester til at planlægge og forberede sig til test. Da forberedelse til krig er en del af krigenJ, gælder det samme her. Jo mere kortfattet disse dokumenter oprettes, det er lettere for den prover at validere funktionaliteten og afsløre næsten alle mangler. Den næste fase af testerens rejse er udførelse.
Udførelse af software tester fungerer
Dette er den fase, hvor alle ovennævnte dokumenter tages i brug. Krav blev brugt til at oprette et scenario, Scenario blev brugt til at oprette det Tilfælde. dette sagsdokument er det selvforsynende dokument her til at starte validering af applikationen. Prover starter validering af applikationen ved at udføre trin fra dette sagsdokument. Flere af disse tilfælde kan bruges til at validere et enkelt scenarie, eller endda et enkelt testtilfælde kan svare til et enkelt testscenario. Det hele afhænger af kompleksiteten af scenarierne eller nogle gange den standard, der følges i testholdet. Derfor kan et enkelt test case dokument indeholde 20-50 test cases, eller det kan have 100-120 test cases. Disse tal er kun til forklaringsformål, det kan variere meget fra projekt til projekt. Resultatet af denne fase er testdefekter. Antallet af gyldige defekter, der er rejst i denne fase, giver en god idé om stabiliteten i applikationen, kvaliteten af testning, kvaliteten af bygningen og mange sådanne faktorer, der direkte påvirker produktet. Denne fase er den vigtigste fase, da tester trives med at dække alle testtilfælde (validering af næsten alle krævede brugerstier) og samtidig hæve så mange gyldige defekter som muligt. Al forberedelse, kommunikationsevner, spørgsmål, der stilles til virksomheden, kommer til at handle i denne fase af testning.
Defekter af software tester fungerer
Under udførelse af denne sag rejses enhver opførsel, der ikke er lig med det forventede resultat, som manglen. Hver testtilfælde har en beskrivelse, forventet resultat og en kolonne for faktisk resultat. Mens disse planlægning Software Tester Work-dokumenter har en beskrivelse og forventede resultater og en tom kolonne for faktiske resultater. Mens testsagerne udføres, skal testeren udfylde den faktiske resultatsøjle. Samtidig, hvis den faktiske ikke er lig med det forventede resultat, logges defekten. At registrere en defekt betyder bare ikke at informere udvikleren om problemet. Det er igen en formel proces, der normalt udføres ved hjælp af et værktøj. I øjeblikket er der forskellige værktøjer på markedet, nogle open source og nogle licenserede. Ethvert værktøj til logning af fejl har følgende felter -
- Projekt / udgivelsesnavn
- Defekt resume
- Beskrivelse af defekt
- Defekt alvorlighed
- Defekt prioritet
- Fase blev fundet
- Tildelt
- Vedhæftede filer
Som vi kan se, er formålet med alle disse felter at have en formel procesvis detaljerede oplysninger om problemet fundet. Dette hjælper udviklere med at gengive defekten i deres miljø og rette den. Nedenfor er den korte beskrivelse af alle disse felter -
- Projekt / udgivelsesnavn - Navnet på frigivelsen, hvor defekten blev fundet, normalt har projektet flere udgivelser, og det samme projekt har muligvis flere underprojekter. Dette felt hjælper med at rejse et spørgsmål til en bestemt udgivelse.
- Defektoversigt - En kort beskrivelse af en fundet mangel på en linie.
- Defect Detail Description - Dette er den detaljerede beskrivelse af defekten, den skal indeholde detaljer som miljø, hvor defekten blev fundet, og testdata, der blev brugt, faktiske resultater forventede resultatet og eventuelle yderligere oplysninger, der tilføjer mere værdifulde oplysninger for interessenterne til at forstå defekt.
- Defect Severity - Det betyder, hvor alvorlig manglen er. Normalt har det værdier, der ligner kritiske, høje, mellemstore, lave eller numeriske værdier som 4, 3, 2, 1.
- Defektprioritet - Det betyder, hvor presserende det er at rette fejlen.
- Fase defekten blev fundet - Da der er mange faser, hvor en defekt kan logges, Enhedstestfase, SIT (systemintegrationstest), UAT (brugeraccepttest) eller endda produktionsfase.
- Tildelt til - Navn på udvikleren eller udviklingsledningen.
- Vedhæftede filer - Dette fik testeren en mulighed for at vedhæfte snapshot på skærmen, hvor problemet blev stødt.
Testeksekvering og defekt-logning er den fase, hvor der er mange udfordringer, som en tester kan møde. Nogle af dem kommunikerer effektivt med udviklerne. Kan vi hævde, at der logges en mangel med al nødvendig information, der ikke er tilstrækkelig til, at udviklerne kan forstå fejlen?
Det er, og i nogle af tilfældene kræver det yderligere forklaring / diskussion med udviklerne. Der er tilfælde, hvor en tester støder på en uventet opførsel, som han / hun måske ikke er sikker på, om det er en mangel. Disse omstændigheder står normalt over for prover, der er nye i teamet, som har begrænset domæne viden eller har uklarhed om kravene. Nå, testeren skal ikke bebrejdes her, hvis der er stramme frister, og der er stadigt skiftende krav, og i de fleste tilfælde lærer prover om domænet, mens de faktisk planlægger og udfører testsager. Som vi kan se, er en testers sti ikke så let, som den opfattes. Det kræver evt. Indlæringsholdning, gode kommunikationsevner, gode samarbejdsevner og iver efter at tilpasse sig til forhold, hvor der er ændringer i domæner, værktøjer, anvendte processer. Mens vi talte om manuelle testers rejse, gælder den samlede proces også Automation-testere. Automation har på den anden side betydelige ændringer i processen, da omfanget af test og planlægning, udførelse varierer markant.
I betragtning af den provers rejse som diskuteret ovenfor, kan vi stadig sige, at jobbet med softwaretesterkvaliteter er lettere end for en udvikler?
Det kan siges, at mere end at sammenligne tester v / s-udviklerroller, vil det være mere nyttigt at diskutere, hvordan samarbejdet mellem to kan føre til en stor succes for produktet som helhed. Vi glemmer undertiden, at testers opgave er at finde problemer i applikationen og ikke at pege på udviklernes fejl. Når vi glemmer selve ideen om vores job, fører det undertiden til unødvendig diskussion. Imidlertid observeres det, at der er lige så gode test-udviklingshold, hvor alle forstår, at slutformålet er at få applikationen til at fungere som forventet. Lad os håbe for alle at se på den positive side af testjobbet som en rolle, der hjælper med at rengøre produktet og ikke som den, der bare finder fejl!
Anbefalede artikler
Dette har været en guide til at afdække og validere de åbenlyse og ikke så åbenlyse applikationsstier er altid den primære forventning fra et software-testerarbejde. Dette er følgende eksterne link, der er relateret til software tester arbejde.
- Defekter livscyklus i softwaretest
- 6 mest fantastiske softwaretestintervjuespørgsmål
- Karrierer inden for softwaretestning