-

Забезпечення Якості -- Quality Assurance
-

четвер, 9 жовтня 2008 р.

Документація у тестуванні

Документація займає важливе місце у процесі розробки програмного забезпечення. Хоча, варто визнати, що комунікація є кермом ... Гуру бізнес-водіння умудряються розробляти проекти з мінімальною кількістю документів (ідеться про проекти, де задіяно до 5 осіб). Довготривалі проекти з числом виконавців більше трьох осіб прямують до нескінченної кількості непорозумінь і безвихідних ситуацій у випадку відсутності достатньої кількості документації.

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

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

З готовою документацією тестувати досить легко і приємно. Такий підхід, як мінімум, запевняє у максимальному тестовому покритті проекту. Також не варто обмежуватися тестовою документацією. Трішки творчого підходу при виконанні будь-якого завдання не завадить ;). Хорошим показником якості роботи тестера є тип і пріоритетність знайдених Багів, котрі також повинні бути задокументовані у зрозумілому стилі.
Кінцевий підсумок про якість продукту, який базується на результатах тестування, тобто знайдених Багах, зображається у Тестовому Звіті.
Найкращим шаблоном документу є той який є зручним для усіх хто його читає :).

4 коментарі:

  1. "Традиційно замовник отримуючи наступну версію продукту змінює вимоги або у нього появляються нові ідеї"

    Це, як на мене, основна риса замовника, а от велика біда починається тоді - коли його "святість" своєю новою ідеєю спричиняє конфлікт старого функціоналу з новим, а бідні QA що їли/гризли/курили функціональні вимоги і в важких муках вродили ТЕСТ ПЛАН змушені знову вертатись на етап "зачаття"

    "... і не нав'язливе фантазування на тему "як це буде тестуватися" ..."

    фантазування супроводжується тісними діалогами з девелоперами на тему "... ми то так робити не будем - зробим трішки інакше"
    Хто пам"ятає карикатуру "Девелопери будують качелю на дереві"? Так і виходить щось подібне :)

    І взагалі необхідно щоб девелопер, або якийсь там Тім-лід(Самий крутий ШЕФ на проекті) покурив (почитав) ваше творіння під назвою "Тест план", додав свої зауваження, пропозиції. Це наперед захистить вас і його від усіляких непорозумінь в майбутньому.

    ВідповістиВидалити
  2. Ось тут можна переглянути ролик про славнозвісну качелю.
    http://ru.youtube.com/watch?v=OfgfnZZdMlI

    ВідповістиВидалити
  3. шось забагато документів вийшло

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

    ВідповістиВидалити