Menu

Wat de QA-tester moet weten over het beheerproces voor release en implementatie

what qa tester should know about release

Probeer Ons Instrument Voor Het Oplossen Van Problemen

In onze teamvergadering van vandaag heeft de manager met iedereen gecontroleerd gereedheid voor testuitvoering ​Hij zei dat de 'code morgenochtend klaar is voor QA'. Wat bedoelde hij toen hij zei 'code zal klaar zijn', betekent dit dat de ontwikkelaars vanavond de code gaan schrijven in een QA-omgeving?

Hij bedoelde eigenlijk dat de implementatie gepland staat om 's nachts te gebeuren en dat de nieuwe code zal worden geïmplementeerd in de QA-omgeving om te testen.

Velen van jullie zullen zich nu afvragen: wat is implementatie en wat doen ze er echt in?

release- en implementatiebeheerproces voor qa

Wat je leert:

Algeheel release- en implementatiebeheerproces en belang voor het QA-team

  • Waarom onderhouden we echt verschillende omgevingen?
  • Hoe wordt de code gemigreerd van de ene omgeving naar de andere?

Ik zal in dit artikel de volgende onderwerpen behandelen

  1. Waarom is het belangrijk dat testers op de hoogte zijn van het release- en implementatieproces?
  2. Verschillende omgevingen
  3. Wat bedoel je met Build en Deployment?
  4. Geplande vs. noodimplementatie
  5. QA-checklist - voor en na implementatie

# 1. Waarom is het belangrijk dat testers op de hoogte zijn van het implementatieproces?

Onze belangrijkste taak van het uitvoeren van tests hangt af van hoe succesvol de implementatie was. Als het implementatieteam voor uitdagingen stond en verschillende problemen tegenkwam en de code niet correct kon implementeren, zal dit zeker aangeven dat het QA-team veel bugs gaat identificeren die mogelijk verband houden met de omgeving of het implementatieproces.

  • Als Testers op de hoogte zijn van het implementatieproces, zullen ze het belang inzien van het voltooien van hun taken binnen het geplande tijdsbestek.
  • Testers krijgen een idee of het probleem echt een functionaliteitfout is of iets dat tijdens de implementatie is veroorzaakt, zeg maar dat een tester is toegewezen om de rapportfunctie te testen, maar wanneer hij probeert in te loggen op de website, ziet hij een fout, wat betekent dat de omgeving niet werkt , kunnen dergelijke kwesties niet als functionele kwesties worden beschouwd, maar als milieukwesties. Als de tester op de hoogte is van de implementatie, kan hij het probleem beschouwen als een implementatieprobleem.
  • Veel niet-problemen kunnen worden vermeden als de testers echt op de hoogte zijn van de lijst die is geïmplementeerd. Soms gebeurt het dat u test en een probleem rapporteert voor gebieden die nooit zijn geïmplementeerd.

# 2. Verschillende omgevingen

Verschillende omgevingen

In bovenstaande classificatie heb ik de 4 belangrijkste omgevingen behandeld die de meeste organisaties volgen, maar veel klanten onderhouden veel meer omgevingen zoals staging, pre-staging enz. Ook kan de naamgevingsconventie verschillen.

  • DEV - Dev-omgeving is degene die is gemaakt en onderhouden door het ontwikkelingsteam voor het schrijven van de code. De toegang voor deze omgeving wordt alleen aan het ontwikkelteam gegeven. Meestal heeft het QA-team geen toegang tot deze omgeving. Deze omgeving wordt meestal gebruikt door het Dev-team voor het testen van hun eenheden.
  • QA - Q Een omgeving is de omgeving waar het testen daadwerkelijk plaatsvindt. Deze omgeving is eigendom van het QA-team. Het DEV-team heeft geen toegang tot deze omgeving. Nadat het ontwerp en de codering zijn voltooid, wordt de code verplaatst naar de QA-omgeving zodat het QA-team de testuitvoering kan uitvoeren.
  • GAT - Gebruikers acceptatie test is een omgeving waarin het testen wordt uitgevoerd door de zakelijke gebruikers. Dit wordt gedaan nadat de systeemtest is voltooid. De belangrijkste bedoeling is om het systeem zakelijk te testen. Alleen de zakelijke gebruikers krijgen toegang tot deze omgeving. In sommige gevallen zoeken ze echter wel QA-assistentie, in dergelijke omstandigheden krijgt het QA-team tijdelijk toegang tot de omgeving.
  • PROD - De PROD-omgeving is de daadwerkelijke live-omgeving die wordt blootgesteld aan de echte gebruikers en geen van de DEV- en QA-teams heeft lees- / schrijftoegang tot deze omgeving. Prod-ondersteuningsteams worden onderhouden om problemen op te lossen die verband houden met de productieomgeving.

