what are iq oq pq 3 q s software validation process
Introduction to IQ-OQ-PQ:
IQ, OQ и PQ представляват 3Q на процеса на валидиране на софтуера.
Като тестери всички знаем, че Екипът за разработка на софтуер разработва софтуер вътре в съответствие със спецификацията на софтуерните изисквания (SRS), функционалната спецификация и по-късно тестващият екип проверява изпълнението на различни нива на тестване в различни среди за тестване, от най-простите до висок клас, който по този начин възпроизвежда производствената среда.
С този подход на SDLC, екипът за разработка на софтуер обикновено отмива ръцете си, като предава завършения софтуер (разработен и проверен) на операционния екип. Освен това, Операционният екип (обикновено наричан Ops Team) се грижи за разполагането му в производствена среда и го прави готов за използване от крайните потребители.
Сега тук се крие истинското предизвикателство за Операционния екип да направи софтуера функционален в производствената среда, тъй като по време на фазите на разработване на софтуер разработката и проверката се извършват в симулирана среда и доста рядко в близост до живата среда, само в случай на наличност на данни и конфигурации на производствената среда.
Това е мястото, където валидирането на софтуера влиза в картината. След като проверката приключи и софтуерът бъде подписан от екипа на програмата / продукта, Ops Team ще извърши набор от дейности, преди да приеме софтуера за внедряване в производството, за да докаже, че софтуерът се държи според очакванията, което не е нищо друго освен дейности по валидиране.
Какво ще научите:
Проверка срещу проверка
Тук нека ясно разберем разликата между дейностите „Проверка“ и „Проверка“. ' Проверка “Е да оцени софтуера по отношение на дадения набор от изисквания и спецификации, който се извършва вътрешно в сайта за разработка на софтуер от разработчиците и тестерите.
Като има предвид, че Проверка “Е набор от проверки за осигуряване на качеството, които се извършват от външни клиенти, собственици, продавачи на продукта, който им се доставя, за да се провери годността преди приемане или закупуване на продукта. Дейностите по валидиране се извършват най-вече на производствената площадка.
Следователно, в случай на разработка на приложения, екипът на Ops извършва дейностите по проверка на софтуера.
Прочетете също:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Фази на процеса на валидиране
Обикновено процесът на валидиране на всеки продукт се отнася до пълния жизнен цикъл на продукта от разработването чрез използване и поддръжка. И следователно процесът на валидиране е разделен на 5 фази.
5 фази на процеса на валидиране са:
Този 5-фазен подход на процеса на валидиране се следва в много индустрии като производството, медицината, фармацевтиката и др. Тук валидирането ще бъде извършено от крайния клиент преди закупуване на машини, оборудване или продукт.
Съставните елементи на дейностите за проверка на софтуера са да докажат, че „софтуерът е готов за консумация от потребителите“, и да проверят главно успешната инсталация на софтуера, последвана от функционалността и работоспособността.
3Q’s approach: IQ-OQ-PQ
В софтуерния контекст обаче 3Q’s approach, IQ-OQ-PQ се проследява като част от валидирането и ще бъде извършено от оперативния екип, който в крайна сметка е отговорен за внедряването на софтуера в производството.
По-долу е дадена диаграмата на процеса на валидиране:
Шаблонът, планът и всички други документи, които са въведени за извършване на тримесечието, ще бъдат изготвени от софтуерния екип за техния софтуер и включват подробен подход, задачи / дейности / тестове, които трябва да бъдат проведени като част от тези квалификации заедно с резултатите от теста.
Обобщени отчети ще бъдат предадени на Ops Team по време на предаването на софтуера, заедно с двоичните файлове и други резултати.
На високо ниво,
Като цяло целта на провеждането на IQ, OQ и PQ е да се гарантира, че софтуерът може да бъде успешно разгърнат и всички функционалности могат да бъдат използвани без затруднения.
В идеалния случай IQ, OQ и PQ са последователните дейности, които трябва да бъдат изпълнени в поръчката. Освен ако инсталацията не е направена, функционалността на софтуера не може да бъде проверена и освен ако функционалността не бъде доказана, няма смисъл да се измерва производителността. Понякога поради ограничение във времето, PQ може да започне паралелно на OQ, след като се установят ключовите аспекти на OQ.
Сега нека разберем повече за всяка от тези 3 фази в детайли.
Квалификация за инсталиране (IQ)
Квалификацията за монтаж също се нарича „IQ“ , е процесът на валидиране, ако предоставеният софтуер (двоични файлове, скриптове и т.н.) може да бъде успешно инсталиран в определената среда с посочените конфигурации и да се провери как тези стъпки на инсталация са записани в документа, наречен „Ръководство за инсталиране“.
Следните елементи се предоставят от екипа за разработка заедно с доставения софтуерен пакет и се използват от екипа на Ops за извършване на IQ.
1) Документ „Инструкция за инсталиране“, който документира стъпките за инсталиране в избраните среди.
две) Документ „Ръководство за конфигуриране“, за да настроите конфигурируемия софтуер. Понякога този документ става част от самия документ с ръководството за инсталиране.
3) Софтуерен пакет и скриптове за инсталиране, за предпочитане автоматизирани скриптове.
Фазата на квалификация за инсталиране на софтуер се счита за най-важната и обикновено има много проблеми отворен по време на тази фаза.
Защото:
да се) Средата за разработка няма да разполага със 100% среда в реално време за проверка на проблемите с инсталирането и следователно разликата в средата допринася за няколко проблема.
б) Поради различни причини може да няма достатъчно сътрудничество и координация между екипа за разработка и оперативния екип по време на началните етапи на разработване на софтуер, за да се справят с проблемите много напред.
° С) Възможно е да има някои проблеми с документирането, докато се записват действителните стъпки за инсталиране в документа, които може да не съвпадат точно в производствената среда.
В наши дни цялата процедура за инсталиране на софтуера ще бъде автоматизирана възможно най-много чрез поредица от скриптове. Ако има някакви проблеми с инсталацията, тогава автоматизираната инсталация се проваля поради липса на съвпадение в конфигурациите и се изисква ръчна намеса за отстраняване на тези проблеми.
Тъй като екипът на Ops извършва IQ, следвайки стриктно инструкциите, предоставени от софтуерния екип в ръководството за инсталиране, е много важно, а също и отговорността на софтуерния екип да гарантира, че „Ръководство за инсталиране“ е написано по такъв начин, че стъпките за инсталиране съответстват на средата в реално време.
И отговорността на тестерите е да гарантират, че процесът на „инсталиране“ е проверен вътрешно заедно с проверката на документа за неговата пълнота и да идентифицират всички пропуски с действителните стъпки, които трябва да бъдат изпълнени в системата спрямо документираните стъпки в Ръководство за инсталиране.
Следните точки трябва да се имат предвид, докато пишете Ръководство за инсталиране и ги проверявате вътрешно, за да сведете до минимум проблемите по време на инсталацията на софтуера при производството.
| SNO | Точки от ръководството за инсталиране |
|---|---|
| 7 | Типичното време, необходимо за инсталиране на софтуера, трябва да бъде споменато в Ръководството за инсталиране на екипа на Ops, за да има представа за приблизителния момент на инсталацията, за да планира съответно своите дейности. |
| 1 | Основно и крайно, „Ръководство за инсталиране“ трябва да бъде написано на прост и лесен за следване език. |
| две | Необходимо е да се гарантира, че не се стига до дълги, повече от 5 страници. То трябва да е кратко и спретнато. |
| 3 | Трябва да предоставите серийни номера за всяка стъпка на изпълнение, за да проследите нейното състояние. |
| 4 | Автоматизирайте стъпките възможно най-много и групирайте всички в един скрипт. |
| 5 | За писане на инсталационната процедура трябва да се използва стандартен шаблон. |
| 6 | Предварителните условия трябва да бъдат ясно посочени, за да се избегне пропускането на мача и трябва да бъдат предоставени стъпките за тяхното проверяване. Ако има пропуснат мач, трябва да се предостави инструкция да ги доведете до очакваното ниво или да инсталирате тези пакети. |
| 8 | Услугите, които трябва да бъдат премахнати по време на инсталацията, как да бъдат свалени, въздействието от тяхното сваляне трябва да бъдат ясно посочени в ръководството. |
| 9 | Предоставянето на връзки към други документи трябва да се избягва и преминаването от един документ към друг. Всяка необходима информация трябва да бъде предоставена в същия документ. Ако трябва да се посочат допълнителни документи, предоставете ги заедно със софтуерния пакет и от своя страна те трябва да бъдат посочени в основните документи. |
| 10 | Трябва да се уверите, че името на скрипта, споменато в документа, е същото като това, което е пакетирано заедно с двоичния файл. |
| единадесет | Трябва да гарантира, че всички скриптове, посочени в документа за ръководство за инсталиране, се доставят заедно с двоичния файл. |
| 12 | Уверете се, че всички конфигурационни параметри са ясно споменати в Ръководството за инсталиране / Ръководство за конфигуриране заедно със стойностите по подразбиране и други поддържани стойности. |
| 13 | Трябва да се предоставят автоматизирани тестове за извършване на тестове за проверка на компилация след приключване на инсталирането на софтуера. Те трябва да бъдат минимални на брой и важни, за да се провери дали компилацията е инсталирана успешно. |
| 14. | Трябва да се предоставят „Тестове за дим“, за да се гарантира, че свързаността на системата от край до край е перфектна и всички компоненти на системата разговарят помежду си, както се очаква. |
| петнадесет | В случай на неуспех при инсталацията на софтуера се предоставят скриптове за връщане заедно с пакета и процедурата за връщане е ясно записана в Ръководството за инсталиране, за да се извърши възстановяването и да се възстанови системата успешно. |
С всички горепосочени точки, за които трябва да се погрижи, най-добрата практика е да автоматизирате процеса на инсталиране на софтуера с минимална човешка намеса, за да избегнете човешките грешки.
Ако по време на фазата на валидиране на IQ бъдат открити някакви проблеми, това ще бъде докладвано на софтуерния екип, при отстраняване на който, тестовете за дим и проверка на конструкцията ще се извърши за проверка на успеха на инсталацията на софтуера.
Следователно фазата на IQ включва инсталиране на софтуерния пакет, последвано от провеждане на проверка на компилация и тестове за дим.
Така че, успешното завършване на фазата на IQ е много важно, тъй като успешната и правилна инсталация на софтуер гарантира, че повечето от проблемите, свързани с откази във функционалността, са отхвърлени.
Оперативна квалификация (OQ)
Оперативна квалификация, наричана още като КАКВО е следващата дейност в процеса на валидиране на софтуера след успешното завършване на IQ.
Оперативната квалификационна дейност включва t той тества да бъде стартиран, за да провери дали софтуерът е оперативно годен за разполагане на потребителите. В идеалния случай ключовите функционалности на софтуера се проверяват като част от този процес на валидиране.
План за OQ за извършване на OQ валидиране трябва да бъде изготвен от софтуерния екип (тестери), който да обхваща всички аспекти на OQ тестването, което трябва да се извърши, включително подробности като №. на тестове, график на теста, методология, инструменти, въздействие върху услугата, последователност на изпълнението на теста, метод за докладване на проблемите и SLA за тяхното отстраняване, подход Defect Triage и т.н.,
Тестовете за оперативна квалификация, които се изпълняват като част от OQ, отново се предоставят от софтуерния екип заедно със софтуерните продукти. Тези тестове за оперативна квалификация представляват съвкупност от важни тестове, които са създадени въз основа на документа „Спецификация на функционалните изисквания“, за да гарантират, че цялата софтуерна система функционира според очакванията.
Този документ за спецификация за OQ тест е изготвен от тестовите инженери срещу документа за спецификация на функционалните изисквания. Често този документ ще бъде подмножеството на документа за спецификация на системния тест, изготвен и проверен по време на фазата на системно тестване на SDLC.
Тестовете могат да бъдат променени или актуализирани в съответствие с изискванията на Оперативния екип и условията на сайта, където ще бъдат изпълнени.
Следователно трябва да се обърне допълнително внимание при избора на тестовете, които са част от OQ, за да се гарантира, че всички ключови функционалности и основните бизнес потоци са включени като част от тази проверка.
По-долу са съветите за тестерите при подготовката на документа за спецификация на OQ теста.
| Сно | Съвети за тестери при подготовката на документа за спецификация на OQ теста |
|---|---|
| 7 | Не е необходимо да се включват тестови случаи, свързани с гранична стойност, което проверява за екстремни стойности, но използвайте най-често използваните ежедневни стойности като входни данни, където е необходимо. |
| 1 | Уверете се, че ключовите функционални тестове, за да се докаже, че софтуерните функции, както се очаква, са избрани и включени и следователно необходимата проследимост за всеки от писмените тестови случаи са налични в документа OQ Test Spec. |
| две | Уверете се, че тестовете са изрядно написани с стъпка по стъпка, са обяснителни и могат да бъдат разбрани от обикновен човек. |
| 3 | Не посочвайте и не избягвайте използването на каквито и да е технически термини в тестовите случаи, доколкото е възможно, тъй като потребителят на този документ може да не знае за тези терминологии.e, че използваните тестови данни вече не съществуват в системата. Предоставете множество набори от данни, в случай че потребителят иска да изпълни тестовите случаи повече от веднъж. |
| 4 | Ясно посочете задължителните и незадължителните предпоставки за всеки от тестовете. |
| 5 | Включете по-голямата част от положителните тестови случаи, за да проверите функционалността. |
| 6 | Включете много малко отрицателни тестови случаи, за да сте сигурни, че поведението на софтуера е очаквано в случай на неподходящо въвеждане и системата може да се справи успешно с негативните случаи. |
| 8 | Споменете конфигурационните стойности, които трябва да бъдат зададени, ако трябва да бъдат променени от стойностите по подразбиране. |
| 9 | Предоставете автоматизираните тестови случаи, които да се изпълняват, където и да са налични. Уверете се преди това, че тези скриптове за автоматизация могат да се изпълняват в системата, където се планира OQ. |
| 10 | Уверете се, че всеки тестов случай има ясните „Очаквани“ и „Действителни“ резултати като ориентир. И добавете коментари, ако е необходимо, за да обясните действителния резултат. |
| единадесет | Също така е необходимо да се включат „критерии за приемане“ за всеки от тестовите случаи. Критериите за приемане могат да бъдат състоянието на системата след изпълнението на тестовите случаи. |
| 12 | Посочете „Тестови данни“, които да се използват точно за всеки от тестовете. Опитайте се да предоставите най-често срещаните данни на живо. И също така няколко изключителни данни, за да се гарантира, че системата може да се справи и с изключителните случаи. Уверете се, че използваните тестови данни вече не съществуват в системата. Предоставете множество набори от данни, в случай че потребителят иска да изпълни тестовите случаи повече от веднъж. |
| 13 | Ако множество оперативни потребители изпълняват тестовете паралелно от различни места, предоставете инструкция за провеждане на тестване съответно с различен набор от данни. |
| 14. | Осигурете контролни списъци, където някога се изисква, за да сте сигурни, че всички конфигурации, предварителни условия са зададени, както се очаква, преди да стартирате тестовете. |
| петнадесет | Продължавайте да наблюдавате дневниците, когато тестовете се изпълняват, ако има достъп до системата. |
| 16. | Ако е възможно и е необходимо, осигурете поддръжка за изпълнение на операционните потребители по време на изпълнението на тези тестови случаи. |
| 17 | Обяснете метода за докладване на проблемите, открити по време на изпълнението. По-добре е да използвате инструмента за проследяване на грешки, за да проследите проблемите. Следете внимателно всеки брой и го затваряйте съгласно договорените SLA. |
| 18. | Изпълнете „Дефектни проби“, включващи правилните заинтересовани страни, за да разберете критичните и сериозни проблеми и да предоставяте актуализации по тези проблеми често. |
| 19. | Предоставете окончателния шаблон „Обобщен отчет за изпълнение на теста за OQ“, за да публикувате крайните резултати след приключване на изпълнението. |
Така подготвеният план за OQ и спецификацията на теста трябва да бъдат щателно прегледани и подписани от съответните заинтересовани страни, за да се гарантира главно, че покритието не е твърде малко или твърде много и всички ключови функции са покрити.
Успешното завършване на OQ демонстрира, че софтуерът ще функционира в съответствие с оперативните си спецификации в избраната среда и това е етапът на придвижване на софтуера към неговото производство и е сигнал за продължаване на следващата дейност от процеса на валидиране, която е PQ .
Квалификация за изпълнение (PQ)
След осигуряване на успешен IQ, завършване на OQ, следващата дейност в процеса на валидиране е да се гарантира дали продуктът / софтуерът отговаря на определените аспекти на производителността при очакваното натоварване последователно, без да причинява пречки в производствената среда.
Ключовият аспект на PQ е да гарантира, че софтуерът, когато е инсталиран на очакваната система, може да се справи с натоварването на живо и да отговори на очакваното време за реакция и не се срива при пикови натоварвания и стрес, докато обработва едновременни потребители.
Следователно PQ е основно да гарантира, че посочените критерии за производителност на даден софтуер са постигнати за определен период от време (може би седмица) на надеждна основа с променливи условия на натоварване, какъвто е моделът на живо. Следователно тези тестове трябва да се провеждат всеки ден, за да се следи поведението на софтуерната система и следователно PQ ще отнеме известно време, за да завърши, докато се гарантира, че системата е доказана за своята ефективност.
В идеалния случай валидирането на PQ се извършва след завършване на OQ, където функционалността на софтуера е осигурена и може да продължи с проверка на аспекта на производителността на продукта или софтуера. Понякога поради ограничение във времето, PQ може да започне паралелно на OQ, въз основа на доверието в процента на завършване на OQ.
Идеално е да се извършат тези тестове за ефективност на системата под наем с напълно заредена система или при условия, подобни на условията на живот, и да се гарантира, че няма тесни места по аспектите на производителността.
Следните тестове обикновено се изпълняват като част от квалификацията за изпълнение. И изборът на тестовете варира от софтуер до софтуер.
# 1) Тест за наличност: За да сте сигурни, че софтуерът е непрекъснато достъпен, без да се срива или слиза.
# 2) Тест за достъпност: За да се гарантира, че софтуерът е лесно достъпен от всяко място с очакваната скорост на производителност, без никакви проблеми.
# 3) Тест за натоварване: За измерване на поведението на системата при очакваното ежедневно натоварване, както и пиковите условия на натоварване.
# 4) Стрес тест: За измерване на точката на прекъсване на системата при екстремни условия на натоварване.
# 5) Тест за производителност: За измерване на времето за реакция на системата и за измерване на TPS (транзакции в секунда)
# 6) Тестване на мащабируемост: Системата може да се мащабира, за да се справи с очакваните едновременни потребители.
Сценариите за тестване на производителността и съответните автоматизирани скриптове се изготвят въз основа на изискванията, свързани с производителността, посочени в документите „Спецификация на потребителските изисквания“.
Подобно на плана за OQ, подробен план за PQ, който ясно посочва тестовия подход, стратегия, план и график, заедно с инструменти, трябва да бъде изготвен и проведен заедно с изпълнителите на PQ.
Инструментът за тестване и мониторинг на производителността трябва да бъде инсталиран в средата, където се извършва PQ, за да се измерват и отчитат показателите за ефективността.
По-долу са съветите за тестерите, за да се даде възможност на оперативния екип да изпълни PQ успешно.
| Сно | Съвети за тестерите за активиране на операционния екип |
|---|---|
| 7 | Насочвайте, поддържайте и обучавайте оперативния екип да извършва тестване на производителността в системата. |
| 1 | Подгответе ключовите бизнес специфични сценарии за извършване на тестване на производителността въз основа на URS. |
| две | Уверете се, че са включени тестове, за да се докаже, че системата отговаря на очакванията за време за реакция, скорост, мащабируемост и стабилност при различни условия на натоварване. |
| 3 | Уверете се, че е наличен определен товар или методът и инструментите за генериране на необходимия товар са ясно посочени в съответните тестови случаи. |
| 4 | Споменете ясно условието за всеки от сценариите, като условията за предварително зареждане, които трябва да съществуват в системата, броя на едновременните потребители и т.н., |
| 5 | Инструменти за споменаване, препоръчани да се използват за извършване на тестове за ефективност, специфични за всяка категория тест и за всеки тест. |
| 6 | Уверете се, че процесът за наблюдение на показателите за ефективност е споменат ясно. |
След успешното завършване на PQ, спазването на изискванията за производителност е много важно, тъй като всякакви отклонения, свързани с производителността, могат да причинят огромна бизнес загуба, като създават дискомфорт на потребителя и доверието към използвания софтуер ще бъде загубено, което води до отказ на софтуера.
Накратко, t той под таблицата обобщава IQ-OQ-PQ дейностите.
| IQ | КАКВО | PQ | |
|---|---|---|---|
| Какво | За да проверите процеса на инсталиране на софтуера и как процесът е документиран | За да проверите правилното функциониране на системата | Клиенти, собственици, продавачи, оперативен екип |
| Който | Клиенти, собственици, продавачи, оперативен екип | Клиенти, собственици, продавачи, оперативен екип | Клиенти, собственици, продавачи, оперативен екип |
| Където | В сайта на собствениците, местоположението на оперативния екип, сайта на живо, подобна среда | В сайта на собствениците, местоположението на оперативния екип, сайта на живо, подобна среда | В сайта на собствениците, местоположението на оперативния екип, сайта на живо, подобна среда |
| Кога | Когато софтуерът е получен от софтуерния екип, преди OQ и PQ. | Преди пускане на системата за употреба и след успешно завършване на IQ | Преди пускане на системата на живо и след успешен IQ, OQ завършване |
Таблицата по-долу обяснява различните входове за всяка от фазите на валидиране.
| Тип | Вход |
|---|---|
| IQ | 1. Документ за спецификация на проекта 2. Софтуерни двоични файлове и други инсталационни скриптове 3. Документ с Ръководство за инсталиране 4. Документ с ръководство за конфигуриране 5. Съставете документ за проверка и тест за дим |
| КАКВО | 1. Документ за функционална спецификация 2. Документ за OQ план 3. Документ за тест за оперативна квалификация 4. Шаблон за обобщен отчет на OQ тест 5. IQ завършен успешно |
| PQ | 1. Документ на URS (User Requirement Specification) 2. Документ за PQ план 3. Документ за изпит за квалификация за изпълнение 4. Шаблон за обобщен отчет на PQ тест 5. IQ и OQ завършиха успешно |
Заключение
Дори ако продуктът / софтуерът е преминал всички етапи на проверка и не успее да докаже някой от IQ-OQ-PQ, резултатът може да бъде пагубен и да доведе до огромни разходи. Следователно успешното завършване само на IQ-OQ-PQ е успешното прехвърляне на продукта от площадката за разработка към производствената площадка.
Като цяло успешното завършване на процеса на валидиране на IQ-OQ-PQ не само дава увереност в софтуера, но също така дава спокойствие на клиента, собственика, разработчиците на софтуер и тестерите.
основни въпроси и отговори за интервю за Java
Изпълнението на IQ-OQ-PQ също намалява риска от внедряването му на живо, без извършване на тестове и намалява разходите за повреда и намалява риска от изземване на продуктите.
Така че, момчета, разработчици на софтуер и тестери, няма празненство след завършване на вътрешната разработка и тестване и пускане на софтуера на Ops Team. Празникът е само тогава, когато успешно завърши IQ-OQ-PQ и софтуерът работи в реално време на целевата система.
Следователно успехът на софтуера зависи от успешното завършване на IQ-OQ-PQ и кога софтуерът е активен и готов за консумация от крайните потребители.
За автора: Тази статия е написана от член на екипа на STH Гаятри Субраманям. Тя има повече от 2 десетилетия опит в областта на софтуерното тестване. По време на тестовата си кариера тя е направила много оценки на TMMI, работи за индустриализация на тестове, настройки на TCOE в допълнение към обработката на тестови доставки и внедрила DevOps практика за огромен ангажимент. Но според нея ученето никога не спира ...
Споделете своя опит относно провеждането на процеса на валидиране и ни уведомете, ако имате въпроси относно тази статия.
Препоръчително четене
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- Някои интересни въпроси за интервю за тестване на софтуер
- Обратна връзка и рецензии на курсове за софтуерно тестване
- Тестване на софтуер Помощ Партньорска програма!