2.7.2.Створення середовища для тестування

Якщо говорити про середовище для тестування, потрібно виділити в ній апаратну частину і “людський” фактор. Що стосується апаратури, те найкраще використовувати для тестування той же комплекс апаратних засобів, що буде стояти в користувача (замовника). Якщо додаток повинний працювати в мережі, тестування його на окремому комп'ютері¹⁰ не дозволить знайти безліч специфічних, “мережних” помилок, зв'язаних зі спільним доступом до файлів і записів.

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

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

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

Аж ніяк не всі розроблювачі можуть добре тестувати програми. Деяким це вдається краще, і для них такий рід діяльності навіть більш привабливий. Часто це люди, яким подобаються всякі бюрократичні процедури. Нерідкі випадки, коли здібні розроблювачі не виявляють таких же здібностей при тестуванні. Тут може зіграти злий жарт саме близьке знайомство з логікою роботи програми — підспудно при цьому вводяться саме такі набори даних, що передбачалися при розробці. Помилки ж найчастіше виникають у нетривіальних ситуаціях, що і в голову не могли прийти під час проектування. Крім того, логіка поводження розроблювача і користувача стосовно програми дуже відрізняється. Тому дуже корисна практика передачі функції тестування кому-небудь сторонньому, що не приймав участі в роботі над проектом на ранніх стадіях.

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

2.7.3.Створення тестових наборів даних, що забезпечують повноту накриття додатка

Набори тестових даних прийнято розділяти на набори для білого ящика (white box testing) і набори для чорного ящика (black box testing). Набори першої групи розробляються для того, щоб змусити програму задіяти в ході обробки всі можливі гілки процесу обчислень. Для формування такого набору потрібно дуже добре розбиратися в логіці роботи додатку що тестується, а тому процес тестування за допомогою цього типу даних іноді називають logic - driven — відомий логікою. Другий підхід до створення набору даних не вимагає знання алгоритмів обробки в додатку — воно вважається чорним ящиком. Програма при цьому працює з випадковими даними, і немає ніякої впевненості, що ці дані змушують інтенсивно працювати усі компоненти додатка.

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

• аналізуються і тестуються всі можливі шляхи виконання алгоритмів обробки;

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