65. Управління якістю проекту.

66. Додаткова інформація про підхід до розробки.

67. Тестування.

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

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

Тут термін «тестування» позначає перевірку тих робочих продуктів, які визначають код, розроблювальних (і/або використовуваних) у проекті програм. Усі інші види

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

Для робочих продуктів, одержуваних на різних етапах життєвого циклу мети й Роль тестування різні:

• робочі продукти аналізу бідують твердженні замовником, щоб упевнитися в коректності вистави про приклад ну область і про користувачів, а також утому,

що всі вимоги враховані;

• робочі продукти конструювання потребують перевірки їх відповідності результатам аналізу, щоб упевнитися в тому, що обрані проектні розв'язки забезпечують виконання всіх вимог;

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

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

• по-друге, легше виявити й виправити помилку не в результаті наслідків з неї, які зробили протиріччя явним, а під час її появи, коли помилка не «обростила» багатьма зв'язками й впливами на інші компоненти програмної системи.

Конкретний план тестування може бути складений, коли готовий план ітерацій проекту, тобто після проходження контрольної крапки 2 життєвого циклу проекту «Загальні вимоги й загальний план складені». До цього моменту доцільно розробити загальні положення про тестування, які служать технологічним регламентом надалі. Ці положення фіксують наступне. Для кожної діяльності, певної в плані ітерацій, для кожної ітерації й для проекту в цілому вказується:

• Які результати тестуються, яким методом і як визначається, що тестування виконане;

• Як для діяльності даного виду визначається період тестування — час, що приділяється для тестування в плані ітерації (резиза, проекту);

• Які кадрові і технічні ресурси потрібні для кожного з періодів тестування;

• Які інструменти використовуються при тестуванні даного виду діяльності;

• Що слід вважати якістю тестування.

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

(можлива та інша градація). Для його завдання використовуються відомості уточненого замовлення і угоди з Концепцій розвитку проекту. Рівень якості тестування

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

виправляються на поточній ітерації, а інші — у ході наступних ітерацій, можливо, у наступних релізах). Цей показник прямо зв'язується з виділенням часу й інших ресурсів, для проведення тестування, виконання діагностики й виправлення помилок:

• високий — вимагає виділення для тестування часу 95% і більш із сумарного часу, відведеного для робіт даної ітерації;

• середній — для тестування потрібно від 20% до 50% із сумарного часу робіт даної ітерації;

• низький — для тестування приділяється порядку 5% сумарного часу робіт даної ітерації.

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

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

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

• указати причину помилки;

• визначити, що треба виправити й оцінити ресурси, які необхідно виділити на виправлення;

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