what are iq oq pq 3 q s software validation process
Introduktion til IQ-OQ-PQ:
IQ, OQ og PQ udgør 3Q'erne af softwarevalideringsprocessen.
Som testere ved vi alle, at softwareudviklingsteamet udvikler softwaren internt i henhold til softwarekravspecifikationen (SRS), funktionel specifikation og senere testteamet verificerer implementeringen på forskellige testniveauer i forskellige testmiljøer, fra den enkleste til den high end, som derved replikerer produktionsmiljøet.
Med denne tilgang til SDLC vasker softwareudviklingsteamet generelt deres hænder ved at aflevere den færdige software (udviklet og verificeret) til Operations Team. Desuden er det Operations Team (generelt benævnt Ops Team), der tager sig af at implementere det i et produktionsmiljø og gøre det klar til brug af slutbrugerne.
Her ligger den virkelige udfordring for Operations Team om at gøre softwaren funktionel i produktionsmiljøet, fordi udvikling og verifikation under softwareudviklingsfaserne er foretaget i et simuleret miljø og ganske sjældent tæt på det levende miljø, kun i tilfælde af tilgængelighed af data og konfigurationer af produktionsmiljøet.
Det er her valideringen af softwaren kommer ind i billedet. Når verifikationen er afsluttet, og softwaren er underskrevet af Program / Product-teamet, vil Ops Team udføre et sæt aktiviteter, inden de accepterer softwaren, der skal distribueres til produktionen, for at bevise, at softwaren opfører sig som forventet, hvilket er intet andet end valideringsaktiviteterne.
Hvad du lærer:
Verifikation vs validering
Lad os her klart forstå forskellen mellem 'Verifikation' og 'Validering' -aktiviteter. '' Verifikation ”Er at evaluere softwaren med hensyn til det givne sæt krav og specifikationer, der udføres internt på Softwareudviklingsstedet af udviklere og testere.
Der henviser til, at Validering 'Er et sæt kvalitetssikringskontrol, der udføres af eksterne kunder, ejere, leverandører af det produkt, der leveres til dem, for at kontrollere egnetheden, inden de accepterer eller køber produktet. Valideringsaktiviteter udføres for det meste på produktionsstedet.
I tilfælde af applikationsudvikling er det derfor Ops-teamet, der udfører valideringsaktiviteterne for softwaren.
Læs også:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Faser af valideringsprocessen
Generelt refererer valideringsprocessen for ethvert produkt til den komplette livscyklus for et produkt fra udviklingen gennem brug og vedligeholdelse. Og derfor er valideringsprocessen opdelt i 5 faser.
5 faser af valideringsprocessen er:
Denne 5-fasede tilgang til valideringsprocessen følges i mange brancher som fremstilling, medicin, lægemidler osv. Her skal validering foretages af slutkunden, inden de køber maskiner, udstyr eller produktet.
Bestanddelene af valideringsaktiviteterne for en software er at bevise, at 'softwaren er klar til forbrug af brugerne' og hovedsagelig at kontrollere den vellykkede installation af softwaren efterfulgt af funktionalitet og brugbarhed.
3Q's tilgang: IQ-OQ-PQ
I softwarekonteksten er det dog 3Q's tilgang, IQ-OQ-PQ følges som en del af validering, og det vil blive udført af operationsteamet, som i sidste ende er ansvarlig for at implementere softwaren til produktionen.
Nedenfor er validationsprocesflowdiagrammet:
Skabelonen, planen og andre dokumenter, der er input til at udføre 3Q'erne, vil blive lagt ud af softwareteamet til deres software, og det inkluderer den detaljerede tilgang, opgaver / aktiviteter / test, der skal udføres som en del af disse kvalifikationer sammen med testresultaterne.
Resumérapporter vil blive afleveret til Ops Team under softwareoverdragelsen sammen med binærfiler og andre leverancer.
På højt niveau,
Samlet set er formålet med at udføre IQ, OQ og PQ at sikre, at softwaren med succes kan implementeres, og alle funktionerne kan bruges uden flaskehalse.
Ideelt set er IQ, OQ og PQ de sekventielle aktiviteter, der skal udføres i rækkefølgen. Medmindre installationen er udført, kan en softwarefunktionalitet ikke verificeres, og medmindre funktionaliteten er bevist, er der ingen mening i at måle ydelsen. Nogle gange på grund af tidsbegrænsning kan PQ starte parallelt med OQ, når de vigtigste aspekter af OQ er etableret.
Lad os nu forstå mere om hver af disse 3 faser i detaljer.
Installationskvalifikation (IQ)
Installationskvalifikation også kaldet 'IQ' , er valideringsprocessen, hvis den leverede software (binærfiler, scripts osv.) kan installeres med succes i det specificerede miljø med de angivne konfigurationer, og for at kontrollere, hvordan disse installationstrin er registreret i dokumentet kaldet 'Installationsvejledning'.
Følgende varer leveres af Development Team sammen med den leverede softwarepakke og bruges af Ops Team til at udføre IQ.
1) 'Installationsguide'-dokument, der dokumenterer installationstrinnene i de valgte miljøer.
to) 'Configuration Guide' dokument til konfiguration af softwaren, der kan konfigureres. Nogle gange bliver dette dokument en del af selve installationsvejledningsdokumentet.
3) Softwarepakke og installationsskripter, helst automatiserede scripts.
Softwareinstallation Kvalifikationsfase anses for at være den mest afgørende og typisk mange problemer åben op i denne fase.
Fordi:
til) Udviklingsmiljø vil ikke have 100% realtidsmiljø til rådighed for at kontrollere installationsproblemerne, og derfor bidrager en forskel i miljøet til flere problemer.
b) Af forskellige årsager er der muligvis ikke nok samarbejde og koordinering mellem udviklingen og driftsteamet i de indledende faser af softwareudvikling til at håndtere problemerne i god tid.
c) Der kan være nogle dokumentationsproblemer under optagelse af de faktiske installationstrin i dokumentet, som muligvis ikke nøjagtigt svarer til produktionsmiljøet.
I disse dage vil hele softwareinstallationsproceduren blive automatiseret så meget som muligt via en række scripts. Hvis der er problemer med installationen, mislykkes den automatiske installation på grund af misforhold i konfigurationerne, og manuel indgriben for at løse disse problemer er påkrævet.
Da Ops-teamet udfører IQ ved nøje at følge instruktionerne fra softwareteamet i installationsvejledningen, er det meget vigtigt og også softwareteamets ansvar at sikre, at 'installationsvejledning' er skrevet på en sådan måde, at installationstrin svarer til realtidsmiljøet.
Og det er testernes ansvar at sikre, at 'installations'-processen verificeres internt sammen med dokumentbekræftelsen for at være fuldstændig og at identificere eventuelle miss-matches med de faktiske trin, der skal køres på systemet, mod de dokumenterede trin i Installationsvejledning.
Følgende punkter skal huskes, mens du skriver en installationsvejledning og verificerer dem internt for at minimere problemerne under softwareinstallation ved produktion.
| SNO | Installationsvejledningspunkter |
|---|---|
| 7 | Den typiske tid, det tager at installere softwaren, bør nævnes i installationsvejledningen til Ops-teamet for at få en idé om den omtrentlige installationstidspunkt for at planlægge deres aktiviteter i overensstemmelse hermed. |
| 1 | Vigtigste og yderste skal 'Installationsvejledningen' skrives på et enkelt og let at følge sprog. |
| to | Behov for at sikre, at det ikke løber langt, mere end 5 sider. Det skal være kort og pænt. |
| 3 | Brug for at give serienumrene til hvert udførelsestrin for at spore dets status. |
| 4 | Automatiser trinene så meget som muligt, og bundt dem alle i et enkelt script. |
| 5 | En standardskabelon skal bruges til at skrive installationsproceduren. |
| 6 | Forudsætninger skal tydeligt nævnes for at undgå miss-match, og trinene til at verificere dem skal leveres. Hvis der er en miss-match, skal der gives instruktion om at bringe dem op på det forventede niveau eller installere disse pakker. |
| 8 | De tjenester, der skal bringes ned under installationen, hvordan man nedbringer, virkningen af at nedbringe dem skal tydeligt nævnes i vejledningen. |
| 9 | At give links til andre dokumenter bør undgås og skifte fra et dokument til et andet. Alle nødvendige oplysninger skal gøres tilgængelige i det samme dokument. Hvis yderligere dokumenter skal henvises, skal du levere dem sammen med softwarepakken, og til gengæld skal de henvises til hoveddokumenterne. |
| 10 | Behov for at sikre, at navnet på det script, der er nævnt i dokumentet, er det samme som det, der er pakket sammen med binærprogrammet. |
| elleve | Skal sikre, at alle de scripts, der henvises til i installationsvejledningsdokumentet, leveres sammen med binærprogrammet. |
| 12 | Sørg for, at alle konfigurationsparametre er tydeligt nævnt i installationsvejledningen / konfigurationsvejledningen sammen med standardværdierne og andre understøttede værdier. |
| 13 | Automatiske tests til at udføre build-verifikationstest efter installation af software skal leveres. De skal have et minimum i antal og vigtige for at kontrollere, at build er installeret med succes. |
| 14 | Der skal leveres 'røgtest' for at sikre, at systemets tilslutning fra ende til anden er perfekt, og at alle systemets komponenter taler til hinanden som forventet. |
| femten | I tilfælde af mislykket softwareinstallation leveres rollback-scripts sammen med pakken, og rollback-proceduren er tydeligt skrevet i installationsvejledningen for at udføre rollback og gendanne systemet med succes. |
Da alle ovenstående punkter skal tages hånd om, er det en bedste praksis at automatisere softwareinstallationsprocessen med mindst mulig menneskelig indgriben for at undgå de menneskelige fejl.
Hvis der opstår problemer under IQ-valideringsfasen, rapporteres det til softwareteamet, når det er rettet, røgtestning og opbygning verifikationstest udføres for at kontrollere, om softwareinstallationen er vellykket.
Derfor inkluderer IQ-fasen installation af softwarepakken efterfulgt af udførelse af verifikation af byggeri og røg.
Så en vellykket afslutning af IQ-fasen er meget vigtig, da en vellykket og korrekt installation af en software sikrer, at de fleste af problemerne i forbindelse med funktionsfejl ignoreres.
Operativ kvalifikation (OQ)
Operationel kvalifikation, også kaldet som HVAD er den næste aktivitet i softwarevalideringsprocessen efter en vellykket afslutning af IQ.
Den operationelle kvalifikationsaktivitet inkluderer t han tester for at blive kørt for at kontrollere, at softwaren er operationelt egnet til at blive brugt til forbrugerne. Ideelt set verificeres softwarens nøglefunktioner som en del af denne valideringsproces.
En OQ-plan til udførelse af OQ-validering skal udarbejdes af softwareteamet (testere), der skal dække alle de aspekter af OQ-test, der skal udføres, herunder detaljerne som nej. af tests, testplan, metodologi, værktøjer, indflydelse på tjenesten, testudførelsessekvens, metode til rapportering af problemer og SLA'er til løsning af dem, Defect Triage-tilgang osv.,
De operationelle kvalifikationstest, der køres som en del af OQ, leveres igen af softwareteamet sammen med softwareleverancerne. Disse operationelle kvalifikationstest er en samling af vigtige tests, som er designet ud fra dokumentet 'Specifikation af funktionelle krav' for at sikre, at hele softwaresystemet fungerer som forventet.
Dette OQ-testspecifikationsdokument er udarbejdet af testingeniørerne mod dokumentet om specifikation af funktionskrav. Dette dokument er ofte delmængden af dokumentet System Test Specification, der er udarbejdet og verificeret under systemtestfasen af SDLC.
Testene kan ændres eller opdateres, så de passer til kravene fra det operationelle team og betingelserne på det sted, hvor det vil blive udført.
Derfor skal der udvises ekstra forsigtighed, når man vælger de tests, der er en del af OQ'en, for at sikre, at alle nøglefunktionaliteterne og de vigtigste forretningsprocesser er inkluderet som en del af denne verifikation.
Følgende er tip til testere under udarbejdelse af OQ-testspecifikationsdokumentet.
| Sno | Tips til testere under udarbejdelsen af OQ-testspecifikationsdokumentet |
|---|---|
| 7 | Testtilfælde relateret til grænseværdien behøver ikke at være inkluderet, hvilket verificerer for ekstreme værdier, men brug de mest almindelige daglige anvendte værdier som input, hvor det er nødvendigt. |
| 1 | Sørg for, at nøglefunktionalitetstest for at bevise, at softwarefunktioner som forventet er valgt og inkluderet, og derfor er den nødvendige sporbarhed til hver af de skriftlige testcases tilgængelige i OQ Test Spec-dokumentet. |
| to | Sørg for, at testene er pænt skrevet med trinvise handlinger, er selvforklarende og kan forstås af en almindelig mand. |
| 3 | Henvis eller undgå ikke brugen af tekniske udtryk i testsagerne så meget som muligt, da brugeren af dette dokument muligvis ikke kender til disse terminologier. E at de anvendte testdata ikke allerede findes på systemet. Angiv flere datasæt, hvis brugeren ønsker at udføre testsagerne mere end én gang. |
| 4 | Nævn klart de obligatoriske og valgfri forudsætninger for hver af testene. |
| 5 | Inkluder flertallet af de positive testsager for at kontrollere funktionaliteten. |
| 6 | Inkluder meget få negative testtilfælde for at sikre, at softwareadfærd er som forventet i tilfælde af irrelevant input, og systemet er i stand til at håndtere de negative sager med succes. |
| 8 | Nævn de konfigurationsværdier, der skal indstilles, hvis de skal ændres fra standardværdierne. |
| 9 | Lever de automatiske testsager, der skal køres, hvor det er tilgængeligt. Sørg inden hånden for, at disse automatiseringsskripter kan køres på det system, hvor OQ planlægges. |
| 10 | Sørg for, at hver testsag har de klare 'Forventede' og 'Faktiske' resultater som reference. Og tilføj eventuelle kommentarer, hvis det er nødvendigt for at forklare det faktiske resultat. |
| elleve | Det er også nødvendigt at medtage 'acceptkriterierne' for hver af testsagerne. Acceptkriterierne kunne være systemets status efter udførelsen af testsagerne. |
| 12 | Angiv de 'testdata', der skal bruges til hver af testene nøjagtigt. Prøv at levere de mest almindelige data fra live. Og også få ekstraordinære data for at sikre, at systemet også kan håndtere de ekstraordinære tilfælde. Sørg for, at de anvendte testdata ikke allerede findes på systemet. Angiv flere datasæt, hvis brugeren ønsker at udføre testsagerne mere end én gang. |
| 13 | Hvis flere operationelle brugere kører testene fra forskellige steder parallelt, skal du give instruktioner til at udføre test i overensstemmelse hermed med forskellige datasæt. |
| 14 | Angiv tjeklister, hvor det nogensinde er nødvendigt for at sikre, at alle konfigurationer, forudsætninger er indstillet som forventet, før testene køres. |
| femten | Bliv ved med at overvåge logfilerne, når testene kører, hvis der er adgang til systemet. |
| 16 | Hvis det er muligt og påkrævet, yde en eksekveringssupport til de operationelle brugere under udførelsen af disse testsager. |
| 17 | Forklar metoden til rapportering af de problemer, der blev fundet under udførelsen. Det er bedre at bruge fejlsporingsværktøjet til at spore problemerne. Overvåg hvert emne omhyggeligt og tag det til afslutning i henhold til de aftalte SLA'er. |
| 18 | Kør 'Defektforsøg', der involverer rettighedshavere for at forstå de kritiske og alvorlige problemer og give opdateringer om disse spørgsmål ofte. |
| 19 | Giv den endelige 'OQ Test Execution Summary Report' skabelon for at offentliggøre de endelige resultater efter afslutningen af udførelsen. |
Så den udarbejdede OQ-plan og testspecifikation bør gennemgås grundigt og underskrives af de relevante interessenter for primært at sikre, at enten dækningen ikke er for mindre eller for meget, og at alle nøglefunktionaliteterne er dækket.
Vellykket færdiggørelse af OQ viser, at softwaren vil fungere i henhold til dens operationelle specifikationer i det valgte miljø, og det er scenegangen i at flytte softwaren mod sin produktion og er signalet om at gå videre med den næste aktivitet i valideringsprocessen, som er PQ .
Performance Qualification (PQ)
Efter at have sikret en vellykket IQ, OQ færdiggørelse af den næste aktivitet i valideringsprocessen er at sikre, om produktet / softwaren opfylder de specificerede præstationsaspekter under den forventede belastning konsekvent uden at forårsage nogen flaskehals i produktionsmiljøet.
Nøgleaspektet ved PQ er at sikre, at en software, når den er installeret på det forventede system, kan håndtere den levende belastning og imødekomme den forventede responstid og går ikke ned under spidsbelastninger og stress under håndtering af samtidige brugere.
Derfor er PQ primært for at sikre, at de specificerede præstationskriterier for en software opnås over en periode (måske en uge) på en pålidelig basis med varierende belastningsforhold, som det er mønsteret i live. Derfor skal disse tests køres hver dag for at overvåge softwaresystemets opførsel, og det vil derfor tage et stykke tid at gennemføre PQ, indtil det er sikret, at systemet er bevist for sin ydeevne.
Ideelt set udføres PQ-validering efter afslutningen af OQ, hvor softwarens funktionalitet er sikret og kan fortsætte med at verificere produktets eller softwarens ydeevne. Undertiden på grund af tidsbegrænsning kan PQ starte parallelt med OQ, baseret på tilliden til procentdelen af OQ-færdiggørelse.
Det er ideelt at udføre disse præstationstest på live-systemet med det fuldt belastede system eller på lignende betingelser som live og sikre, at der ikke er nogen flaskehalse på ydeevneaspekterne.
Følgende tests køres generelt som en del af Performance Qualification. Og valget af test varierer fra software til software.
# 1) Tilgængelighedstest: For at sikre, at softwaren kontinuerligt er tilgængelig uden at gå ned eller gå ned.
# 2) Tilgængelighedstest: For at sikre, at softwaren er let tilgængelig fra hvert sted med den forventede ydeevnehastighed uden problemer.
# 3) Belastningstest: At måle systemets opførsel under den forventede daglige belastning og også spidsbelastningsforhold.
# 4) Stresstest: At måle systemets brudpunkt under ekstreme belastningsforhold.
# 5) Gennemstrømningstest: For at måle systemets responstid og måle TPS (transaktioner pr. Sekund)
# 6) Test af skalerbarhed: Systemet kan skaleres for at håndtere de forventede samtidige brugere.
Ydelsestestscenarierne og de tilsvarende automatiserede scripts udarbejdes på baggrund af de præstationsrelaterede krav, der er specificeret i dokumentet 'Specifikationer for brugerkrav'.
Som svarende til en OQ-plan, bør en detaljeret PQ-plan, der klart angiver testmetoden, strategien, planen og tidsplanen sammen med værktøjerne, udarbejdes og gennemføres med PQ-eksekutørerne.
Ydelsesprøvnings- og overvågningsværktøjet skal installeres i det miljø, hvor PQ'en udføres for at måle og rapportere præstationsmålingerne.
Følgende er tipene til testerne, så Operations Teamet kan udføre PQ'en med succes.
| Sno | Tips til testere for at aktivere driftsteamet |
|---|---|
| 7 | Vejled, support og træn operationsteamet til at udføre præstationsafprøvningen på systemet. |
| 1 | Forbered de vigtigste forretningsspecifikke scenarier til at udføre præstationstestning baseret på URS. |
| to | Sørg for, at der er inkluderet test for at bevise, at systemet lever op til forventningerne om responstid, hastighed, skalerbarhed og stabilitet under forskellige belastningsforhold. |
| 3 | Sørg for, at specificeret belastning er tilgængelig, eller metode og værktøjer til at generere den krævede belastning er tydeligt nævnt i de respektive testtilfælde. |
| 4 | Nævn forudsætningen for hvert af scenarierne tydeligt, som de betingelser, der skulle være forud for belastningen på systemet, antallet af samtidige brugere osv., |
| 5 | Nævnningsværktøjer, der anbefales til at udføre den præstationstest, der er specifik for hver testkategori og for hver test. |
| 6 | Sørg for, at processen til overvågning af præstationsmålinger er nævnt tydeligt. |
Efter en vellykket afslutning af PQ er det meget vigtigt at opfylde præstationskravene, da enhver præstationsrelateret afvigelse kan forårsage et enormt forretningstab ved at skabe ubehag for brugeren, og tilliden til den software, der skal bruges, går tabt, hvilket fører til, at softwaren svigter.
I en nøddeskal, t nedenstående tabel opsummerer IQ-OQ-PQ-aktiviteterne.
| IQ | HVAD | PQ | |
|---|---|---|---|
| Hvad | For at kontrollere processen med softwareinstallation og hvordan processen er dokumenteret | For at kontrollere, at systemet fungerer korrekt | Kunder, ejere, leverandører, driftsteam |
| WHO | Kunder, ejere, leverandører, driftsteam | Kunder, ejere, leverandører, driftsteam | Kunder, ejere, leverandører, driftsteam |
| Hvor | På ejers websted, placering af driftsteam, live websted, prod-lignende miljø | På ejers websted, placering af driftsteam, live websted, prod-lignende miljø | På ejers websted, placering af driftsteam, live websted, prod-lignende miljø |
| Hvornår | Når softwaren modtages fra softwareteamet, før OQ og PQ. | Før systemet frigives til brug og efter vellykket afslutning af IQ | Før du sætter systemet i live og efter vellykket IQ, OQ-færdiggørelse |
Nedenstående tabel forklarer de forskellige input for hver valideringsfase.
| Type | Indgang |
|---|---|
| IQ | 1. Designspecifikationsdokument 2. Software-binære filer og andre installationsskripter 3. Dokument til installationsvejledningen 4. Konfigurationsvejledning Dokument 5. Byg verifikations- og røgtestdokument |
| HVAD | 1. Funktionelt specifikationsdokument 2. OQ-plandokument 3. Testdokument for operationel kvalifikation 4. OQ-testoversigtsskabelon 5. IQ afsluttet med succes |
| PQ | 1. URS-dokument (User Requirement Specification) 2. PQ-plandokument 3. Testdokument til præstationskvalifikation 4. Skabelon til rapportoversigt for PQ-test 5. IQ og OQ gennemført med succes |
Konklusion
Selvom produktet / softwaren har bestået alle verifikationsfaser og ikke kan bevise nogen af IQ-OQ-PQ, kan resultatet være katastrofalt og medføre enorme omkostninger. Derfor er vellykket gennemførelse af IQ-OQ-PQ alene den vellykkede overførsel af produktet fra udviklingsstedet til produktionsstedet.
Samlet set giver den vellykkede afslutning af IQ-OQ-PQ-valideringsprocessen ikke kun tilliden til softwaren, men giver også ro i sindet til klienten, ejeren, softwareudviklerne og testerne.
hvordan man bruger regex i c ++
Kørsel af IQ-OQ-PQ reducerer også risikoen for at anvende den til live uden at udføre test og reducerer omkostningerne ved fiasko og mindsker risikoen for tilbagekaldelse af produkterne.
Så fyre, softwareudviklere og testere, ingen fest efter at have gennemført udvikling og test internt og frigive softwaren til Ops Team. Fejringen er kun, når den med succes fuldender IQ-OQ-PQ, og softwaren er live på det målrettede system.
Derfor afhænger succesen af en software af en vellykket afslutning af IQ-OQ-PQ, og hvornår softwaren er live og klar til forbrug af slutbrugerne.
Om forfatteren: Denne artikel er skrevet af STH-teammedlem Gayathri Subrahmanyam. Hun har mere end 2 årtiers erfaring inden for softwaretest. I løbet af sin testkarriere har hun lavet en masse TMMI-vurderinger, testindustrialiseringsværker, TCOE-opsætninger ud over at håndtere testleverancer og implementeret DevOps-praksis for et kæmpe engagement. Men ifølge hende stopper læringen aldrig ...
Del dine erfaringer med udførelse af valideringsprocessen, og lad os vide, hvis du har spørgsmål om denne artikel.
Anbefalet læsning
- Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Software Testning QA Assistant Job
- Valg af softwaretest som din karriere
- Softwaretest Teknisk indhold Writer Freelancer Job
- Nogle interessante spørgsmål om software-test Interview
- Software Testing Course Feedback og anmeldelser
- Software Testing Hjælp Affiliate Program!