Lees ook​ Effectief voorbereiden van een 'testbed' en het minimaliseren van defecten in de testomgeving

# 3. Wat bedoel je met Build en Deployment

Een build bevat voornamelijk het gecompileerde pakket dat de uitvoerbare bat, exe, de bibliotheken zoals dll, lib en archieven zoals zip-bestanden kan bevatten. Development Team maakt de build en levert deze aan het implementatieteam voor installatie.

De compilatie van de broncode wordt voornamelijk verzorgd door het ontwikkelteam en nadat ze de build hebben gegenereerd, plaatsen ze deze op een bepaalde locatie die toegankelijk is voor het implementatieteam voor implementatie in een andere omgeving.

software ontwikkeling levenscyclusfasen pdf

Zodra de build is geïmplementeerd, wordt het QA-team op de hoogte gebracht om het verificatietesten bouwen (BVT) en als het lukt, voert het team de rest van de functioneel testen ​

In sommige organisaties waar ze geen apart implementatieteam hebben, levert het ontwikkelingsteam de build voor QA en voltooit het QA-team zelf de implementatie. Er is een groot risico aan verbonden, in dergelijke gevallen moeten QA-bronnen technisch deugdelijk zijn om het algehele implementatieproces van de build te begrijpen en ook moeten ze weten hoe ze moeten worden verholpen als er een probleem optreedt.

Builds worden onderhouden met behulp van nummers, bijvoorbeeld 1.0.01 of 1.0.03. Het is dus mogelijk dat build 1.0.01 DLL v0.2 draait en build 1.0.03 DLL v0.5. Het wordt belangrijk voor het QA-team om ervoor te zorgen dat de juiste build in de omgeving wordt geïmplementeerd voordat het testen begint. Het is altijd een goed idee om de wijzigingen bij te houden als onderdeel van elke build.

Het onderhouden van een apart implementatieteam is altijd een goede gewoonte, omdat het helpt bij een soepele verplaatsing van code van de ene omgeving naar de andere.

Implementatie is een proces waarbij de code / build van de ene omgeving naar de andere wordt verplaatst. Het merendeel van de organisatie volgt tegenwoordig een goed kanaal voor de inzet en onderhoudt een apart team dat voor al deze zaken zorgt.

Bouw en implementatie

hoe maak je een makefile c ++

Voorafgaand aan de dag van implementatie komt een team van de ontwikkelaar, ontwikkelingsmanager, implementatie-engineer, testleider en andere zakelijke belanghebbenden bijeen. In de vergadering wordt de ontwikkelaar meestal gevraagd om zijn / haar wijziging te beschrijven. Ze moeten meestal een bepaald formulier invullen met details over de wijzigingen en het terugdraaiplan.

In het geval dat sommige details worden gemist, worden de wijzigingen niet goedgekeurd voor implementatie. Het team beslist dan of de wijziging deel kan uitmaken van de implementatie van de volgende dag. De QA-test lead wordt om goedkeuring gevraagd om ervoor te zorgen dat de wijziging geen invloed heeft op de bestaande tests. In de vergadering worden de laatste inzetitems gepland.

De goedgekeurde lijst wordt op de dag van implementatie door het implementatieteam uitgewerkt. Het team voert een reeks programma's uit zoals gedefinieerd in elk van de wijzigingsformulieren (geleverd door ontwikkelaars) en verzendt vervolgens de communicatie als de implementatie is voltooid.

