præsentation af et perfekt produkt til kunden er slutmålet for enhver organisation. Men vidste du, at der var en tid, hvor test ikke engang var en del af programudviklingens livscyklus (SDLC)?

intet afskrækker kunder mere end bugfyldt brugeroplevelse. Så da virksomhederne indså dette, begyndte de at inkludere test som en obligatorisk del af SDLC. Siden da er test blevet en integreret del af enhver organisation.

testens kompetence har udviklet sig i løbet af de sidste par årtier. I øjeblikket handler test ikke om at rapportere fejl til udvikleren. Det har et bredt omfang og er en obligatorisk fase, der skal udføres fra de indledende faser af et projekt.

med agile blev en applikations testlivscyklus mere procesorienteret og alsidig. Normalt er hele virksomhedens fokus på SDLC alene. Og de overvejer at teste en del af denne proces. Men det er på høje tid, at virksomheder indser, at test af programmer har sin egen livscyklus.

i dette indlæg vil vi tage et kig på rollen af programmet testing life style (STLC) og dens faser i detaljer. Så lad os dykke lige ind!

Hvad er testens livscyklus?

lad os først forstå udtrykket livscyklus, før vi går ind i alle detaljer. En livscyklus er sekvensen af ændringer, som en enhed gennemgår fra en form til en anden. Mange konkrete og uklare enheder gennemgår en række ændringer fra start til slut.

Når vi taler om programtestens livscyklus, er programmet en enhed. Livscyklussen for test af programmer er processen med at udføre forskellige aktiviteter under test.

disse aktiviteter omfatter kontrol af det udviklede program for at se, om det opfylder specifikke krav. Hvis der er fejl i produktet, arbejder testere med udviklingsholdet. I nogle tilfælde skal de kontakte Interessenten for at få indsigt i forskellige produktspecifikationer. Validering og verifikation af et produkt er også vigtige processer i STLC.

SDLC vs. STLC

den komplette rejse af et produkt fra dets start til at blive det endelige produkt er taget hånd om af SDLC. Blandt de forskellige faser af SDLC er test en af de vigtigste. Test er en del af SDLC. Og denne del har sin egen livscyklus-STLC.

så hvordan er SDLC forskellig fra STLC?

SDLC

• fokus på at opbygge et produkt
• en overordnet proces
• forståelse af brugerkrav og opbygning af et produkt, der er nyttigt for brugerne
• SDLC-faser er afsluttet inden Test
• slutmålet er at implementere et produkt af høj kvalitet, som brugerne kan bruge

STLC

• fokus på at teste et produkt, der er
• et barn af SDLC-proces
• forståelse af udviklingskrav og sikring af, at produktet fungerer som forventet
• stlc-faser starter efter faser af SDLC er afsluttet
• slutmålet er at finde fejl i produkt og rapport til udviklingsteam til fejlrettelse

disse er de grundlæggende forskelle mellem SDLC og STLC. Lad os nu forstå STLC i dybden.

Hvad er STLC ‘ s rolle?

nu hvor vi har kernen i, hvad programtestens livscyklus er, lad os se på, hvorfor det er vigtigt. Selv hvis et firma har de bedste programmører og udviklere, er de bundet til at lave fejl. STLC ‘ s vigtigste rolle er at finde disse fejl og få dem rettet. Hovedmålet med at gennemføre en STLC er at opretholde produktkvaliteten.

Borte er de dage, hvor middelmådig test var trenden. I dagens verden skal virksomheder foretage detaljerede test.

fra planlægning og forskning til udførelse og vedligeholdelse spiller hver fase en afgørende rolle i test af et produkt.

SDLC handler om at sikre produktets kvalitet. Hver applikation har forskellige attributter såsom pålidelighed, funktionalitet og ydeevne. Og STLC hjælper med at forbedre disse egenskaber og letter leveringen af et ideelt slutprodukt.

et produkt af høj kvalitet resulterer i lavere vedligeholdelsesomkostninger på lang sigt. Stabiliteten af en applikation eller et program er et must for at lokke nye brugere. Bortset fra det hjælper konsekvent pålidelige produkter også med at bevare eksisterende kundekreds. For at et produkt skal forblive i erhvervslivet, er det vigtigt at fokusere på hver fase af STLC.

faser af Programtestning livscyklus

validering af hvert modul af programmer eller applikationer er et must for at sikre produktpræcision og nøjagtighed. Da programmelprøvning i sig selv er en udførlig proces, udfører testere det i faser. Kompleksiteter kan dukke op, hvis test mangler organisation. Kompleksiteten kan omfatte uløste fejl, uopdagede regressionsfejl eller i værste fald et modul, der sprang over test, fordi fristen kom nærmere.

