what are iq oq pq 3 q s software validation process
Inleiding tot IQ-OQ-PQ:
IQ, OQ en PQ vormen de 3Q's van het softwarevalidatieproces.
Als testers weten we allemaal dat het Software Development Team de software intern ontwikkelt volgens de Software Requirements Specification (SRS), Functional Specification en later verifieert het testteam de implementatie op verschillende testniveaus in verschillende testomgevingen, van de eenvoudigste tot de high-end, die daarmee de productieomgeving nabootst.
Bij deze aanpak van SDLC spoelt het Software Development Team hun handen doorgaans uit door de voltooide software (ontwikkeld en geverifieerd) over te dragen aan het Operations Team. Verder is het Operations Team (doorgaans Ops Team genoemd) dat ervoor zorgt dat het in een productieomgeving wordt geïmplementeerd en klaar is voor gebruik door de eindgebruikers.
Nu ligt hier de echte uitdaging voor het Operations Team om de software functioneel te maken in de productieomgeving, omdat tijdens de softwareontwikkelingsfasen de ontwikkeling en verificatie is uitgevoerd in een gesimuleerde omgeving, en vrij zelden dicht bij de live-omgeving, alleen in geval van beschikbaarheid van gegevens en configuraties van de productieomgeving.
Dit is waar de validatie van de software in beeld komt. Zodra de verificatie is voltooid en de software is afgetekend door het programma- / productteam, voert het Ops Team een reeks activiteiten uit voordat wordt geaccepteerd dat de software wordt geïmplementeerd in de productie, om te bewijzen dat de software zich gedraagt zoals verwacht, wat is niets anders dan de validatieactiviteiten.
Wat je leert:
Verificatie versus validatie
Laten we hier duidelijk het verschil begrijpen tussen ‘Verificatie’ en ‘Validatie’ activiteiten. Verificatie ’Is om de software te evalueren met betrekking tot de gegeven reeks vereisten en specificaties die intern wordt gedaan op de Software Development-site door de ontwikkelaars en testers.
Terwijl ' Validatie ’Is een reeks kwaliteitscontroles die worden uitgevoerd door de externe klanten, eigenaren en verkopers van het product dat aan hen wordt geleverd, om de geschiktheid te controleren voordat het product wordt geaccepteerd of gekocht. Validatiewerkzaamheden worden veelal op de productielocatie uitgevoerd.
Daarom is het in het geval van applicatieontwikkeling het Ops-team dat de validatieactiviteiten voor de software uitvoert.
Lees ook:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Fasen van validatieproces
Over het algemeen verwijst het validatieproces van elk product naar de volledige levenscyclus van een product, van ontwikkeling tot gebruik en onderhoud. En daarom is het validatieproces opgesplitst in 5 fasen.
5 fasen van validatieproces zijn:
Deze 5-fasenbenadering van het validatieproces wordt in veel industrieën gevolgd, zoals de fabricage, de medische sector, de farmaceutische industrie, enz. Hier zal validatie worden uitgevoerd door de eindklant voordat de machine, apparatuur of het product wordt gekocht.
De onderdelen van de validatieactiviteiten voor een software zijn om te bewijzen dat ‘de software klaar is voor gebruik door de gebruikers’, en om vooral de succesvolle installatie van de software te verifiëren, gevolgd door de functionaliteit en bruikbaarheid.
3Q's aanpak: IQ-OQ-PQ
In de softwarecontext is het De aanpak van 3Q, IQ-OQ-PQ wordt gevolgd als onderdeel van Validatie en wordt uitgevoerd door het Operations team, die eindverantwoordelijk is voor het inzetten van de software naar de productie.
Hieronder is het stroomdiagram van het validatieproces weergegeven:
De sjabloon, het plan en alle andere documenten die worden ingevoerd om de 3Q's uit te voeren, worden door het Softwareteam voor hun software opgesteld en bevatten de gedetailleerde aanpak, taken / activiteiten / tests die moeten worden uitgevoerd als onderdeel van deze kwalificaties. met de testresultaten.
Samenvattingsrapporten worden tijdens de softwareoverdracht aan Ops Team overhandigd, samen met de binaire bestanden en andere resultaten.
Op hoog niveau,
Over het algemeen is het doel van het uitvoeren van IQ, OQ en PQ om ervoor te zorgen dat de software succesvol kan worden geïmplementeerd en dat alle functionaliteiten zonder knelpunten kunnen worden gebruikt.
Idealiter zijn IQ, OQ en PQ de opeenvolgende activiteiten die in de volgorde moeten worden uitgevoerd. Tenzij de installatie is voltooid, kan een functionaliteit van de software niet worden geverifieerd en tenzij de functionaliteit is bewezen, heeft het geen zin om de prestaties te meten. Soms kan PQ vanwege tijdgebrek parallel aan OQ starten, zodra de belangrijkste aspecten van OQ zijn vastgesteld.
Laten we nu meer in detail over elk van deze 3 fasen begrijpen.
Installatiekwalificatie (IQ)
Installatiekwalificatie ook wel 'IQ' , is het proces van valideren of de meegeleverde software (binaire bestanden, scripts enz.) met succes kan worden geïnstalleerd in de gespecificeerde omgeving met de gespecificeerde configuraties, en om te verifiëren hoe deze installatiestappen zijn vastgelegd in het document genaamd ‘Installation Guide’.
De volgende items worden door het Development Team geleverd samen met het geleverde softwarepakket en worden door het Ops Team gebruikt om IQ uit te voeren.
1) ‘Installation Guide’ document, waarin de installatiestappen in de geselecteerde omgevingen worden beschreven.
twee) ‘Configuratiegids’ document om de configureerbare software in te stellen. Soms wordt dit document een onderdeel van het installatiegidsdocument zelf.
3) Softwarepakket en installatiescripts, bij voorkeur geautomatiseerde scripts.
De kwalificatiefase voor software-installatie wordt beschouwd als de meest cruciale fase en kent doorgaans veel problemen Open omhoog tijdens deze fase.
Omdat:
naar) De ontwikkelomgeving heeft geen 100% real-time omgeving beschikbaar om de installatieproblemen te verifiëren en daarom draagt een verschil in de omgeving bij aan verschillende problemen.
b) Om verschillende redenen is er mogelijk niet voldoende samenwerking en coördinatie tussen het ontwikkelingsteam en het operationele team tijdens de eerste stadia van softwareontwikkeling om de problemen op de lange termijn aan te pakken.
c) Er kunnen enkele documentatieproblemen zijn tijdens het opnemen van de feitelijke installatiestappen in het document, die mogelijk niet exact overeenkomen in de productieomgeving.
Tegenwoordig wordt de volledige software-installatieprocedure zoveel mogelijk geautomatiseerd via een reeks scripts. Als er problemen zijn met de installatie, mislukt de automatische installatie vanwege een miss-match in de configuraties en is handmatige tussenkomst vereist om deze problemen op te lossen.
Aangezien het Ops-team de IQ uitvoert door de instructies van het Softwareteam in de Installatiehandleiding strikt op te volgen, is het erg belangrijk en ook de verantwoordelijkheid van het Softwareteam om ervoor te zorgen dat de 'Installatiehandleiding' zo is geschreven dat de installatiestappen komen overeen met de real-time omgeving.
En het is de verantwoordelijkheid van de testers om ervoor te zorgen dat het 'installatie'-proces intern wordt geverifieerd, samen met de documentverificatie voor de volledigheid ervan en om eventuele missers te identificeren met de feitelijke stappen die op het systeem moeten worden uitgevoerd ten opzichte van de gedocumenteerde stappen in de Installatie gids.
De volgende punten moeten in gedachten worden gehouden bij het schrijven van een installatiehandleiding en het intern verifiëren ervan, om de problemen tijdens de software-installatie tijdens de productie te minimaliseren.
SNO | Installatiehandleiding Punten |
---|---|
7 | De typische tijd die nodig is om de software te installeren, moet worden vermeld in de Installatiehandleiding zodat het Ops-team een idee heeft van de geschatte timing van de installatie om hun activiteiten dienovereenkomstig te plannen. |
1 | Het belangrijkste is dat de ‘Installatiehandleiding’ in een eenvoudige en gemakkelijk te volgen taal moet worden geschreven. |
twee | Zorg ervoor dat het niet lang wordt, meer dan 5 pagina's. Het moet kort en netjes zijn. |
3 | U moet de serienummers opgeven voor elke uitvoeringsstap om de status ervan te kunnen volgen. |
4 | Automatiseer de stappen zoveel mogelijk en bundel ze allemaal in één script. |
5 | Een standaardsjabloon moet worden gebruikt om de installatieprocedure te schrijven. |
6 | De voorwaarden moeten duidelijk worden vermeld om miss-match te voorkomen en er moeten stappen worden ondernomen om deze te verifiëren. Als er een miss-match is, moet er instructie worden gegeven om ze op het verwachte niveau te brengen of om die pakketten te installeren. |
8 | De services die tijdens de installatie moeten worden afgebroken, hoe ze moeten worden afgebroken, de impact van het naar beneden halen, moeten duidelijk in de gids worden vermeld. |
9 | Het aanbieden van links naar andere documenten moet worden vermeden en het overschakelen van het ene document naar het andere. Alle benodigde informatie moet in hetzelfde document beschikbaar worden gesteld. Als er aanvullende documenten moeten worden doorverwezen, dient u deze samen met het softwarepakket aan te leveren, en op hun beurt moeten ze worden verwezen in de hoofddocumenten. |
10 | U moet ervoor zorgen dat de naam van het script dat in het document wordt vermeld, hetzelfde is als het script dat samen met het binaire bestand is verpakt. |
elf | Moet ervoor zorgen dat alle scripts waarnaar in het installatiegidsdocument wordt verwezen, samen met het binaire bestand worden geleverd. |
12 | Zorg ervoor dat alle configuratieparameters duidelijk worden vermeld in de Installatiehandleiding / Configuratiegids, samen met de standaardwaarden en andere ondersteunde waarden. |
13 | Geautomatiseerde tests om de buildverificatietests uit te voeren nadat de software-installatie is voltooid, moeten worden geleverd. Ze moeten minimaal in aantal zijn en belangrijk om te controleren of de build met succes is geïnstalleerd. |
14 | Er moeten ‘rooktesten’ worden geleverd om ervoor te zorgen dat de end-to-end-connectiviteit van het systeem perfect is en dat alle componenten van het systeem met elkaar praten zoals verwacht. |
vijftien | In het geval dat de software-installatie mislukt, worden rollback-scripts samen met het pakket geleverd en wordt de rollback-procedure duidelijk beschreven in de installatiehandleiding om rollback uit te voeren en het systeem met succes te herstellen. |
Met alle bovenstaande punten die in acht moeten worden genomen, is het een best practice om het software-installatieproces met minimale menselijke tussenkomst te automatiseren om menselijke fouten te vermijden.
Als er problemen worden gevonden tijdens de IQ-validatiefase, dan wordt dit gerapporteerd aan het Softwareteam, na het oplossen daarvan, de rooktesten en buildverificatietesten zal worden uitgevoerd om het succes van de software-installatie te controleren.
Daarom omvat de IQ-fase het installeren van het softwarepakket, gevolgd door het uitvoeren van de buildverificatie en rooktesten.
Succesvolle afronding van de IQ-fase is dus erg belangrijk, omdat een succesvolle en juiste installatie van software ervoor zorgt dat de meeste problemen met betrekking tot functiestoringen worden verholpen.
Operationele kwalificatie (OQ)
Operationele kwalificatie, ook wel WAT is de volgende activiteit van het softwarevalidatieproces na de succesvolle afronding van IQ.
De activiteit Operationele kwalificatie omvat t De tests die moeten worden uitgevoerd om te verifiëren dat de software operationeel geschikt is om te worden ingezet bij de consumenten. Idealiter worden de belangrijkste functionaliteiten van de software geverifieerd als onderdeel van dit validatieproces.
Een OQ-plan voor het uitvoeren van de OQ-validatie moet worden opgesteld door het softwareteam (testers) dat alle aspecten van OQ-testen moet omvatten die moeten worden uitgevoerd, inclusief de details zoals nee. van tests, testschema, methodologie, tools, impact op de service, testuitvoeringsvolgorde, methode voor het melden van problemen en de SLA's om ze op te lossen, Defect Triage-aanpak enz.,
De operationele kwalificatietests die worden uitgevoerd als onderdeel van OQ, worden opnieuw geleverd door het softwareteam, samen met de softwareleveringen. Deze operationele kwalificatietests zijn een verzameling van belangrijke tests die zijn ontworpen op basis van het document 'Functional Requirements Specification' om ervoor te zorgen dat het gehele softwaresysteem functioneert zoals verwacht.
Dit OQ Test Specification Document is opgesteld door de Test Engineers op basis van het Functional Requirements Specification document. Vaak is dit document de subset van het systeemtestspecificatiedocument dat is opgesteld en geverifieerd tijdens de systeemtestfase van de SDLC.
De tests kunnen worden gewijzigd of bijgewerkt om te voldoen aan de vereisten van het operationele team en de omstandigheden van de locatie waar ze zullen worden uitgevoerd.
Daarom moet extra aandacht worden besteed aan het selecteren van de tests die deel uitmaken van de OQ om ervoor te zorgen dat alle belangrijke functionaliteiten en de belangrijkste zakelijke workflows worden opgenomen als onderdeel van deze verificatie.
Hieronder volgen de tips voor testers bij het opstellen van het OQ-testspecificatiedocument.
Sno | Tips voor testers bij het opstellen van het OQ Test Specification Document |
---|---|
7 | Testgevallen met betrekking tot de grenswaarde hoeven niet te worden opgenomen, wat verifieert voor extreme waarden, maar gebruiken de meest gebruikelijke dagelijkse gebruikte waarden als invoer, waar nodig. |
1 | Zorg ervoor dat de belangrijkste functietests om te bewijzen dat de software functioneert zoals verwacht, worden gekozen en opgenomen en dat de nodige traceerbaarheid voor elk van de schriftelijke testcases beschikbaar is in het OQ Test Spec-document. |
twee | Zorg ervoor dat de tests netjes worden geschreven met stapsgewijze acties, voor zichzelf spreken en begrijpelijk zijn voor een gewone man. |
3 | Verwijs of vermijd het gebruik van technische termen in de testcases zo veel mogelijk, aangezien de gebruiker van dit document mogelijk niet op de hoogte is van die terminologieën. E dat de gebruikte testgegevens niet al op het systeem bestaan. Geef meerdere sets gegevens op, voor het geval de gebruiker de testgevallen meer dan eens wil uitvoeren. |
4 | Vermeld duidelijk de verplichte en optionele voorwaarden voor elk van de tests. |
5 | Neem de meerderheid van de positieve testgevallen op om de functionaliteit te verifiëren. |
6 | Neem zeer weinig negatieve testgevallen op om ervoor te zorgen dat het softwaregedrag is zoals verwacht in het geval van irrelevante invoer en het systeem in staat is om de negatieve gevallen met succes af te handelen. |
8 | Noem de in te stellen configuratiewaarden als deze gewijzigd moeten worden ten opzichte van de standaardwaarden. |
9 | Lever de uit te voeren geautomatiseerde testcases, waar beschikbaar. Zorg er van tevoren voor dat die automatiseringsscripts kunnen worden uitgevoerd op het systeem waarop de OQ wordt gepland. |
10 | Zorg ervoor dat elke testcase de duidelijke ‘Verwachte’ en ‘Werkelijke’ resultaten als referentie heeft. En voeg eventueel commentaar toe om het daadwerkelijke resultaat toe te lichten. |
elf | Het is ook noodzakelijk om de ‘Acceptatiecriteria’ voor elk van de testgevallen op te nemen. De acceptatiecriteria kunnen de status van het systeem zijn na het uitvoeren van de testcases. |
12 | Geef nauwkeurig de ‘Testgegevens’ die voor elk van de tests moeten worden gebruikt. Probeer de meest voorkomende gegevens van de live aan te leveren. En ook enkele uitzonderlijke gegevens, om ervoor te zorgen dat dat systeem ook de uitzonderlijke gevallen aankan. Zorg ervoor dat de gebruikte testgegevens niet al op het systeem bestaan. Geef meerdere sets gegevens op, voor het geval de gebruiker de testgevallen meer dan eens wil uitvoeren. |
13 | Als meerdere operationele gebruikers de tests parallel uitvoeren vanaf verschillende locaties, geef dan de instructie om de tests dienovereenkomstig met verschillende sets gegevens uit te voeren. |
14 | Voorzie waar nodig checklists om ervoor te zorgen dat alle configuraties en vereisten zijn ingesteld zoals verwacht voordat de tests worden uitgevoerd. |
vijftien | Blijf de logboeken in de gaten houden wanneer de tests worden uitgevoerd, als er toegang is tot het systeem. |
16 | Indien mogelijk en nodig ondersteunende uitvoering verlenen aan de Operationele gebruikers tijdens de uitvoering van deze testcases. |
17 | Leg de methode uit voor het melden van de problemen die tijdens de uitvoering zijn gevonden. Het is beter om de bug-trackingtool te gebruiken om de problemen op te sporen. Houd elk probleem nauwlettend in de gaten en sluit het af volgens de overeengekomen SLA's. |
18 | Voer ‘Defect Triages’ uit waarbij de juiste belanghebbenden betrokken zijn om de kritieke en ernstige problemen te begrijpen en regelmatig updates over deze problemen te geven. |
19 | Verstrek het definitieve ‘OQ Test Execution Summary Report’ -sjabloon om de definitieve resultaten te publiceren na voltooiing van de uitvoering. |
Het aldus opgestelde OQ-plan en testspecificatie moeten dus grondig worden herzien en ondertekend door de relevante belanghebbenden om er voornamelijk voor te zorgen dat ofwel de dekking niet te veel of te weinig is en dat alle belangrijke functionaliteiten worden gedekt.
Succesvolle afronding van OQ toont aan dat de software zal functioneren volgens zijn operationele specificaties in de geselecteerde omgeving en het is de stage-poort om de software naar zijn productie te brengen en is het signaal om door te gaan met de volgende activiteit van het validatieproces, namelijk PQ
Prestatiekwalificatie (PQ)
Na het verzekeren van een succesvol IQ, is de voltooiing van OQ de volgende activiteit in het validatieproces om ervoor te zorgen dat het product / de software consistent voldoet aan de gespecificeerde prestatieaspecten onder de verwachte belasting, zonder dat dit een bottleneck in de productieomgeving veroorzaakt.
Het belangrijkste aspect van PQ is ervoor te zorgen dat software, indien geïnstalleerd op het verwachte systeem, kan de live belasting aan en voldoet aan de verwachte reactietijd en crasht niet onder de piekbelastingen en stress tijdens het omgaan met gelijktijdige gebruikers.
Daarom is PQ voornamelijk bedoeld om ervoor te zorgen dat de gespecificeerde prestatiecriteria voor software worden bereikt over een bepaalde periode (misschien een week) op een betrouwbare basis met variërende belastingscondities, zoals het patroon in de live. Daarom moeten deze tests elke dag worden uitgevoerd om het gedrag van het softwaresysteem te monitoren en daarom zal het even duren voordat PQ is voltooid totdat zeker is dat het systeem zijn prestaties heeft bewezen.
Idealiter wordt PQ-validatie uitgevoerd na de voltooiing van OQ, waarbij de functionaliteit van de software is gegarandeerd en kan worden doorgegaan met het verifiëren van het prestatieaspect van het product of de software. Soms kan PQ vanwege tijdgebrek parallel met de OQ starten, op basis van het vertrouwen in het percentage van OQ voltooiing.
Het is ideaal om deze prestatietests uit te voeren op het live-systeem met het volledig geladen systeem of onder omstandigheden die vergelijkbaar zijn met live en ervoor te zorgen dat er geen bottlenecks zijn op de prestatieaspecten.
De volgende tests worden doorgaans uitgevoerd als onderdeel van de prestatiekwalificatie. En de keuze van de tests varieert van software tot software.
# 1) Beschikbaarheidstest: Om ervoor te zorgen dat de software continu beschikbaar is zonder te crashen of down te gaan.
# 2) Toegankelijkheidstest: Om ervoor te zorgen dat de software vanaf elke locatie gemakkelijk toegankelijk is met de verwachte prestatiesnelheid zonder problemen.
# 3) Laadtest: Om het gedrag van het systeem te meten onder de verwachte dagelijkse belasting en ook tijdens piekbelasting.
# 4) Stresstest: Om het breekpunt van het systeem te meten onder extreme belastingsomstandigheden.
# 5) Doorvoerprestatietest: Om de reactietijd van het systeem te meten en om TPS (transacties per seconde) te meten
# 6) Schaalbaarheidstests: Het systeem kan worden geschaald om de verwachte gelijktijdige gebruikers te verwerken.
De Prestatietestscenario's en de bijbehorende geautomatiseerde scripts worden opgesteld op basis van de prestatiegerelateerde vereisten die zijn gespecificeerd in de ‘Specificatie van gebruikersvereisten’.
Zoals vergelijkbaar met een OQ-plan, moet een gedetailleerd PQ-plan worden opgesteld waarin duidelijk de testaanpak, strategie, plan en planning worden vermeld, samen met hulpmiddelen, en worden doorgenomen met de PQ-uitvoerders.
De prestatietest- en monitoringtool moet worden geïnstalleerd in de omgeving waar de PQ wordt uitgevoerd om de prestatiestatistieken te meten en te rapporteren.
Hieronder volgen de tips voor de testers om het Operations Team in staat te stellen de PQ succesvol uit te voeren.
Sno | Tips voor de testers om het Operations Team in te schakelen |
---|---|
7 | Begeleiden, ondersteunen en trainen van het Operations-team om de prestatietests op het systeem uit te voeren. |
1 | Bereid de belangrijkste bedrijfsspecifieke scenario's voor om de prestatietests uit te voeren op basis van de URS. |
twee | Zorg ervoor dat er tests zijn opgenomen om te bewijzen dat het systeem voldoet aan de verwachtingen op het gebied van responstijd, snelheid, schaalbaarheid en stabiliteit onder verschillende belastingsomstandigheden. |
3 | Zorg ervoor dat de gespecificeerde belasting beschikbaar is of dat de methode en tools om de vereiste belasting te genereren duidelijk worden vermeld in de respectievelijke testgevallen. |
4 | Noem de eerste vereiste voor elk van de scenario's duidelijk, zoals de pre-load condities die op het systeem zouden moeten bestaan, het aantal gelijktijdige gebruikers enz., |
5 | Vermeld hulpmiddelen die worden aanbevolen voor het uitvoeren van de prestatietests die specifiek zijn voor elke testcategorie en voor elke test. |
6 | Zorg ervoor dat het proces om de prestatiestatistieken te bewaken duidelijk wordt vermeld. |
Na succesvolle afronding van PQ is het voldoen aan de prestatie-eisen erg belangrijk, aangezien eventuele prestatiegerelateerde afwijkingen een enorm zakelijk verlies kunnen veroorzaken door ongemak voor de gebruiker te creëren en het vertrouwen in de te gebruiken software zal verloren gaan, wat leidt tot het falen van de software.
In een notendop, t Onderstaande tabel geeft een overzicht van de IQ-OQ-PQ-activiteiten.
IQ | WAT | PQ | |
---|---|---|---|
Wat | Om het proces van software-installatie te verifiëren en hoe het proces is gedocumenteerd | Om de goede werking van het systeem te verifiëren | Klanten, eigenaren, verkopers, operationeel team |
WHO | Klanten, eigenaren, verkopers, operationeel team | Klanten, eigenaren, verkopers, operationeel team | Klanten, eigenaren, verkopers, operationeel team |
Waar | Op de site van de eigenaar, locatie van het operatieteam, live site, productachtige omgeving | Op de site van de eigenaar, locatie van het operatieteam, live site, productachtige omgeving | Op de site van de eigenaar, locatie van het operatieteam, live site, productachtige omgeving |
Wanneer | Wanneer de software is ontvangen van het softwareteam, vóór OQ en PQ. | Voordat het systeem wordt vrijgegeven voor gebruik en na succesvolle IQ-voltooiing | Voordat het systeem live wordt gezet en na succesvolle IQ, OQ-voltooiing |
In de onderstaande tabel worden de verschillende ingangen voor elk van de validatiefasen uitgelegd.
Type | Invoer |
---|---|
IQ | 1. Ontwerpspecificatiedocument 2. Binaire bestanden van software en andere installatiescripts 3. Installatiehandleiding document 4. Configuratiegids Document 5. Bouw een verificatie- en rooktestdocument op |
WAT | 1. Functioneel specificatiedocument 2. OQ-plandocument 3. Operationeel kwalificatietestdocument 4. Sjabloon voor OQ-testoverzicht 5. IQ succesvol voltooid |
PQ | 1. URS-document (Specificatie gebruikersvereisten) 2. PQ-plandocument 3. Prestatiekwalificatietestdocument 4. Sjabloon voor PQ-testoverzicht 5. IQ en OQ succesvol afgerond |
Gevolgtrekking
Zelfs als het product / de software alle verificatiefasen heeft doorstaan en geen enkele van IQ-OQ-PQ kan bewijzen, kan het resultaat rampzalig zijn en hoge kosten met zich meebrengen. Daarom is de succesvolle afronding van IQ-OQ-PQ alleen de succesvolle overdracht van het product van de ontwikkelingslocatie naar de productiesite.
Al met al geeft de succesvolle voltooiing van het IQ-OQ-PQ-validatieproces niet alleen het vertrouwen in de software, maar geeft het ook gemoedsrust aan de klant, eigenaar, softwareontwikkelaars en de testers.
hoe u nep-e-mailaccounts maakt
Het draaien van IQ-OQ-PQ verkleint ook het risico om het live te gebruiken, zonder testen uit te voeren, verlaagt de faalkosten en verkleint het risico van terugroepactie.
Dus jongens, softwareontwikkelaars en testers, geen feest na het voltooien van de ontwikkeling en het testen in eigen huis en het vrijgeven van de software aan Ops Team. De viering is alleen als IQ-OQ-PQ succesvol is voltooid en de software live is op het beoogde systeem.
Het succes van een software hangt dus af van de succesvolle afronding van IQ-OQ-PQ en wanneer de software live is en klaar is voor consumptie door de eindgebruikers.
Over de auteur: Dit artikel is geschreven door Gayathri Subrahmanyam, lid van het STH-team. Ze heeft meer dan 2 decennia ervaring op het gebied van Software Testing. Tijdens haar testcarrière heeft ze veel TMMI-assessments gedaan, testindustrialisatiewerken, TCOE-setups naast het afhandelen van testleveringen en DevOps-praktijk geïmplementeerd voor een enorme opdracht. Maar volgens haar houdt leren nooit op ...
Deel uw ervaringen met het uitvoeren van het validatieproces en laat het ons weten als u vragen heeft over dit artikel.
Aanbevolen literatuur
- Software Testing-cursus: bij welk Software Testing Institute moet ik me aansluiten?
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Software testen QA Assistant Job
- Softwaretests kiezen als uw carrière
- Softwaretest Schrijver van technische inhoud Freelancer-baan
- Enkele interessante sollicitatievragen voor het testen van software
- Feedback en recensies over softwaretestcursussen
- Hulp bij het testen van software Affiliate-programma!