РУКОПИСИ НЕ ГОРЯТ.
НО И НЕ ТОНУТ…
Тестовая документация
Специально для Grammarly Test Club 2013
О себе
Ярослав
Пернеровский



Тренер в QA Factory
Test Automation Lead в
Global Logic
Документация




Какие ассоциации у вас вызывает это слово?
Какие вы знаете документы в тестировании?
Кто их должен писать?
Что такое тестирование?


Это в первую очередь процесс
Процесс
Подготовка

Анализ
результатов

Выполнение
Еще раз…


Тестирование - одна из техник контроля
качества, включающая в себя активности по
планированию работ (Test Management),
проектированию тестов (Test Design),
выполнению тестирования (Test Execution) и
анализу полученных результатов (Test Analysis)
Тест документация
Выполнение

Подготовка
•
•
•
•
•
•

Test Plan
Test Design
Test Case
Test Procedure
Traceability Matrix
…

•
•
•
•

Test Log
Coverage Matrix
Check-lists
…

Результаты
•
•
•
•
•

Bug Report
Release notes
Test Summary
Test metrics
…
Более того, есть стандарты…






IEEE 829-1998
IEEE 829-2008
RUP
MSF
…
Стандарты это безумно круто








Все уже придумали до нас
Чистый лист отменяется
Бери и пользуйся!
Пользуются
Это хорошо
Но…
Но не будем спешить..









Водопадная модель разработки живее всех живых
Водопадная модель подразумевает написание
кучи документов
Зачем?
Определенность
Прогнозируемость
Контроль
Первая крайность














Много документации
Документация излишне подробная
Документация не успевает обновляться
В документации сложно разобраться
Документация устаревает
Технологический долг растет
Время уходит
Мотивация снижается
Сроки срываются
Качества нет
Не надо так
Вторая крайность









Безумный аджайл
Working Software Over Comprehensive
Documentation
Документации нет вообще
Зато есть много времени
И со временем приходят проблемы
Качества как не было, так и нет
Компромиссы






Документация должна быть
Но писать нужно только необходимые
документы
В достаточном объёме
С адекватной детализацией
Что же у нас Самое главное?








Тест План
Что? Где? Когда? Кто?
Тест Стратегия
Как?
Тест Кейсы
Это святое
И тут море проблем
А еще ?








Баг репорты
Все знают, все умеют, но в итоге все равно
фигня
Репорты
Как понять что я протестировал?
Чек-листы
Матрица покрытия
План и стратегия




Можно без них ?
Иногда можно
Но лучше сделать, хотя бы в самом
примитивном виде
Что не так с тест кейсами?








Их нет
Они есть, но они плохие
Начинать надо с идей для теста (дизайн)
Расставлять приоритеты и уточнять данные
(специфицировать)
Описывать собственно тест (процедура)
И это есть в стандарте IEEE-829
Test design specification
 Test case specification
 Test procedure specification




http://testitquickly.com/tag/grammarly-test-club/
Что еще не так с тест кейсами?









Их много
Их никто не использует
Их никто не обновляет
Они никому не нужны…
Тестировщики используют чек-листы в екселе
Регрессия?
Руками?
Рецепт счастья?





Тестировщик должен тестировать
Документация должна возникать сама по себе
И сама себя поддерживать в актуальном состоянии
Really?

Требование

История

Автотест
Ну и как?



Specification by example
BDD

http://blogs.developpeur.org/blogs/thavo/image_thumb_6371D030.png
Что не так с покрытием?










Никто не знает что протестировано
Никто не знает что тестировать
Тестируем новую функциональность
Ок
А потом?
Тестируем критические места
Тестируем все остальное
Где это увидеть?
Матрица покрытия



Банально в екселе
Не банально в каком то модном тулзе
http://www.w3.org/2001/sw/rdb2rdf/wiki/R2RML_TC
http://www.ibm.com/developerworks/rational/library/04/r-3217/
Что не так с баг репортами?









Баг репорт по сути не баг репорт
Простые вещи
Описание
Как воспроизвести
Ожидаемый результат
Фактический результат
Остальное - детали
Плохой баг репорт
Уже не плохо
Хороший баг репорт
Инструменты



Jira + Wiki
Excell
OneNote
MindMaps (Xmind)



Cucumber/Jbehave/Specflow/Codeception/…




Тестировщик – источник документов






Именно так
Главное не лениться
Разобрался с чем-то – запиши, потом
пригодится
Документы в общем доступе
Что делать?










Писать как минимум чек листы
Или писать правильные тест кейсы
Старятся делать матрицу покрытия
Писать баг репорты правильно
Документировать постоянно
Не накапливать технологический долг
Это не сложно, но безумно полезно
fin

Ярослав Пернеровский (QA Factory/GlobalLogic):"Рукописи не горят, но и не тонут".