how improve test release process
La oss se den typiske prosessen som er involvert i å levere programvare fra 'utviklingsfase' til 'testfase' for en vellykket feilfri programvareutgivelse til produksjon / klient .
Disse prosessene blir enten oversett eller hoppet over av programvareselskaper, noe som resulterer i dårlig testadministrasjon og derved 'en ' buggy ”Programvareutgivelser til klienten, noe som fører til“ misfornøyde kunder ”.
Selv om mye tid og stor innsats fra testteamet for hver eneste utgivelse , når den utgitte programvaren ikke har kvaliteten som definert eller benkemerket eller ikke oppfyller de forventede kriteriene, vil den ikke bare påvirke selskapets omdømme hos kundene, men demotiverer og demoraliserer prosjektgruppen, viktigst og fremst testteamet som helhet .
Hvis du er en del av et testteam i dette scenariet, kan du tenke deg selv 'hvordan du kan forbedre testfunksjonene mine, og er det noen bedre måte å overvinne denne situasjonen på'.
Jeg vil gi noen tips og forslag, basert på min erfaring med forskjellige testteam involvert i programvareapplikasjoner og utgivelser av bedriftsprodukter med flere domener og plattformer og med flere testrammer, på hvordan du kan forbedre testutgivelsesprosessene , som vil forenkle yrkeslivet ditt som testingeniør eller testleder for levering av programvare i verdensklasse.
Hva du vil lære:
- Testutgivelsesprosess
- Testutgivelsesprosessforbedring:
- Administrere og kontrollere innholdet i testutgivelsen
- Eksempel på mal for utgivelsesrapport:
- Konklusjon:
- Anbefalt lesing
Testutgivelsesprosess
Tabellen nedenfor gir en oversikt over en testutgivelsesprosess med tre universelle faser som Input, Process & Output.
hvordan du spiller en shockwave flash-fil
INNGANG | PROSESS | PRODUKSJON |
---|---|---|
7 | Sjekklisten for kodevurderinger er oppdatert og tilgjengelig i VSS? | |
Forrige prosess Utvikling | Prosessen starter med • Installasjon av utgitt programvare i testserveren | Neste prosess trenger • Programvare som har bestått røyk / sunnhetstesting |
Informasjon / dokumentreferanse • Dokument for brukerkrav • Spesifikasjoner for programvarekrav • Enhetstestplan • Kodningsstandarder • Sjekkliste for gjennomgang av koder • Utviklingsplan • Kvalitetssikringsplan • Oppgavefordeling • Arbeidspakke • Prosjektplan • Prosjektplan • Konfigurasjonsadministrasjonsplan • Risikostyringsplan. | Underprosesser • Forbereder testsaker for alle enhetene • Utvikling og enhetstesting • Håndtering av avviksprosedyrer • Implementering av konfigurasjonsstyringsplan. • Implementering av risikostyringsplan • Overvåking av prosjektfremdrift • Feilkorrigering og omtaler | Interne kundebehov • Programvarebygging med versjonsnummer • Utgivelsesrapport • Test tilfeller / Test Suite-dokument • Test utførelsesplanlegging • Sporbarhetsmatrise • Testdata |
Innkommende verifisering • Prosjektdokumenter blir gjennomgått og godkjent? • Kodningsstandarder, sjekkliste for gjennomgang av kode er tilgjengelig for referanse? • Oppgavetildeling og arbeidspakke oppdatert? • Funksjonell spesifikasjon, utviklingsplan og kvalitetsplan blir vurdert og godkjent? • Risikostyringsplan har avbøtende virkning og beredskap for å håndtere risiko? • Effektiviteten av prosjektplanen for å levere produktet i tide? | Prosessspesifikasjon • Enhetstesttilfeller bør bestå av alle inngangs- og utgangskriterier • Overholdelse av kode med kodestandarder • NCP bør håndteres i henhold til retningslinjene • Trinnene for konfigurasjonsadministrasjon skal overholde konfigurasjonsadministrasjonsplanen • Risikohåndtering bør overholde risikostyringsplanen • Røykprøving består alle de viktigste funksjonene og funksjonene | Eksterne kundebehov • Feilfri programvare |
Støtter prosesser • Tildeling av mennesker / maskinvare / programvare / ressurser • Vedlikehold av maskinvare • Trening til teammedlemmer | Prosessen slutter med • Utførelse av røyk / sunnhetsprøving på den utgitte bygningen | Effektivitetsparametere • Hver enhet skal bestå den første testrunden • Oppgaver som skal fullføres i henhold til prosjektplanen • Røykprøve bør bestås før utgivelsen • Testing av teamets lidenskap for å teste programvaren |
Hvert testteam bør opprette en unik sjekkliste for programvareutgivelse, i henhold til programvarens domene og plattform og prosjektledelsesmetoden (som Agile Scrum etc.), og i henhold til manuelt / automatisert testrammeverk, for å godta den utgivne bygningen, før du starter testutførelsen for å spare tid og krefter.
Dette er en av de viktigste effektivitetsparametrene i testutgivelsesfasen.
Testutgivelsesprosessforbedring:
1) Gå gjennom utgivelsesrapporten for den nye funksjonaliteten, tilpasning / modifisering av eksisterende funksjonalitet, feilrettinger fra forrige versjon, som bestemmer seg for å begynne å utføre Smoke Testing eller Sanity Testing eller en kombinasjon av begge.
to) Gjennomgå oppdateringen Testing av dokumenter i henhold til den nye funksjonaliteten og feilrettingen, hvis den ikke allerede er oppdatert. Normalt, i løpet av programvarens utviklingslivssyklus, blir disse dokumentene oppdatert av testteamet basert på de vanlige ukentlige prosjektgjennomgangsmøtene.
3) Gjennomgå programvarebygget i konfigurasjonsregisteret oppdateres for byggenummer, versjonsnummer, merkes eller kommenteres med utgivelsesnavnet i henhold til standardene definert i prosjektplanen. Sørg også for at build er vellykket kompilert og installert på testserveren.
4) Planlegg et raskt prosjektgjennomgangsmøte etter utgivelsen for å diskutere fordeler og ulemper med den utgivne versjonen, kjente feil og kritisk funksjonalitet etc., for å unngå feilkommunikasjon og for å gjennomgå viktige kundekrav. Unngå strengt enhver muntlig kommunikasjon mellom utviklings- og testteamene, da det i høy grad påvirker kvaliteten på programvareutgivelsen.
5) Forsikre deg om at feilsporingsverktøyet er riktig konfigurert , for det tildelte testteamet og utviklingsteamet til prosjektet, programvarebygging og utgivelsesnumre samt modulene / funksjonaliteten til programvaren, som vil bidra til å logge feilene effektivt. Hvis ikke, skal det eskaleres til prosjektleder eller testleder med høy prioritet.
6) Returner Build til utviklingsteamet uten kompromisser, hvis bygningen mislykkes i røyk- eller sunnhetsprøving. Strengt tatt bør ikke testing fortsette når systemet mislykkes i røykprøving. Dette vil spare mye tid og krefter og forbedre kvaliteten på programvaren som utgis i de påfølgende utgivelsene.
7) Planlegg prosjektutgivelsen 1.St.Ukedag som vil hjelpe testlederen med å planlegge den kommende testsyklusen basert på byggestabilitet og også å sende en rask testrapport til prosjektlederen som vil øke kvaliteten på programvaren i god tid. Hvis utviklingsteamet planlegger prosjektutgivelsen på fredag, kan helgen brukes til eventuelle glidninger, samt eventuelle byggeproblemer i et manuelt eller automatisert byggerammeverk.
8) Forsikre deg om at testerne blir trent riktig på domenet som vil hjelpe testteamet til å følge testplanen og samle tid til neste testrunde. Testteamet skal også være opplært og ha eksponering for den nødvendige teknologien som Scripting og SQL hvis prosjektet krever hvit boksing.
9) Unngå tildeling av testere i flere prosjekter ettersom det i stor grad påvirker kvaliteten på testutførelsen i sanntid. I praksis overser selv de erfarne testerne funksjonene og funksjonaliteten, i tillegg til at de hopper over testtilfellene, forutsatt at noen testsaker aldri mislykkes når de er overbelastet med arbeid eller tildelt på flere prosjekter med tidsfrister.
10) Setter pris på testteamet for å ha lidenskap da testere ikke burde jobbe for “dagen” eller kommentere “Kall det en dag”. Når programvare har flere moduler og funksjonalisten er helt eller delvis integrert eller innbyrdes relatert, bør testere ha lidenskap for å skrive / utføre testsakene med god dekning og sporbarhetsmatrise, og målrette kvaliteten på den endelige programvaren / produktet. Fordi til og med et kosmetisk problem er en 'bug' og regnes som '1 bug'.
elleve) Forsikre deg om at programvareinstallasjonen er enkel og grei da det hjelper testteamet til å installere programvaren på nytt når det er nødvendig, i stedet for å vente på at utviklingslederen eller en installasjonsleder gjør den samme jobben, noe som vil drepe den tilgjengelige testtiden unødvendig. For eksempel, selv om Windows-basert installasjon er enkel, men når det involverer flere webservere og vidvannsnettverk i et testnivå med flere nivåer, kan det ta timer å installere testere å installere programvaren. Hvis den programvare testing dekker og installasjon, avinstallering , oppdateringer eller oppdateringer av programvare, er det mer sannsynlig å bli diskutert i detalj prosessen med å utføre testsakene med testteamet.
12) Sørg for at automatiserte verktøy er tilgjengelige med lisens for en rammeverk for automatiseringstesting . Utførelsen av testsaker i et automatisert rammeverk er enkelt sammenlignet med et manuelt testscenario, gitt hvis de automatiserte verktøyene er riktig konfigurert og lisensiert for flere brukere. Spesielt når testplanen involverer ytelse og belastningstesting bortsett fra vanlig utførelse av testtilfelle og regresjonstesting, bør testere dekke utførelse av testtilfeller i flere miljøer som flere servere, flere nettlesere, flere brukere etc.
1. 3) Forsikre deg om at Ghosted Machines er oppsett for testing før testutførelse startet. Ghosted maskiner er maskiner med forskjellige testmiljøer. For eksempel kan en webapplikasjonsprogramvare planlegges for å teste i flere miljøer som Windows 7 & Access DB eller Windows 2008 & SQL Server eller Windows 8 & Oracle eller Mainframe & DB2 etc., med alle nettlesere som Chrome, Firefox, Internet Explorer , Safari osv., Noen “System Testing” krever til og med å formatere harddisken fullstendig og installere en ny programvare eller oppdatere eksisterende programvare med oppdateringer osv.
14) Unngå å implementere nye funksjoner / endringsforespørsel ved å stoppe testutførelsen og gi ut programvaren på nytt for å oppgi testfasen igjen. Dette er en veldig dårlig praksis i mange programvareorganisasjoner i henhold til forretningskravene for å tilfredsstille eksterne kunder eller i det minste for å oppfylle kravene fra lederstyringskomiteen eller noen ganger salgs- / markedsføringsteamene. Selv om endringsforespørsler fra kundene alltid blir oppmuntret i et ‘Agile’ prosjektmiljø, bør det planlegges og implementeres riktig før programvaren slippes til testteamet.
Administrere og kontrollere innholdet i testutgivelsen
Administrering og kontroll av innholdet i testutgivelsen er viktigst for enhver IT-programvare eller til og med for et ikke-IT-programvaremiljø som vil være avbildet i figuren nedenfor.
- Prosjektledere og / eller prosjektstyringskomiteen er avhengig av autoriteten til organisasjonsmatrisen, er ansvarlig for å velge innholdet for hver utgivelse.
- Når feilene og / eller de nye funksjonene og endringsforespørselen fra kundene er identifisert og godkjent, vil den implementeres av utviklingsteamet, som bør antydes til interessentene i prosjektet før utviklingen / implementeringen startes.
- Basert på den implementerte endelige utgivelsen, vil testteamet oppdatere de relaterte dokumentene og forberede seg på testingen deretter.
- Testteamet vil starte røyk / sunnhetstesting i henhold til de definerte kravene i utgivelsesrapporten.
- Når Sanity har bestått, vil testteamet starte testutførelsen i henhold til tidsplanen og tildelte oppgaver, dvs. funksjonstesting, ikke-funksjonell testing, sikkerhetstesting, systemtesting, ytelsestesting, belastningstesting, brukertillatelse osv.
- Når den første runden med testsyklus er fullført, vil testrapporter sendes til alle interessenter og leder for utviklingsteamet for å planlegge for neste iterasjon av testgjennomføring.
- Avhengig av status for testrapportene og alvorlighetsgrad og kompleksitet av feil, vil en komplett syklus med en annen runde med testutførelse eller regresjonstesting planlegges sammen med brukertest.
- Etter å ha fullført de planlagte testutførelsessyklusene, vil testrapportene sendes til alle interessentene i prosjektet for bestått / mislykket / savnet av funksjoner, funksjonalitet og feilrettinger.
Eksempel på mal for utgivelsesrapport:
Merk : Eksempel på MS Word-mal for utgivelsesrapport er også tilgjengelig for nedlasting nedenfor.
Finn under en “ Eksempel på utgivelsesrapport ”Som dekker hovedaspektene av utgivelsesprosessen som gjør hele prosjektgruppens profesjonelle liv mye lykkeligere enn noen gang før.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Omfang
GPS-navigasjon for XYZ Company Limited lanseres for intern testing. Den utgitte versjonen er 1.0.7, utgivelsesnummeret er 14.0 og build-nummer 105.25.03. Denne programvareutgivelsen inkluderer de nye funksjonene og de viktigste feilrettingene fra forrige utgivelse. Røykprøving overføres fra utviklingsfasen, men det kreves en røyk og sunnhet før du går til regresjonstesting.
# 2) Referanser
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) Utgivelsesbeskrivelse
Denne utgivelsen er en kontrollert utgivelse av GPS-navigasjon og inneholder følgende funksjoner og funksjonalitet.
Funksjonene merket med * er nye i denne utgivelsen.
Følgende funksjoner er ikke implementert i denne versjonen.
1. Modul 1
1.1 Funksjon 1
1.1.1 Funksjonalitet 1
# 4) Konfigurasjonsadministrasjon
Vi bruker Visual Source Safe som konfigurasjonsadministrasjonsverktøy. Byggingen er tilgjengelig i følgende bane.
Intern lenke: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Ekstern lenke: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Installasjonsinstruksjoner og trinn
Gi detaljert informasjon for installasjonen av bygningen til QA / Testing team.
# 6) Problemer / feil løst
Statusen for feilene oppdateres i system for feilsporing.
# 7) Problemer / feil som skal løses
# 8) Leveranser
# 9) Kjente feil / problemer
# 10) Slipp sjekkliste
Ja Nei / | Beskrivelse | J / N |
---|---|---|
1 | Har alle filene blitt sjekket i Visual Source Safe? | |
to | Har etiketten blitt satt på riktig mappe i VSS i henhold til interne standarder? | |
3 | Er utgivelsen identifiserbar som 'ekstern' / 'intern' utgivelse i VSS? | |
4 | Har versjonen blitt nevnt i VSS i kommentarene? | |
5 | Har en kort beskrivelse blitt nevnt i VSS i kommentarene? | |
6 | Koden har blitt gjennomgått og problemene med kodegjennomgangen er logget inn Clear Quest? | |
8 | Enhetstestdokument er utarbeidet og gjennomgått? | |
9 | Enhetsprøvesaker utført og resultatene oppdatert for status? | |
10 | Oppdatert enhetstestdokument er tilgjengelig i VSS? | |
elleve | Alle Clear Quest-problemene for denne utgivelsen er løst / lukket? | |
12 | Alle arbeidspakkeoppgavene fullført og oppdatert i VSS? | |
1. 3 | Er røykprøving ferdig og bestått? |
=> nedlasting: Klikk her for å laste ned prøveutgivelsesrapportmal i MS Word-format.
Konklusjon:
Hvordan du forbedrer testutgivelsesprosessen kontinuerlig
Tips nr. 1) Sett opp et utgivelsesingeniørteam som skal ta seg av de kritiske faktorene for å opprettholde programvareutgivelser og -bygg og som er ansvarlig for de sentraliserte programvarekonfigurasjonsstyringssystemene.
Tips 2) Motivere og sette pris på prosjektgruppene for å følge prosessen involvert i programvareutvikling livssyklus, produktutvikling livssyklus og programvare testing livssyklus. Vi kan definere prosessen, men inntil og med mindre den blir fulgt av involverte personer, nytter det ikke å definere prosessen.
Tips nr. 3) Beregn testinnsatsen basert på erfaringene og den tidligere historien. Å skrive testsaker er helt forskjellig fra å utføre det samme. Testerne bør forstå hva de skal teste, hvordan de skal teste og når de skal teste, ellers blir innsatsen som blir gitt til testsyklusen bortkastet, selv om flere runder med testsyklus skjedde.
Tips nr. 4) Til slutt, hvis mulig og gjennomførbart, automatiser testfasen ved hjelp av noen allment aksepterte testverktøy. Bruk av automatiserte byggeverktøy og automatiserte testverktøy reduserer testinnsatsen med mer enn 50% og forbedrer kvaliteten på programvaren og sikrer 100% kvalitet hvis automatiseringsrammeverket er riktig utformet.
Tips nr. 5) Sist men ikke minst, testutgivelse er ikke bare en jobb, det er en kunst å gjøre alle interessentene i et prosjekt enkelt og mer komfortabelt.
Om forfatteren: Balu A. er en erfaren teknofunksjonell IT-profesjonell med over to tiår med IT-programvareerfaring og et tiår med prosjekt- og testledelseserfaring som leverer bedriftsapplikasjoner og mobilitetsløsninger på tvers av domener ved bruk av Microsoft-, Oracle-, Java- og Mobile-teknologier. Han er i utgangspunktet en leder med en lidenskap for å fremme folk til å bli ledere med riktig holdning og elsker å jobbe i et prosessorientert miljø og mener prosessen forbedrer ansattes effektivitet, kvalitet og produktivitet.
Ineste opplæring, vil vi lære - Hvordan Forbedre effektiviteten i testtilfellet.
Gi oss beskjed om dine tanker / spørsmål i kommentarene nedenfor.
Få en programvareutgivelse i henhold til prosessen!
Komplett testing etter planen med stor produktivitet og innsats!
Prøv å oppnå feilfri, kvalitetssikret programvarelevering !!!
Hvis du liker denne artikkelen, bør du vurdere å dele den med vennene dine!
Anbefalt lesing
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Hva er Monkey Testing i Software Testing?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Eksempel på feilrapport
- Praktisk programvaretesting av QA-prosessflyt (krav til utgivelse)