РУКОПИСИ НЕ ГОРЯТ. НО И НЕ ТОНУТ…

Тестовая документация Специально для 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