how improve test release process
Låt oss se den typiska processen som är involverad i att leverera programvara från 'utvecklingsfas' till 'testfas' för en framgångsrik buggfri programvaruversion till produktion / klient .
Dessa processer förbises antingen eller hoppas över av mjukvaruföretag, vilket resulterar i dålig testhantering och därmed ”en” buggy ”Mjukvaruutgivningar till klienten, vilket leder till” missnöjda kunder ”.
Även om mycket tid och stora ansträngningar från testteamet för varje release , när den släppta mjukvaran inte har den definierade eller benchmarkerade kvaliteten eller inte uppfyller de förväntade kriterierna, kommer det inte bara att påverka företagets anseende hos kunderna utan också demotivera och demoralisera projektteamet, framför allt testteamet som helhet .
Om du är en del av ett testteam i det här scenariot kan du tänka dig själv 'hur man kan förbättra mina testmöjligheter och finns det något bättre sätt att övervinna denna situation'.
Jag vill ge några tips och förslag, baserat på min erfarenhet av olika testteam som är involverade i programvaruapplikationer och företagsproduktsreleaser med flera domäner och plattformar och med flera testramar, om hur man förbättrar testfrigöringsprocesserna , vilket förenklar ditt yrkesliv som testingenjör eller testchef för att leverera programvara i världsklass.
Vad du kommer att lära dig:
- Testfrigöringsprocess
- Förbättring av testsläppsprocessen:
- Hantera och kontrollera innehållet i testrelease
- Exempel på rapportmall:
- Slutsats:
- Rekommenderad läsning
Testfrigörande process
Tabellen nedan ger en översikt över en testreleaseprocess med tre universella faser som Input, Process & Output.
intervjufrågor om manuell och automatiseringstestning
| INMATNING | BEARBETA | PRODUKTION |
|---|---|---|
| 7 | Kontrollista för kodgranskning har uppdaterats och tillgänglig i VSS? | |
| Tidigare process Utveckling | Processen börjar med • Installation av släppt programvara i testservern | Nästa process behöver • Programvara som klarade rök / sanitetstest |
| Information / Dokumentreferens • Användarkravsdokument • Specifikationer för programvarukrav • Enhetstestplan • Kodningsstandarder • Checklista för granskning av kod • Utvecklingsplan • Kvalitetssäkringsplan • Uppgiftsallokering • Arbets packet • Projekt schema • Projekt plan • Konfigurationshanteringsplan • Riskhanteringsplan. | Underprocesser • Förbereda testfall för alla enheter • Utveckling och enhetstestning • Hantering av avvikelser • Implementering av konfigurationshanteringsplan. • Implementering av riskhanteringsplan • Projektövervakning • Felkorrigering och recensioner | Interna kundbehov • Programvara byggd med versionsnummer • Släpp rapport • Testfall / Test Suite-dokument • Testa genomförandeplanering • Spårbarhetsmatris • Testdata |
| Inkommande verifiering • Projektdokument granskas och godkänns? • Kodningsstandarder, checklista för kodgranskning finns tillgängliga för referens? • Uppgift allokerad och arbetspaket uppdaterat? • Funktionsspecifikation, utvecklingsplan och kvalitetsplan granskas och godkänns? • Riskhanteringsplan har lindring och beredskap för att hantera risk? • Effektiviteten i projektplanen för att leverera produkten i tid? | Processpecifikation • Enhetstestfall bör bestå av alla in- och utgångskriterier • Uppfyllelse av kod med kodningsstandarder • NCP ska hanteras enligt riktlinjerna • Konfigurationshanteringsstegen ska följa konfigurationshanteringsplanen • Riskhantering bör följa riskhanteringsplanen • Rökprovning klarar alla de viktigaste funktionerna och funktionerna | Externa kundbehov • Felfri programvara |
| Stödjande processer • Mänsklig / hårdvara / programvara / resursallokering • Underhåll av maskinvarufel • Träning till teammedlemmar | Processen slutar med • Utförande av rök / sanitetstestning på den släppta byggnaden | Effektivitetsparametrar • Varje enhet ska klara den första testomgången • Uppgifter som ska slutföras enligt projektplanen • Rökprov ska godkännas före utsläppet • Testa teamets passion för att testa programvaran |
Varje testteam bör skapa en unik checklista för programsläpp, enligt programvarans domän och plattform och metod för projektledning (som Agile Scrum etc.) och enligt manuell / automatiserad testram, att acceptera den släppta versionen innan testkörningen påbörjas för att spara tid och ansträngning.
Detta är en av de viktigaste effektivitetsparametrarna i testfrisättningsfasen.
Förbättring av testsläppsprocessen:
1) Granska utgivningsrapporten för den nya funktionaliteten, anpassning / modifiering av befintlig funktionalitet, felkorrigeringar från föregående version, som kommer att besluta att börja köra Smoke Testing eller Sanity Testing eller en kombination av båda.
två) Granska uppdateringen Testa dokument enligt den nya funktionaliteten och buggfixarna, om den inte redan har uppdaterats. Normalt uppdateras dessa dokument under testcykelns livscykel under programvaruutvecklingen baserat på de regelbundna veckovisa projektgranskningsmötena.
3) Granska Software Build in Configuration Repository uppdateras för byggnummer, versionsnummer, märks eller kommenteras med utgivningsnamnet enligt de standarder som definieras i projektplanen. Se också till att byggnaden har kompilerats och installerats på testservern.
4) Planera ett snabbt projektgranskningsmöte efter släpp för att diskutera fördelar och nackdelar med den släppta versionen, kända buggar och kritisk funktionalitet etc., för att undvika felkommunikation och granska alla viktiga kundkrav. Undvik strikt all muntlig kommunikation mellan utvecklings- och testteam, eftersom det i hög grad påverkar kvaliteten på programversionen.
5) Se till att bugspårningsverktyget är korrekt konfigurerat , för det tilldelade testteamet och utvecklingsteamet i projektet, programvara bygga och släppa nummer samt modulerna / funktionaliteten i programvaran, vilket hjälper till att logga buggarna effektivt. Om inte, bör eskaleras till projektledaren eller testledaren med hög prioritet.
6) Returnera byggnaden till utvecklingsteamet utan några kompromisser, om byggandet misslyckas i rök- eller sanitetstestning. Strikt bör testning inte fortsätta när systemet misslyckas i rökprovning. Detta sparar mycket tid och ansträngningar och förbättrar kvaliteten på programvaran som släpptes i de efterföljande versionerna.
7) Schemalägg projektutgåvan den 1stVeckodag vilket hjälper testchefen att planera den kommande testcykeln baserat på byggstabilitet och även att skicka en snabb testrapport till projektledaren som kommer att öka kvaliteten på programvaran i god tid. Om utvecklingsteamet schemalägger projektsläppet på fredagen kan helgen användas för eventuella glidningar samt för eventuella byggproblem i en manuell eller automatiserad byggram.
8) Se till att testarna tränas ordentligt på domänen vilket hjälper testteamet att följa testschemat och samla tid för nästa testomgång. Testteamet bör också utbildas och ha exponering för erforderlig teknik som Scripting och SQL om projektet kräver vitboxning.
9) Undvik allokering av testare i flera projekt eftersom det i hög grad påverkar kvaliteten på testkörningen i realtid. I praktiken förbiser även de erfarna testarna funktionerna och funktionaliteten och hoppar över testfallet förutsatt att vissa testfall aldrig misslyckas när de är överbelastade med arbete eller tilldelas på flera projekt med deadlines.
10) Uppskatta testteamet för att ha passion eftersom testare inte borde arbeta för 'dagen' eller kommentera 'kalla det en dag'. När programvaran har flera moduler och funktionalisten är helt eller delvis integrerad eller inbördes relaterad, bör testare ha passion för att skriva / genomföra testfall med stor täckning och spårbarhetsmatris, med inriktning på kvaliteten på den slutliga programvaran / produkten. Eftersom även en kosmetisk fråga är en 'bug' och räknas som '1 bug'.
elva) Se till att installationen av programvaran är enkel och okomplicerad eftersom det hjälper testteamet att installera om programvaran när det behövs istället för att vänta på att utvecklingschefen eller en installationschef ska göra samma jobb, vilket kommer att döda den tillgängliga testtiden i onödan. Till exempel, även om Windows-baserad installation är enkel, men när det handlar om flera webbservrar och breda nätverk i en testnivå med flera nivåer, kan testare ta timmar att installera programvaran. Om programvarutestning täcker och installation, avinstallation , korrigeringar eller uppdateringar av programvara, är det mer sannolikt att det kommer att diskuteras i detalj processen för utförande av testfall med testteamet.
12) Se till att de automatiska verktygen är tillgängliga med licens för en ramverk för automatiseringstest . Utförandet av testfall i ett automatiskt ramverk är enkelt jämfört med ett manuellt testscenario, förutsatt att de automatiska verktygen är korrekt konfigurerade och licensierade för flera användare. Speciellt när testplanen innefattar prestanda- och belastningstestning bortsett från regelbunden utförande av testfall och regressionstestning, bör testare täcka körning av testfall i flera miljöer som flera servrar, flera webbläsare, flera användare etc.
13) Se till att Ghosted Machines är inställda för testning innan testet utfördes. Ghosted-maskiner är maskiner med olika testmiljö. Till exempel kan en webbapplikationsprogramvara planeras att testas i flera miljöer som Windows 7 & Access DB eller Windows 2008 & SQL Server eller Windows 8 & Oracle eller Mainframe & DB2 etc. med alla webbläsare som Chrome, Firefox, Internet Explorer , Safari etc., Några “Systemtestning” kräver till och med att helt formatera hårddisken och installera en ny programvara eller uppdatera den befintliga programvaran med korrigeringar och uppdateringar etc.
14) Undvik att implementera de nya funktionerna / ändringsförfrågan genom att stoppa testkörningen och åter släppa programvaran för att ange testfasen igen. Detta är en mycket dålig praxis i många mjukvaruorganisationer enligt företagets krav för att tillfredsställa de externa kunderna eller åtminstone för att möta kraven från ledningsstyrgruppen eller ibland sälj- / marknadsföringsteamet. Även om kundernas ändringsförfrågningar alltid uppmuntras i en ”Agile” -miljö, bör den planeras och implementeras ordentligt innan programvaran släpps till testteamet.
Hantera och kontrollera innehållet i testrelease
Hantering och kontroll av innehållet i testrelease är viktigast för alla IT-programvaror eller till och med för alla icke-IT-programvarumiljöer som kommer att visas i figuren nedan.
- Projektledarna och / eller projektstyrkommittén är beroende av organisationsmatrisens behörighet, ansvarar för att välja innehåll för varje utgåva.
- När buggarna och / eller de nya funktionerna och ändringsförfrågan från kunderna har identifierats och godkänts, kommer den att implementeras av utvecklingsteamet som bör antydas till projektets intressenter innan utvecklingen / implementeringen påbörjas.
- Baserat på den implementerade slutliga utgåvan kommer testteamet att uppdatera de relaterade dokumenten och förbereda sig för testningen därefter.
- Testteamet startar rök / sanitetstest enligt de definierade kraven i utgivningsrapporten.
- När Sanity har passerat kommer testteamet att starta testkörningen enligt schemat och tilldelade uppgifter, dvs. funktionstestning, icke-funktionell testning, säkerhetstestning, systemtestning, prestandatestning, belastningstestning, användaracceptansprovning etc.
- När den första omgången av testcykeln är klar skickas testrapporter till alla intressenter och utvecklingslagschefen för att planera för nästa iteration av testkörningen.
- Beroende på status för testrapporterna och felens svårighetsgrad och komplexitet kommer en fullständig cykel med en andra omgång av testkörning eller regressionstest att planeras tillsammans med användaracceptans testning.
- Efter att ha slutfört de planerade testkörningscyklerna skickas testrapporterna till alla projektets intressenter för godkänd / misslyckad / missad funktion, funktionalitet och felkorrigeringar.
Exempel på rapportmall:
Notera : Exempel på MS Word-mall för utgivningsrapport finns också att ladda ner nedan.
Hitta nedan en “ Exempel på utgivningsrapport ”Som täcker huvudaspekterna av släppprocessen som gör hela projektgruppens yrkesliv mycket lyckligare än någonsin tidigare.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Räckvidd
GPS-navigering för XYZ Company Limited släpps för intern testning. Den släppta versionen är 1.0.7, släppnumret är 14.0 och byggnummer 105.25.03. Denna programvaruversion ger de nya funktionerna och de viktigaste buggfixarna från föregående version. Rökprovning skickas från utvecklingsfasen, men rök och sanitet krävs innan du går till regressionstestning.
# 2) Referenser
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) Släppbeskrivning
Denna version är en kontrollerad version av GPS-navigering och innehåller följande funktioner och funktioner.
Funktionerna markerade i * är nya i den här versionen.
Följande funktioner har inte implementerats i den här versionen.
1. Modul 1
1.1 Funktion 1
1.1.1 Funktionalitet 1
# 4) Konfigurationshantering
Vi använder Visual Source Safe som konfigurationshanteringsverktyg. Bygget är tillgängligt på följande väg.
Intern länk: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Extern länk: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Installationsinstruktioner och steg
Ge den detaljerade informationen för installationen av build till QA / Testing team.
# 6) Problem / buggar fixade
Felens status uppdateras i spårningssystemet för fel.
# 7) Problem / buggar som ska åtgärdas
# 8) Leveranser
# 9) Kända buggar / problem
# 10) Släpp checklista
| Ja Nej / | Beskrivning | J / N |
|---|---|---|
| 1 | Har alla filer kontrollerats i Visual Source Safe? | |
| två | Har etiketten satts i rätt mapp i VSS enligt interna standarder? | |
| 3 | Är utgivningen identifierbar som 'extern' / 'intern' utgåva i VSS? | |
| 4 | Har versionen nämnts i VSS i kommentarerna? | |
| 5 | Har en kort beskrivning nämnts i VSS i kommentarerna? | |
| 6 | Koden har granskats och problem med kodgranskning loggas i Clear Quest? | |
| 8 | Enhets testdokument har utarbetats och granskats? | |
| 9 | Enhetstestfall utförda och resultaten uppdaterade för status? | |
| 10 | Uppdaterat enhets testdokument finns i VSS? | |
| elva | Alla Clear Quest-problem för detta släppt har lösts / stängts? | |
| 12 | Har alla arbetspaketuppgifter slutförts och uppdaterats i VSS? | |
| 13 | Är rökprovning klar och godkänd? |
=> Ladda ner: Klicka här för att ladda ner mall för exempel på rapportversion i MS Word-format.
Slutsats:
Hur man förbättrar testutsläppsprocessen kontinuerligt
Tips nr 1) Ställ in ett släpptekniksteam som kommer att ta hand om de kritiska faktorerna för att underhålla programvaruversionerna och bygga och ansvarar för de centraliserade programvarukonfigurationshanteringssystemen.
Tips nr 2) Motivera och uppskatta projektteamen för att följa processen involverad i programvaruutveckling livscykel, produktutveckling livscykel och programvarutestning livscykel. Vi kan definiera processen men tills och såvida den inte följs av involverade personer, finns det ingen användning av att definiera processen.
Tips nr 3) Uppskatta testinsatsen baserat på erfarenheterna och tidigare historia. Att skriva testfall skiljer sig helt från att utföra samma. Testarna bör förstå vad man ska testa, hur man testar och när man ska testa, annars blir de ansträngningar som görs för testcykeln bortkastade, trots att flera omgångar av testcykeln har hänt.
Tips nr 4) Slutligen, om möjligt och genomförbart, automatisera testfasen med hjälp av några allmänt accepterade testverktyg. Användning av automatiserade byggverktyg och automatiserade testverktyg minskar testansträngningarna med mer än 50%, vilket förbättrar kvaliteten på programvaran och säkerställer 100% kvalitet om automatiseringsramen är korrekt utformad.
Tips nr 5) Sist men inte minst, testrelease är inte bara ett jobb, det är en konst att göra alla intressenters liv i ett projekt enkelt och bekvämare.
Om författaren: Balu A. är en erfaren teknofunktionell IT-professionell med över två decennier av IT-programvaruupplevelse och ett decennium med erfarenhet av projekt- och testhantering som levererar företagsapplikationer och mobilitetslösningar över domäner med Microsoft-, Oracle-, Java- och mobilteknik. Han är i grunden en ledare med en passion för att främja människor att bli ledare med rätt attityd och älskar att arbeta i en processorienterad miljö och anser att processen förbättrar medarbetarnas effektivitet, kvalitet och produktivitet.
Inästa handledning, kommer vi att lära oss - Hur man gör det Förbättra effektiviteten i testfallet.
Låt oss veta dina tankar / frågor i kommentarerna nedan.
Ha en mjukvaruversion enligt processen!
Komplett testning enligt schema med stor produktivitet och insatser !!
Försök uppnå felfri, kvalitetssäkrad leverans av programvara !!!
Om du gillar den här artikeln kan du överväga att dela den med dina vänner!
Rekommenderad läsning
- Programvarutestningskurs: Vilket programvarutestinstitut ska jag gå med?
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Programvarutestning QA-assistentjobb
- Vad är Monkey Testing i Software Testing?
- Välja programvarutestning som din karriär
- Programvarutestning Tekniskt innehåll Writer Freelancer Jobb
- Exempel på felrapport
- Praktisk programvarutestning av QA-processflöde (krav att släppas)