what are iq oq pq 3 q s software validation process
Вступ до 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 етапів процесу валідації:
Цей п’ятифазний підхід до процесу валідації дотримується у багатьох галузях промисловості, таких як виробництво, медицина, фармацевтика тощо. Тут валідація здійснюється кінцевим замовником перед покупкою обладнання, обладнання чи продукту.
Складова діяльності з перевірки програмного забезпечення полягає в тому, щоб довести, що «програмне забезпечення готове до споживання користувачами», і в основному перевірити успішну інсталяцію програмного забезпечення, а потім функціональність та працездатність.
Підхід 3Q: IQ-OQ-PQ
Однак у контексті програмного забезпечення Підхід 3Q, IQ-OQ-PQ виконується в рамках перевірки, і її буде проводити операційна команда, яка в кінцевому рахунку відповідає за розгортання програмного забезпечення на виробництві.
Нижче наведена діаграма процесу перевірки:
Шаблон, план та будь-які інші документи, які вводяться для виконання 3Q, будуть розроблені Комітетом програмного забезпечення для свого програмного забезпечення, і вони включають детальний підхід, завдання / заходи / тести, які повинні проводитися як частина цих кваліфікацій з результатами випробувань.
Підсумкові звіти будуть передані 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 задоволення вимог до продуктивності є дуже важливим, оскільки будь-які відхилення, пов’язані з продуктивністю, можуть спричинити величезні втрати бізнесу, створюючи дискомфорт для користувача, і довіра до використовуваного програмного забезпечення буде втрачена, що призведе до виходу з ладу програмного забезпечення.
У двох словах, т він нижче таблиці підсумовує діяльність IQ-OQ-PQ.
| IQ | ЩО | PQ | |
|---|---|---|---|
| Що | Щоб перевірити процес встановлення програмного забезпечення та те, як процес документується | Для перевірки належного функціонування системи | Клієнти, власники, продавці, операційна команда |
| ВООЗ | Клієнти, власники, продавці, операційна команда | Клієнти, власники, продавці, операційна команда | Клієнти, власники, продавці, операційна команда |
| Де | На майданчику власників, розташуванні операційної групи, реальному сайті, подібному середовищі | На майданчику власників, розташуванні операційної групи, реальному сайті, подібному середовищі | На майданчику власників, розташуванні операційної групи, реальному сайті, подібному середовищі |
| Коли | Коли програмне забезпечення отримано від команди програмного забезпечення, перед OQ та PQ. | До випуску системи для використання та після успішного завершення IQ | Перш ніж перевести систему в режим Live та після успішного IQ, завершення OQ |
У таблиці нижче пояснюються різні вхідні дані для кожного з етапів перевірки.
| Тип | Вхідні дані |
|---|---|
| IQ | 1. Документ технічного завдання 2. Бінарні програми та інші сценарії встановлення 3. Документ керівництва з встановлення 4. Документ керівництва з налаштування 5. Складіть документ про перевірку та перевірку диму |
| ЩО | 1. Функціональний специфікаційний документ 2. Документ плану OQ 3. Документ про перевірку кваліфікації 4. Шаблон звітного зведення тесту OQ 5. IQ успішно завершено |
| PQ | 1. Документ URS (специфікація вимог користувача) 2. Документ плану PQ 3. Документ про тестування кваліфікації 4. Шаблон звітного звіту про тестування PQ 5. IQ та OQ успішно завершені |
Висновок
Навіть якщо виріб / програмне забезпечення пройшло всі етапи верифікації та не змогло довести жодного з IQ-OQ-PQ, результат може бути згубним та матиме величезні витрати. Отже, успішне завершення IQ-OQ-PQ - це успішне перенесення продукту з місця розробки на виробниче місце.
Загалом, успішне завершення процесу перевірки IQ-OQ-PQ не тільки надає впевненості в програмному забезпеченні, але також дає спокій клієнту, власнику, розробникам програмного забезпечення та тестувальникам.
запити oracle sql інтерв’ю запитання та відповіді для досвідчених
Запуск IQ-OQ-PQ також зменшує ризик використання його в режимі реального часу без проведення випробувань, а також знижує вартість несправностей та зменшує ризик відкликання продукції.
Отже, хлопці, розробники програмного забезпечення та тестувальники, жодного торжества після завершення внутрішньої розробки та тестування та випуску програмного забезпечення до команди Ops. Святкування відбувається лише тоді, коли воно успішно завершує IQ-OQ-PQ і програмне забезпечення працює в цільовій системі.
Отже, успіх програмного забезпечення залежить від успішного завершення IQ-OQ-PQ і від того, коли програмне забезпечення працює та готове до споживання кінцевими користувачами.
Про автора: Ця стаття написана членом команди STH Гаятрі Субраманіамом. Вона має понад 2 десятиліття досвіду у галузі тестування програмного забезпечення. Протягом своєї тестової кар'єри вона зробила багато оцінок TMMI, тестові роботи з індустріалізації, налаштування TCOE на додаток до обробки тестових поставок та впровадила практику DevOps для величезної участі. Але за її словами, навчання ніколи не припиняється ...
Поділіться своїм досвідом щодо проведення процесу перевірки та повідомте нам, якщо у вас є запитання щодо цієї статті.
Рекомендована література
- Курс тестування програмного забезпечення: до якого інституту тестування програмного забезпечення слід приєднатися?
- Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
- Тестування програмного забезпечення QA Assistant Job
- Вибір тестування програмного забезпечення як вашу кар’єру
- Тестування програмного забезпечення Технічний вміст Письменник Робота фрілансера
- Деякі цікаві запитання щодо тестування програмного забезпечення
- Відгуки та відгуки про курс тестування програмного забезпечення
- Тестування програмного забезпечення Довідка Партнерська програма!