hver fase af STLC har et specifikt mål og leverancer. Det indebærer initiering, udførelse og afslutning af testprocessen.

lad os se nærmere på de forskellige faser af programtestens livscyklus.

kravanalyse

dine værdifulde testere skal se, studere og analysere de tilgængelige Specifikationer og krav. Visse krav giver resultater ved at fodre dem med inputdata. Disse krav er testbare krav. Testere studerer både funktionelle og ikke-funktionelle krav. Derefter skal de udvælge testbare krav.

aktiviteter i denne fase inkluderer brainstorming til kravanalyse og identifikation og prioritering af testkrav. De omfatter også udvælge krav til både automatiseret og manuel test.

der er et par ting, du har testet, selvom det ikke udtrykkeligt er nævnt. Et klik på en aktiv knap skal gøre noget, et tekstfelt til telefonnummer bør ikke acceptere alfabeter indsendt. Disse ting er universelle og bør altid testes. Men i kravanalysefasen handler det om at vide mere specifikke detaljer om produktet. Du skal lære, hvordan produktet skal være i sin ideelle tilstand.

for at opsummere det:

• forstå det forventede output fra produktet.
• Identificer eventuelle smuthuller i specifikationerne.
• Saml prioriteter.
• Udfør automatisering gennemførlighedskontrol.

testplanlægning

det andet trin er testplanlægning, og KVALITETSSTYRINGSHOLDET opretter denne plan efter at have analyseret alle de nødvendige testkrav. De skitserer omfanget og målene efter at have forstået produktdomænet. Holdet analyserer derefter de involverede risici og definerer tidsplaner og testmiljøer for at skabe en strategi.

derefter afslutter ledelsen værktøjerne og tildeler roller og ansvar til enkeltpersoner. En omtrentlig tidslinje defineres også, hvormed testningen af hvert modul skal afsluttes.

for at opsummere det:

• Forbered testplan dokumentation.
• skøn tid og indsats.
• færdiggør på værktøjer og platform.
• Tildel opgaver til teams og enkeltpersoner.
• Identificer træningskrav

Test Case Design og udvikling

efter udvikling og planlægning er det tid til at lade de kreative juice flyde! Baseret på testplanen designer og udvikler testere testsager. Testsager skal være omfattende og bør dække næsten alle mulige tilfælde. Alle gældende permutationer og kombinationer skal indsamles. Du kan prioritere disse testsager ved at undersøge, hvilke af dem der er mest almindelige, eller hvilke af dem der vil påvirke produktet mest.

næste kommer verifikation og validering af specificerede krav i dokumentationsfasen. Gennemgang, opdatering og godkendelse af automatiseringsskripter og testsager er også vigtige processer i denne fase. Denne fase inkluderer også definition af forskellige testbetingelser med inputdata og forventede resultater.

for at opsummere det:

• forskning og indsamle mulige handlinger på produktet.
• Opret testcases.
• Prioriter testsager.
• Forbered automatiserede scripts til testcases.

opsætning af testmiljø

testaktiviteter kræver visse miljøfaktorer—f.eks. servere, rammer, udstyr og programmer—til udførelse af udviklede testcases. Programmel og udstyrskonfiguration sammen med testdataopsætning er hovedkomponenterne i denne fase. Og det er obligatorisk at ryge test og at udstyre dine testere med fejlrapporteringsværktøjer.

i udviklerfællesskabet er det almindeligt at høre “det kørte på mit system, men det kører ikke på dit”. Derfor er det vigtigt, at dit testmiljø dækker alle de miljøer, som brugeren vil bruge.

for eksempel fungerer nogle funktioner, der fungerer i Google Chrome, ikke i Internetudforsker. Funktionen af funktioner varierer også baseret på krav til programmer og udstyr. En funktion fungerer muligvis problemfrit på 4 GB RAM, men kan skabe problemer med 1 GB RAM. Forskning i miljøer, der bruges af slutbrugere, vil hjælpe dig med at prioritere dine testmiljøer.

det er en opgave for KVALITETSSTYRINGSCHEFEN, der fører tilsyn med teamet, at sørge for at opsætte testmiljøet.

for at opsummere det:

• forstå minimumskrav
• liste ned programmer og udstyr, der kræves til forskellige niveauer af ydeevne.
• Prioriter testmiljøer
• Setup testmiljøer
• Røgtest de byggede miljøer

Testudførelse