Het bericht Implementatie voltooid geeft het QA-team een ​​indicatie dat de wijzigingen / nieuwe code klaar is om getest te worden.

Het is de verantwoordelijkheid van het implementatieteam om de wijzigingen van DEV naar QA te verplaatsen. Nadat de QA-test is voltooid, wordt de code verplaatst naar UAT. PROD-gegevensverplaatsing is het belangrijkste onderdeel en moet buiten kantooruren worden gedaan, omdat tijdens de implementatie de omgeving moet worden afgebroken en het met de grootste zorg moet worden gedaan, aangezien dit ernstige gevolgen kan hebben voor het bedrijf.

De meeste Prod-implementaties vinden 's avonds laat plaats, wanneer de kans kleiner is dat de omgeving wordt getroffen door eindgebruikers.

# 4. Geplande vs. noodimplementatie

Elke organisatie houdt een implementatiekalender bij. Veel klanten volgen de implementatie van één keer per week en velen gaan voor een tweewekelijkse implementatie, zeggen dat de geplande implementatie alleen op dinsdag zou moeten plaatsvinden of dat het op dinsdag en vrijdag kan gebeuren. De dagen van inzet kunnen veranderen als de geplande dag van inzet op een feestdag valt.

In het bovenstaande gedeelte heb ik het proces behandeld dat voor elk wordt gevolgd geplande inzet ​

De geplande implementaties kunnen hun eigen uitdaging hebben. Denk aan een geval waarin nieuwe code wordt geïmplementeerd in de QA-omgeving en tijdens de gezondheidstest het team een ​​blocker-defect identificeert en het testen moet worden gestopt. Wacht het testteam een ​​week tot de volgende implementatie?

Om dergelijke situaties het hoofd te bieden, worden noodoplossingen en implementaties uitgevoerd waarbij het implementatieteam niet hoeft te wachten tot de geplande implementatiedag. Ze moeten zelfs voor noodimplementaties volgen en goedkeuring vragen, maar deze goedkeuringen gebeuren meestal snel en de nieuwe wijzigingen kunnen op dezelfde dag of zo snel mogelijk worden geïmplementeerd in de QA-omgeving.

# 5. QA-checklist - voor en na implementatie

Vóór implementatie -

De hele test ontwerpfase vindt plaats voordat de code daadwerkelijk naar de omgeving wordt verplaatst. Het is de testuitvoering die afhankelijk is van de beschikbaarheid van de code in de QA-omgeving, terwijl het Deployment-team werkt aan het implementeren van de code in QA, moet het QA-team ervoor zorgen dat de onderstaande activiteiten zijn voltooid:

Na implementatie -

Na de implementatie is het allereerste dat we als QA-team doen, aan de slag gaan met onze Sanity-test. Maar voordat we aan onze geestelijke gezondheidstest beginnen, moeten we ervoor zorgen dat het volgende is gedaan -

  • Het QA-team zou van het implementatieteam een ​​melding moeten hebben ontvangen over succesvolle implementatie en klaar voor QA.
  • Het QA-team moet de geïmplementeerde build bijhouden.
  • Zorg ervoor dat het QA-team beschikt over de lijst met succesvol geïmplementeerde wijzigingen en ook met items die niet zijn geïmplementeerd, zelfs als ze waren gepland. Het kan gebeuren dat het implementatieteam niet kon implementeren vanwege ontbrekende details enz.

Gevolgtrekking

Ik hoop dat het bovenstaande artikel je een idee heeft gegeven van het algehele release- en implementatiebeheerproces dat wordt gevolgd als onderdeel van de algehele softwareontwikkelingscyclus. Dit was slechts een generieke procedure die in de meeste organisaties werd gevolgd, maar veel klanten hebben verschillende protocollen.

Auteur : Dit geweldige artikel is geschreven door STH-teamlid Priya R.

Vond u dit proces nuttig? Laat het ons weten over het implementatieproces dat u in uw organisatie volgt.

Aanbevolen literatuur

^