Page 34 - 4566

Роль експерта предметної області може бути корисна
для розробника, оскільки дає додаткові критерії при рішенні
його власних проблем. Проте ця додаткова роль часом
надмірно перевантажує співробітника і, як наслідок, існує
небезпека затягування термінів проекту або його етапу
(принцип 3). Те ж можна сказати і про поєднання ролей
розробника і фахівця з інтерфейсу. Але тут поєднання
доцільніше, особливо для розробників, яким доручені
завдання, що стосуються інтерфейсу. Причина цілком
зрозуміла: виключається додаткова ланка між розробником і
зацікавленими в якісному інтерфейсі особами.
З приводу тестувальників потрібні деякі роз'яснення.
Слід розрізняти два види тестування: тестування модулів,
автономне за своєю суттю, і тестування наданих функцій, яке
може бути і комплексним (перевірка спільного виконання
функцій), і автономним, коли перевіряється працездатність
окремого аспекту системи. У першому випадку завдання
тестувальника неможливо виконати без знання не лише
призначення, але і структури модуля, що перевіряється.
Найкраще в цьому розбирається розробник модуля, тож саме
йому цей модуль і налаштовувати. Автономне тестування є
іншим боком перевірки працездатності модуля. В обох
випадках самотестування для розробника є не додатковою
роллю в проекті, а частиною його професійних обов'язків у
межах автономного відлагодження.
Цікавим є метод перехресного тестування, коли
розробники незалежних компонентів проекту тестують
функціональність один одного. Тут можна говорити про
перехресне поєднання ролей розробників і тестувальників,
оскільки для виконання перехресного тестування потрібне
різне уявлення про випробовуваний модуль.
Матеріали замовника про діяльність користувача, для
автоматизації якої призначена програма, розглядаються в
якості інформаційної бази комплексного тестування.

34