Різниця між верифікацією та валідацією

Перевірка та перевірка – це терміни, які зазвичай використовуються в програмі. Перевірку та валідацію можна відрізнити тим, що перевірка програмного забезпечення – це процес перевірки проектних результатів та порівняння його із заданими вимогами до програмного забезпечення. Навпаки, перевірка програмного забезпечення – це процес вивчення специфікацій програмного забезпечення на потреби користувача. В цілому ці заходи завершують одна одну і є частиною розробки ПЗ.

1. 1. Порівняльна діаграма
   2. Визначення
   3. Ключові відмінності
   4. Висновок

   Порівняльна діаграма

   Основа для порівняння	Перевірка	Перевірка
   Основні	Процес дослідження продукту на стадії розробки проти заданих вимог.	Включає оцінку продукту відповідно до потреб користувача в кінці розробки.
   Мета	Забезпечення розробки продукту відповідає технічним характеристикам дизайну та вимогам.	Забезпечує правильність розробленого продукту та відповідає вимогам користувачів.
   Залучені заходи	Оцінюються плани, специфікації вимог, специфікація проекту, код, тестові випадки.	Програмне забезпечення, що тестується, оцінюється.
   Виконано	Команда QA	Команда тестування
   Порядок виконання	Виконується попередньо	Після перевірки
   Вартість	Менше	Більше

   Визначення верифікації

   Перевірка з точки зору інженерії програмного забезпечення – це група методів, які підтверджують точну реалізацію конкретних функцій у програмному забезпеченні. Він використовується для перевірки того, чи виріб правильно побудовано чи ні. У цій фазі процесу розробки програмного забезпечення помилки та помилки усуваються для забезпечення надійності.

   Процес перевірки передбачає наступне:

   • Він забезпечує прогностичний спосіб аналізу складеної конструкції для забезпечення функціональності функції вводу / виводу після розробки.
   • Точність та якість конструкції також перевірені.
   • Він перевіряє наявність кінцевого продукту на предмет дизайну, просто кажучи, чи відповідає продукт технічним характеристикам.

   Перевірку можна проводити за допомогою різних способів, таких як імітаційний, апаратна емуляція і формальні методи. Практично тестування пристрою та системи використовується для перевірки коду програмного забезпечення. Тестування блоку перевіряє, чи відповідає поведінка коду специфікації пристрою чи ні. Що стосується тестування системи, то модулі з’єднуються разом у сенсі тестування повної системи. Результат тестування системи включає перевірку того, чи відповідає система її специфікаціям.

   Визначення валідації

   Перевірка стосується набору процесів, що використовуються для забезпечення відстеження програмного забезпечення відповідно до вимог замовника. У більшості останніх випадків комп’ютерні системи не задовольняють потреби користувача, і це одне з найважливіших питань. Проблеми, пов’язані з валідацією, виникають через неправильну комунікацію між користувачами та розробниками та культурні прогалини. Отже, перевірка використовується для перевірки того, чи відповідає система користувачам потреби, наміри, прийняття, а також забезпечує функціонування системи, що відповідає цим вимогам.

   Навіть якщо система працює бездоганно, вона повинна слугувати основній меті, яка потрібна користувачеві. Діяльність з перевірки включає тестування приймання, яке виконується в кінці проекту. У цьому тестуванні програмне забезпечення демонструється своєму клієнту, якщо програмне забезпечення відповідає його вимогам, а потім воно приймається клієнтом.

   1. Дія перевірки забезпечує об’єктивне підтвердження того, що проектні результати певного компонента задовольняють заданій вимозі. Навпаки, перевірка програмного забезпечення підтверджує остаточне відповідність програмного продукту вимогам користувача.
   2. Помилки, виявлені під час перевірки, генерують менші витрати порівняно з пов’язаною вартістю помилок у процесі перевірки.
   3. Перевірка проводиться на етапі розробки, тоді як валідація проводиться після розробки продукту (тобто після верифікації).
   4. Команда QA несе відповідальність за проведення перевірки. І навпаки, перевірку проводить група тестування.

   Висновок

   Перевірка описується як сукупність заходів, що гарантують точну реалізацію певної функції в програмному забезпеченні. З іншого боку, перевірка – це група заходів, яка підтверджує, що розроблене програмне забезпечення відповідає вимогам замовника.

   Точна різниця між верифікацією та валідацією з прикладами

   Це повернення до основ Друзі! Класичний погляд на різницю між Верифікація та валідація .

   У світі тестування програмного забезпечення існує багато плутанини і суперечок навколо цих термінів.

   У цій статті ми розглянемо, що таке верифікація та валідація з точки зору тестування програмного забезпечення. Наприкінці статті ми зрозуміємо суть відмінностей між цими двома термінами.

   Нижче наведено кілька важливих причин, які допоможуть зрозуміти різницю:

   1. Це фундаментальна концепція QA, тому вона є майже будівельним блоком для того, щоб бути обізнаним у QA.
   2. Це найпоширеніше запитання на співбесіді з тестування програмного забезпечення.
   3. У програмі сертифікації є чимало розділів, присвячених цьому питанню.
   4. Нарешті, оскільки ми, тестувальники, виконуємо обидва типи тестування, ми можемо бути експертами в цьому питанні.

   Що таке верифікація та валідація в тестуванні програмного забезпечення?

   У контексті тестування, ” Верифікація та валідація “У більшості випадків ми сприймаємо обидва терміни як один і той самий, але насправді вони дуже відрізняються один від одного.

   Існує два аспекти завдань V&V (Verification & Validation):

   • Відповідає вимогам (погляд виробника на якість)
   • Придатність до використання (думка споживачів про якість)

   Погляд виробника на якість Простіше кажучи, це сприйняття розробниками кінцевого продукту.

   Споживачі оцінюють якість означає сприйняття користувачем кінцевого продукту.

   Коли ми виконуємо завдання V&V, ми повинні зосередитися на обох цих поглядах на якість.

   Давайте почнемо з визначень верифікації та валідації, а потім розглянемо ці терміни на прикладах.

   Зауважте: Ці визначення, як зазначено в CSTE CBOK QAI (перейдіть за цим посиланням, щоб дізнатися більше про CSTE).

   Що таке верифікація?

   Верифікація – це процес оцінки проміжних робочих продуктів життєвого циклу розробки програмного забезпечення, щоб перевірити, чи ми знаходимося на правильному шляху до створення кінцевого продукту.

   Іншими словами, ми також можемо стверджувати, що верифікація – це процес оцінки посередницьких продуктів програмного забезпечення, щоб перевірити, чи задовольняють ці продукти умови, накладені на початку фази.

   Тепер питання ось у чому: Що таке продукти-посередники або продукти-медіатори?

   Сюди можна віднести документи, які створюються на етапах розробки, такі як специфікація вимог, проектна документація, дизайн таблиць бази даних, ER-діаграми, тестові кейси, матриця простежуваності і т.д.

   Іноді ми схильні нехтувати важливістю перегляду цих документів, але ми повинні розуміти, що перегляд сам по собі може виявити багато прихованих аномалій, які, якщо їх знайти або виправити на більш пізній фазі циклу розробки, можуть коштувати дуже дорого.

   Верифікація гарантує, що система (програмне забезпечення, обладнання, документація та персонал) відповідає стандартам і процесам організації, спираючись на аналітичні або невиконавчі методи.

   Де проводиться верифікація?

   Специфічно для ІТ-проектів, нижче наведені деякі з областей (я повинен підкреслити, що це не всі), в яких виконується перевірка.

   Ситуація перевірки	Актори	Визначення	Вихідні дані
   Огляд бізнес/функціональних вимог	Команда розробників/клієнт для бізнес-вимог.	Це необхідний крок, щоб не тільки переконатися, що вимоги були зібрані та/або правильно оформлені, але й переконатися, чи є вони здійсненними.	Фіналізовані вимоги, які готові до споживання на наступному етапі – проектування.
   Перевірка дизайну	Команда розробників	Після створення дизайну команда розробників ретельно переглядає його, щоб переконатися, що функціональні вимоги можуть бути виконані за допомогою запропонованого дизайну.	Дизайн готовий до впровадження в ІТ-систему.
   Пояснення коду	Індивідуальний розробник	Написаний код перевіряється на наявність синтаксичних помилок. Ця перевірка має більш випадковий характер і виконується окремим розробником над кодом, який він сам розробив.	Код готовий до модульного тестування.
   Перевірка коду	Команда розробників	Це більш формальний процес. Експерти та розробники перевіряють код, щоб переконатися, що він відповідає бізнес-цілям та функціональним завданням, які ставить перед собою програмне забезпечення.	Код готовий до тестування.
   Перегляд плану тестування (внутрішній для команди QA)	Команда QA	Команда QA перевіряє план тестування, щоб переконатися, що він є точним і повним.	Документ плану тестування, готовий до передачі зовнішнім командам (управління проектом, бізнес-аналіз, розробка, навколишнє середовище, клієнт і т.д.)
   Перегляд плану тестування (зовнішній)	Керівник проектів, бізнес-аналітик та розробник.	Формальний аналіз плану тестування, щоб переконатися, що графік та інші міркування команди QA узгоджуються з іншими командами та всім проектом в цілому.	Підписаний або затверджений документ плану тестування, на основі якого буде проводитися тестування.
   Рецензування тестової документації (Peer review)	Члени команди QA	Експертна оцінка – це коли члени команди перевіряють роботу один одного, щоб переконатися, що в самій документації немає помилок.	Тестова документація готова до передачі зовнішнім командам.
   Фінальний перегляд тестової документації	Бізнес-аналітик та команда розробників.	Огляд тестової документації, щоб переконатися, що тестові кейси охоплюють всі бізнес-умови та функціональні елементи системи.	Тестова документація готова до виконання.

   Див. статтю про перевірку тестової документації, в якій детально описано, як тестувальники можуть виконувати перевірку.

   Що таке валідація?

   Валідація – це процес оцінки кінцевого продукту для перевірки того, чи відповідає програмне забезпечення потребам бізнесу. Простими словами, виконання тестів, які ми робимо в повсякденному житті, насправді є діяльністю з валідації, яка включає в себе димове тестування, функціональне тестування, регресійне тестування, системне тестування тощо.

   Валідація – це всі форми тестування, які передбачають роботу з продуктом і його випробування.

   Нижче наведено методи перевірки:

   • Модульне тестування
   • Інтеграційне тестування
   • Тестування системи
   • Тестування прийнятності для користувачів

   Валідація фізично гарантує, що система працює відповідно до плану, виконуючи системні функції за допомогою серії тестів, які можна спостерігати і оцінювати.

   Справедливо, чи не так? А ось і мої два центи:

   Коли я намагаюся розібратися з цією концепцією V&V у своєму класі, навколо неї виникає багато плутанини. Простий, дріб’язковий приклад, здається, вирішує всю цю плутанину. Він дещо дурний, але дійсно працює.

   Приклади валідації та верифікації

   Приклад з реального життя Уявіть, що ви йдете до ресторану/закусочної і замовляєте, наприклад, млинці з чорницею. Коли офіціант/офіціантка приносить ваше замовлення, як ви можете сказати, що їжа, яку принесли, відповідає вашому замовленню?

   Перш за все, ми дивимося на нього і помічаємо наступні речі:

   • Чи виглядає їжа так, як зазвичай виглядають млинці?
   • Чи можна побачити чорницю?
   • Як вони пахнуть?

   Може більше, але суть ви зрозуміли?

   З іншого боку, коли вам потрібно бути абсолютно впевненим у тому, що їжа така, як ви очікували: вам доведеться її з’їсти.

   Верифікація – це коли ви ще не їсте, але перевіряєте деякі речі, переглядаючи предмети. Валідація – це коли ви фактично їсте продукт, щоб переконатися, що він правильний.

   У цьому контексті я не можу не повернутися до посилання на КБО КБСЄ. Там є чудове твердження, яке допомагає нам повернути цю концепцію додому.

   Верифікація відповідає на питання: “Чи правильно ми побудували систему?”, тоді як валідація відповідає на питання: “Чи правильно ми побудували систему?”.

   V&V на різних етапах життєвого циклу розробки

   Верифікація та валідація виконуються на кожному з етапів життєвого циклу розробки.

   Спробуємо поглянути на них.

   #1) Завдання V і V – Планування

   • Перевірка контракту.
   • Оцінка Концептуального документу.
   • Проведення аналізу ризиків.

   #2) V і V завдання – Етап вимог

   • Оцінка вимог до програмного забезпечення.
   • Оцінка/аналіз інтерфейсів.
   • Формування плану тестування систем.
   • Формування плану приймальних випробувань.

   #3) V&V завдання – Етап проектування

   • Оцінка дизайну програмного забезпечення.
   • Оцінка / аналіз інтерфейсів (UI).
   • Формування плану тестування інтеграції.
   • Генерація плану тестування компонента.
   • Генерація тестового дизайну.

   #4) Завдання VV – Етап впровадження

   • Оцінка вихідного коду.
   • Оцінка документів.
   • Генерація тестових кейсів.
   • Генерація тестової процедури.
   • Виконання тестових кейсів компонентів.

   #5) Завдання VV – Тестовий етап

   • Виконання системного тестового кейсу.
   • Виконання приймально-здавального тесту.
   • Оновлення метрик простежуваності.
   • Аналіз ризиків

   #6) Завдання VV – Етап встановлення та перевірки

   • Аудит інсталяції та конфігурації.
   • Фінальне тестування збірки-кандидата на встановлення.
   • Формування фінального тестового звіту.

   #7) Завдання VV – Етап експлуатації

   • Оцінка нового обмеження.
   • Оцінка запропонованих змін.

   #8) Завдання VV – Етап технічного обслуговування

   • Оцінка аномалій.
   • Оцінка міграції.
   • Оцінка особливостей повторного судового розгляду.
   • Оцінка запропонованої зміни.
   • Перевірка виробничих питань.

   Різниця між верифікацією та валідацією

   Верифікація	Валідація
   Оцінює проміжну продукцію, щоб перевірити, чи відповідає вона специфічним вимогам конкретної фази.	Оцінює кінцевий продукт, щоб перевірити, чи відповідає він потребам бізнесу.
   Перевіряє, чи продукт побудований відповідно до заданих вимог і специфікації дизайну.	Він визначає, чи придатне програмне забезпечення для використання і чи задовольняє воно потреби бізнесу.
   Перевіряє “Чи правильно ми створюємо продукт”?	Перевіряє “Чи створюємо ми правильний продукт”?
   Це робиться без виконання програмного забезпечення.	Закінчується виконанням програмного забезпечення.
   Включає всі методи статичного тестування.	Включає всі методи динамічного тестування.
   Приклади включають огляди, інспекції та перевірки.	Приклад включає всі види тестування, такі як димове, регресійне, функціональне, системне та UAT.

   Різні стандарти

   ISO / IEC 12207:2008

   Діяльність з верифікації	Діяльність з валідації
   Перевірка вимог передбачає перегляд вимог.	Підготуйте документи з вимогами до тестів, тестові кейси та інші специфікації для аналізу результатів тестування.
   Верифікація проекту передбачає перевірку всієї проектної документації, включаючи HLD і LDD.	Оцініть, що ці тестові вимоги, тестові кейси та інші специфікації відображають вимоги і придатні для використання.
   Перевірка коду включає в себе огляд коду.	Перевірка граничних значень, напружень і функціональних можливостей.
   Верифікація документації – це верифікація посібників користувача та інших супутніх документів.	Перевірка на наявність повідомлень про помилки, і в разі виявлення помилки додаток плавно завершує роботу. Перевіряє, чи відповідає програмне забезпечення бізнес-вимогам і чи придатне воно для використання.

   CMMI:

   Верифікація та валідація – це два різні КПД на рівні зрілості 3

   Діяльність з верифікації	Діяльність з валідації
   Проведення експертних оцінок.	Переконайтеся, що продукція та її компоненти придатні для навколишнього середовища.
   Перевірте вибрані робочі продукти.	Коли процес валідації впроваджується, його моніторять і контролюють.
   Стандартизуйте певний процес, встановивши політику на рівні організації щодо планування та проведення оглядів.	Вивчайте отримані уроки та збирайте інформацію про вдосконалення. Інституціоналізуйте певний процес.

   IEEE 1012:

   Цілі цих тестових заходів полягають у наступному:

   • Сприяє ранньому виявленню та виправленню помилок.
   • Заохочує та посилює управлінське втручання в ризики процесів та продуктів.
   • Забезпечує підтримку процесу життєвого циклу програмного забезпечення, щоб підвищити відповідність графіку та бюджетним вимогам.

   Коли використовувати валідацію та верифікацію?

   Це незалежні процедури, які слід застосовувати разом, щоб перевірити, чи відповідає система або програма вимогам і специфікаціям і чи досягає вона свого призначення. Обидві процедури є важливими компонентами системи управління якістю.

   Часто трапляється так, що продукт проходить верифікацію, але зазнає невдачі на етапі валідації. Хоча він відповідає задокументованим вимогам і специфікаціям, ці специфікації самі по собі не здатні задовольнити потреби користувача. Таким чином, важливо проводити тестування обох типів, щоб забезпечити загальну якість.

   Верифікація може використовуватися як внутрішній процес при розробці, масштабуванні або виробництві. З іншого боку, валідація повинна використовуватися як зовнішній процес, щоб отримати визнання придатності від зацікавлених сторін.

   Що таке валідація чи верифікація UAT?

   UAT (User Acceptance Testing) слід розглядати як валідацію. Це перевірка системи або додатку в реальних умовах, яку здійснюють реальні користувачі, які перевіряють, чи є система “придатною для використання”.

   Висновок

   Процеси V&V визначають, чи відповідає продукція певного виду діяльності вимогам і чи придатна вона для використання.

   Насамкінець, наведемо кілька зауважень:

   1. Говорячи дуже простими словами (щоб уникнути плутанини), ми просто пам’ятаємо, що верифікація означає перевірку або методи статичного тестування, а валідація – власне виконання тесту або методи динамічного тестування.
   2. Верифікація може включати або не включати сам продукт. Валідація, безумовно, потребує продукту. Верифікація іноді може бути виконана на документах, які представляють кінцеву систему.
   3. Верифікація та валідація не обов’язково повинні виконуватися тестувальниками. Як ви бачили вище в цій статті, деякі з них виконуються розробниками та іншими командами.

   Це все, що вам потрібно знати про верифікацію та валідацію, щоб бути експертами в цій галузі.