Розробка тестів

Механізм варіантів використання (uses cases), розглянутий у темі №7, дозволяє відповісти на питання, як буде використовуватися система. Щоб перевірити систему, реалізовують аналогічний механізм – тестових сценаріїв (test cases).

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

Тестові сценарії, як і варіанти використання, можуть підтримувати різні рівні абстракції. Розрізняються концептуальні і детальні ТС. Концептуальний рівень припускає опрацювання процедури тестування, інваріантної до конкретної реалізації варіанта використання.

Як використати тестові сценарії для тестування вимог? У [1] пропонується наступна процедура:

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

2. Переконатися, що кожний з ТС здійсненний на існуючому наборі вимог.

3. Переконатися, що для кожної вимоги представлений як мінімум один ТС.

4. Прокреслити «шлях» кожного з ТС на карті діалогів. Це дозволить: виявити некоректні або пропущені вимоги, виправити помилки на карті діалогів і відшліфувати варіанти тестування.

Як бути з тестуванням нефункціональних вимог? Згідно [5], процедура аналізу вимог вважається виконаною тільки тоді, коли усі вимоги, включені до специфікації, мають методи оцінки відповідності ним створюваного програмного продукту.

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

Визначення критеріїв прийнятності

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

Щоб не відкладати таке важливе питання до моменту приймання системи, украй важливо, разом з формуванням вимог, залучати замовника на ранніх стадіях створення продукту до процесу формування критеріїв прийнятності. Критерії прийнятності (acceptance criteria) повинні відбити точку зору замовника на те, що він вважає «правильною системою».

Делегування розробки тестів на прийнятність користувачам — ефективна стратегія розробки вимог [1]. Це дозволяє вже на етапі збору інформації перейти від формулювання питання з «Що треба робити за допомогою системи?» до «Як ви робите висновок про те, що система задовольняє ваші потреби?» Якщо клієнт не зможе описати, яким чином він зрозуміє, що конкретна вимога задоволена системою, значить, вимога сформульована недостатньо ясно.

Якнайраніше формування тестів для перевірки прийнятності дозволяє виявити дефекти у вимогах.

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

Література до теми:

1. Вигерс К. Разработка требований к программному обеспечению. Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2004. -576с.

2. http://www.agile.org.

3. Соммервилл И. Инженерия программного обеспечения, 6-е издание

4. Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 624 с.

5. Орлик С. Программная инженерия. Качество программногообеспечения (Software Quality) http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf