what are iq oq pq 3 q s software validation process
Úvod do IQ-OQ-PQ:
IQ, OQ a PQ představují 3Q procesu ověřování softwaru.
Jako testeři všichni víme, že vývojový tým softwaru vyvíjí software interně podle specifikace softwarových požadavků (SRS), funkční specifikace a později testovací tým ověřuje implementaci na různých úrovních testování v různých testovacích prostředích, od nejjednodušších po high-end, který tím replikuje produkční prostředí.
S tímto přístupem SDLC si tým pro vývoj softwaru obecně smývá ruce tím, že předává dokončený software (vyvinutý a ověřený) operačnímu týmu. Dále je to Operations Team (obecně označovaný jako Ops Team), který se stará o jeho nasazení do produkčního prostředí a připravuje jej k použití koncovými uživateli.
Nyní zde leží skutečná výzva pro operační tým, aby byl software funkční v produkčním prostředí, protože během fází vývoje softwaru byl vývoj a ověřování prováděno v simulovaném prostředí a velmi zřídka v blízkosti živého prostředí, pouze v v případě dostupnosti dat a konfigurací produkčního prostředí.
To je místo, kde se do obrazu dostává ověření softwaru. Jakmile je ověření dokončeno a software je odhlášen týmem programu / produktu, Ops Team by před přijetím softwaru, který má být nasazen do výroby, provedl řadu aktivit, aby prokázal, že se software chová podle očekávání, což není nic jiného než ověřovací činnosti.
Co se naučíte:
Ověření vs ověření
Zde jasně pochopíme rozdíl mezi činnostmi „Ověření“ a „Ověření“. '' Ověření „Je vyhodnotit software s ohledem na danou sadu požadavků a specifikací, které provádějí interně vývojáři a testeři v místě vývoje softwaru.
Zatímco ' Validace „Je soubor kontrol zajištění kvality, které provádějí externí zákazníci, majitelé, prodejci produktu, který jim je dodáván, za účelem ověření vhodnosti před přijetím nebo zakoupením produktu. Validační činnosti se většinou provádějí v místě výroby.
Proto v případě vývoje aplikace provádí Ops tým, který provádí validační aktivity pro software.
Přečtěte si také:
https://www.softwaretestinghelp.com/difference-b Between-verification-vs-validation/
Fáze procesu validace
Obecně se proces ověření jakéhokoli produktu týká úplného životního cyklu produktu od vývoje přes použití a údržbu. A proto je proces ověřování rozdělen do 5 fází.
5 fází procesu ověření je:
Tento 5fázový přístup procesu ověřování se používá v mnoha průmyslových odvětvích, jako je výroba, lékařství, farmaceutika atd. Zde bude ověření provedeno koncovým zákazníkem před zakoupením strojů, zařízení nebo produktu.
Součástí ověřovacích činností pro software je dokázat, že „je software připraven ke spotřebě uživateli“, a hlavně ověřit úspěšnou instalaci softwaru s následnou funkčností a funkčností.
Přístup 3Q: IQ-OQ-PQ
V kontextu softwaru však Přístup 3Q, IQ-OQ-PQ je sledován jako součást ověřování a bude prováděn operačním týmem, který je v konečném důsledku odpovědný za nasazení softwaru do výroby.
Níže je uveden vývojový diagram procesu ověřování:
Šablonu, plán a jakékoli další dokumenty, které jsou vstupem pro provádění 3Q, stanoví softwarový tým pro svůj software a obsahuje podrobný přístup, úkoly / činnosti / testy, které mají být provedeny jako součást těchto kvalifikací spolu s výsledky zkoušek.
Souhrnné zprávy budou předány Ops Team během předání softwaru spolu s binárními soubory a dalšími výstupy.
Na vysoké úrovni,
Celkově je účelem provádění IQ, OQ a PQ zajistit, aby bylo možné úspěšně nasadit software a používat všechny funkce bez jakýchkoli úzkých míst.
V ideálním případě jsou IQ, OQ a PQ sekvenční aktivity, které je třeba provést v pořadí. Pokud není instalace provedena, nelze funkčnost softwaru ověřit a pokud není funkčnost prokázána, nemá smysl měřit výkon. Někdy kvůli časovému omezení může PQ začít paralelně s OQ, jakmile budou stanoveny klíčové aspekty OQ.
Pojďme nyní podrobněji porozumět každé z těchto 3 fází.
Kvalifikace instalace (IQ)
Kvalifikace instalace označovaná také jako ‚IQ ' , je proces ověřování, zda lze dodaný software (binární soubory, skripty atd.) úspěšně nainstalovat do zadaného prostředí se zadanými konfiguracemi, a ověřit, jak jsou tyto kroky instalace zaznamenány v dokumentu nazvaném „Průvodce instalací“.
Následující položky jsou dodávány vývojovým týmem spolu s dodaným softwarovým balíčkem a jsou používány týmem Ops k provádění IQ.
1) Dokument „Průvodce instalací“, který dokumentuje kroky instalace ve vybraných prostředích.
2) Dokument „Průvodce konfigurací“ k nastavení konfigurovatelného softwaru. Někdy se tento dokument stane součástí samotného dokumentu instalačního průvodce.
3) Softwarový balíček a instalační skripty, nejlépe automatizované skripty.
Fáze kvalifikace instalace softwaru je považována za nejdůležitější a obvykle za mnoho problémů otevřeno během této fáze.
Protože:
na) Vývojové prostředí nebude mít k dispozici 100% prostředí v reálném čase k ověření problémů s instalací, a proto rozdíl v prostředí přispívá k několika problémům.
b) Z různých důvodů nemusí být vývoj a operační tým během počátečních fází vývoje softwaru dostatečný pro spolupráci a koordinaci, aby byly problémy vyřešeny v dostatečném předstihu.
C) Při nahrávání skutečných kroků instalace v dokumentu mohou nastat některé problémy s dokumentací, které se nemusí přesně shodovat v produkčním prostředí.
V dnešní době bude celý postup instalace softwaru co nejvíce automatizován pomocí řady skriptů. Pokud dojde k problémům s instalací, automatická instalace se nezdaří z důvodu chybné shody v konfiguracích a je třeba provést ruční zásah.
Jelikož tým Ops provádí IQ přísným dodržováním pokynů poskytnutých softwarovým týmem v instalační příručce, je velmi důležité a také odpovědností softwarového týmu zajistit, aby byl „instalační průvodce“ napsán tak, aby instalační kroky odpovídají prostředí v reálném čase.
Je odpovědností testerů zajistit, aby byl proces „instalace“ ověřen interně spolu s ověřením úplnosti dokumentu a identifikován případný nesoulad se skutečnými kroky, které mají být v systému spuštěny, oproti dokumentovaným krokům v Instalační příručka.
Při psaní instalačního průvodce a jejich interním ověřování je třeba mít na paměti následující body, aby se minimalizovaly problémy během instalace softwaru při výrobě.
| SNO | Body instalačního průvodce |
|---|---|
| 7 | Typický čas potřebný k instalaci softwaru by měl být uveden v Instalační příručce pro tým Ops, aby měl představu o přibližném načasování instalace, aby mohl odpovídajícím způsobem naplánovat své aktivity. |
| jeden | „Instalační příručka“ by měla být napsána v jednoduchém a snadno srozumitelném jazyce. |
| dva | Je třeba zajistit, aby nedošlo k dlouhým, více než 5 stránkám. Mělo by to být krátké a elegantní. |
| 3 | Je třeba uvést sériová čísla pro každý krok provedení, aby bylo možné sledovat jeho stav. |
| 4 | Automatizujte kroky co nejvíce a spojte je všechny do jednoho skriptu. |
| 5 | K zápisu instalační procedury je třeba použít standardní šablonu. |
| 6 | Měly by být jasně zmíněny předpoklady, aby se zabránilo zmeškání zápasu, a je třeba uvést kroky k jejich ověření. Pokud dojde k chybě, měl by být poskytnut návod, jak je dostat na očekávanou úroveň nebo nainstalovat tyto balíčky. |
| 8 | V příručce musí být jasně uvedeny služby, které je třeba během instalace snížit, jak je snížit, dopad jejich snížení. |
| 9 | Je třeba se vyhnout poskytování odkazů na jiné dokumenty a přecházet z jednoho dokumentu na druhý. Všechny potřebné informace by měly být zpřístupněny ve stejném dokumentu. Pokud je třeba odkázat na další dokumenty, dodejte je spolu se softwarovým balíčkem a na oplátku je třeba je odkázat v hlavních dokumentech. |
| 10 | Je třeba zajistit, aby název skriptu uvedeného v dokumentu byl stejný jako název skriptu zabaleného spolu s binárním souborem. |
| jedenáct | Mělo by se zajistit, že všechny skripty uvedené v dokumentu Instalační příručka jsou dodávány spolu s binárním souborem. |
| 12 | Zajistěte, aby všechny konfigurační parametry byly jasně uvedeny v Instalační příručce / Konfigurační příručce spolu s výchozími hodnotami a dalšími podporovanými hodnotami. |
| 13 | Měly by být dodány automatizované testy k provedení testů ověření sestavení po dokončení instalace softwaru. Musí být minimální a důležité, aby ověřili, že sestavení je úspěšně nainstalováno. |
| 14 | Je třeba dodat „kouřové testy“, aby bylo zajištěno, že propojení systému bude perfektní a všechny komponenty systému budou podle očekávání komunikovat. |
| patnáct | V případě selhání instalace softwaru jsou skripty vrácení vráceny spolu s balíčkem a postup vrácení zpět je jasně napsán v Instalační příručce, aby bylo možné provést vrácení zpět a úspěšně obnovit systém. |
Se všemi výše uvedenými body, které je třeba věnovat pozornost, je osvědčeným postupem automatizovat proces instalace softwaru s minimálním lidským zásahem, aby se předešlo lidským chybám.
Pokud během fáze ověřování IQ dojde k problémům, bude to nahlášeno softwarovému týmu, po jehož opravě, zkoušky kouře a ověřovací zkoušky sestavení bude provedena kontrola úspěšnosti instalace softwaru.
Fáze IQ tedy zahrnuje instalaci softwarového balíčku s následným provedením ověření sestavení a kouřových testů.
Úspěšné dokončení fáze IQ je tedy velmi důležité, protože úspěšná a správná instalace softwaru zajišťuje, že většina problémů souvisejících s poruchami funkcí bude negována.
Provozní kvalifikace (OQ)
Provozní kvalifikace, nazývaná také jako CO je další aktivita procesu validace softwaru po úspěšném dokončení IQ.
Činnost operační kvalifikace zahrnuje t testuje, aby byl spuštěn, aby se ověřilo, že software je provozně vhodný pro nasazení spotřebitelům. V ideálním případě jsou klíčové funkce softwaru ověřeny jako součást tohoto procesu ověřování.
Softwarový tým (testeři) musí připravit plán OQ pro provedení ověření OQ, který by měl zahrnovat všechny aspekty testování OQ, které je třeba provést, včetně podrobností jako ne. testů, harmonogram testů, metodologie, nástroje, dopad na službu, posloupnost provádění testů, způsob hlášení problémů a smlouvy SLA pro jejich řešení, přístup Defect Triage atd.,
Testy provozní kvalifikace, které jsou spouštěny jako součást OQ, jsou opět dodávány softwarovým týmem spolu se softwarovými výstupy. Tyto testy provozní kvalifikace jsou souborem důležitých testů, které jsou navrženy na základě dokumentu „Specifikace funkčních požadavků“, aby bylo zajištěno, že celý softwarový systém funguje podle očekávání.
Tento dokument se specifikací testu OQ připravují technici testu proti dokumentu se specifikací funkčních požadavků. Tento dokument bude často podmnožinou dokumentu Specifikace testu systému připraveného a ověřeného během fáze testování systému SDLC.
Testy mohou být pozměněny nebo aktualizovány tak, aby vyhovovaly požadavkům operačního týmu a podmínkám místa, kde budou provedeny.
Při výběru testů, které jsou součástí OQ, je proto třeba věnovat zvýšenou pozornost, aby bylo zajištěno, že všechny klíčové funkce a hlavní obchodní pracovní postupy budou zahrnuty jako součást tohoto ověření.
Níže jsou uvedeny tipy pro testery při přípravě dokumentu specifikace testu OQ.
| Sno | Tipy pro testery při přípravě dokumentu Specifikace testu OQ |
|---|---|
| 7 | Není třeba zahrnout testovací případy související s hraniční hodnotou, která ověří extrémní hodnoty, ale jako vstupy použijte nejběžnější každodenně používané hodnoty, kdykoli je to nutné. |
| jeden | Zajistěte, aby byly v dokumentu OQ Test Spec k dispozici testy klíčových funkcí, které dokážou, že jsou vybrány a zahrnuty očekávané funkce softwaru, a proto je pro každý z písemných testovacích případů k dispozici nezbytná sledovatelnost. |
| dva | Zajistěte, aby byly testy úhledně napsány krok za krokem, byly samy vysvětlující a aby jim rozuměl obyčejný člověk. |
| 3 | Nepoužívejte v žádném případě co nejvíce technické výrazy v testovacích případech, protože uživatel tohoto dokumentu nemusí o těchto terminologiích vědět. E, že použitá testovací data již v systému neexistují. Poskytněte více sad dat, pokud chce uživatel testovací případy provést vícekrát. |
| 4 | Jasně uveďte povinné a volitelné předpoklady pro každý z testů. |
| 5 | Zahrňte většinu pozitivních testovacích případů k ověření funkčnosti. |
| 6 | Zahrňte velmi málo negativních testovacích případů, abyste zajistili, že chování softwaru bude podle očekávání v případě irelevantního vstupu a systém je schopen úspěšně zvládnout negativní případy. |
| 8 | Pokud je třeba změnit výchozí hodnoty, uveďte konfigurační hodnoty, které se mají nastavit. |
| 9 | Poskytněte automatické testovací případy, které mají být spuštěny, kdekoli jsou k dispozici. Předtím se ujistěte, že tyto automatizační skripty lze spustit v systému, kde se plánuje OQ. |
| 10 | Zajistěte, aby každý testovací případ měl jako referenci jasné výsledky „Očekávané“ a „Skutečné“. A v případě potřeby přidejte jakékoli komentáře k vysvětlení skutečného výsledku. |
| jedenáct | Je také nutné zahrnout „kritéria přijetí“ pro každý z testovacích případů. Kritériem přijetí může být stav systému po provedení testovacích případů. |
| 12 | Zadejte přesně „zkušební data“, která se použijí pro každý z testů. Zkuste zadat nejběžnější data ze živého přenosu. A také několik výjimečných dat, aby bylo zajištěno, že systém zvládne i výjimečné případy. Ujistěte se, že použitá testovací data již v systému neexistují. Poskytněte více sad dat, pokud chce uživatel testovací případy provést vícekrát. |
| 13 | Pokud paralelně spouští testy z různých míst více provozních uživatelů, poskytněte instrukci k odpovídajícímu provedení testování s jinou sadou dat. |
| 14 | Poskytněte kontrolní seznamy, kdykoli je to nutné, abyste zajistili, že všechny konfigurace, předpoklady jsou nastaveny podle očekávání před spuštěním testů. |
| patnáct | Pokud jsou k dispozici přístup do systému, neustále sledujte protokoly, když jsou testy spuštěny. |
| 16 | Je-li to možné a nutné, poskytněte operačním uživatelům podporu provádění během provádění těchto testovacích případů. |
| 17 | Vysvětlete způsob hlášení problémů nalezený během provádění. Ke sledování problémů je lepší použít nástroj pro sledování chyb. Pečlivě sledujte každý problém a ukončete jej podle dohodnuté smlouvy SLA. |
| 18 | Spusťte program „Defect Triages“ zahrnující držitele práv, abyste pochopili kritické a závažné problémy a poskytovali o nich často aktuální informace. |
| 19 | Poskytněte závěrečnou šablonu „Souhrnná zpráva o provedení testu OQ“, která zveřejní konečné výsledky po dokončení provádění. |
Takto připravený plán OQ a specifikace testu by měly být důkladně zkontrolovány a podepsány příslušnými zúčastněnými stranami, aby bylo zajištěno, že pokrytí není příliš nízké nebo příliš velké a jsou pokryty všechny klíčové funkce.
Úspěšné dokončení OQ ukazuje, že software bude ve zvoleném prostředí fungovat podle jeho provozních specifikací a je to brána v posunu softwaru směrem k jeho výrobě a je to signál k pokračování další činnosti procesu ověřování, který je PQ .
Performance Qualification (PQ)
Po zajištění úspěšného IQ, dokončení OQ je další činností v procesu ověřování zajistit, aby produkt / software splňoval specifikované aspekty výkonu pod očekávanou zátěží důsledně, aniž by docházelo k překážkám v produkčním prostředí.
Klíčovým aspektem PQ je zajistit, aby software po instalaci do očekávaného systému zvládne živé zatížení a splní očekávanou dobu odezvy a při manipulaci se souběžnými uživateli nespadne pod špičkovým zatížením a stresem.
Proto PQ je hlavně zajistit, aby bylo dosaženo stanovených výkonnostních kritérií pro software po určitou dobu (možná týden) na spolehlivém základě s měnícími se podmínkami zátěže, jako je tomu v reálném čase. Tyto testy proto musí být prováděny každý den, aby bylo možné sledovat chování softwarového systému, a proto bude PQ chvíli trvat, než bude zajištěno, že je systém ověřen pro svůj výkon.
V ideálním případě se ověření PQ provádí po dokončení OQ, kde je zajištěna funkčnost softwaru a může pokračovat v ověřování aspektu výkonu produktu nebo softwaru. Někdy kvůli časovému omezení může PQ začít paralelně s OQ, na základě důvěry v procento dokončení OQ.
Ideální je provádět tyto testy výkonu na živém systému s plně načteným systémem nebo za podobných podmínek, jako je živé, a zajistit, aby v aspektech výkonu neexistovala žádná úzká místa.
Následující testy se obvykle spouštějí jako součást Kvalifikace výkonu. A výběr testů se liší od softwaru k softwaru.
# 1) Test dostupnosti: Zajistit, aby byl software neustále k dispozici, aniž by došlo ke zhroucení nebo pádu.
# 2) Test přístupnosti: Zajistit, aby byl software bez problémů snadno přístupný z jakéhokoli místa s očekávanou rychlostí výkonu.
# 3) Zátěžový test: Měřit chování systému při předpokládaném každodenním zatížení a také podmínkách špičkového zatížení.
# 4) Zátěžový test: Měření bodu zlomu systému za podmínek extrémního zatížení.
# 5) Test výkonu propustnosti: Měření doby odezvy systému a měření TPS (transakce za sekundu)
# 6) Testování škálovatelnosti: Systém lze škálovat tak, aby zvládl očekávané souběžné uživatele.
Scénáře testování výkonu a odpovídající automatické skripty se připravují na základě požadavků týkajících se výkonu uvedených v dokumentech „Specifikace požadavků uživatele“.
Podobně jako plán OQ by měl být připraven podrobný plán PQ, který jasně stanoví testovací přístup, strategii, plán a plán spolu s nástroji, a projít s exekutory PQ.
Nástroj pro testování a monitorování výkonu je třeba nainstalovat do prostředí, kde se provádí PQ, aby bylo možné měřit a vykazovat metriky výkonu.
Níže jsou uvedeny tipy pro testery, jak umožnit operačnímu týmu úspěšně provést PQ.
| Sno | Tipy pro testery k povolení operačního týmu |
|---|---|
| 7 | Průvodce, podpora a školení operačního týmu k provádění testování výkonu v systému. |
| jeden | Připravte klíčové podnikové scénáře k provedení testování výkonu na základě URS. |
| dva | Zajistěte, aby byly zahrnuty testy, které dokážou, že systém splňuje očekávání doby odezvy, rychlosti, škálovatelnosti a stability za různých podmínek načítání. |
| 3 | Zajistěte, aby bylo k dispozici zadané zatížení nebo aby byly v příslušných testovacích případech jasně uvedeny metody a nástroje pro generování požadovaného zatížení. |
| 4 | Jasně uveďte předpoklady pro každý scénář, jako jsou podmínky předběžného načtení, které by v systému měly existovat, počet souběžných uživatelů atd., |
| 5 | Uveďte nástroje, které se doporučují použít k provedení testování výkonnosti specifické pro každou kategorii testu a pro každý test. |
| 6 | Zajistěte, aby byl jasně uveden proces monitorování metrik výkonu. |
Po úspěšném dokončení PQ je splnění výkonnostních požadavků velmi důležité, protože jakékoli odchylky související s výkonem mohou způsobit obrovskou obchodní ztrátu tím, že vytvoří nepohodlí pro uživatele a dojde ke ztrátě důvěry v software, který bude používán, což povede k selhání softwaru.
Stručně řečeno, t níže uvedená tabulka shrnuje aktivity IQ-OQ-PQ.
| IQ | CO | PQ | |
|---|---|---|---|
| Co | Chcete-li ověřit proces instalace softwaru a jak je tento proces dokumentován | Ověření správného fungování systému | Zákazníci, majitelé, prodejci, provozní tým |
| SZO | Zákazníci, majitelé, prodejci, provozní tým | Zákazníci, majitelé, prodejci, provozní tým | Zákazníci, majitelé, prodejci, provozní tým |
| Kde | Na webu vlastníků, umístění provozního týmu, živém webu, prostředí jako pro výrobce | Na webu vlastníků, umístění provozního týmu, živém webu, prostředí jako pro výrobce | Na webu vlastníků, umístění provozního týmu, živém webu, prostředí jako pro prodávající |
| Když | Když je software přijat od softwarového týmu, před OQ a PQ. | Před uvolněním systému do provozu a po úspěšném dokončení IQ | Před uvedením systému do provozu a po úspěšném IQ, dokončení OQ |
Níže uvedená tabulka vysvětluje různé vstupy pro každou z fází ověřování.
| Typ | Vstup |
|---|---|
| IQ | 1. Dokument se specifikací návrhu 2. Softwarové binární soubory a další instalační skripty 3. Instalační příručka 4. Dokument Průvodce konfigurací 5. Sestavte dokument o ověření a kouřovém testu |
| CO | 1. Dokument funkční specifikace 2. Dokument plánu OQ 3. Dokument o provozní kvalifikační zkoušce 4. Šablona souhrnné zprávy o testu OQ 5. IQ úspěšně dokončeno |
| PQ | 1. Dokument URS (Specifikace požadavku uživatele) 2. Dokument plánu PQ 3. Dokument o zkoušce kvalifikace výkonu 4. Šablona souhrnné zprávy o testu PQ 5. IQ a OQ byly úspěšně dokončeny |
Závěr
I když produkt / software prošel všemi fázemi ověření a neprokáže žádnou z IQ-OQ-PQ, výsledek může být katastrofální a bude znamenat obrovské náklady. Samotné úspěšné dokončení IQ-OQ-PQ je tedy úspěšný přenos produktu z místa vývoje do místa výroby.
Celkově lze říci, že úspěšné dokončení procesu validace IQ-OQ-PQ poskytuje nejen důvěru v software, ale také dává klid klientovi, majiteli, vývojářům softwaru a testerům.
otázky k rozhovoru na c ++
Spuštění IQ-OQ-PQ také snižuje riziko jeho nasazení do provozu, aniž by bylo nutné provádět testování, a snižuje náklady na selhání a snižuje riziko stažení produktů.
Takže, lidi, vývojáři softwaru a testeři, žádná oslava po dokončení interního vývoje a testování a vydání softwaru Ops Team. Oslava je pouze tehdy, když úspěšně dokončí IQ-OQ-PQ a software je aktivní v cílovém systému.
Úspěch softwaru tedy závisí na úspěšném dokončení IQ-OQ-PQ a na tom, kdy je software aktivní a připravený ke spotřebě koncovými uživateli.
O autorovi: Tento článek napsal člen týmu STHGayathri Subrahmanyam. Má více než 2 desetiletí zkušeností v oblasti testování softwaru. Během své testovací kariéry absolvovala řadu testů TMMI, testovala industrializační práce, nastavení TCOE, kromě zpracování testovacích dodávek a implementovala praxi DevOps pro velké zapojení. Ale podle ní se učení nikdy nezastaví ...
Podělte se o své zkušenosti s prováděním procesu ověřování a dejte nám vědět, pokud máte ohledně tohoto článku nějaké dotazy.
Doporučené čtení
- Kurz testování softwaru: Ke kterému institutu pro testování softwaru bych se měl připojit?
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Úloha pomocníka QA při testování softwaru
- Výběr testování softwaru jako vaší kariéry
- Práce na volné noze se softwarem pro testování technického obsahu Writer
- Některé zajímavé otázky týkající se testování softwaru
- Zpětná vazba a recenze kurzu testování softwaru
- Testování softwaru Pomoc Partnerský program!