Меню

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

  • Головна
  • Інший
  • Точна різниця між верифікацією та валідацією на прикладах

exact difference between verification

Спробуйте Наш Інструмент Для Усунення Проблем

Перевірка проти перевірки: Вивчіть відмінності на прикладах

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

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

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

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

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

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

Що ви дізнаєтесь:

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

У контексті тестування ' Перевірка та перевірка ”- це два широко вживані терміни. Здебільшого ми розглядаємо обидва терміни як однакові, але насправді ці терміни досить різні.

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

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

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

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

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

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

Що таке перевірка?

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

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

Тепер питання тут: Що таке посередництво чи посередник?

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

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

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

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

Особливо для ІТ-проектів, наведено деякі сфери (я повинен наголосити, що це ще не все), в яких проводиться перевірка.

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

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

Що таке перевірка?

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

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

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

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

Досить справедливо, так? Ось мої два центи:

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

Приклади перевірки та перевірки

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

Перш за все ми дивимось на це і помічаємо такі речі:

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

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

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

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

У цьому контексті я не можу стриматися, але повернутися до CSTE CBOK посилання. Існує чудове твердження, яке допомагає нам повернути цю концепцію додому.

Перевірка відповідає на запитання: 'Чи ми створили правильну систему?' в той час як перевірка звертається: 'Ми правильно побудували систему?'

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

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

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

# 1) V & V tasks - Планування

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

# 2) V & V tasks - Фаза вимог

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

# 3) V & V tasks - Етап проектування

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

# 4) V & V Tasks - Фаза впровадження

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

# 5) V & V Tasks - Фаза випробування

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

# 6) V & V Tasks - Етап встановлення та замовлення

  • Аудит встановлення та конфігурації.
  • Остаточний тест збірки кандидатів на встановлення.
  • Створення остаточного звіту про випробування.

# 7) V & V Tasks - Етап операції

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

# 8) V & V Tasks - Етап технічного обслуговування

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

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

Перевірка проти перевірки

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

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

ISO / IEC 12207: 2008

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

CMMI:

Перевірка та перевірка є двома різними KPA на рівні зрілості 3

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

IEEE 1012:

Завданнями цих тестових заходів є:

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

Коли використовувати перевірку та перевірку?

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

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

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

Валідація або верифікація UAT?

UAT (Тест прийняття користувача) слід розглядати як перевірку. Це реальна перевірка системи чи програми, яку виконують фактичні користувачі, які перевіряють, чи система “придатна для використання”.

Висновок

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

Нарешті, є кілька речей, на які слід звернути увагу:

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

Це все, що вам потрібно знати про верифікацію та валідацію, щоб бути МСП (експертами з предметних питань) з цього питання.

Рекомендована література

^