how perform post release testing effectively
Toen ik mijn carrière begon als QA, werkte ik bij een bedrijf dat zijn producten aanbood als SaaS. Productiereleases waren kritisch en er was een mogelijkheid dat de functionaliteit voor de live clients werd beïnvloed.
Toen ons klantenbestand groeide, nam het QA-team het over om het risico te beheersen en de impact van de vrijgave voor live klanten te minimaliseren de testpraktijk na de release.
Dit was allemaal nieuw voor mij en ik had zoveel vragen en twijfels in mijn hoofd:
- Wat is testen na de release?
- Ik heb alles goed getest, waarom moeten we testen na de release?
- Test ik alles opnieuw? Wat moet ik precies doen bij verificatie na vrijgave?
- Wat gebeurt er als ik een probleem vind? Enz.
Ik ben blij om toe te geven dat ik al mijn antwoorden heb gevonden in mijn eerste paar productiereleases.
Hier deel ik die kennis met jullie allemaal. Ik heb ervoor gekozen om het artikel in een vraag- en antwoordformaat te schrijven om u te laten zien hoe ik de antwoorden ontdekte.
Wat je leert:
- Wat is verificatie na de productie?
- Welke taken en activiteiten zijn inbegrepen in de verificatiefase na vrijgave?
- Moet ik alles opnieuw testen?
- Hoe formuleer ik een verificatiestrategie na de productie?
- Wie maakt het testplan voor de release na de productie?
- Wie keurt het testplan voor de release na de productie goed?
- Wanneer maak ik het verificatieplan voor de vrijgave na de productie?
- Ik heb de verificatie van de vrijgave na de productie voltooid. Wat is het volgende?
- Wat gebeurt er als ik een probleem vind?
- Wat moet ik nog meer weten over het verificatieproces voor vrijgave na productie?
- Gevolgtrekking:
- Aanbevolen literatuur
Wat is verificatie na de productie?
Per definitie, Post middelen Na Productieversie verwijst naar inzet naar LIVE / productieomgevingen en Verificatie omvat ervoor zorgen dat de vrijgegeven functies voldoen aan de vereisten
Aanbevolen om te lezen Hoe u de 'testomgeving' effectief kunt voorbereiden voordat u begint met testen
Het doel is om de release op productie- / LIVE-omgevingen te verifiëren.
dot net interviewvragen en antwoorden
Maar de vragen rijzen dan:
- Waarom moeten we tests uitvoeren na de productierelease als ik alles in een QA-omgeving heb getest?
- Waarom verwachten we dat er problemen zullen optreden tijdens de productie, hoewel we de release grondig hebben getest in een testomgeving?
Er zijn veel redenen waarom we problemen zouden hebben met de productie, ook al hadden we het misschien volledig gevolgd Kwaliteitsborgingsproces (d.w.z. testplanning , beoordeling testplan, testcyclus, regressietests enzovoort.)
Redenen waarom we problemen zouden hebben met de productie:
1) Gegevensprobleem - De beschikbare gegevens over productie- en testomgevingen kunnen variëren. Dit kan ertoe leiden dat bepaalde hoekproblemen in testomgevingen worden gemist.
2) Implementatieprobleem - Als uw bedrijf een handmatig build-implementatieproces heeft, is uw release mogelijk vatbaarder voor implementatieproblemen. Enkele veelvoorkomende scenario's kunnen zijn: ontbrekende configuratie- of site-instellingen, ontbrekende DB-scripts, volgorde van implementatie die niet wordt gevolgd (eerst code, dan DB enz.), Onjuist geïnstalleerde afhankelijkheden, enz.
Lees ook Wat QA-tester moet weten over het implementatieproces
3) Impactgebieden niet geïdentificeerd - Er kunnen enkele scenario's zijn waarvoor de getroffen gebieden mogelijk niet correct en volledig door het team zijn geïdentificeerd.
Bijvoorbeeld, overweeg dan een SaaS milieu.
Als het team de impact van een herwerkte databasetabel op een client met een ouder tabelschema (bijv. Gegevensverlies, behoefte aan data migratie vóór de release, enz.), enz. Dit probleem doet zich minder vaak voor bij goed geplande projecten met precieze vereisten. Maar de mogelijkheid bestaat nog steeds.
4) Onbekende impactgebieden - Dit kan gebeuren als de omvang en de getroffen gebieden van de release niet bekend zijn. In een bedrijf met verschillende softwareproducten die een gemeenschappelijke database en architectuur delen, kan zelfs een kleine wijziging de functionaliteit van veel producten verstoren.
Welke taken en activiteiten zijn inbegrepen in de verificatiefase na vrijgave?
Taken en activiteiten na de productie omvatten over het algemeen:
- Verificatie na productie vrijgave
- Rapporteer verificatieresultaten
- Eventuele problemen melden die tijdens de productie zijn gevonden
- Verificatiegegevens na vrijgave opschonen
- Monitoring na vrijgave (indien van toepassing)
Moet ik alles opnieuw testen?
Niet noodzakelijk. Dit hangt af van de build die wordt vrijgegeven en de impactanalyse.
Gedetailleerde tests moeten worden uitgevoerd tijdens de normale QA-cyclus. Verificatie na vrijgave moet worden uitgevoerd door een testplan voor verificatie na vrijgave na productie te volgen, dat een afgeleide moet zijn van het volledige testplan voor die uitgave.
Hoe formuleer ik een verificatiestrategie na de productie?
De planning voor verificatie van de vrijgave na productie moet op dezelfde manier worden gedaan als uw normale testplanning.
De strategie moeten op dezelfde lijnen zijn als de teststroom die wordt gevolgd tijdens de QA-cyclus. Het is belangrijk om de belangrijkste en meest kritische stappen op te nemen die een maximale functionaliteitsdekking mogelijk maken.
pl sql interviewvragen voor ervaren
Een goede strategie voor postproductie moet:
- Neem stappen op om nieuwe functies te testen, evenals belangrijke bestaande functies
- Controleer gebieden met grote impact
- Zorg voor maximale functionaliteitsdekking
- Optioneel: neem eventuele kritieke bugs op die in de testomgeving zijn gevonden
- Optioneel: neem de prioriteit van de testcases op
Wie maakt het testplan voor de release na de productie?
Dit verschilt per bedrijf en is afhankelijk van de organisatiestructuur.
Laten we een voorbeeld nemen van de volgende QA-teamorganisatie.
In dit scenario zal QA die aan het specifieke project werkt, het initiële testplan voor de vrijgave na de productie formuleren.
Wie keurt het testplan voor de release na de productie goed?
Dit verschilt per bedrijf en is afhankelijk van de organisatiestructuur.
Opnieuw rekening houdend met dezelfde organisatiestructuur als getoond in de vorige vraag, moet het testplan voor vrijgave na de productie worden beoordeeld en goedgekeurd door de Test Lead of QA Manager
Wanneer maak ik het verificatieplan voor de vrijgave na de productie?
Het testplan voor de postproductie-release kan op elk moment tijdens de softwareontwikkelingscyclus worden gemaakt nadat de vereisten, het ontwikkelingsbereik en de impactgebieden zijn geïdentificeerd en vergrendeld. Het is meestal gemakkelijker voor de QA om halverwege de sprint het testplan voor de postproductie-release te maken. Dat zorgt ervoor dat er voldoende tijd is voor beoordeling en goedkeuring.
Het is een goede gewoonte om dit testplan samen met eventuele formele QA-documenten ondertekenen voordat het project de inzet- en releasefase ingaat.
Ik heb de verificatie van de vrijgave na de productie voltooid. Wat is het volgende?
Nadat de verificatie na vrijgave is voltooid, zijn de volgende stappen
1) Mededeling van verificatieresultaten - De verificatieresultaten moeten worden meegedeeld aan de belanghebbenden, inclusief eventuele problemen die bij de productie zijn aangetroffen.
2) Rapporteren van eventuele problemen die tijdens de productie zijn gevonden in de tool Defect Management - Naar de analyse van de hoofdoorzaak vergemakkelijken en traceerbaarheid
3) Verificatiegegevens na vrijgave opschonen - De gegevens moeten worden opgeschoond nadat de verificatie is voltooid.
Bijvoorbeeld, overweeg dan een release voor een e-commerce-applicatie en stel dat u tijdens de productie een testorder hebt gemaakt. Deze testbestelling moet worden geannuleerd nadat de verificatie is voltooid.
4) Monitoring van vrijgave na productie (indien van toepassing) - Sommige releases vereisen monitoring van de productie.
Bijvoorbeeld, als het team verbeteringen heeft aangebracht om de laadtijden van de pagina in de applicatie te verbeteren, zou dit gedurende een bepaalde periode moeten worden gecontroleerd om er zeker van te zijn dat de verbetering inderdaad werd gezien na de release. De verantwoordelijke persoon (personen) voor het toezicht moeten duidelijk worden geïdentificeerd en gecommuniceerd.
Wat gebeurt er als ik een probleem vind?
Eventuele problemen moeten worden gemeld in het Hulpprogramma voor defectbeheer en gecommuniceerd naar de belanghebbenden. Als er kritieke problemen worden gevonden bij de productie, moeten de resultaten onmiddellijk worden gecommuniceerd, omdat er een beslissing moet worden genomen als de build moet worden teruggedraaid om het probleem verder te onderzoeken.
Het is belangrijk dat alle gevonden problemen worden gerapporteerd in de Defect Tracking Tool. Het wordt aanbevolen om deze als afzonderlijk probleemtype aan te geven (bijv. Post-productiebug) om scheiding van reguliere QA-cyclusbugs aan te tonen. Deze problemen kunnen indien nodig eenvoudig worden uitgefilterd voor analyse van de hoofdoorzaak.
Wat moet ik nog meer weten over het verificatieproces voor vrijgave na productie?
Naast het daadwerkelijke verificatieproces, het plan en de strategie na de productie, volgen hieronder enkele tips:
- Het is belangrijk om duidelijke verwachtingen te stellen met betrekking tot de reikwijdte en het doel van verificatie na vrijgave. Belanghebbenden (intern en extern) moeten op het volgende worden gewezen
- Team kan niet alles testen op productie
- Het team kan de dagen van testen niet in enkele uren persen die gereserveerd zijn voor verificatie na de release
Daarom zouden de productietests in wezen gebaseerd zijn op een goedgekeurd testplan voor de vrijgave na de productie.
Beperkingen
Voorzichtigheid is geboden bij het bepalen van de omvang van het testen van de postproductie. Er zijn beperkingen aan wat en hoeveel we daadwerkelijk op productie kunnen testen. De productieomgeving heeft live klantgegevens en moet zeer zorgvuldig worden behandeld. Er moet aanvullende planning worden gemaakt voor wijzigingen die betrekking hebben op gegevensmigratie, bijwerken, verwijderen enz.
Voorbeeld 1): Voor een eSurvey-bedrijf, als het testen het beantwoorden en indienen van de enquête inhoudt, zou QA een verzoek moeten sturen om de testenquête na verificatie te verwijderen om geen invloed te hebben op de verzamelingsgegevens van de klantenonderzoeken en hun statistieken.
IS voorbeeld # 2): Laten we voor een e-commercebedrijf aannemen dat een SQL-taak voor prijsupdates elke dag om middernacht wordt uitgevoerd en de definitieve prijs naar de website uploadt. We kunnen deze SQL niet meerdere keren on-demand uitvoeren voor verificatie na de release, omdat hierdoor mogelijk niet-gefinaliseerde gegevens naar productie worden gepusht.
Bovendien kan het de kans op DB-impasses en een hoog verbruik van CPU- en geheugenbronnen tijdens piekuren, wat de prestaties van de clienttoepassing kan beïnvloeden.
- De inspanning die nodig is voor het testen na de release en alle gerelateerde activiteiten moet worden ingebouwd en opgenomen in het projectplan. Afhankelijk van de bedrijfsregels en projectspecificaties kan dit worden beschouwd als projectoverhead of worden opgenomen in de QA-cyclus of worden opgenomen als onderdeel van het releasemanagementplan.
- Voor de problemen die worden gemeld tijdens verificatie na de uitgave, moet een hoofdoorzaakanalyse worden uitgevoerd om erachter te komen waarom het probleem niet vroegtijdig werd opgemerkt en wat er de volgende keer beter kan worden gedaan om te voorkomen dat het probleem wordt aangepakt. De hoofdoorzaakanalyse kan het team helpen om van deze problemen uit het verleden te leren en eventuele hiaten in de implementatie op te vullen. Op basis van de organisatiestructuur kan de Test Lead of QA Manager de Oorzaakanalyse uitvoeren met input van het projectteam. Enkele veelvoorkomende hoofdoorzaken kunnen een coderingsprobleem, een vereistenprobleem, een ontwerpprobleem, een gegevensprobleem, beperkingen van derden, een ontbrekend testscenario enz. Zijn. Overeenkomstige corrigerende en preventieve maatregelen kunnen worden gemaakt en gevolgd.
- Serverlogboeken kan ook worden gebruikt om de build na release te volgen. Serverlogboek kan gebeurtenissen of problemen bevatten die mogelijk niet zichtbaar zijn voor de klant, maar die problemen veroorzaken in de backend. Deze monitoring kan als actie-item worden toegewezen aan Dev-lead en DevOps-team.
Een voorbeeld
Projectoverzicht:
De volgende wijzigingen moeten worden aangebracht in een sociale-mediatoepassing, met name in het aanmeldingsproces
- De validatie van het veld Achternaam moet worden verwijderd. Het was eerder geïmplementeerd als ‘Achternaam moet minimaal 4 tekens bevatten’ (Verbetering voor bestaand veld)
- Implementeer de schakelknop naast het e-mailadres zodat de gebruiker de privacy-instellingen voor het e-mailadres kan instellen om op hun profiel weer te geven (verzoek om nieuwe functie)
- De gebruiker moet zijn avatar kunnen kiezen (verzoek om nieuwe functie)
- Verminder API-aanroepen tijdens het aanmeldingsproces om de prestaties van de applicatie te verbeteren (verbetering)
Verificatieplan na productie vrijgave:
beste muziekspeler en downloader voor Android
S.No. | Omschrijving | verwacht resultaat | Toestand | Opmerkingen |
---|---|---|---|---|
1 | Ga naar Livesiteurl | De startpagina van de website zou met succes moeten worden geladen | Slagen voor | |
twee | Klik op Aanmelden als nieuwe gebruiker | De gebruiker moet worden omgeleid naar de registratie- / aanmeldingspagina | Slagen voor | |
3 | Vul de verplichte velden in en klik op Registreren Notitie: -Voer achternaam in als ‘Lee’ -Schakel de privacyknop naar Niet weergeven -Dingen in Avatar | -Gebruiker moet worden omgeleid naar zijn profielpagina na succesvolle registratie. - Het telefoonnummer van de gebruiker mag niet worden weergegeven -De door de gebruiker geselecteerde avatar moet worden weergegeven | Gedeeltelijke doorgang | Avatar wordt niet correct weergegeven en wordt weergegeven als een verbroken afbeelding. Gerapporteerd in JIRA als BUG-1088 |
4 | Monitoring - Controleer of de prestaties van de applicatie zijn verbeterd na deze release | Vermindering van API-aanroepen tijdens het aanmeldingsproces zou de prestaties van de applicatie moeten verbeteren | Voortdurende | Actie zit in Dev Lead en Dev Ops-team om de applicatie 24 uur lang te volgen |
5 | Opschonen na vrijgave | Verwijder het aangemaakte testaccount | Gedaan |
Gevolgtrekking:
Nu bij de meeste softwarebedrijven de Agile-methodologie toepassen is het aantal productiereleases toegenomen.
Bijvoorbeeld, Tijdens het gebruik Waterval model , kan een team elke 1,5 maand een productierelease hebben, maar met het Agile-proces kan hetzelfde team nu elke 2-3 weken een productierelease hebben.
Bij elke productierelease hebben we de mogelijkheid om bewust of onbewust de functionaliteit van de live clients te beïnvloeden. De acceptatie van verificatie na de productie onmiddellijk na de release kan extra vertrouwen geven in de release en tegelijkertijd het vangnet bieden van het terugdraaien van de release voordat onze live klanten problemen tegenkomen.
Voor projecten met een hoge impact / risico kan het verificatieplan voor de vrijgave na productie worden gestructureerd op basis van de prioriteit van het testscenario. Kritische prioriteitstest kan eerst worden uitgevoerd en communicatie naar belanghebbenden over resultaten en eventuele problemen. Als er geen kritieke problemen worden gevonden, kan de verificatie van de release na de productie worden voortgezet, anders moet de beslissing voor terugdraaien worden genomen om de downtime van applicaties en de impact op live clients te minimaliseren.
Bovendien, het testen van de release na de productie kan worden geautomatiseerd en de testscripts kunnen na elke release op aanvraag worden uitgevoerd als een regressietest. Nogmaals, er moet de nodige voorzichtigheid worden betracht bij het uitvoeren van de geautomatiseerde testscripts in productie, aangezien dit invloed kan hebben op live klantgegevens en functionaliteit.
Verificatie na productie is de laatste verdedigingslinie voor elk softwarebedrijf. Als we de problemen niet opmerken, zullen onze klanten dat wel doen en dit kan de reputatie van elk softwarebedrijf verwoestend zijn.
Om de betrouwbaarheid van het product te behouden, is het essentieel dat we de wijzigingen die in de productie zijn geïmplementeerd onmiddellijk na implementatie verifiëren.
Over de auteur: Dit nuttige artikel is geschreven door Neha B. Ze werkt momenteel als Quality Assurance Manager en is gespecialiseerd in het leiden en managen van interne en offshore QA-teams.
Deel uw teststrategie / tips / ervaring na de productie met onze lezers.
Aanbevolen literatuur
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Primer eBook downloaden testen
- Praktische implementatie in 7 stappen van handmatige tests voordat de productie wordt vrijgegeven
- Laadtests met HP LoadRunner-zelfstudies
- Praktische software testen QA-processtroom (vereisten voor vrijgave)
- Verschil tussen Desktop, Client Server Testing en Web Testing
- Wat is gammatesten? De laatste testfase
- Wat is vroeg testen: vroeg testen, vaak testen, MAAR hoe? (Een praktische gids)