how improve test release process
Laten we eens kijken naar het typische proces dat betrokken is bij het leveren van software van ‘ontwikkelingsfase’ tot de ‘testfase’ voor een succesvolle softwareversie zonder fouten voor productie / klant
Deze processen worden door softwarebedrijven over het hoofd gezien of overgeslagen, wat resulteert in slecht testmanagement en daarmee een ‘ buggy 'Software releases aan de klant, wat leidt tot' ontevreden klanten
Hoewel veel tijd en moeite wordt gestoken door het testteam voor elke release , wanneer de vrijgegeven software niet de kwaliteit heeft zoals gedefinieerd of benchmarks of niet voldoet aan de verwachte criteria, zal dit niet alleen de reputatie van het bedrijf bij de klanten beïnvloeden, maar ook het projectteam demotiveren en demoraliseren, en vooral het testteam als geheel .
Als je in dit scenario deel uitmaakt van een testteam, zou je jezelf kunnen blijven denken 'hoe kan ik mijn testcapaciteiten verbeteren en is er een betere manier om deze situatie te boven te komen'.
Ik wil wat tips en suggesties geven, gebaseerd op mijn ervaring met verschillende testteams die betrokken zijn bij softwaretoepassingen en releases van bedrijfsproducten met meerdere domeinen en platforms en met meerdere testframeworks, op hoe u de testreleaseprocessen kunt verbeteren , wat uw professionele leven als testingenieur of testmanager voor het leveren van software van wereldklasse zal vereenvoudigen.
Wat je leert:
- Test vrijgaveproces
- Verbetering van het testversieproces:
- Beheren en controleren van de inhoud van de testrelease
- Voorbeeld van een rapportsjabloon:
- Gevolgtrekking:
- Aanbevolen literatuur
Test vrijgaveproces
De onderstaande tabel geeft een overzicht van een testreleaseproces met drie universele fasen, zoals Input, Process & Output.
beste manier om youtube naar mp4 te converteren
| INVOER | WERKWIJZE | UITGANG |
|---|---|---|
| 7 | Controlelijst voor codebeoordeling is bijgewerkt en beschikbaar in VSS? | |
| Vorig proces Ontwikkeling | Proces begint met • Installatie van vrijgegeven software op de testserver | Volgende procesbehoeften • Software die de Smoke / Sanity Testing heeft doorstaan |
| Informatie / documentreferentie • Document met gebruikersvereisten • Specificaties softwarevereisten • Eenheidstestplan • Coderingsnormen • Controlelijst voor codebeoordeling • Ontwikkelingsplan • Kwaliteitsborgingsplan • Taakverdeling • Werkpakket • Project planning • Project Plan • Configuratiebeheerplan • Risicobeheerplan. | Subprocessen • Voorbereiden van testcases voor alle units • Ontwikkeling en testen van eenheden • Behandeling van non-conformiteitsprocedures • Implementeren van Configuration Management Plan. • Implementeren van een risicomanagementplan • Monitoring van de voortgang van het project • Foutcorrectie en beoordelingen | Interne klantbehoeften • Software gebouwd met versienummer • Vrijgaveverslag • Testcases / Testsuite-document • Planning van de uitvoering van tests • Traceerbaarheid Matrix • Testgegevens |
| Verificatie van inkomende invoer • Projectdocumenten worden beoordeeld en goedgekeurd? • Codeernormen, controlelijst voor codebeoordeling beschikbaar voor referentie? • Taak toegewezen en werkpakket bijgewerkt? • Functionele specificatie, ontwikkelingsplan en kwaliteitsplan worden beoordeeld en goedgekeurd? • Risicobeheerplan heeft mitigatie en onvoorziene omstandigheden om risico's te behandelen? • Effectiviteit van projectplanning om het product op tijd te leveren? | Processpecificatie • Unit Test Cases dienen te bestaan uit alle Entry en Exit Criteria • Naleving van code met coderingsnormen • NCP moet worden behandeld volgens de richtlijn • De stappen voor configuratiebeheer moeten voldoen aan het configuratiebeheerplan • Risicobeheersing moet plaatsvinden in overeenstemming met het risicobeheerplan • Rooktesten voldoen aan alle belangrijke kenmerken en functionaliteiten | Externe klantbehoeften • Bugvrije software |
| Ondersteunende processen • Toewijzing van mens / hardware / software / middelen • Onderhoud van hardware-defecten • Training voor teamleden | Proces eindigt met • Uitvoering van rook- / gezondheidstests op de vrijgegeven build | Efficiëntieparameters • Elke eenheid moet de eerste testronde doorstaan • Taken die moeten worden voltooid volgens de projectplanning • De rooktest moet vóór de release worden doorstaan • Teampassie testen om de software te testen |
Elk testteam moet een uniek checklist voor softwareversie, volgens het domein en het platform van de software en de projectmanagementmethodologie (zoals Agile Scrum enz.) en volgens het handmatige / geautomatiseerde testraamwerk, om de vrijgegeven build te accepteren, voordat de testuitvoering wordt gestart om tijd en moeite te besparen.
Dit is een van de belangrijkste efficiëntieparameters in de testreleasefase.
Verbetering van het testversieproces:
1) Bekijk het releaserapport voor de nieuwe functionaliteit, aanpassing / wijziging van bestaande functionaliteit, bugfixes van de vorige build, die zal beslissen om te beginnen met het uitvoeren van de Smoke Testing of Sanity Testing of een combinatie van beide.
twee) Bekijk de update Documenten testen volgens de nieuwe functionaliteit en de bugfixes, indien niet al bijgewerkt. Normaal gesproken worden deze documenten tijdens de levenscyclus van softwareontwikkeling bijgewerkt door het testteam op basis van de reguliere wekelijkse projectbeoordelingsvergaderingen.
3) Bekijk de Software Build in Configuration Repository wordt bijgewerkt voor het buildnummer, versienummer, gelabeld of becommentarieerd met de releasenaam volgens de normen die zijn gedefinieerd in het projectplan. Zorg er ook voor dat de build met succes is gecompileerd en geïnstalleerd op de testserver.
4) Plan een snelle projectbeoordelingsbijeenkomst na vrijgave om de voor- en nadelen van de vrijgegeven build, bekende bugs en kritieke functionaliteit enz. te bespreken, om eventuele miscommunicatie te voorkomen en om belangrijke klantvereisten te bekijken. Vermijd mondelinge communicatie tussen de ontwikkel- en testteams, aangezien dit een grote invloed heeft op de kwaliteit van de softwareversie.
5) Zorg ervoor dat de Bug Tracking Tool correct is geconfigureerd , voor het toegewezen testteam en ontwikkelingsteam van het project, software build- en releasenummers en de modules / functionaliteit van de software, die zullen helpen om de bugs efficiënt te loggen. Als dit niet het geval is, moet deze met hoge prioriteit worden geëscaleerd naar de projectmanager of testmanager.
6) Geef de build terug aan het ontwikkelteam zonder enig compromis, als de build mislukt in Smoke of Sanity Testing. Strikt genomen mag het testen niet worden voortgezet als het systeem faalt in rooktesten. Dit bespaart veel tijd en moeite en verbetert de kwaliteit van de software die in de volgende releases wordt uitgebracht.
7) Plan de projectrelease op de 1stDag van de week die de testmanager zal helpen om de komende testcyclus te plannen op basis van de build-stabiliteit en ook om een snel testrapport naar de projectmanager te sturen, waardoor de kwaliteit van de software ruim van tevoren wordt geëscaleerd. Als het ontwikkelingsteam de projectrelease op vrijdag plant, kan het weekend worden gebruikt voor eventuele ontsporingen en voor buildproblemen in een handmatig of geautomatiseerd build-framework.
8) Zorg ervoor dat de testers goed zijn opgeleid op het domein wat het testteam zal helpen om zich aan het testschema te houden en tijd te verzamelen voor de volgende testronde. Het testteam moet ook worden getraind en de nodige kennis hebben van de vereiste technologie zoals scripting en SQL als het project white boxing vereist.
9) Vermijd de toewijzing van testers aan meerdere projecten omdat het de kwaliteit van de testuitvoering in realtime sterk beïnvloedt. In de praktijk zien zelfs de ervaren testers de kenmerken en functionaliteit over het hoofd en slaan ze de testcases over, ervan uitgaande dat sommige testcases nooit mislukken, wanneer ze worden overladen met werk of worden toegewezen aan meerdere projecten met deadlines.
10) Waardeer het testteam om passie te hebben aangezien testers niet moeten werken voor de 'dag' of commentaar moeten geven op 'noem het een dag'. Wanneer software meerdere modules heeft en de functionalist volledig of gedeeltelijk geïntegreerd of met elkaar verbonden is, moeten testers de passie hebben voor het schrijven / uitvoeren van de testcases met een grote dekking en traceerbaarheidsmatrix, gericht op de kwaliteit van de uiteindelijke software / product. Omdat zelfs een cosmetisch probleem een 'bug' is en als '1 bug' wordt geteld.
elf) Zorg ervoor dat de software-installatie eenvoudig en duidelijk is omdat het het testteam helpt om de software indien nodig opnieuw te installeren in plaats van te wachten tot de ontwikkelingsmanager of een installatiemanager hetzelfde werk doet, wat de beschikbare testtijd onnodig zal doden. Hoewel de op Windows gebaseerde installatie bijvoorbeeld eenvoudig is, maar wanneer het meerdere webservers en wide area networks in een testomgeving met meerdere niveaus betreft, kan het uren duren voordat testers de software installeren. Als het software testen covers en installatie, verwijdering , patches of updates van software, is het waarschijnlijker dat het proces van het uitvoeren van de testcases in detail met het testteam wordt besproken.
12) Zorg ervoor dat de geautomatiseerde tools beschikbaar zijn met licentie voor een automatisering testraamwerk Het uitvoeren van testcases in een geautomatiseerd raamwerk is eenvoudig in vergelijking met een handmatig testscenario, mits de geautomatiseerde tools correct zijn geconfigureerd en gelicentieerd voor meerdere gebruikers. Vooral wanneer het testplan prestatie- en belastingtests omvat, afgezien van de reguliere uitvoering van testcases en regressietests, moeten testers het uitvoeren van testcases op meerdere omgevingen zoals meerdere servers, meerdere browsers, meerdere gebruikers enz. Dekken.
13) Zorg ervoor dat de Ghost-machines zijn ingesteld om te testen voordat de test werd uitgevoerd. Ghost-machines zijn machines met een verschillende testomgeving. Er kan bijvoorbeeld een webtoepassingssoftware worden gepland om te testen in meerdere omgevingen zoals Windows 7 & Access DB of Windows 2008 & SQL Server of Windows 8 & Oracle of Mainframe & DB2 enz., Met alle browsers zoals Chrome, Firefox, Internet Explorer , Safari enz., Enkele 'systeemtests' vereist zelfs om de harde schijf volledig te formatteren en nieuwe software te installeren of de bestaande software bij te werken met patches en updates enz.
14) Vermijd het implementeren van de nieuwe functies / wijzigingsverzoeken door de testuitvoering te stoppen en de software opnieuw vrij te geven om de testfase opnieuw te vermelden. Dit is een zeer slechte praktijk in veel software-organisaties volgens de zakelijke vereisten om de externe klanten tevreden te stellen of op zijn minst om te voldoen aan de eisen van de stuurgroep van het management of soms de verkoop- / marketingteams. Hoewel de wijzigingsverzoeken van de klanten altijd worden aangemoedigd in een ‘Agile’ projectomgeving, moet deze goed worden gepland en geïmplementeerd voordat de software wordt vrijgegeven aan het testteam.
Beheren en controleren van de inhoud van de testrelease
Het beheren en controleren van de inhoud van de testrelease is het belangrijkst voor alle IT-software of zelfs voor een niet-IT-softwareomgeving, zoals in de onderstaande afbeelding wordt weergegeven.
- De projectmanagers en / of de projectstuurgroep zijn afhankelijk van de autoriteit van de organisatiematrix, zijn verantwoordelijk voor het selecteren van de inhoud voor elke release.
- Zodra de bugs en / of de nieuwe functies en het wijzigingsverzoek van de klanten zijn geïdentificeerd en goedgekeurd, zal het worden geïmplementeerd door het ontwikkelteam dat moet worden geïnformeerd aan de belanghebbenden van het project voordat de ontwikkeling / implementatie wordt gestart.
- Op basis van de geïmplementeerde definitieve release zal het testteam de gerelateerde documenten bijwerken en zich dienovereenkomstig voorbereiden op het testen.
- Het testteam begint met het testen van rook / gezondheid volgens de gedefinieerde vereisten in het vrijgaveverslag.
- Zodra de Sanity geslaagd is, zal het testteam de testuitvoering starten volgens het schema en de toegewezen taken, namelijk functionele tests, niet-functionele tests, beveiligingstests, systeemtests, prestatietests, belastingtests, gebruikersacceptatietests enz.
- Zodra de eerste testcyclus is voltooid, worden testrapporten naar alle belanghebbenden en de manager van het ontwikkelteam gestuurd om de volgende iteratie van de testuitvoering te plannen.
- Afhankelijk van de status van de testrapporten en de ernst en complexiteit van de bug, zal een volledige cyclus van een tweede ronde van testuitvoering of regressietesten worden gepland samen met de gebruikersacceptatietesten.
- Na het voltooien van de geplande testuitvoeringscycli, worden de testrapporten naar alle belanghebbenden van het project gestuurd voor de geslaagde / mislukte / gemiste functies, functionaliteit en bugfixes.
Voorbeeld van een rapportsjabloon:
Notitie : Een voorbeeld van een MS Word-sjabloon voor het releaserapport kan hieronder ook worden gedownload.
Vind hieronder een ' Voorbeeld van een vrijgaveverslag ”Dat de belangrijkste aspecten van het releaseproces behandelt, waardoor het professionele leven van het hele projectteam veel gelukkiger is dan ooit tevoren.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Reikwijdte
GPS-navigatie voor XYZ Company Limited wordt vrijgegeven voor interne tests. De uitgebrachte versie is 1.0.7, het releasenummer is 14.0 en buildnummer 105.25.03. Deze softwareversie bevat de nieuwe functies en de belangrijkste bugfixes van de vorige release. Rooktesten zijn geslaagd vanaf de ontwikkelingsfase, maar een Smoke & Sanity is vereist voordat u voor regressietesten gaat.
# 2) Referenties
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) Release Beschrijving
Deze versie is een gecontroleerde versie van GPS-navigatie en bevat de volgende kenmerken en functionaliteit.
De functies die zijn gemarkeerd met een *, zijn nieuw in deze release.
De volgende functies zijn niet geïmplementeerd in deze release.
1. Module 1
1.1 Functie 1
1.1.1 Functionaliteit 1
# 4) Configuratiebeheer
We gebruiken Visual Source Safe als tool voor configuratiebeheer. De build is beschikbaar in het volgende pad.
Interne link: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Externe link: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Installatie-instructies en stappen
Geef de gedetailleerde informatie voor de installatie van de build aan het QA / Testing-team.
# 6) Problemen / bugs opgelost
De status van de bugs wordt bijgewerkt in het defectvolgsysteem.
# 7) Problemen / bugs die moeten worden opgelost
# 8) Deliverables
# 9) Bekende bugs / problemen
# 10) Controlelijst vrijgeven
| Ja nee / | Omschrijving | J / N |
|---|---|---|
| 1 | Zijn alle bestanden gecontroleerd in Visual Source Safe? | |
| twee | Is het label volgens de interne normen op de juiste map in VSS geplakt? | |
| 3 | Is de release identificeerbaar als 'externe' / 'interne' release in VSS? | |
| 4 | Is de versie in de commentaren vermeld in VSS? | |
| 5 | Staat er in de commentaren een korte beschrijving in VSS? | |
| 6 | Code is beoordeeld en problemen met codebeoordeling zijn vastgelegd in Clear Quest? | |
| 8 | Eenheidstestdocument is opgesteld en beoordeeld? | |
| 9 | Unit testcases uitgevoerd en de resultaten bijgewerkt voor de status? | |
| 10 | Bijgewerkt unit test case document is beschikbaar in VSS? | |
| elf | Alle Clear Quest-problemen voor deze release zijn opgelost / gesloten? | |
| 12 | Alle taken van het werkpakket voltooid en bijgewerkt in VSS? | |
| 13 | Zijn rooktesten gedaan en geslaagd? |
Downloaden Klik hier om een voorbeeldsjabloon voor een releaserapport te downloaden in MS Word-formaat.
Gevolgtrekking:
Hoe u het testvrijgaveproces continu kunt verbeteren
Tip # 1) Stel een release-engineeringteam op dat zorgt voor de kritische factoren van het onderhouden van de softwareversies en -builds en verantwoordelijk is voor de gecentraliseerde beheersystemen voor softwareconfiguratie.
Tip # 2) Motiveer en waardeer de projectteams voor het volgen van het proces dat betrokken is bij Software Development Life Cycle, Product Development Life Cycle en Software Testing Life Cycle. We kunnen het proces definiëren, maar totdat en tenzij het wordt gevolgd door de betrokken mensen, heeft het geen zin het proces te definiëren.
Tip # 3) Schat de testinspanning in op basis van de ervaringen en voorgeschiedenis. Het schrijven van testcases is totaal anders dan het uitvoeren ervan. De testers moeten begrijpen wat ze moeten testen, hoe ze moeten testen en wanneer ze moeten testen, anders worden de inspanningen die aan de testcyclus worden besteed verspild, ook al hebben er meerdere testcycli plaatsgevonden.
Tip # 4) Automatiseer ten slotte, indien mogelijk en haalbaar, de testfase met behulp van een aantal algemeen aanvaarde testtools. Het gebruik van geautomatiseerde buildtools en geautomatiseerde testtools vermindert de testinspanningen met meer dan 50%, verbetert de kwaliteit van software en zorgt voor 100% kwaliteit als het automatiseringsraamwerk correct is ontworpen.
Tip # 5) Last but not least, het vrijgeven van een test is niet alleen een baan, het is een kunst om het leven van alle belanghebbenden in een project gemakkelijker en comfortabeler te maken.
Over de auteur: Balu A. is een ervaren technisch-functionele IT-professional met meer dan twee decennia aan IT-software-ervaring en een decennium aan project- en testmanagementervaring die bedrijfsapplicaties en mobiliteitsoplossingen levert over domeinen heen met behulp van Microsoft, Oracle, Java en mobiele technologieën. Hij is in wezen een leider met een passie om mensen te promoten om de leiders met de juiste instelling te worden en houdt ervan om in een procesgeoriënteerde omgeving te werken en gelooft dat proces de efficiëntie, kwaliteit en productiviteit van medewerkers verbetert.
Involgende tutorial, we zullen leren - hoe Verbeter de efficiëntie van de testcase.
Laat ons uw mening / vragen weten in onderstaande opmerkingen.
Zorg voor een softwareversie volgens het proces!
Voltooi testen volgens schema met grote productiviteit en inspanningen !!
Probeer bugvrije, kwaliteitsgegarandeerde softwarelevering te realiseren !!!
Als je dit artikel leuk vindt, overweeg dan om het met je vrienden te delen!
Aanbevolen literatuur
- Software Testing-cursus: bij welk Software Testing Institute moet ik meedoen?
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Software testen QA Assistant Job
- Wat is Monkey Testing in Software Testing?
- Softwaretests kiezen als uw carrière
- Softwaretest Schrijver van technische inhoud Freelancer-baan
- Voorbeeld van een bugrapport
- Praktische software testen QA-processtroom (vereisten voor vrijgave)