3. Місце тестування в циклі розробки програмного забезпечення
В попередніх розділах йшлося про помилки програмного забезпечення (ПЗ). Дуже часто називаючи усі проблеми ПЗ «помилками» (bugs), тепер треба розкрити суть цього поняття.
Повернемося до визначення некоректної роботи ПЗ:
ПЗ не робить чогось, що, відповідно до специфікації, воно повинне робити.
ПЗ робить щось, що, відповідно до специфікації, воно не повинне робити.
ПЗ робить щось, що не згадується в специфікації.
ПЗ не робить чогось, що не згадується в його специфікації, але повинне.
ПЗ складно зрозуміти, важко використовувати, воно повільне, або - на думку тестерів ПЗ - буде сприйнято кінцевими користувачами, як явно не правильне.
Проілюструємо роботу цих правил на прикладі калькулятора:
Нехай у специфікації калькулятора зазначено, що він має правильно виконувати додавання, віднімання, множення та ділення. Якщо тестер, одержавши калькулятор, натискає кнопку «+», і нічого не відбувається, то це помилка відповідно до правила №1. Якщо надана відповідь буде неправильною, то це теж буде помилка №1.
Специфікація може містити вимогу, що калькулятор ніколи не повинен зависати. Якщо тестер щось увів, і калькулятор перестав реагувати на всі подальші дії, це помилка відповідно до пункту №2.
Припустимо, тестер одержав калькулятор на тестування й виявив, що крім додавання, віднімання, множення й ділення, він також містить квадратний корінь. Ніде в специфікації цього не було -честолюбний програміст просто додав його, оскільки вирішив, що це
буде корисна функція. Це не функція - це скоріш за все помилка відповідно до правила №3.
Правило №4, можливо, звучить дивно з подвійним запереченням, але його завдання - вловити нюанси, які були упущені в специфікації. Тестер почав тестувати калькулятор і виявив, що коли батарея сідає, він перестає рахувати правильно. Ніхто ніколи не замислювався, як повинен поводитися калькулятор у таких випадках. Поганим рішенням була б розробка ПЗ з розрахунком на те, що батарея повинна завжди бути повністю зарядженою. Тестер очікував, що зможе продовжити свою роботу, доти батарея не сяде остаточно, або хоча б доти там не залишиться зовсім трошки заряду. Калькулятор рахує не правильно з батареєю, що розряджається, але ніде не записано, як він повинен поводитися в такій ситуації. Це помилка відповідно до правила №4.
Правило №5 дуже узагальнене. Тестер - перша людина, що користується програмою. Якщо це будете не він, то першими користувачами стануть покупці. Якщо тестер знайде щось, що здасться йому не правильним, не важливо чому, - це помилка. У випадку з калькулятором, можливо, він знайде, що кнопки замалі, через що натискати їх незручно. Можливо, при яскравому освітленні складно розібрати, що на екрані. Все це помилки відносно правила
№5.
Зауважимо, що кожна людина, яка використовує ПЗ, буде мати різні сподівання і свою думку що до того, як воно повинно працювати. Це неможливо - написати ПЗ, яке всі користувачі назвуть ідеальним. Тестер ПЗ повинен завжди пам'ятати про це, застосовуючи правило №5 у своїй роботі.