what are iq oq pq 3 q s software validation process
Introduktion till IQ-OQ-PQ:
IQ, OQ och PQ utgör 3Q för programvalideringsprocessen.
Som testare vet vi alla att Software Development Team utvecklar programvaran internt enligt SRS (Software Requirements Specification), funktionsspecifikation och senare verifierar testteamet implementeringen på olika testnivåer i olika testmiljöer, från enklaste till high end, vilket därmed replikerar produktionsmiljön.
Med detta tillvägagångssätt av SDLC tvättar mjukvaruutvecklingsteamet i allmänhet händerna genom att överlämna den färdiga programvaran (utvecklad och verifierad) till Operations Team. Vidare är det Operations Team (allmänt kallat Ops Team) som tar hand om att distribuera det till en produktionsmiljö och göra det redo att användas av slutanvändarna.
Här ligger den verkliga utmaningen för Operations Teamet att göra programvaran funktionell i produktionsmiljön, för under programutvecklingsfaserna har utveckling och verifiering gjorts i en simulerad miljö och ganska sällan nära den levande miljön, bara i fall av tillgänglighet av data och konfigurationer av produktionsmiljön.
Det är här valideringen av programvaran kommer in i bilden. När verifieringen är klar och programvaran har undertecknats av Program / Product-teamet, skulle Ops Team utföra en uppsättning aktiviteter innan de accepterar programvaran som ska distribueras till produktionen för att bevisa att programvaran beter sig som förväntat, vilket är inget annat än valideringsaktiviteterna.
Vad du kommer att lära dig:
Verifiering mot validering
Låt oss här tydligt förstå skillnaden mellan aktiviteterna 'Verifiering' och 'Validering'. '' Verifiering ”Är att utvärdera programvaran med hänsyn till den givna uppsättningen krav och specifikationer som görs internt på Software Development-webbplatsen av utvecklare och testare.
Medan ” Godkännande ”Är en uppsättning kvalitetssäkringskontroller som utförs av externa kunder, ägare, leverantörer av den produkt som levereras till dem, för att kontrollera lämpligheten innan de accepterar eller köper produkten. Valideringsaktiviteter utförs mestadels på produktionsanläggningen.
I fallet med applikationsutveckling är det därför Ops-teamet som utför valideringsaktiviteterna för programvaran.
Läs också:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Faser av valideringsprocessen
Generellt hänvisar valideringsprocessen för en produkt till en produkts hela livscykel från utveckling till användning och underhåll. Och därmed är valideringsprocessen uppdelad i 5 faser.
5 faser av valideringsprocessen är:
Denna 5-fasstrategi i valideringsprocessen följs i många branscher som tillverkning, medicin, läkemedel etc. Här valideras slutkunden innan man köper maskiner, utrustning eller produkten.
Beståndsdelarna i valideringsaktiviteterna för en programvara är att bevisa att ”programvaran är redo att konsumeras av användarna” och att främst verifiera en framgångsrik installation av programvaran följt av funktionalitet och användbarhet.
3Q: s strategi: IQ-OQ-PQ
I programvarusammanhang har dock 3Q: s strategi, IQ-OQ-PQ följs som en del av validering och det kommer att utföras av driftsteamet, som i slutändan är ansvarigt för att distribuera programvaran till produktionen.
Nedan följer flödesdiagrammet för valideringsprocessen:
Mallen, planen och alla andra dokument som matas in för att utföra 3Q: erna kommer att läggas ut av programvaruteamet för deras programvara och det innehåller den detaljerade metoden, uppgifter / aktiviteter / tester som ska genomföras som en del av dessa kvalifikationer längs med testresultaten.
Sammanfattningsrapporter kommer att överlämnas till Ops Team under programvaruöverlämningen tillsammans med binärfilerna och andra leveranser.
På hög nivå,
Sammantaget är syftet med att utföra IQ, OQ och PQ att säkerställa att programvaran kan distribueras framgångsrikt och alla funktioner kan användas utan flaskhalsar.
Helst är IQ, OQ och PQ de sekventiella aktiviteterna som måste utföras i ordningen. Om inte installationen är klar kan en funktionalitet i programvaran inte verifieras, och såvida inte funktionaliteten är bevisad, ingen mening med att mäta prestanda. Ibland på grund av tidsbegränsning kan PQ börja parallellt med OQ, när de viktigaste aspekterna av OQ har fastställts.
Låt oss nu förstå mer om var och en av dessa tre faser i detalj.
Installationskvalificering (IQ)
Installationskvalifikation kallas också 'IQ' , är valideringsprocessen om den medföljande mjukvaran (binärer, skript etc.) kan installeras i den angivna miljön med de angivna konfigurationerna, och för att verifiera hur dessa installationssteg registreras i dokumentet ”Installationsguide”.
Följande artiklar levereras av utvecklingsteamet tillsammans med det levererade mjukvarupaketet och används av Ops Team för att utföra IQ.
1) ”Installationsguide” -dokument, som dokumenterar installationsstegen i de valda miljöerna.
två) ”Configuration Guide” -dokument för att konfigurera programvarans konfigurerbara program. Ibland blir detta dokument en del av själva installationsguiden.
3) Programvarupaket och installationsskript, helst automatiserade skript.
Programvara för kvalificering av programvara anses vara den viktigaste och vanligtvis många frågor öppen upp under denna fas.
Eftersom:
till) Utvecklingsmiljön kommer inte att ha 100% realtidsmiljö tillgänglig för att verifiera installationsproblemen och därmed bidrar en skillnad i miljön till flera problem.
b) På grund av olika anledningar kanske det inte finns tillräckligt med samarbete och samordning mellan utvecklingen och driftsteamet under de första faserna av mjukvaruutveckling för att hantera problemen långt framåt.
c) Det kan finnas några dokumentationsproblem när du registrerar de faktiska installationsstegen i dokumentet, vilket kanske inte exakt matchar i produktionsmiljön.
Dessa dagar kommer hela programvaruinstallationsproceduren att automatiseras så mycket som möjligt via en serie skript. Om det finns några problem med installationen misslyckas den automatiska installationen på grund av missfel i konfigurationerna och manuell intervention för att åtgärda dessa problem krävs.
Eftersom Ops-teamet utför IQ genom att strikt följa instruktionerna från Software Team i installationshandboken är det mycket viktigt och även Software Teams ansvar att se till att 'Installationsguide' är skrivet på ett sådant sätt att installationsstegen matchar realtidsmiljön.
Och det är testarens ansvar att se till att 'installationsprocessen' verifieras internt tillsammans med dokumentverifieringen för att den är fullständig och att identifiera eventuella missmatchningar med de faktiska stegen som ska köras i systemet mot de dokumenterade stegen i Installationsguide.
Följande punkter måste komma ihåg när du skriver en installationsguide och verifierar dem internt för att minimera problemen under programvaruinstallationen vid produktion.
| SNO | Installationsguide |
|---|---|
| 7 | Den typiska tiden det tog att installera programvaran bör nämnas i installationsguiden för Ops-teamet för att få en uppfattning om den ungefärliga tidpunkten för installationen för att planera sina aktiviteter därefter. |
| 1 | Huvudsakligt och ytterst bör ”installationshandboken” skrivas på ett enkelt och lätt att följa språk. |
| två | Måste se till att den inte tar längre, mer än fem sidor. Det ska vara kort och snyggt. |
| 3 | Behöver ange serienumren för varje körningssteg för att spåra dess status. |
| 4 | Automatisera stegen så mycket som möjligt och bunt dem alla i ett enda skript. |
| 5 | En standardmall ska användas för att skriva installationsproceduren. |
| 6 | Förutsättningar bör tydligt nämnas för att undvika missmatchning och stegen för att verifiera dem måste tillhandahållas. Om det finns en missmatchning bör du få instruktioner om att få dem upp till den förväntade nivån eller att installera dessa paket. |
| 8 | De tjänster som måste tas ner under installationen, hur man sänker dem, effekten av att sänka dem måste anges tydligt i guiden. |
| 9 | Att tillhandahålla länkar till andra dokument bör undvikas och byta från ett dokument till ett annat. Varje information som behövs bör göras tillgänglig i samma dokument. Om ytterligare dokument behöver hänvisas, leverera dem tillsammans med programvarupaketet och i sin tur måste de hänvisas till huvuddokumenten. |
| 10 | Måste se till att namnet på skriptet som nämns i dokumentet är detsamma som det som är förpackat tillsammans med binärsystemet. |
| elva | Bör säkerställa att alla skript som hänvisas till i installationshandboken levereras tillsammans med binärsystemet. |
| 12 | Se till att alla konfigurationsparametrar tydligt nämns i installationsguiden / konfigurationsguiden tillsammans med standardvärdena och andra värden som stöds. |
| 13 | Automatiserade tester för att utföra byggverifieringstesterna efter att programvaruinstallationen har slutförts ska tillhandahållas. De måste vara minst antal och viktiga för att verifiera att build har installerats. |
| 14 | 'Rökprov' måste tillhandahållas för att säkerställa att systemets anslutning från slut till slut är perfekt och att alla komponenter i systemet pratar med varandra som förväntat. |
| femton | Om programvaruinstallationen misslyckas levereras återställningsskript tillsammans med paketet och återställningsförfarandet är tydligt skrivet i installationshandboken för att utföra återställning och återställa systemet framgångsrikt. |
Med alla ovanstående punkter att ta hand om är det en bästa praxis att automatisera programvaruinstallationsprocessen med minimalt mänskligt ingripande för att undvika mänskliga fel.
Om några problem upptäcks under IQ-valideringsfasen kommer det att rapporteras till programvaruteamet, efter att det har fixats, rökprovning och byggverifieringstest kommer att utföras för att kontrollera framgången med programinstallationen.
Därför inkluderar IQ-fasen installation av programvarupaket följt av genomförande av byggverifiering och rökprov.
Så framgångsrik slutförande av IQ-fasen är mycket viktigt eftersom en framgångsrik och rätt installation av en programvara säkerställer att de flesta frågor som rör funktionsfel ignoreras.
Operativ kvalifikation (OQ)
Operativ kvalifikation, även kallad VAD är nästa aktivitet i mjukvaruvalideringsprocessen efter att IQ har slutförts.
Den operativa kvalificeringsaktiviteten inkluderar t han testar att köras för att verifiera att programvaran är operativt lämplig att distribueras för konsumenterna. Helst verifieras programvarans nyckelfunktioner som en del av denna valideringsprocess.
En OQ-plan för genomförande av OQ-validering måste utarbetas av Software Team (Testers) som ska täcka alla aspekter av OQ-testning som behöver utföras, inklusive detaljer som nej. av tester, testschema, metodik, verktyg, inverkan på tjänsten, testkörningssekvens, metod för rapportering av problem och SLA: er för att åtgärda dem, Defect Triage-tillvägagångssätt etc.,
De operativa kvalificeringstesterna som körs som en del av OQ levereras åter av programvaruteamet tillsammans med leveranserna av programvaran. Dessa operationella kvalifikationstester är en samling viktiga tester som är utformade utifrån dokumentet ”Functional Requirements Specification” för att säkerställa att hela mjukvarusystemet fungerar enligt förväntningarna.
Detta OQ-testspecifikationsdokument är upprättat av testingenjörerna mot specifikationsspecifikationsdokumentet. Ofta kommer detta dokument att vara delmängden av systemtestspecifikationsdokumentet som utarbetas och verifieras under systemtestfasen av SDLC.
Testerna kan ändras eller uppdateras så att de passar kraven för operativt team och villkoren för webbplatsen där den kommer att utföras.
Därför bör extra försiktighet iakttas när man väljer de tester som ingår i OQ för att säkerställa att alla nyckelfunktioner och de viktigaste affärsflödena ingår som en del av denna verifiering.
Följande är tips för testare när du förbereder OQ-testspecifikationsdokumentet.
| Sno | Tips för testare när du förbereder OQ-testspecifikationsdokumentet |
|---|---|
| 7 | Testfall relaterade till gränsvärde behöver inte inkluderas, vilket verifierar extrema värden, men använder de vanligaste dagliga värdena som ingångar, varhelst det behövs. |
| 1 | Se till att viktiga funktionstest för att bevisa att programvarufunktioner som förväntat är valda och inkluderade och följaktligen är nödvändig spårbarhet för vart och ett av de skriftliga testfallet tillgängliga i OQ Test Spec-dokumentet. |
| två | Se till att testerna är snyggt skrivna med steg för steg-åtgärder, är självförklarande och kan förstås av en vanlig man. |
| 3 | Hänvis eller undvik inte att använda tekniska termer i testfallet så mycket som möjligt, eftersom användaren av detta dokument kanske inte känner till dessa terminologier. E att testdata som används inte redan finns i systemet. Ange flera uppsättningar data, om användaren vill utföra testfallet mer än en gång. |
| 4 | Nämn tydligt de obligatoriska och valfria förutsättningarna för varje test. |
| 5 | Inkludera majoriteten av positiva testfall för att verifiera funktionaliteten. |
| 6 | Inkludera väldigt få negativa testfall för att säkerställa att programbeteende är som förväntat vid irrelevant inmatning och att systemet kan hantera de negativa fallen framgångsrikt. |
| 8 | Nämn de konfigurationsvärden som ska ställas in om de behöver ändras från standardvärdena. |
| 9 | Leverera de automatiska testfall som ska köras, var som helst. Säkerställ innan hand att dessa automatiseringsskript kan köras på systemet där OQ planeras. |
| 10 | Se till att varje testfall har de tydliga resultaten 'Förväntade' och 'Faktiska' som referens. Och lägg till eventuella kommentarer om det behövs för att förklara det faktiska resultatet. |
| elva | Det är också nödvändigt att inkludera ”acceptanskriterierna” för vart och ett av testfallet. Godtagningskriterierna kan vara systemets status efter genomförandet av testfallet. |
| 12 | Ange 'Testdata' som ska användas för vart och ett av testerna korrekt. Försök att leverera de vanligaste uppgifterna från live. Och också få exceptionella data för att säkerställa att systemet även kan hantera undantagsfall. Se till att testdata som används inte redan finns i systemet. Ange flera uppsättningar data, om användaren vill utföra testfallet mer än en gång. |
| 13 | Om flera operativa användare kör testerna från olika platser parallellt, anvisar du instruktioner för att utföra tester därefter med olika datauppsättningar. |
| 14 | Ange checklistor där det någonsin behövs för att säkerställa att alla konfigurationer, förutsättningar är inställda som förväntat innan du kör testerna. |
| femton | Fortsätt att övervaka loggarna när testerna körs om det finns åtkomst till systemet. |
| 16 | Om möjligt och krävs ge ett körningssupport till de operativa användarna under utförandet av dessa testfall. |
| 17 | Förklara metoden för rapportering av problemen som hittades under körningen. Det är bättre att använda spårningsverktyget för att spåra problemen. Övervaka varje utgåva noggrant och ta den till slut enligt de avtalade SLA: erna. |
| 18 | Kör 'Defect Triages' som involverar rätt intressenter för att förstå de kritiska och allvarliga problemen och tillhandahålla uppdateringar om dessa frågor ofta. |
| 19 | Ange den slutgiltiga ”OQ Test Execution Summary Report” -mallen för att publicera de slutliga resultaten efter genomförandet. |
Så den beredda OQ-planen och testspecifikationen bör granskas grundligt och undertecknas av relevanta intressenter för att främst säkerställa att antingen täckningen inte är för mindre eller för mycket och att alla nyckelfunktioner täcks.
Framgångsrik slutförande av OQ visar att programvaran kommer att fungera i enlighet med dess operativa specifikationer i den valda miljön och det är scenporten för att flytta programvaran mot dess produktion och är signalen att gå vidare med nästa aktivitet i valideringsprocessen som är PQ .
Prestandakvalificering (PQ)
Efter att ha säkerställt framgångsrik IQ, OQ slutför nästa aktivitet i valideringsprocessen att säkerställa om produkten / mjukvaran uppfyller de angivna prestandaspekterna under den förväntade belastningen konsekvent utan att orsaka någon flaskhals i produktionsmiljön.
Den viktigaste aspekten av PQ är att säkerställa att en programvara, när den installeras på det förväntade systemet, kan hantera den levande belastningen och möta den förväntade svarstiden och kraschar inte under toppbelastningar och stress när hanterar samtidiga användare.
Därför är PQ främst för att säkerställa om de angivna prestandakriterierna för en programvara uppnås under en tidsperiod (kanske en vecka) på tillförlitlig basis med varierande belastningsförhållanden, liksom mönstret i live. Därför måste dessa tester köras varje dag för att övervaka mjukvarusystemets beteende och därför tar PQ ett tag att slutföra tills det säkerställs att systemet är bevisat för sin prestanda.
Helst utförs PQ-validering efter avslutad OQ, där programvarans funktionalitet säkerställs och kan fortsätta med att verifiera produktens eller programvarans prestandaspekt. Ibland på grund av tidsbegränsning kan PQ starta parallellt med OQ, baserat på förtroendet för andelen OQ-slutförande.
Det är idealiskt att utföra dessa prestandatester på live-systemet med det fulladdade systemet eller under förhållanden som liknar live och se till att det inte finns några flaskhalsar på prestationsaspekterna.
Följande tester körs vanligtvis som en del av prestationskvalificeringen. Och valet av tester varierar från programvara till programvara.
# 1) Tillgänglighetstest: För att säkerställa att programvaran är kontinuerligt tillgänglig utan att krascha eller gå ner.
# 2) Tillgänglighetstest: För att säkerställa att programvaran är lättillgänglig från alla platser med den förväntade prestandahastigheten utan problem.
# 3) Lasttest: För att mäta systemets beteende under den förväntade dagliga belastningen och även toppbelastningsförhållandena.
# 4) Stresstest: För att mäta systemets brytpunkt under extrema belastningsförhållanden.
# 5) Test för genomströmningsprestanda: Att mäta systemets svarstid och att mäta TPS (transaktioner per sekund)
# 6) Testning av skalbarhet: Systemet kan skala för att hantera de förväntade samtidiga användarna.
Prestanda-testscenarierna och motsvarande automatiska skript förbereds utifrån de prestandarelaterade kraven som anges i dokumenten ”Användarkravspecifikation”.
I likhet med en OQ-plan bör en detaljerad PQ-plan som tydligt anger testmetoden, strategin, planen och schemat tillsammans med verktygen utarbetas och genomföras med PQ-utförarna.
Verktyget för prestandatestning och övervakning måste installeras i den miljö där PQ utförs för att mäta och rapportera prestandamätvärdena.
Följande är tips för testarna för att göra det möjligt för Operations Team att genomföra PQ framgångsrikt.
| Sno | Tips för testarna att aktivera Operations Team |
|---|---|
| 7 | Guida, stödja och utbilda driftsteamet för att utföra prestandatester på systemet. |
| 1 | Förbered de viktigaste affärsspecifika scenarierna för att utföra prestandatestning baserat på URS. |
| två | Se till att test ingår för att bevisa att systemet uppfyller förväntningarna om svarstid, hastighet, skalbarhet och stabilitet under olika belastningsförhållanden. |
| 3 | Se till att specificerad belastning är tillgänglig eller metod och verktyg för att generera erforderlig belastning nämns tydligt i respektive testfall. |
| 4 | Nämn förutsättningen för vart och ett av scenariot tydligt, som förhållandena före systemet som ska finnas, antalet samtidiga användare etc., |
| 5 | Nämnverktyg som rekommenderas att användas för att utföra prestandatestning som är specifik för varje testkategori och för varje test. |
| 6 | Se till att processen för att övervaka prestandamätningarna nämns tydligt. |
Efter framgångsrik slutförande av PQ är det mycket viktigt att uppfylla prestationskraven, eftersom alla prestationsrelaterade avvikelser kan orsaka en enorm affärsförlust genom att skapa obehag för användaren och förtroendet för programvaran som ska användas kommer att gå förlorat vilket leder till att programvaran misslyckas.
I ett nötskal, t nedanstående tabell sammanfattar IQ-OQ-PQ-aktiviteterna.
| IQ | VAD | PQ | |
|---|---|---|---|
| Vad | För att verifiera processen för installation av programvara och hur processen dokumenteras | För att verifiera att systemet fungerar korrekt | Kunder, ägare, leverantörer, driftsteam |
| WHO | Kunder, ägare, leverantörer, driftsteam | Kunder, ägare, leverantörer, driftsteam | Kunder, ägare, leverantörer, driftsteam |
| Var | På ägarens webbplats, driftsteamets plats, live-webbplats, produkt som miljö | På ägarens webbplats, driftsteamets plats, live-webbplats, produkt som miljö | På ägarens webbplats, driftsteamets plats, live-webbplats, produkt som miljö |
| När | När programvaran tas emot från programvaruteamet, före OQ och PQ. | Innan systemet släpps för användning och efter framgångsrik IQ-slutförande | Innan du sätter systemet i live och efter framgångsrik IQ, slutfördes OQ |
Nedanstående tabell förklarar de olika ingångarna för var och en av valideringsfaserna.
| Typ | Inmatning |
|---|---|
| IQ | 1. Designspecifikationsdokument 2. Programvarubinarier och andra installationsskript 3. Installationshandbok Dokument 4. Konfigurationshandbok Dokument 5. Skapa verifierings- och rökdokument |
| VAD | 1. Funktionellt specifikationsdokument 2. OQ-plandokument 3. Testdokument för operativ kvalifikation 4. OQ-testsammanfattningsrapportmall 5. IQ slutförd framgångsrikt |
| PQ | 1. URS-dokument (User Requirement Specification) 2. Dokument för PQ-plan 3. Testdokument för prestationskvalificering 4. Mall för rapportrapport för PQ-test 5. IQ och OQ slutfört framgångsrikt |
Slutsats
Även om produkten / programvaran har klarat alla verifieringssteg och inte kan bevisa någon av IQ-OQ-PQ, kan resultatet bli katastrofalt och kommer att medföra en enorm kostnad. Därför är framgångsrik slutförande av IQ-OQ-PQ ensam en framgångsrik överföring av produkten från utvecklingsplatsen till produktionsplatsen.
Sammantaget ger den framgångsrika slutförandet av IQ-OQ-PQ-valideringsprocessen inte bara förtroendet för programvaran utan ger också en sinnesro till klienten, ägaren, mjukvaruutvecklarna och testarna.
som är den bästa e-postleverantören
Att köra IQ-OQ-PQ minskar också risken för att distribuera den för att leva, utan att testa och minskar kostnaden för fel och minskar risken för återkallande av produkterna.
Så killar, mjukvaruutvecklare och testare, ingen fest efter att ha slutfört utvecklingen och testet internt och släppt programvaran till Ops Team. Firandet är bara när det framgångsrikt slutfört IQ-OQ-PQ och programvaran finns live på det riktade systemet.
Därför beror framgången för en programvara på att IQ-OQ-PQ lyckats och när programvaran är live och redo att konsumeras av slutanvändarna.
Om författaren: Den här artikeln är skriven av STH-teammedlem Gayathri Subrahmanyam. Hon har mer än två decenniers erfarenhet inom området Software Testing. Under sin testkarriär har hon gjort många TMMI-utvärderingar, testindustrialiseringsarbeten, TCOE-inställningar förutom att hantera testleveranser och implementerat DevOps-praxis för ett stort engagemang. Men enligt henne slutar lärandet aldrig ...
Dela dina erfarenheter av att utföra valideringsprocessen och låt oss veta om du har frågor om den här artikeln.
Rekommenderad läsning
- Programvarutestningskurs: Vilket programvarutestinstitut ska jag gå med?
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Programvarutestning QA-assistentjobb
- Välja programvarutestning som din karriär
- Programvarutestning Tekniskt innehåll Writer Freelancer Jobb
- Några intressanta programtestintervjufrågor
- Programtestkursfeedback och recensioner
- Programvarutestning Hjälp Affiliate Program!