what are iq oq pq 3 q s software validation process
Úvod do IQ-OQ-PQ:
IQ, OQ a PQ tvoria 3Q procesu overovania softvéru.
Ako testeri všetci vieme, že tím pre vývoj softvéru vyvíja softvér interne podľa špecifikácie softvérových požiadaviek (SRS), funkčných špecifikácií a neskôr testovací tím overuje implementáciu na rôznych úrovniach testovania v rôznych testovacích prostrediach, od najjednoduchších po high-end, ktorý tým replikuje produkčné prostredie.
S týmto prístupom SDLC si tím pre vývoj softvéru všeobecne zmýva ruky odovzdaním dokončeného softvéru (vyvinutého a overeného) operačnému tímu. Ďalej je to Operations Team (všeobecne označovaný ako Ops Team), ktorý sa stará o jeho nasadenie do produkčného prostredia a pripravuje ho na použitie koncovými používateľmi.
Teraz tu leží skutočná výzva pre operačný tím, aby bol softvér funkčný v produkčnom prostredí, pretože počas fáz vývoja softvéru sa vývoj a overovanie uskutočňovali v simulovanom prostredí a veľmi zriedka v blízkosti živého prostredia, iba v prípade dostupnosti údajov a konfigurácií produkčného prostredia.
To je miesto, kde prichádza na rad validácia softvéru. Po dokončení overenia a odhlásení softvéru tímom programu / produktu vykoná tím Ops pred prijatím softvéru, ktorý sa má nasadiť do výroby, súbor aktivít, aby dokázal, že softvér sa chová podľa očakávania, čo nie je nič iné ako overovacie činnosti.
Čo sa dozviete:
Verifikácia vs Validácia
Tu jasne pochopíme rozdiel medzi aktivitami „Overenie“ a „Overenie“. „ Overenie „Je vyhodnotiť softvér s ohľadom na daný súbor požiadaviek a špecifikácií, ktoré vývojári a testéri vykonávajú interne na mieste vývoja softvéru.
Keďže „ Validácia „Je súbor kontrol zabezpečenia kvality, ktoré vykonávajú externí zákazníci, vlastníci alebo predajcovia dodaného produktu s cieľom skontrolovať vhodnosť pred prijatím alebo zakúpením produktu. Validačné činnosti sa väčšinou vykonávajú na výrobnom mieste.
Preto v prípade vývoja aplikácií vykonáva činnosti overovania softvéru Ops tím.
Prečítajte si tiež:
https://www.softwaretestinghelp.com/difference-b Between-verification-vs-validation/
Fázy procesu validácie
Proces validácie ľubovoľného produktu sa vo všeobecnosti vzťahuje na celý životný cyklus produktu od vývoja po použitie a údržbu. Proces validácie je teda rozdelený do 5 fáz.
5 fáz procesu validácie je:
Tento 5fázový prístup procesu validácie sa uplatňuje v mnohých priemyselných odvetviach, ako je výroba, medicína, farmaceutický priemysel atď. Overenie tu vykoná koncový zákazník pred zakúpením stroja, zariadenia alebo produktu.
Súčasťou validačných aktivít pre softvér je preukázanie, že „softvér je pripravený na spotrebu používateľom“, a hlavne overenie úspešnej inštalácie softvéru, po ktorom nasleduje funkčnosť a funkčnosť.
Prístup 3Q: IQ-OQ-PQ
V softvérovom kontexte však Prístup 3Q, IQ-OQ-PQ sa sleduje ako súčasť overovania a bude ju vykonávať operačný tím, ktorý je v konečnom dôsledku zodpovedný za nasadenie softvéru do výroby.
Ďalej je uvedený vývojový diagram procesu validácie:
Šablónu, plán a akékoľvek ďalšie dokumenty, ktoré sa vstupujú do vykonávania 3Q, vypracuje softvérový tím pre svoj softvér a obsahuje podrobný prístup, úlohy / činnosti / testy, ktoré sa majú vykonať ako súčasť týchto kvalifikácií spolu s výsledkami skúšky.
Súhrnné správy budú odovzdané Ops Teamu počas odovzdávania softvéru spolu s binárnymi súbormi a ďalšími dokumentmi.
Na vysokej úrovni,
Celkovo je účelom vykonávania IQ, OQ a PQ zabezpečiť, aby bolo možné softvér úspešne nasadiť a využívať všetky funkcie bez akýchkoľvek prekážok.
V ideálnom prípade sú IQ, OQ a PQ postupné činnosti, ktoré je potrebné vykonať v poradí. Pokiaľ nie je inštalácia vykonaná, nie je možné overiť funkčnosť softvéru a pokiaľ nie je funkčnosť preukázaná, nemá zmysel meranie výkonu. Niekedy z dôvodu časovej tiesne môže PQ začať paralelne s OQ, akonáhle sa stanovia kľúčové aspekty OQ.
Poďme si teraz podrobnejšie uvedomiť každú z týchto 3 fáz.
Kvalifikácia na inštaláciu (IQ)
Kvalifikácia inštalácie sa tiež označuje ako „IQ“ , je proces overovania, či je možné dodaný softvér (binárne súbory, skripty atď.) úspešne nainštalovať do zadaného prostredia so zadanými konfiguráciami, a overiť, ako sú tieto kroky inštalácie zaznamenané v dokumente nazvanom „Sprievodca inštaláciou“.
Nasledujúce položky dodáva vývojový tím spolu s dodávaným softvérovým balíkom a sú používané tímom Ops na uskutočnenie IQ.
1) Dokument „Sprievodca inštaláciou“, ktorý dokumentuje kroky inštalácie vo vybraných prostrediach.
dva) V dokumente „Sprievodca konfiguráciou“ sa nachádza konfigurovateľný softvér. Niekedy sa tento dokument stane súčasťou samotného dokumentu Sprievodca inštaláciou.
3) Softvérový balík a inštalačné skripty, najlepšie automatizované skripty.
Fáza kvalifikácie inštalácie softvéru sa považuje za najdôležitejšiu a zvyčajne za veľa problémov otvorené počas tejto fázy.
Pretože:
do) Vývojové prostredie nebude mať k dispozícii 100% prostredie v reálnom čase na overenie problémov s inštaláciou, a preto rozdiel v prostredí prispieva k niekoľkým problémom.
b) Z rôznych dôvodov nemusí byť vývojový a operačný tím v počiatočných fázach vývoja softvéru dostatočný na spoluprácu a koordináciu na zvládnutie problémov v dostatočnom predstihu.
c) Pri zaznamenávaní skutočných krokov inštalácie do dokumentu sa môžu vyskytnúť problémy s dokumentáciou, ktoré sa v produkčnom prostredí nemusia presne zhodovať.
V dnešnej dobe bude celý postup inštalácie softvéru čo najviac automatizovaný pomocou série skriptov. Ak sa vyskytnú problémy s inštaláciou, automatická inštalácia zlyhá z dôvodu nezhody v konfiguráciách a je potrebný manuálny zásah.
Pretože tím Ops vykonáva IQ dôsledným dodržiavaním pokynov poskytnutých softvérovým tímom v inštalačnej príručke, je veľmi dôležité a tiež zodpovednosťou softvérového tímu zabezpečiť, aby bol „inštalačný sprievodca“ napísaný tak, aby kroky inštalácie zodpovedajú prostrediu v reálnom čase.
Zodpovednosťou testerov je zabezpečiť, aby bol proces „inštalácie“ overený interne spolu s overením úplnosti dokumentu, a identifikovať prípadné nezhody so skutočnými krokmi, ktoré sa majú v systéme spustiť, oproti zdokumentovaným krokom v dokumente. Návod na inštaláciu.
Pri písaní Inštalačnej príručky a ich vnútornom overovaní je potrebné mať na pamäti nasledujúce body, aby sa minimalizovali problémy počas inštalácie softvéru pri výrobe.
| SNO | Body sprievodcu inštaláciou |
|---|---|
| 7 | Typický čas potrebný na inštaláciu softvéru by mal byť uvedený v Inštalačnej príručke pre tím Ops, aby ste mali predstavu o približnom načasovaní inštalácie, aby ste mohli zodpovedajúcim spôsobom naplánovať svoje činnosti. |
| 1 | „Sprievodca inštaláciou“ by mal byť napísaný v jednoduchom a ľahko pochopiteľnom jazyku. |
| dva | Je potrebné zabezpečiť, aby to nezaberalo dlhé, viac ako 5 strán. Mal by byť krátky a upravený. |
| 3 | Je potrebné uviesť sériové čísla pre každý krok vykonania, aby bolo možné sledovať jeho stav. |
| 4 | Kroky čo najviac zautomatizujte a všetky spojte do jedného skriptu. |
| 5 | Na zápis postupu inštalácie by sa mala použiť štandardná šablóna. |
| 6 | Mali by sa jasne uviesť predpoklady, aby sa zabránilo vynechaniu zápasu, a je potrebné uviesť kroky na ich overenie. Ak dôjde k nezhode, mal by sa poskytnúť pokyn na ich uvedenie na očakávanú úroveň alebo na inštaláciu týchto balíkov. |
| 8 | V príručke musia byť jasne uvedené služby, ktoré je potrebné pri inštalácii znížiť, ako ich znížiť, vplyv ich zníženia. |
| 9 | Je potrebné vyhnúť sa poskytovaniu odkazov na iné dokumenty a prechádzať z jedného dokumentu na druhý. Všetky potrebné informácie by mali byť sprístupnené v rovnakom dokumente. Ak je potrebné odkázať na ďalšie dokumenty, dodajte ich spolu so softvérovým balíkom a na druhej strane je potrebné odkázať na ne v hlavných dokumentoch. |
| 10 | Je potrebné zabezpečiť, aby názov skriptu uvedeného v dokumente bol rovnaký ako názov skriptu zabaleného spolu s binárnym súborom. |
| jedenásť | Malo by sa zabezpečiť, aby všetky skripty uvedené v dokumente Sprievodca inštaláciou boli dodané spolu s binárnym súborom. |
| 12 | Zaistite, aby všetky konfiguračné parametre boli jasne uvedené v Sprievodcovi inštaláciou / Sprievodcom konfiguráciou spolu s predvolenými hodnotami a ďalšími podporovanými hodnotami. |
| 13 | Mali by byť dodané automatizované testy na vykonanie testov verifikácie zostavy po dokončení inštalácie softvéru. Musí ich byť minimálny počet a musia byť dôležité, aby overili, že zostavenie je úspešne nainštalované. |
| 14 | Je potrebné dodať „dymové testy“, ktoré zabezpečia dokonalé pripojenie systému k dokonalosti a všetky komponenty systému medzi sebou komunikujú podľa očakávania. |
| pätnásť | V prípade zlyhania inštalácie softvéru sú spolu s balíkom dodané skripty vrátenia zmien a postup vrátenia je jasne napísaný v Sprievodcovi inštaláciou, aby sa vrátenie späť a úspešná obnova systému úspešne vykonali. |
So všetkými vyššie uvedenými bodmi, ktoré je potrebné venovať pozornosť, je najlepším postupom automatizovať proces inštalácie softvéru s minimálnym ľudským zásahom, aby sa zabránilo ľudským chybám.
Ak sa vo fáze overovania IQ vyskytnú nejaké problémy, bude to nahlásené softvérovému tímu, po vyriešení ktorého skúšky dymu a overovacie skúšky sa uskutoční kontrola úspešnosti inštalácie softvéru.
Fáza IQ preto zahŕňa inštaláciu softvérového balíka a následné overenie zostavenia a dymové testy.
Úspešné dokončenie fázy IQ je teda veľmi dôležité, pretože úspešná a správna inštalácia softvéru zaisťuje, že väčšina problémov súvisiacich so zlyhaním funkčnosti bude negovaná.
Prevádzková kvalifikácia (OQ)
Prevádzková kvalifikácia, nazývaná tiež ako ČO je ďalšou aktivitou procesu validácie softvéru po úspešnom dokončení IQ.
Do činnosti prevádzkovej kvalifikácie patrí t testuje, aby sa spustili s cieľom overiť, či je softvér operatívne vhodný na nasadenie zákazníkom. V ideálnom prípade sú kľúčové funkčnosti softvéru overené ako súčasť tohto procesu overovania.
Softvérový tím (testéri) musí pripraviť plán OQ na vykonanie overenia OQ, ktorý by mal pokrývať všetky aspekty testovania OQ, ktoré je potrebné vykonať, vrátane podrobností ako č. testov, harmonogram testov, metodika, nástroje, vplyv na službu, postupnosť vykonávania testov, metóda hlásenia problémov a SLA na ich odstránenie, prístup Defect Triage atď.,
Testy prevádzkovej kvalifikácie, ktoré sa vykonávajú ako súčasť OQ, sú opäť dodávané softvérovým tímom spolu so softvérovými výstupmi. Tieto testy prevádzkovej kvalifikácie sú súborom dôležitých testov, ktoré sú navrhnuté na základe dokumentu „Špecifikácia funkčných požiadaviek“, aby sa zabezpečilo, že celý softvérový systém funguje podľa očakávania.
Tento dokument so špecifikáciou testu OQ pripravujú technici testu proti dokumentu so špecifikáciou funkčných požiadaviek. Tento dokument bude často podmnožinou dokumentu Specification System Test Specification, ktorý sa pripravuje a overuje počas fázy testovania systému SDLC.
Testy môžu byť zmenené alebo aktualizované tak, aby vyhovovali požiadavkám operačného tímu a podmienkam miesta, kde sa budú vykonávať.
Pri výbere testov, ktoré sú súčasťou OQ, by sa preto mala venovať zvýšená pozornosť výberu, aby sa zabezpečilo, že súčasťou tohto overenia budú všetky kľúčové funkcie a hlavné obchodné pracovné toky.
Nasledujú tipy pre testerov pri príprave dokumentu so špecifikáciami testu OQ.
| Sno | Tipy pre testerov pri príprave dokumentu so špecifikáciami testu OQ |
|---|---|
| 7 | Nie je potrebné zahrnúť testovacie prípady týkajúce sa hraničnej hodnoty, ktoré overia extrémne hodnoty, ale ako vstupy sa budú používať najbežnejšie dennodenné hodnoty, kedykoľvek to bude potrebné. |
| 1 | Zaistite, aby boli vybrané a zahrnuté kľúčové testy funkčnosti, ktoré dokazujú, že sú vybrané softvérové funkcie podľa očakávania, a preto je v dokumente OQ Test Spec k dispozícii nevyhnutná vysledovateľnosť pre každý z písomných testovacích prípadov. |
| dva | Zaistite, aby boli testy prehľadne napísané krok za krokom, boli samovysvetľujúce a boli pochopiteľné pre bežného človeka. |
| 3 | V testovacích prípadoch sa v maximálnej možnej miere neodporúčajte používať žiadne technické výrazy alebo sa im vyhýbajte, pretože používateľ tohto dokumentu nemusí vedieť o týchto terminológiách. E, že použité testovacie údaje v systéme už neexistujú. Poskytnite viac množín údajov, ak chce používateľ vykonať testovacie prípady viackrát. |
| 4 | Jasne uveďte povinné a voliteľné predpoklady pre každý z testov. |
| 5 | Zahrňte väčšinu pozitívnych testovacích prípadov na overenie funkčnosti. |
| 6 | Zahrňte veľmi málo negatívnych testovacích prípadov, aby ste sa uistili, že správanie softvéru je očakávané v prípade irelevantného vstupu a systém je schopný úspešne zvládnuť negatívne prípady. |
| 8 | Ak je potrebné zmeniť predvolené hodnoty, uveďte konfiguračné hodnoty, ktoré sa majú nastaviť. |
| 9 | Poskytnite spustené automatizované testovacie prípady, kedykoľvek sú k dispozícii. Predtým sa uistite, že tieto automatizačné skripty je možné spustiť v systéme, kde sa plánuje OQ. |
| 10 | Zaistite, aby mali každý testovací prípad ako referenciu jasné výsledky „Očakávané“ a „Skutočné“. A ak je to potrebné, pridajte akékoľvek vysvetlenie, aby ste vysvetlili skutočný výsledok. |
| jedenásť | Je tiež potrebné zahrnúť „kritériá prijatia“ pre každý z testovacích prípadov. Kritériom prijatia môže byť stav systému po vykonaní testovacích prípadov. |
| 12 | Zadajte „testovacie údaje“, ktoré sa majú presne použiť pri každom z testov. Skúste zadať najbežnejšie údaje zo živého vysielania. A tiež niekoľko výnimočných údajov, aby sa zabezpečilo, že systém zvládne aj výnimočné prípady. Zaistite, aby použité testovacie údaje ešte v systéme neexistovali. Poskytnite viac množín údajov, ak chce používateľ vykonať testovacie prípady viackrát. |
| 13 | Ak súbežne spúšťajú testy z rôznych miest viacerí prevádzkovaní používatelia, vykonajte inštrukcie na vykonávanie zodpovedajúceho testovania s rôznymi súbormi údajov. |
| 14 | Ak je to potrebné, poskytnite kontrolné zoznamy, aby ste sa ubezpečili, že všetky konfigurácie a predpoklady sú pred spustením testov nastavené podľa očakávania. |
| pätnásť | Ak sú k dispozícii prístupy do systému, priebežne sledujte protokoly, keď prebiehajú testy. |
| 16 | Ak je to možné a požadované, poskytnite operačným používateľom podporu vykonania počas vykonávania týchto testovacích prípadov. |
| 17 | Vysvetlite spôsob hlásenia problémov zistený počas vykonávania. Na sledovanie problémov je lepšie použiť nástroj na sledovanie chýb. Starostlivo sledujte každý problém a ukončite ho podľa dohodnutej dohody SLA. |
| 18 | Spustite program „Defect Triages“, do ktorého sú zapojené správne subjekty, aby ste pochopili kritické a závažné problémy a pravidelne o nich poskytovali informácie. |
| 19 | Poskytnite záverečnú šablónu „Súhrnná správa o vykonaní testu OQ“ na zverejnenie konečných výsledkov po dokončení vykonania. |
Takto pripravený plán OQ a špecifikácia testu by mali byť dôkladne preskúmané a podpísané príslušnými zainteresovanými stranami, aby sa zabezpečilo hlavne to, že pokrytie nie je príliš malé alebo príliš veľké a sú pokryté všetky kľúčové funkcie.
Úspešné dokončenie OQ ukazuje, že softvér bude vo zvolenom prostredí fungovať podľa prevádzkových špecifikácií a je vstupnou bránou pri posúvaní softvéru smerom k jeho výrobe a je signálom pre pokračovanie v ďalšej aktivite procesu validácie, ktorá je PQ .
Výkonová kvalifikácia (PQ)
Po zaistení úspešného IQ je dokončenie OQ ďalšou aktivitou v procese overovania zabezpečenie, či produkt / softvér spĺňa špecifikované aspekty výkonu pri očakávanom zaťažení dôsledne bez toho, aby spôsoboval prekážky v produkčnom prostredí.
Kľúčovým aspektom PQ je zabezpečiť, aby softvér, keď je nainštalovaný v očakávanom systéme, dokáže spracovať živé zaťaženie a splniť očakávaný čas odozvy a pri manipulácii so súčasnými používateľmi nezarazí pri špičkových zaťaženiach a strese.
Preto PQ spočíva hlavne v zabezpečení, či sa stanovené výkonnostné kritériá pre softvér dosahujú spoľahlivo na určitom období (možno aj týždni) s meniacimi sa podmienkami zaťaženia, ako je tomu v živom prostredí. Preto tieto testy musia byť vykonávané každý deň, aby sa dalo monitorovať chovanie softvérového systému, a preto bude PQ chvíľu trvať, kým sa zaistí, že systém bude testovaný na svoju výkonnosť.
V ideálnom prípade sa PQ validácia vykonáva po dokončení OQ, kde je zabezpečená funkčnosť softvéru a môže pokračovať v overovaní výkonového aspektu produktu alebo softvéru. Niekedy z dôvodu časového obmedzenia môže PQ začať paralelne s OQ na základe dôvery v percento dokončenia OQ.
Ideálne je vykonať tieto výkonnostné testy na živom systéme s plne naloženým systémom alebo za podobných podmienok, ako sú živé a zabezpečiť, aby z hľadiska výkonu neexistovali úzke miesta.
Nasledujúce testy sa spravidla vykonávajú ako súčasť Kvalifikácie výkonu. A výber testov sa líši od softvéru k softvéru.
# 1) Test dostupnosti: Zaisťuje, že softvér je nepretržite k dispozícii bez pádu alebo pádu.
# 2) Test prístupnosti: Zaisťuje, aby bol softvér bez problémov ľahko prístupný z každého miesta s očakávanou rýchlosťou výkonu.
# 3) Test zaťaženia: Merať správanie systému pri predpokladanom každodennom zaťažení a tiež podmienkach špičkového zaťaženia.
# 4) Stresový test: Na meranie bodu zlomu systému pri extrémnych podmienkach zaťaženia.
# 5) Test výkonu priepustnosti: Na meranie času odozvy systému a na meranie TPS (transakcie za sekundu)
# 6) Testovanie škálovateľnosti: Systém sa dokáže škálovať tak, aby zvládol očakávaných súbežných používateľov.
Scenáre výkonu a príslušné automatizované skripty sa pripravujú na základe výkonových požiadaviek uvedených v dokumentoch „Špecifikácia užívateľských požiadaviek“.
Podobne ako plán OQ, aj podrobný plán PQ, ktorý jasne uvádza prístup, stratégiu, plán a plán testovania spolu s nástrojmi, by mal byť pripravený a prevedený spolu s exekútormi PQ.
Nástroj na testovanie a monitorovanie výkonu je potrebné inštalovať v prostredí, kde sa vykonáva PQ, aby sa mohli merať a vykazovať metriky výkonu.
Nasledujú tipy pre testerov, ako umožniť operačnému tímu úspešne vykonať PQ.
| Sno | Tipy pre testerov na povolenie operačného tímu |
|---|---|
| 7 | Sprievodca, podpora a výcvik operačného tímu na vykonávanie testovania výkonnosti v systéme. |
| 1 | Pripravte kľúčové podnikové scenáre na vykonanie testovania výkonnosti na základe URS. |
| dva | Zaistite, aby boli zahrnuté testy, ktoré dokazujú, že systém spĺňa očakávania týkajúce sa doby odozvy, rýchlosti, škálovateľnosti a stability pri rôznych podmienkach zaťaženia. |
| 3 | Zaistite, aby bolo k dispozícii špecifikované zaťaženie alebo aby boli v príslušných testovacích prípadoch jasne uvedené metódy a nástroje na generovanie požadovaného zaťaženia. |
| 4 | Jasne uveďte predpoklady pre každý zo scenárov, napríklad podmienky predbežného načítania, ktoré by mali v systéme existovať, počet súbežných používateľov atď., |
| 5 | Uveďte nástroje, ktoré sa odporúčajú použiť na vykonanie testovania výkonnosti špecifického pre každú kategóriu testu a pre každý test. |
| 6 | Zaistite, aby bol jasne uvedený proces monitorovania metrík výkonu. |
Po úspešnom absolvovaní PQ je splnenie výkonnostných požiadaviek veľmi dôležité, pretože akékoľvek odchýlky súvisiace s výkonom môžu spôsobiť obrovské obchodné straty tým, že spôsobia nepohodlie pre používateľa a dôjde k strate dôvery v softvér, ktorý sa má použiť, čo vedie k zlyhaniu softvéru.
Stručne povedané, t nižšie uvedená tabuľka sumarizuje aktivity IQ-OQ-PQ.
| IQ | ČO | PQ | |
|---|---|---|---|
| Čo | Na overenie procesu inštalácie softvéru a toho, ako je tento proces zdokumentovaný | Na overenie správneho fungovania systému | Zákazníci, vlastníci, dodávatelia, prevádzkový tím |
| SZO | Zákazníci, vlastníci, dodávatelia, prevádzkový tím | Zákazníci, vlastníci, dodávatelia, prevádzkový tím | Zákazníci, vlastníci, dodávatelia, prevádzkový tím |
| Kde | U vlastníkov stránky, prevádzkový tím umiestnenie, živé stránky, prod ako prostredie | U vlastníkov stránky, prevádzkový tím umiestnenie, živé stránky, prod ako prostredie | U vlastníkov stránky, prevádzkový tím umiestnenie, živé stránky, prod ako prostredie |
| Kedy | Keď je softvér prijatý od softvérového tímu, pred OQ a PQ. | Pred uvoľnením systému do používania a po úspešnom dokončení IQ | Pred uvedením systému do života a po úspešnom IQ, dokončenie OQ |
V nasledujúcej tabuľke sú vysvetlené rôzne vstupy pre každú z fáz overovania.
| Typ | Vstup |
|---|---|
| IQ | 1. Dokument so špecifikáciou dizajnu 2. Softvérové binárne súbory a iné inštalačné skripty 3. Dokument s inštalačnou príručkou 4. Dokument Sprievodca konfiguráciou 5. Vytvorte dokument o overení a skúške dymu |
| ČO | 1. Dokument o funkčnej špecifikácii 2. Dokument plánu OQ 3. Dokument o prevádzkovej kvalifikačnej skúške 4. Šablóna súhrnnej správy o teste OQ 5. IQ bolo úspešne dokončené |
| PQ | 1. Dokument URS (špecifikácia požiadaviek používateľa) 2. Dokument plánu PQ 3. Dokument o teste kvalifikácie výkonu 4. Šablóna súhrnnej správy o teste PQ 5. IQ a OQ boli úspešne dokončené |
Záver
Aj keď produkt / softvér prešiel všetkými fázami overenia a nedokáže niektorú z IQ-OQ-PQ, výsledok môže byť katastrofálny a bude s ním spojené obrovské náklady. Samotné úspešné dokončenie IQ-OQ-PQ je teda úspešný presun produktu z vývojového miesta do výrobného závodu.
Celkovo úspešné dokončenie procesu validácie IQ-OQ-PQ nielen dáva dôveru v softvér, ale dáva pokoj aj klientovi, vlastníkovi, vývojárom softvéru a testerom.
najlepší bezplatný optimalizátor systému Windows 10
Spustenie IQ-OQ-PQ tiež znižuje riziko jeho nasadenia do života bez vykonania testovania a znižuje náklady na zlyhanie a zmierňuje riziko stiahnutia produktov z obehu.
Takže, chlapci, vývojári softvéru a testéri, žiadna oslava po dokončení vlastného vývoja a testovania a vydaní softvéru Ops Team. Oslava je iba vtedy, keď sa úspešne dokončí IQ-OQ-PQ a softvér je aktívny v cieľovom systéme.
Úspešnosť softvéru preto závisí od úspešného dokončenia IQ-OQ-PQ a od okamihu, keď je softvér aktívny a pripravený na spotrebu koncovými používateľmi.
O autorovi: Tento článok je napísaný členom tímu STHGayathri Subrahmanyam. Má viac ako 2 desaťročia skúseností v oblasti testovania softvéru. Počas svojej testovacej kariéry absolvovala veľa testov TMMI, testovala industrializáciu, nastavovala TCOE, okrem dodávok testovacích služieb a implementovala prax DevOps pre veľké nasadenie. Podľa nej sa však učenie nikdy nezastaví ...
Podeľte sa o svoje skúsenosti s vykonaním procesu overenia a dajte nám vedieť, ak máte akékoľvek otázky týkajúce sa tohto článku.
Odporúčané čítanie
- Kurz testovania softvéru: Do ktorého inštitútu pre testovanie softvéru by som sa mal pripojiť?
- Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
- Úloha pomocníka QA pri testovaní softvéru
- Ako svoju kariéru si zvolíte testovanie softvéru
- Práca na voľnej nohe pre spisovateľa technického obsahu, ktorý testuje softvér
- Niektoré zaujímavé otázky týkajúce sa testovania softvéru
- Spätná väzba a recenzie na kurz testovania softvéru
- Testovanie softvéru Pomoc Partnerský program!