Page 52 - 4787

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

Деякі розробники для тестів з квадранта 2 застосовують термін

,,примальні тести’’ (asseptance tests), але слід зауважити, що приймальні тести
охоплють більш широкий діапазон тестів, що описані в квандрантах 3 і 4.

Приймальні тести первіряють, що всі аспекти системи, включаючи такі якості

як зручність використання і продуктивність, відповідають вимогам
користувача.

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

при кожній зміні або додаванні коду, формують фундамент гнучкої команди. Ці

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

коду, запобігаючи небажаним побічним ефектам.

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

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

відмінностей в середовищі. Тільки-но отримано повідомлення електронної

пошти про збій збірки, особа, що зафіксувала помилковий код, виправляє його.
Бізнес–орієнтовані функціональні тести запускаються на ,,повній збірці’’, яка

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

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

Тести в квадрантах 1 і 2 пишуться для того, щоб допомогти команді

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

прикладам, представленим замовником.

Тести, що критикують програмний продукт. Відомо, що замовникові
виразити свої вимоги до програмного засобу досить важко. І навіть, якщо

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

замовник.

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

51