how improve test release process
Lad os se den typiske proces involveret i levering af software fra 'udviklingsfase' til 'testfase' for en vellykket fejlfri softwareudgivelse til produktion / klient .
Disse processer overses enten eller springes over af softwarevirksomheder, hvilket resulterer i dårlig testadministration og derved 'en ' buggy ”Softwareudgivelser til klienten, hvilket fører til“ utilfredse kunder ”.
Selv om meget tid og stor indsats fra testteamet til hver eneste udgivelse , når den frigivne software ikke har kvaliteten som defineret eller benchmarket eller ikke opfylder de forventede kriterier, vil det ikke kun påvirke virksomhedens omdømme hos kunderne, men demotiverer og demoraliserer projektteamet vigtigst af alt testteamet som helhed .
Hvis du er en del af et testteam i dette scenarie, tænker du måske selv ”hvordan man forbedrer mine testfunktioner og er der nogen bedre måde at overvinde denne situation på”.
Jeg vil give nogle tip og forslag baseret på min erfaring med forskellige testteam involveret i softwareapplikationer og frigivelser af virksomhedsprodukter med flere domæner og platforme og med flere testrammer, om hvordan man forbedrer testudgivelsesprocesserne , hvilket forenkler dit professionelle liv som testingeniør eller testmanager til levering af software i verdensklasse.
Hvad du vil lære:
- Testudgivelsesproces
- Testfrigivelsesprocesforbedring:
- Administration og styring af testudgivelsesindholdet
- Eksempel på udgivelsesrapportskabelon:
- Konklusion:
- Anbefalet læsning
Testudgivelsesproces
Tabellen nedenfor giver et overblik over en testfrigivelsesproces med tre universelle faser som Input, Process & Output.
bedste annonceblokker til mac chrome
| INDGANG | BEHANDLE | PRODUKTION |
|---|---|---|
| 7 | Tjekliste til gennemgang af kode er blevet opdateret og tilgængelig i VSS? | |
| Tidligere proces Udvikling | Processen starter med • Installation af frigivet software på testserveren | Næste procesbehov • Software, der bestod røg / sundhedstest |
| Information / Dokumentreference • Dokument til brugerkrav • Specifikationer for softwarekrav • Enhedstestplan • Kodningsstandarder • Tjekliste til gennemgang af kode • Udviklingsplan • Kvalitetssikringsplan • Opgavefordeling • Arbejdspakke • Projektplan • Projektplan • Konfigurationsstyringsplan • Risikostyringsplan. | Underprocesser • Forberedelse af testtilfælde til alle enhederne • Udvikling og enhedstest • Håndtering af afvigelsesprocedurer • Implementering af konfigurationsstyringsplan. • Implementering af risikostyringsplan • Overvågning af projektforløb • Fejlkorrektion og anmeldelser | Interne kundebehov • Software bygget med version nummer • Udgiv rapport • Test sager / Test Suite-dokument • Test udførelsesplanlægning • Sporbarhedsmatrix • Test data |
| Indgående verifikation af input • Projektdokumenter gennemgås og godkendes? • Kodningsstandarder, Tjekliste til kodevurdering er tilgængelige til reference? • Opgaveallokeret og arbejdspakke opdateret? • Funktionel specifikation, udviklingsplan og kvalitetsplan gennemgås og godkendes? • Risikostyringsplan har afbødning og beredskab til at håndtere risiko? • Effektiviteten af projektplanen til levering af produktet til tiden? | Processpecifikation • Enhedstestsager skal bestå af alle indgangs- og udgangskriterier • Overholdelse af kode med kodningsstandarder • NCP skal håndteres i henhold til retningslinjen • Konfigurationsstyringstrin skal overholde konfigurationsstyringsplanen • Risikohåndtering skal overholde risikostyringsplanen • Røgtest bestå alle de vigtigste funktioner og funktioner | Eksterne kundebehov • Fejlfri software |
| Understøttende processer • Tildeling af mennesker / hardware / software / ressourcer • Vedligeholdelse af hardwarefordeling • Træning til teammedlemmer | Processen slutter med • Udførelse af røg / sundhedstest på den frigivne bygning | Effektivitetsparametre • Hver enhed skal bestå den første testrunde • Opgaver, der skal udføres i henhold til projektplanen • Røgtest skal bestås inden frigivelsen • Test af teamets passion for at teste softwaren |
Hvert testteam skal oprette en enestående tjekliste til softwareudgivelse, i henhold til domænet og platformen for softwaren og projektledelsesmetoden (som Agile Scrum osv.) og i henhold til manuel / automatiseret testramme at acceptere den frigivne build, inden testudførelsen påbegyndes for at spare tid og kræfter.
Dette er en af de vigtigste effektivitetsparametre i testfrigivelsesfasen.
Testfrigivelsesprocesforbedring:
1) Gennemgå frigivelsesrapporten til den nye funktionalitet, tilpasning / ændring af eksisterende funktionalitet, fejlrettelser fra den forrige build, som vil beslutte at starte udførelsen af røgtest eller sanity-test eller en kombination af begge.
to) Gennemgå opdateringen Test af dokumenter i henhold til den nye funktionalitet og fejlrettelserne, hvis den ikke allerede er opdateret. Normalt opdateres disse dokumenter i løbet af softwareudviklingslivscyklussen af testteamet baseret på de regelmæssige ugentlige projektgennemgangsmøder.
3) Gennemgå Software Build in Configuration Repository opdateres til build-nummer, versionsnummer, mærkes eller kommenteres med frigivelsesnavnet i henhold til de standarder, der er defineret i projektplanen. Sørg også for, at build er succesfuldt kompileret og installeret på testserveren.
4) Planlæg et hurtigt projektmøde efter frigivelse at diskutere fordele og ulemper ved den frigivne build, kendte bugs og kritisk funktionalitet osv. for at undgå misforståelse og gennemgå vigtige kundekrav. Undgå strengt enhver mundtlig kommunikation mellem udviklings- og testteamet, da det i høj grad påvirker kvaliteten af softwareudgivelsen.
5) Sørg for, at fejlsporingsværktøjet er konfigureret korrekt , for det tildelte testteam og projektudviklingsteam, softwarebygning og frigivelsesnumre samt softwarens moduler / funktionalitet, som vil hjælpe med at logge fejlene effektivt. Hvis ikke, skal det eskaleres til projektlederen eller testlederen på høj prioritetsbasis.
6) Returner Build til udviklingsteamet uden kompromiser, hvis bygningen mislykkes i røg- eller sundhedstest. Strengt taget bør testning ikke fortsættes, når systemet mislykkes i røgtest. Dette vil spare meget tid og kræfter og forbedre kvaliteten af den software, der frigives i de efterfølgende udgivelser.
7) Planlæg projektudgivelsen den 1.St.Dag i ugen som vil hjælpe testlederen med at planlægge den kommende testcyklus baseret på byggestabilitet og også sende en hurtig testrapport til projektlederen, som eskalerer kvaliteten af softwaren i god tid. Hvis udviklingsteamet planlægger projektudgivelsen på fredag, kan weekenden bruges til eventuelle glider såvel som eventuelle buildproblemer i en manuel eller automatiseret build-ramme.
8) Sørg for, at testerne trænes korrekt på domænet som vil hjælpe testteamet med at overholde testplanen og samle tid til næste testrunde. Testteamet skal også trænes og have eksponering for den krævede teknologi som Scripting og SQL, hvis projektet kræver hvid boksning.
9) Undgå tildeling af testere i flere projekter da det i høj grad påvirker kvaliteten af testudførelsen i realtid. I praksis overser selv de erfarne testere funktionerne og funktionaliteten samt springer testkasserne over, forudsat at nogle testkasser aldrig fejler, når de er overbelastet med arbejde eller tildelt på flere projekter med deadlines.
10) Sæt pris på, at testteamet har lidenskab da testere ikke burde arbejde for 'dagen' eller kommentere 'kalde det en dag'. Når software har flere moduler, og funktionalisten er helt eller delvist integreret eller indbyrdes relateret, skal testere have lidenskab for at skrive / udføre testcases med stor dækning og sporbarhedsmatrix, der målretter kvaliteten af det endelige software / produkt. Fordi selv et kosmetisk problem er en 'bug' og tælles som '1 bug'.
elleve) Sørg for, at softwareinstallationen er let og ligetil da det hjælper testteamet med at geninstallere softwaren, når det er nødvendigt, i stedet for at vente på, at udviklingschefen eller en installationsmanager udfører det samme job, hvilket vil dræbe den tilgængelige testtid unødigt. For eksempel, selvom Windows-baseret installation er let, men når det involverer flere webservere og wide area-netværk i et testniveau med flere niveauer, kan det tage timer at installere softwaren. Hvis softwaretest dækker og installation, afinstallation , programrettelser eller opdateringer af software, er det mere sandsynligt, at det diskuteres detaljeret processen med at udføre testsagerne med testteamet.
12) Sørg for, at de automatiserede værktøjer er tilgængelige med licens til en ramme om automatiseringstest . Udførelsen af testsager i en automatiseret ramme er let sammenlignet med et manuelt testscenarie, forudsat at de automatiserede værktøjer er korrekt konfigureret og licenseret til flere brugere. Især når testplanen involverer ydeevne- og belastningstest bortset fra den almindelige testcaseudførelse og regressionstest, bør testere dække udførelse af testsager i flere miljøer som flere servere, flere browsere, flere brugere osv.
13) Sørg for, at Ghosted Machines er konfigureret til test før start af testudførelse. Ghosted maskiner er maskiner med forskellige testmiljøer. For eksempel kan der planlægges en webapplikationssoftware til test i flere miljøer som Windows 7 & Access DB eller Windows 2008 & SQL Server eller Windows 8 & Oracle eller Mainframe & DB2 osv. Med alle browsere som Chrome, Firefox, Internet Explorer , Safari osv., Noget “Systemtest” kræver endda at formatere harddisken fuldstændigt og installere en ny software eller opdatere den eksisterende software med programrettelser og opdateringer osv.
14) Undgå at implementere de nye funktioner / ændringsanmodning ved at stoppe testudførelsen og genudgive softwaren til at angive testfasen igen. Dette er en meget dårlig praksis i mange softwareorganisationer i henhold til forretningskravene for at tilfredsstille de eksterne kunder eller i det mindste for at imødekomme kravene fra ledelsesstyringskomiteen eller undertiden salgs- / marketingteamet. Selvom ændringsanmodningerne fra kunderne altid opmuntres i et 'Agile' projektmiljø, skal det planlægges korrekt og implementeres inden frigivelsen af softwaren til testteamet.
Administration og styring af testudgivelsesindholdet
Administration og styring af testudgivelsesindholdet er vigtigst for enhver it-software eller endda for ethvert ikke-it-softwaremiljø, som vil blive vist i nedenstående figur.
- Projektledere og / eller projektstyringsudvalget afhænger af autoriteten i organisationsmatrixen, er ansvarlig for at vælge indholdet til hver eneste udgivelse.
- Når fejlene og / eller de nye funktioner og ændringsanmodningen fra kunderne er identificeret og godkendt, vil den blive implementeret af udviklingsteamet, som skal intimideres til projektets interessenter, inden udviklingen / implementeringen påbegyndes.
- Baseret på den implementerede endelige udgivelse opdaterer testteamet de relaterede dokumenter og forbereder sig på testen i overensstemmelse hermed.
- Testteamet starter røg / sanitetstest i henhold til de definerede krav i frigivelsesrapporten.
- Når Sanity er bestået, vil testteamet starte testudførelsen i henhold til tidsplanen og tildelte opgaver, dvs. funktionel test, ikke-funktionel test, sikkerhedstest, systemtest, ydelsestest, belastningstest, brugeracceptstest osv.
- Når den første runde af testcyklus er afsluttet, sendes testrapporter til alle interessenter og lederne for udviklingsteamet for at planlægge den næste iteration af testudførelse.
- Afhængig af status for testrapporterne og fejlens sværhedsgrad og kompleksitet planlægges en komplet cyklus af en anden runde af testudførelse eller regressionstest sammen med brugeraccepteringstesten.
- Efter at have afsluttet de planlagte testudførelsescyklusser, sendes testrapporterne til alle projektets interessenter for bestået / mislykket / savnet af funktionerne, funktionaliteten og fejlrettelserne.
Eksempel på udgivelsesrapportskabelon:
Bemærk : Eksempel MS Word-skabelon til udgivelsesrapport kan også downloades nedenfor.
Find nedenfor en “ Prøveudgivelsesrapport ”Der dækker de vigtigste aspekter af frigivelsesprocessen, der gør hele projektteamets professionelle liv meget lykkeligere end nogensinde før.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Anvendelsesområde
GPS-navigation til XYZ Company Limited frigives til intern test. Den udgivne version er 1.0.7, frigivelsesnummeret er 14.0 og build-nummer 105.25.03. Denne softwareudgivelse inkluderer de nye funktioner og de største fejlrettelser fra den forrige udgivelse. Røgtest overføres fra udviklingsfasen, men der kræves en røg og tilregnelighed, inden man går til regressionstest.
# 2) Referencer
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Udgivelsesbeskrivelse
Denne udgivelse er en kontrolleret frigivelse af GPS-navigation og indeholder følgende funktioner og funktionalitet.
Funktionerne markeret med * er nye i denne udgivelse.
Følgende funktioner er ikke implementeret i denne udgivelse.
1. Modul 1
1.1 Funktion 1
1.1.1 Funktionalitet 1
# 4) Konfigurationsstyring
Vi bruger Visual Source Safe som konfigurationsstyringsværktøj. Bygningen er tilgængelig på følgende sti.
Internt link: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Eksternt link: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Installationsinstruktioner og trin
Giv de detaljerede oplysninger til installationen af buildet til QA / Testteam.
# 6) Problemer / fejl løst
Fejlstatusen opdateres i system til fejlsporing.
# 7) Problemer / fejl, der skal rettes
# 8) Leverancer
# 9) Kendte fejl / problemer
# 10) Slip tjekliste
| Ja Nej / | Beskrivelse | J / N |
|---|---|---|
| 1 | Er alle filerne blevet kontrolleret i Visual Source Safe? | |
| to | Er etiketten sat på den korrekte mappe i VSS i henhold til interne standarder? | |
| 3 | Kan frigivelsen identificeres som 'ekstern' / 'intern' frigivelse i VSS? | |
| 4 | Er versionen nævnt i VSS i kommentarerne? | |
| 5 | Er der i VSS nævnt en kort beskrivelse i kommentarerne? | |
| 6 | Koden er blevet gennemgået, og problemer med kodevurderingen er logget i Clear Quest? | |
| 8 | Enhedstestdokument er udarbejdet og gennemgået? | |
| 9 | Enhedstestsager udført, og resultaterne opdateret til status? | |
| 10 | Opdateret enhedstestdokument er tilgængeligt i VSS? | |
| elleve | Alle Clear Quest-problemer for denne frigivet er løst / lukket? | |
| 12 | Alle arbejdspakkeopgaver afsluttet og opdateret i VSS? | |
| 13 | Er røgtest udført og bestået? |
=> Hent: Klik her for at downloade prøveudgivelsesrapportskabelon i MS Word-format.
Konklusion:
Sådan forbedres løbende testudgivelsesprocessen
Tip nr. 1) Opsæt et frigivelsesteknikteam, der tager sig af de kritiske faktorer for vedligeholdelse af softwareudgivelser og builds og ansvarlig for de centraliserede softwarekonfigurationsstyringssystemer.
Tip nr. 2) Motiver og værdsat projektteamene for at følge processen involveret i softwareudvikling livscyklus, produktudvikling livscyklus og softwaretest livscyklus. Vi kan definere processen, men indtil og medmindre den følges af involverede mennesker, er der ingen brug af at definere processen.
Tip nr. 3) Anslå testindsatsen baseret på erfaringerne og den tidligere historie. Skrivning af testsager er helt forskellig fra at udføre det samme. Testerne skal forstå, hvad de skal teste, hvordan man tester, og hvornår de skal teste, ellers bliver indsatsen til testcyklussen spildt, selvom der er sket flere runder af testcyklus.
Tip nr. 4) Endelig, hvis det er muligt og muligt, automatiserer testfasen ved hjælp af nogle universelt accepterede testværktøjer. Brug af automatiserede buildværktøjer og automatiserede testværktøjer reducerer testindsatsen med mere end 50%, hvilket forbedrer kvaliteten af softwaren og sikrer 100% kvalitet, hvis automatiseringsrammen er korrekt designet.
Tip nr. 5) Sidst men ikke mindst, testudgivelse er ikke kun et job, det er en kunst at gøre alle interessenters liv i et projekt let og mere behageligt.
Om forfatteren: Balu A. er en erfaren teknofunktionel IT-professionel med over to årtier IT-softwareerfaring og et årti med projekt- og testledelseserfaring, der leverer virksomhedsapplikationer og mobilitetsløsninger på tværs af domæner ved hjælp af Microsoft-, Oracle-, Java- og Mobile-teknologier. Han er dybest set en leder med en passion for at fremme folk til at blive ledere med den rigtige holdning og elsker at arbejde i et procesorienteret miljø og mener, at processen forbedrer medarbejdernes effektivitet, kvalitet og produktivitet.
Inæste tutorial, vi lærer - Sådan Forbedre effektiviteten af testkassen.
Fortæl os dine tanker / spørgsmål i kommentarerne nedenfor.
Få en softwareudgivelse i henhold til processen!
Komplet test efter plan med stor produktivitet og indsats !!
Prøv at opnå fejlfri, kvalitetssikret softwarelevering !!!
Hvis du kan lide denne artikel, skal du overveje at dele den med dine venner!
Anbefalet læsning
- Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Softwaretest QA Assistant Job
- Hvad er abetest i softwaretest?
- Valg af softwaretest som din karriere
- Softwaretest Teknisk indhold Writer Freelancer Job
- Eksempel på fejlrapport
- Praktisk softwaretestning af QA-procesflow (krav til frigivelse)