какая бывает тестовая документация
Виды тестовой документации
Создание тестовой документации является вторым этапом жизненного цикла ПО.
Тестовая документация включает в себя:
Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Хороший тест план должен описывать следующее:
Критерии начала тестирования:
Критерии окончания тестирования — результаты тестирования удовлетворяют критериям качества продукта:
Преимущества тест плана:
Составляющей частью планирования тестирования (как отдельного документа или же процесса планирования в целом) является стратегия тестирования. Стратегия может быть:
Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования.
В стратегии тестирования описывают:
Стратегия может быть представлена как в виде традиционно расписанного документа, так и в более наглядном формате, например, используя таблицу:
В общем, план тестирования устанавливает цели процесса тестирования, он определяет, что будет проверяться, а стратегия тестирования описывает, как достичь целей, поставленных в плане тестирования.
Пользовательские истории
Пользовательские истории (User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.
Примеры:
Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
Структура юзер стори
Текст самой юзер стори должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится.
Правила на написание User Story
Actor
Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла — значит эта часть бесполезна.
Джеф Паттон предлагает следующее:
Действие
Это суть истории, «что нужно сделать». Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать» авторизуется и выполняется поиск» или «указывает параметры поиска и выполняет поиск». Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне «ЧТО?» делает, а не «КАК?». Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное «КАК» — решение.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите «чтобы …».
Уберите эту часть из истории. Если ничего не потеряли — значит формализация ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки «чтобы». Для каких-то историй можно указать ценность истории в таком формате, но не для большинства.
Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Представим что вы создали историю — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение».
У меня Аcceptance Сriteria — это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ». То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.
Практические советы по написанию пользовательских историй
Пример юзер стори:
продолжение:
Что такое тестовая документация и зачем она нужна?
Как и в любом другом процессе, документация в QA помогает командам организовать свою работу. С ее помощью мы можем стандартизировать процесс, дать определение терминам, установить основные этапы тестирования и держать всех членов команды в курсе дел.
Что такое тестовая документация?
Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д.
В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных).
В чем важность тестовой документации?
Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.
Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.
И QA-инженеры, и клиенты могут хотеть получить на выходе приложение, вообще не имеющее багов. Но это не достижимая цель, а мечты. Поэтому имеет смысл обсудить, что будет определять конец фазы QA.
Например, мы можем протестировать весь функционал один раз. Или тестировать приложение до тех пор, пока в продакшене не останется критических ошибок. Или быстро проверить критически важные для бизнеса функции, что позволит успеть к дедлайну.
Как правило, попытки оговорить все это в переписке или телефонных переговорах неэффективны. Все дело в человеческом факторе. У кого-то просто слишком много информации, которую нужно обработать и запомнить. Кто-то может неправильно понять договоренности. В результате у каждого появляется своя интерпретация требований и целей.
Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.
Непонимание того, как и почему должна вести себя та или иная функция, приводит к большему количеству ошибок. Неправильная расстановка приоритетов может привести к пропуску багов и предоставлению неполных отчетов. Примеры можно продолжать и продолжать.
Какую тестовую документацию используют QA-команды?
Наиболее часто используемые документы — это планы тестирования, чеклисты, тест-кейсы, сценарии использования, баг-репорты и спецификации требований.
План тестирования (test plan)
План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта.
В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.
Чеклист (checklist)
Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик.
Выглядит чеклист как список функций с указанием статуса — результата проверки.
Чеклисты могут использоваться вместо тест-кейсов, поскольку их легче подготовить. Но если вам нужно более конкретное описание процедуры, без тест-кейсов не обойтись.
Тест-кейс (test case)
В тест-кейсе содержатся:
Компании могут использовать разные форматы тест-кейсов, но информация в них всегда очень подробная и конкретная.
Сценарий использования (use case)
Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением.
Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя.
При создании юзкейсов тестировщики учитывают требования и бизнес-цели.
Баг-репорт
Баг-репорт предоставляет полную информацию о баге (его описание, серьезность, приоритет и т. д.) и документирует шаги и условия для воспроизведения этого бага.
Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.
Требования (requirements specification)
Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения.
В требованиях указываются свойства, качества и особенности разрабатываемой программы. Используя эту информацию, команды могут избежать недоразумений и разногласий.
Как все это работает?
Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей.
А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.
Чем крупнее проект, тем больше документации нужно.
Если команда использует для сложного продукта только чеклисты, есть риск неправильного понимания приоритетов и проведения неэффективных тестов. Причина кроется в отсутствии деталей. Чеклист только называет функцию, и каждый тестировщик может интерпретировать объект тестирования и результаты по-своему.
Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет.
Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.
Аналогично, со временем устаревают и теряют свою актуальность тест-кейсы и сценарии использования. Может появиться новый функционал, который тоже нужно покрыть тестами. И если вы не будете все тщательно записывать, вы рискуете получить бесполезную документацию.
В заключение
Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.
Что касается преимуществ документирования рабочего процесса, то они вполне очевидны. Описанные нами документы помогают упорядочить имеющуюся информацию. Благодаря этому даже новичок в команде сможет легко разобраться, что к чему. И хотя создание документации требует дополнительного времени, ее отсутствие приведет к куда большим временным затратам.
QA evolution
Итак, основные артефакты тестирования ПО и тестовая документация:
Тестовая документация
План тестирования (Test Plan) — это документ или совокупность документов, расписывающих все тестовую активность пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. Поверхностно можно выделить моменты описываемые в тест-плане : объект тестирования, расписания работ, критерии начала и окончания тестирования, стратегию, риски и список проводимых работ.
Тест дизайн (Test Design) — процесс проектирования и создания тестовых случаев, для проведения в дальнейшем проверки ПО с учетом спецификации проекта и требований.
Тестовый случай (Test-case) — строго сформированный документ (на каждой организации могут быть свои правила, в той или иной мере похожие) с подробным описанием шагов и действий, для проверки одной части функционала, со строго заданными критериями прохождения.
Юзе-кейс (Use-case) — документ для тестирования продукта или ПО менее официален и используется для предугадывания и построения на основе предполагаемых сценариев использования путей тестирования приложения. Часто разрабатывается на основе бизнес задач и проверки критического пути тестирования.
Баг-репорт (Bug report) — документ, случай — в котором описывается ситуация, последовательность шагов приведшая к возникновению ошибки на тестируемом ПО. Чаще всего требуется описание ожидаемого результата для такой конкретной последовательности шагов который будет являться правильным.
Чек-лист (Check-list) — документ который содержит в себе краткое описание функциональности всего приложения, для проверки его (ПО). Создание и написание чек-листа обычно заменяет написание тестовых случаев, в большинстве случаев ускоряет подготовку к проведению тестирования.
Спецификация требований (Software Requirements Specification) — это полное, четкое описание разрабатываемой программы. Ключевыми особенностями является полное описание всей функциональности программы, четкость требований, отсутствие неточностей в их описании, простота понятий, и достаточно четкая детализации. (Тестирование требований)
Тестовая документация
Тестовая документация на практике
На практике тестовая документация, называется еще тестовые артефакты, или артефакты тестирования. Чаще всего используются тест-планы, чек-листы, баг-репорты и спецификации требований. В меньшей степени из-за своей трудо-затратности используются тест-кейсы, хотя практика когда тестовая документация создаются по техникам тест дизайна и достаточно популярна, все же чаще ее результаты оформляют в виде чек-листов.
Какая бывает тестовая документация
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Антонина Бжассо
Давным-давно…
Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.
Аргументом для прекращения написания тестовой документации и каких-либо спецификаций стало то, что на выходе убытков было больше, чем прибыли. Спецификация и различная документация себя не оправдывали, потому что требовать высокие цены за небольшие мобильные приложения компания не могла. Да и какие могут быть чек-листы на новую функциональность, когда:
— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.
В итоге приходилось без документации думать о том, что именно и на какие части могло повлиять. В срочном порядке нужно было проводить полноценное исследовательское тестирование за полчаса! При этом, нужно было найти критические для пользователей баги. Полчаса — это максимум времени, потому что выявленные проблемы еще нужно исправлять и перепроверять. Со временем при такой организации работы начинали возникать проблемы:
— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.
И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…
Как, что и по каким законам там происходило – не было понятно никому. Особенно новым разработчикам, которым передавали дальнейшую разработку:
Коллеги, я потратил три дня на изучение кода, потому что разработчиков этой программы уже нет, и ничего не понятно. Комментариев в коде мало. Непонятно, для чего какой костыль. Если я начну писать, то сломаю то, что работает. Мне легче это всё переписать заново. Давайте напишем нормально.
Так работают множество компаний. И далеко не все получают хорошие результаты.
Хоть выше описан и неточный рассказ, так как прошло уже много лет и что-то перефразировано, но смысл тот же. Есть компании, которые всё-таки пишут тестовую документацию и активно ею пользуются. Обычно это крупные компании, разрабатывающие многофункциональные масштабные системы. А есть компании, от качества и наличия документации которых могут зависеть жизни людей (например, компания разрабатывает автопилот для самолета). Автопилот можно разрабатывать годами, в итоге один раз выпустив его в свет. Это очень дорогой процесс. Если автопилот будет с багами, то потери будут колоссальными.
Как же сделать так, чтобы продукт получился качественным и хорошо продаваемым? Необходимо начать с документации.
В каком виде и для чего нужна тестовая документация?
Существуют различные виды документации, используемой при тестировании. Каждая из них играет роль в достижении общей цели — создании успешного продукта. Ниже рассмотрим самые распространенные виды документации и причины их использования.
Рабочая проектная документация, используемая тестировщиками
ТЗ (техническое задание) – позволяет донести суть предмета разработки до сотрудников компании. Помогает понять, какой именно функциональностью должен обладать разрабатываемый продукт (иногда с указанием используемых технологий и методов).
Если ТЗ будет в общем доступе, то сотрудники, плохо пересекающиеся с командой разработки, смогут его посмотреть. Возможно, что при тестировании будет обнаружена какая-то проблема, о которой сообщит тестировщик (например, программа не выполняет то, для чего была создана).
Новым сотрудникам не нужно будет рассказывать о смысле программы и методах ее реализации. Можно будет быстро ввести в курс дела любого человека.
ТЗ помогает сотрудникам понять программу лучше. Непонимание разрабатываемого продукта приводит к ошибкам.
При тестировании не будет возникать попыток проверять лишнее. В первую очередь, проверке подвергнется то, что обязательно должно работать по ТЗ.
ТЗ дает возможность понять суть разрабатываемого продукта сотрудникам, которые будут представлять готовый вариант реализации публичной аудитории.
ЧТЗ (частное техническое задание) – создается на основе ТЗ. Обычно содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования предмета разработки пользователями, макеты разрабатываемой части предмета разработки, его логику и суть).
Помогает разработчикам реализовать разрабатываемый продукт точно так, как задумывалось. Помогает понять логику и правила оформления.
Помогает новым сотрудникам разобраться в крупных и масштабных проектах, так как на некоторые системы нужны недели изучения. Имея под рукой ЧТЗ, сотрудник с легкостью сможет найти в нем необходимую информацию, сразу приступив к тестированию. Не нужно будет привлекать других сотрудников, знающих продукт, тем самым отвлекая их от работы. Очевидная экономия времени!
Дает возможность примерно оценить трудозатраты на разработку и тестирование еще до начала работ.
Помогает тестировщикам создать ЧЛ и тест-кейсы до начала работ и тестирования.
ЧТЗ и ТЗ можно отобразить:
в текстовом виде с картинками
в виде графического шаблона-таблицы
в виде интеллект-карт, UML или подобного алгоритма
Проектная документация, подготавливаемая тестировщиками
ЧЛ (чек-лист) – список того, что нужно проверить.
Помогает планировать сроки окончания работ в будущем и настоящем, т.к. в ЧЛ можно указать, сколько времени необходимо для проверки и сколько было затрачено.
Хранит историю пройденных тестов. Можно будет легко вспомнить, какие именно тесты проходили с ошибками, и перепроверить именно их.
ЧЛ с результатами наглядно показывает любому сотруднику компании текущее состояние разрабатываемого продукта. Помогает определить его степень готовности.
Помогает помнить, что уже было проверено, а что нет.
Помогает не забыть, какие тесты необходимо выполнить в первую очередь, какие во вторую, какие в третью и т. д. Это рождает уверенность, что за определенное запланированное время самые важные тесты будут проведены, а результаты по ним — получены.
Чек-листы можно записать:
в виде таблиц (удобно в Google Sheets)
в виде интеллект-карт (удобно в XMind)
в виде списка проверок в специально предназначенной системе (удобно в Sitechco)
в виде списка в текстовом документе, который привычен.
ТК (тест-кейс) – создается на основе ЧТЗ (если оно есть) тест-аналитиками и тестировщиками.
Почему необходимо?
Совместно с ЧЛ может хранить историю тестирования и отображать, что именно и как тестировалось. Можно убедиться, что та или иная функциональность обязательно была или будет проверена и затронута при тестировании.
Помогает быстро включить в работу новых сотрудников. Сотруднику не обязательно неделями изучать предмет разработки, ему будет достаточно открыть сохраненный ТК и пройти его по шагам так же, как проходил другой опытный специалист, ранее работавший в компании.
Помогает увидеть как предмет разработки (программа, сайт и т. п.) должен выглядеть. С имеющимися скриншотами экранов, если они есть, можно будет не забыть о том, что “вон та” кнопка должна быть серой, а не красной.
Тест-кейсы можно отобразить:
в виде таблицы с текстовыми данными
в специальном сервисе для ведения тест-кейсов (например, в TestLink).
Отчет о тестировании – письменный или медийный отчёт о проделанной работе и ее результате.
Наглядно отображает, какой именно результат выполненных работ получен.
Исторически фиксирует информацию. К ней всегда можно будет вернуться и увидеть, что именно было выполнено и что именно получили в итоге.
Уведомляет о результатах всех, кому важно о них знать. Например, для сотрудников отдела поддержки сообщается о выходе новой версии разрабатываемой программы, а также о самых критических проблемах. Можно будет заранее подготовиться к возникающим жалобам.
Помогает принимать решение о дальнейших действиях (например, стоит ли выпускать версию программы в текущем состоянии).
Пример отчета в письменном виде:
Как определить, какую именно документацию необходимо внедрить в проект?
Ниже приведем примеры того, когда и какую документацию и средства можно использовать как необходимый минимум.
На проекте до 15 человек (проекты низкой сложности):
техническое задание (предотвращает неверное понимание задачи разработчиками, т. к. документации нет);
чек-листы (легко поддерживать, не отнимают много времени);
отчеты в виде краткого письма или отписки в специальном сервисе ведения проектов, с указанием критических багов для выпуска.
На проекте от 15 до 50 человек (проекты средней сложности):
база знаний (например, в Wiki);
отчеты в виде письма с приложенным пройденным ЧЛ с указанием критических багов.
Большой проект – от 50 человек и больше (проекты высокой сложности):
частное техническое задание;
база знаний (например, в Wiki);
отчеты в принятом в компании виде (обычно, в виде письма с подробными графиками и приложенными файлами);
прочее (зависит от типа, целей и нужд компании).
Что из этого выбрать — решать самим сотрудникам, т. к. именно они будут заниматься разработкой и смогут понять, что им нужнее. Все вышеперечисленное — лишь примерное представление и рекомендации.
Что делать, если написание документации занимает много времени?
Опыт показывает, что при работе над небольшим проектом нужно уметь приспосабливаться. Можно видоизменить документацию так, чтобы ее ведение было удобным и не занимало много времени. Например, ТЗ можно сделать в виде презентации или вебинара и получить от разработчиков уточняющие вопросы. Каждый из видов документации обладает своими плюсами и минусами, поэтому нужно экспериментировать и не бояться создавать что-то новое. Все научные открытия совершаются методом проб и ошибок, при этом случаются и неудачи!
Но отрицательный результат – это тоже результат! Нужно уметь им воспользоваться и учесть его в своих дальнейших экспериментах, пока не будет достигнут приемлемый итог. Великолепных вам решений и успехов в написании документаций!