Чи є верифікація та валідація частиною процесу тестування?

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

1. Визначте, що (програмні продукти) відповідають визначеним вимогам (я думаю, її перевірка)

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

3. Виявити дефекти

   Я погодився б, що тестування - це перевірка, перевірка та виявлення дефектів. Це правильно?

Я думаю, ти це правильно зрозумів.

1. Перевірка та перевірка - це різні речі і насправді досить чітко визначені. Хоча документ мені не дуже подобається, ISO 9000ff дуже важливий для якості та визначає перевірку як порівняння товару з його вимогами, а перевірку як перевірку, чи відповідає він дійсно потребам замовника / користувача, і всі ми знаємо, що це може відрізнятися .

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

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

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

Ви не можете перевірити потреби користувача та перевірити правильність технічних характеристик за кодом. Тому перевірка не проводиться шляхом тестування.

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

У реальному світі тестування - це перевірка та перевірка програмного забезпечення, яке відповідає вимогам програмного забезпечення (ділового / функціонального / нефункціонального). Мета їх - визначити, чи відповідає програмне забезпечення за призначенням. Будь-яка поведінка, яка не відповідає вимогам програми, є дефектом - серйозність якого потрібно буде зважити, перш ніж визначити, чи відповідає програмне забезпечення за призначенням.

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

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

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

Тим не менш, тестування повинно проводитися з метою виявлення помилок, а не з метою перевірки відповідності вимогам.

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

Великий тестер пристрасно розбиває програмне забезпечення, а не напружує його.

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

Тож для цієї частини питання, пошук помилок та перевірка може бути лише двома сторонами одного процесу:

• тести не вдається: виявлені дефекти

• тести проходять: перевірка зроблена (принаймні, до певної міри, якщо ви забезпечите достатню кількість і правильних тестів)

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

Все залежить від вашого визначення поняття "верифікація". Наприклад, формальна перевірка, як правило, не робиться командою з контролю якості, а натомість є відповідальністю розробників. Майже ніхто не проводить офіційну перевірку через пов’язану з цим високу вартість (необхідний розрив знань та ресурси).

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

Таким чином, переконатись, що програмне забезпечення працює відповідно до вимог - це головна мета QA (спеціаліста із забезпечення якості - він ще років тому називався просто тестерами). Однак це не просто тестування . QA забезпечує належний набір процесів для перевірки якості відповідного продукту або принаймні прийнятий на етапі проектування проекту.

Таким чином, в ідеалі ви б очікували, що ваш QA перевірить додаток відповідно до набору вимог, а не просто намагатиметься перевірити його, порушивши програмне забезпечення та виявивши дефекти.