2.6Результати нового підходу

Новий підхід, опробуваний на ряді проектів протягом більш ніж трьохлітнього терміну, показав добрі результати. Проводити тестування стало значно легше, завдяки ранньому виявленню і усуненню помилок. В декількох випадках в проектах, що використовують ці методи, спостерігалося істотне (20-38%) зниження кількості помилок на завершальній стадії тестування продукту. Це привело до зниження трудовитрат по тестуванню продукту на 50%.

2.7Застосовність V-модели

Значущість V-модели тестування була продемонстрована в проектах, різних стилів розробки, що використали дещо. У разі швидкої розробки (rapid development) V-модель допомагає визначити процес перевірки коректності, який необхідно виконувати для кожної ітерації розробки. Надалі це збільшує необхідність визначення кожної ітерації в термінах "тестових вимог". Для об'єктної розробки (object development) V-модель забезпечує основу для організації тестування на рівнях класу і компоненту.

2.8Заповіді тестування

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

Розробляйте плани для тестування наперед. Починати думати про тестування безпосередньо перед запуском тесту - це недолік багатьох проектів. Відсутність належного планування часто приводить проект в режим "звалища", коли умови тестів, дані і середовище тестування незлагоджені. Це віднімає масу часу і сил, а у результаті заходи формального тестування починаються пізніше, та ще і в умовах вичерпаного бюджету. План тестування повинен бути невід'ємною частиною початкових планів проекту. Випереджаюче планування допомагає організації почати тестування вчасно і залишатися в рамках плану і бюджету.

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

Визначайте критерії входу і виходу. Критерії входу і виходу визначаються для тих моментів, коли стадія починається і закінчується. Керівники робіт повинні визначити їх під час планування проекту. Застосування критеріїв покращує просування проекту із стадії на стадію.

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

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

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

Залучайте замовника до процесу розробки. Розробники проекту повинні залучити замовника в процес розробки і тестування. Це можливо в рамках описуваної методики тестування, де умови тестів з'являються разом із специфікацією. При цьому необхідна незалежна команда розробників, що здійснюють тестування. Залучення замовників в роботу за визначенням умов тестів дозволяє колективу розглядати що висуваються замовником критерії як умови тестування, а не як чиїсь суб'єктивні побажання. Умови тестування визначаються метою роботи, побажання - ні. Колектив також виграє від включення замовників в процес тестування, оскільки це підтримує їх зацікавленість протягом всього процесу розробки.

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

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

Ефективно використовуйте інструменти тестування. Тестування, поза сумнівом, може бути вельми трудомістким процесом. Інструменти тестування автоматизують окремі сторони цього процесу і, таким чином, допомагають заощадити час і зусилля. Зацікавлені колективи повинні розглядати ці інструменти як частину своїх планів тестування, архітектури тестування і середовища розробки. Перевага такого підходу може бути істотною - один з наших колективів повністю автоматизував регресивне тестування свого клиент-серверного online-додатку.