тестування на основі аналізу дефект

ів (defect-based

test design)

перевірка введення (input validation)

статичний аналіз коду (static code analysis)

еквівалентне розбиття (equivalence partitioning)

Розробка, орієнтована на поведінку (BDD –

Behavior-Driven Development) розглядає дизайн приймального тесту як діяльність,

яку має виконувати команда тестування після отримання фінальної версії вимог

Як у розробці, орієнтованої на приймання (ATDD –

Acceptance-Test Driven Development), так і в розробці, орієнтованої на

поведінку (BDD),

І в розробці, орієнтованої на прийняття (ATDD), і в

розробці, керованої поведінкою (BDD), приклади приймальних тестів записуються

інженером з автоматизації тестування як код автоматизації тестування

У розробці, орієнтованій на прийняття (ATDD), тест-кейс

и

формують перед формуванням критеріїв приймання

Критерії приймання визначають, що має бути перевірено, щоб переконатися, що вимога або історія користувача були реалізовані правильно

Тестувальники не повинні брати участь у написанні критеріїв приймання , щоб забезпечити незалежність тесту

Критерії приймання є характерними для гнучких фреймворків, де вони відповідають функціональним вимогам

У розробці ПЗ, що керується приймальними тестуваннями (ATDD – acceptance test-driven development), критерії приймання замінюють приймальні випробування

Бізнес-цілі, бізнес-потреби та вимоги описують на

різних рівнях абстракції те, що має бути досягнуто

Щоб визначити бізнес-потреби, бізнес-аналітик спочатку

повинен зрозуміти бізнес-цілі та вимоги

Бізнес-потреби відповідають бізнес-рішенню, тоді як

вимоги бізнесу визначають бізнес-проблему або можливість

Бізнес-цілі та бізнес-потреби є синонімами

Аналізом (Test analysis)

Імплементацією (Test implementation)

Плануванням (Test planning)

Дизайном (Test design)

Моніторингом (Test monitoring)

здатність реагувати на швидкі

зміни в технологіях;

критичні функції реалізуються в першу чергу та

тестуються значно ретельніше;

раннє планування виконання тестування та виялення

завершення першої версії остаточно затверджує вимоги і

проект;

найменш критичні задачі реалізуються останніми, що

мінімізує наслідки відмови через

замовник повинен усвідомлювати, що загальні витрати

на виконання проекту не будуть знижені;

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

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

може виникнути тенденція до відстрочення рішень важких

проблем на майбутнє із ціллю продемонструвати керівництву успіх, отриманий на ранніх

етапах розробки;

усі можливості мають бути реалізовані одразу;

Усі можливості проектованої системи повинні бути

реалізовані одразу;

Усі

три перелічені спершу випадки є показником для використання послідовної моделі.

Система зазвичай невеликого розміру та складності;

Жоден із наведених вище аргументів не свідчить на

користь послідовної моделі;

Вимоги до системи зрозумілі і суттєвих змін не

передбачають;