what are test deliverables software testing
Lær alt om testleverancer i softwaretest med eksempler:
Et lettelsens suk kommer for hver tester, når den tildelte opgave er afsluttet med succes. Ved afslutningen af hver test skal testeren sende de relevante testleverancer til klienten.
I denne artikel vil vi se nærmere på nogle af de vigtige testleverancer.
Testleverancer bruges generelt gennem et projekt. De bruges i alle testfaser, og de skal altid sendes til tiden for at fortsætte til yderligere behandling.
Hvad du vil lære:
Testleverancer i softwaretest
Testleverancer spiller en vigtig rolle i softwaretest. Denne artikel diskuterer alt om testleverancer i detaljer.
Nogle af de vigtige testleverancer er anført nedenfor til din reference:
- Teststrategi
- Testplan og estimering
- Test scenarie
- Test tilfælde og testdata
- RTM
- Testoversigtsrapport
- Testlukningsrapport
- Hændelses rapport
Teststrategi
Teststrategi vil blive besluttet baseret på specifikationerne for forretningskrav. Det er et vigtigt dokument, der indeholder alle detaljer i det testarbejde, der skal udføres. Det er et komplet ledelsesdokument.
hvorfor er det nødvendigt at køre et program ved hjælp af testdata til input?
Sammenlignet med testplanen er dette et dokument på højt niveau og udarbejdes normalt af testadministratoren eller leadet. Testmål, testtilgang, testomfang, indgangs- og udgangskriterier, typer og testniveauer, milepæle, personale osv. Skal nævnes her.
Testplan og skøn
Detaljerne på det granulære niveau for hvert testtrin skal nævnes her. Generelt fører en ordentlig plan til en ordentlig arbejdsstruktur. Tilsvarende fører en god plan til god testning.
Testmål, testtilgang, testomfang, indgangs- og udgangskriterier, typer og testniveauer, milepæle, personale osv. Skal nævnes her på en detaljeret måde.
Masterplanen, der inkluderer, hvordan test skal gennemføres, bruges til enkle projekter.
Skøn: Estimering definerer, hvor længe hvert trin vil ske i test sammen med de samlede omkostninger.
Læs også => En perfekt testplanvejledning - En dybdegående guide
Testscenarie
Vi vil forstå dette med et eksempel nu. Lad os tage togreservation som et eksempel her. Alle de funktioner, som vi har brug for at teste, er nævnt i højtstående former i testscenariedokumentet. Med enkle ord betyder det en gruppe af lignende aktiviteter, der skal udføres.
To teknikker til scenariet:
# 1) Brugssag
Det er den målrettede metode, der er et sæt interaktioner mellem de eksterne faktorer og systemet. Dets komponenter inkluderer primær flow, alternativ flow, triggere eller aktiviteter, undtagelsesflow, præ-betingelser, post-betingelser osv.
Eksempel:
[billede kilde ]
# 2) ACE (aktivitetskomponentelement)
Aktivitetskomponentelementet opdeler forretningskravene i aktiviteter.
Eksempel:
Generelt booker vi en billet ved at udfylde passageroplysninger, køn osv. Derfor er vi nødt til at validere følgende felter, som derved bliver scenarier.
- Reservation: Tjek reservationsfunktionaliteten.
- Passageroplysninger: Kontroller funktionerne for køn, alder og kønsfelter.
- Modificere: Kontroller, om ændringsfunktionen fungerer korrekt.
- Koncession: Kontroller, om koncessionsfunktionaliteten fungerer korrekt.
- Udsigt: Kontroller, om visningsfunktionaliteten fungerer korrekt.
- Afbestille: Kontroller, om annulleringsfunktionen fungerer korrekt.
Her kan koncessionen kaldes et ”alternativt scenarie”, som brugeren kan reservere med eller uden det baseret på alderen. Målet er dog det samme, dvs. at booke en billet.
Test sag
Ved at tage det samme ovenstående eksempel på reservationssiden, skrives testsagerne som følger:
Reservation:
- Kontroller, om brugeren kan bestille en billet ved at udfylde gyldige detaljer i alle felterne.
- Kontroller, om brugeren kan bestille en billet ved at udfylde ugyldige detaljer i alle felterne.
- Kontroller, om brugeren kan bestille en billet ved at efterlade et tomt felt.
Passageroplysninger:
manuelle testinterviewspørgsmål til erfarne
- Kontroller, om brugeren kan bestille en billet ved at indtaste et gyldigt navn.
- Kontroller, om brugeren kan bestille en billet ved at indtaste et ugyldigt navn.
- Kontroller, om brugeren kan bestille en billet ved at vælge et køn ad gangen.
- Kontroller, om brugeren kan bestille en billet ved at indtaste en alder, der er over 60 år.
- Kontroller, om brugeren kan bestille en billet ved at indtaste en alder under 60 år.
- Kontroller, om brugeren kan bestille en billet ved at indtaste en gyldig alder, der er større end 5 år.
- Kontroller, om brugeren ikke er i stand til at booke ved at indtaste en alder under 5 år.
Modificere:
- Kontroller, om brugeren kan ændre navnefeltet.
- Kontroller, om brugeren kan ændre kønsfeltet.
- Kontroller, om brugeren kan ændre aldersfeltet.
Koncession:
- Kontroller, om brugeren kan få indrømmelse ved at vælge “ Senior borger ' mulighed.
- Kontroller, om brugeren kan få indrømmelse ved at vælge “ Handicappet / handicappet ' mulighed.
Udsigt:
- Kontroller, om brugeren kan se den reserverede billet.
Afbestille:
- Kontroller, om brugeren kan annullere billetten.
Således fortæller testcases, hvad der præcist skal testes i detaljer. Testcases skal skrives på et enkelt sprog og skal være let forståelige. Det skal skrives i korrekt format, som den berørte klient har bedt om.
Testdata
Nogle projekter har brug for forudgående data fra klienten, inden de fortsætter med udførelsen af testsagen. Testdata skal anvendes for at udføre test.
Eksempel: I hospitalets portal til at få en injektion er det vigtigt at få patientoplysningerne til at kontrollere injektionspåmindelsesmuligheden.
Her er ”patientoplysningerne” testdataene.
Foreslået læsning => Testdata - Betydning og forberedelsesteknikker med eksempler
RTM / kravsporbarhedsmatrix
- Som navnet antyder, betyder det simpelthen, at du skal kortlægge ethvert krav med den relevante testcase.
- Det hjælper os med at kontrollere, om vi har dækket alle kravene i vores testsager eller ej.
- Det hjælper med omarbejdning eller de næste successive udgivelser af et projekt.
- Klienten kan nemt kontrollere vores dækningsstatus og kende vores testproces.
Testoversigtsrapport
Testoversigtsrapport opsummerer alle udførte testaktiviteter, og testresultaterne er samlet heri. Alle testoplysninger såsom medlemmer involveret i test, mål, omfang, klientoplysninger, anvendt testtilgang, testresultater, manglerapport osv. Bør nævnes her.
Testresumérapporten skal dog udarbejdes efter kundens råd. Således er det et nyttigt dokument for klienten såvel som at gennemgå den samlede præstation.
Test lukningsrapport
Det betyder, at vi vil lukke projektet efter test og fejlretning. Så her skal vi give en detaljeret analyse af udførelsen af testene.
De fundne og faste mangler skal nævnes her. Den samlede kravdækning ses i denne rapport. Det udarbejdes generelt af teamlederen eller lederen. Alle udgangskriterier skal opfyldes i overensstemmelse hermed.
c # interviewspørgsmål med svar
Hændelses rapport
Under udførelse af formationsudførelse, hvis en bruger finder mangler, skal en Incident-rapport (IR) hæves. Dette betyder, at der er en fejl, og at eksekveringen skal stoppes. Vi er nu nødt til at rejse en hændelsesrapport til klienten for at bede dem om tilladelse til at udføre fejlområderne igen som en separat testsag.
Dette er faktisk et sort mærke og forventes ikke af en tester. Alle mangler skal findes i selve tørløbet. Hvis det bliver savnet og fundet i formel udførelse, bliver det en IR.
Eksempel:
Hvis jeg savner en vis funktionalitet i mobiltestning, skal du sige “ ændring af pauseskærm ' mulighed. Derefter bliver jeg låst, mens jeg udfører en testsag, og jeg kan ikke gå videre på grund af denne mulighed. Derefter hæver jeg en IR og skriver en separat testcase for at udføre pauseskærm.
Konklusion
Artefakterne, der sendes til interessenterne i et softwareprojekt under STLC, er kendt som testleverancer. Vi kiggede på de vigtigste testleverancer i denne artikel.
Vi håber, at denne artikel hjalp dig med at lære om testleverancer i softwaretest !!
Anbefalet læsning
- Forskellen mellem præstationsplan og præstationsprøvestrategi
- Sådan udarbejdes testplan og skriv testtilfælde til ERP-applikation - ERP-test del-2
- Testplan Tutorial: En guide til at skrive et softwaretestplan-dokument fra bunden
- Test Data Management koncept, proces og strategi
- Hvad er testdata? Testdata Klargøringsteknikker med eksempel
- Sådan skriver du testtilfælde: Den ultimative guide med eksempler
- Sådan skriver du teststrategidokument (med prøve teststrategiskabelon)
- Forskellen mellem testplan, teststrategi, test case, test script, testscenarie og testtilstand