en applikation er klar til test, når teamet er færdig med alle de foregående faser. I henhold til testplanen udfører testerne testsager. De identificerer også, registrerer og logger fejlene og rapporterer dermed fejlene. Holdet er også ansvarlig for at sammenligne forventede resultater med det reelle resultat. Hvis der findes fejl, skal de dokumenteres for at videregive det til udviklingsholdet for at få en løsning.

når udviklingsholdet fjerner en fejl, begynder regressionstest. Regressionstest er at sikre, at programmet eller applikationen fungerer, selv efter implementering af en ændring. Når du tester efter en fejlrettelse, skal du teste det komplette produkt igen. Fordi en rettelse til en fejl kunne skabe en fejl på en anden del af produktet. Og fordi de samme tests skal køres igen og igen efter hver rettelse og implementering, anbefales det at bruge scripts eller automatiserede testværktøjer.

for at opsummere det:

• Kør testsager.
• Identificer afvigelse fra produktets forventede opførsel.
• Log mislykkede tilfælde med detaljer
• Test igen efter fejlrettelser.

Testlukning

og det bringer os til den sidste fase af STLC: testlukning.

afslutningen af testudførelsen og leveringen af slutproduktet markerer starten på testlukningsfasen. KVALITETSSTYRINGSHOLDET kontrollerer testresultaterne og diskuterer dem med andre teammedlemmer. Nogle andre faktorer, de overvejer, er produktkvalitet, testdækning og projektomkostninger. Hvis der er en afvigelse fra estimerede værdier, kan yderligere analyser udføres for at identificere, hvad der ikke gik som forventet.

det er en vigtig praksis for testere at komme sammen og diskutere konklusionen efter test. Eventuelle problemer, der står over for under test, mangler i strategier kan diskuteres her. Du kan også arbejde på at komme med en bedre tilgang til test baseret på læringen under test. Hvis du følger DevOps eller kanariefrigivelsespraksis, er test hyppig. Du kan beslutte, hvor ofte du vil sende rapporter, og hvilke detaljer du skal nævne, mens du sender rapporter til forskellige interessenter.

bortset fra det overvejer teamet også testmålinger, opfyldelse af mål og deres overholdelse af deadlines. Når de har en total forståelse for, hvad der skete, kan de evaluere hele teststrategien og processen.

for at opsummere det:

• Kontroller, at alle test er afsluttet.
• Evaluer faktorer som kvalitet, testdækning, tidslinje og omkostninger.
• dokument konklusionen.
• Diskuter læringen og find ud af, om testprocessen kan forbedres.
• Forbered test lukning rapport.

Hvad er indgangs-og Udgangskriterierne for test?

alle seks faser af en programtestnings livscyklus har ind-eller udgangskriterier forbundet med dem. Testere skal afslutte udførelsen af testsagerne inden for en fast tid. De skal også opretholde slutproduktets kvalitet, funktionalitet og effektivitet. Derfor er det et must at definere ind-og udgangskriterier. Det gør vi nu.

adgangskriterier

adgangskriterier angiv hvilke krav holdet skal tage sig af, før testproceduren påbegyndes. Før testen begynder, er det obligatorisk at krydse alle krav.

der er nogle igangværende aktiviteter og betingelser, der skal være til stede, før testen begynder. For det første har du brug for input fra udviklingsholdet. Du vil også gerne undersøge testplanen, testcases og data, testmiljøet og din kode.

Afslutningskriterier

Afslutningskriterier angiv de krav og handlinger, der skal gennemføres, inden testen afsluttes. Med andre ord inkluderer de elementer, der skal krydses af opgavelisten, og processer, der skal udføres, før testningen stopper.

Udgangskriterier inkluderer identifikation af defekter med høj prioritet. Du bliver nødt til at få dem rettet med det samme. Testere skal bestå forskellige testsager og sikre fuld funktionel dækning.

konklusion

det er ikke længere en effektiv praksis at identificere fejl i den sidste fase af en SDLC. Der er forskellige andre daglige aktiviteter, som et firma skal fokusere på. At bruge for meget af din dyrebare tid til at teste og rette fejl kan hæmme effektiviteten. Når alt kommer til alt tager du mere tid til at generere mindre output.

for at lette testprocessen er det vigtigt at udnytte tid og ressourcer effektivt. Efter en systematisk STLC resulterer ikke kun i hurtig fejlrettelse, men det forbedrer også produktkvaliteten. Ved at øge kundetilfredsheden får du øget ROI og forbedret brandtilstedeværelse.

dette indlæg er skrevet af Arnab Roy. Arnab er en UI udvikler af profession og en blogging entusiast. Han har stor ekspertise inden for de nyeste trends, projektmetoder, test og scripting.

hvad skal jeg læse næste

Hvad er Shift Left Testing? En Guide til forbedring af din kvalitet