Как написать тестовую документацию

Тестовая документация и анализ требований

В преддверии старта курса «Game QA Engineer» публикуем текстовую расшифровку онлайн-интенсива, который провела Надежда Чертовских — руководитель отдела QA в компании BeresnevGames и преподаватель OTUS.  

Цели интенсива:

• познакомиться с основными видами тестовой документации;

• проанализировать документ от game-дизайнера;

• попрактиковать составление чек-листа.

Для начала давайте обсудим такой животрепещущий вопрос: почему сегодня на курсе «тестировщик игр» мы обсуждаем документацию?

Как тестировщик, который целый день только в игры играет и сообщает разработчикам об обнаруженных ошибках, связан с документацией? Какая вообще работа у тестировщика игры? Какие у тестировщика могут быть документы?

Существует распространённое заблуждение, что тестировщик игр целый день только и делает, что в игры играет. Но на самом деле это не так. Тестировщик в геймдеве точно  такой же тестировщик, как и в любой другой сфере, и работает точно по такому же принципу, но продукт у него не web-страничка, не application на операционной системе, а игра (мобильная, консольная, десктопная).

Тестирование может быть автоматизированным и ручным

На интенсиве мы поговорим в целом об артефактах тестирования, с которыми работает тестировщик:

1. План тестирования (Test Plan)

2. Тест-кейс (Test Case)

3. Чек-лист (Check-List)

4. Баг-репорт (Bug Report)

5. Отчёт о тестировании (Test Report)

6. Инструкция (Manual)

Из этого мы можем сделать вывод, что тестировщик не только читает требования, которые подготовили к продукту, но и сам генерирует документы.

В ходе интенсива мы более подробно поговорили о 6 типах документов, которые перечислили выше, обсудили, какие из них полезные, какие используются чаще, какие меньше и составили чек-лист по требованиям.

План тестирования

План тестирование (далее ПТ) или тест-план – это большой документ, который чаще всего описывает весь объем работ по тестированию проекта либо части проекта (например, релиза или предрелизного билда). ПТ описывает, что будет тестироваться, в какие сроки, какими инструментами, какая команда, обязанности и ответственности каждого члена команды. Также часто в ПТ включается стратегия тестирования, график релизов на  несколько ближайших спринтов. В зависимости от команды бывает разная степень детализации ПТ и его могут делать разные люди в команде. В каких-то компаниях ПТ делает менеджер, в каких-то middle-тестировщик, либо senior-тестировщик, либо тимлид отдела тестирования.

Всё, что мы далее обсудим по документам, которые генерирует тестировщик, может отличаться от компании к компании, от команды к команде. В зависимости от команды и компании форм-фактор всех документов может быть либо уже обговорён и установлен, либо, если вы приходите первым QA специалистом на проект, то вы сами устанавливаете, как удобно вам.

Форм-фактор у тест-плана может быть разный (схема, интеллектуальная карта и т.д.) и зависит от того, как команде будет удобнее взаимодействовать с документами.

Чаще всего ПТ требуется именно для людей, которые принимают решения по проекту, чтобы они поняли, что в следующий момент мы делаем: релизим билд или нужно подвинуть сроки, добавить к тестированию, убавить к каким-то другим срокам. И лучше всего не делать ПТ огромным, чтобы человек, который будет его читать, смог осилить весь объём. Если посмотреть примеры тест-планов в интернете — часто это одностраничная схема, чтобы все в общем и целом понимали, какой объем тестирование предстоит. Обычно план тестирования делается до начала тестирования и до момента релиза.

Таким образом План тестирования:

• описывает стратегию тестирования, цели, график, оценку, результаты, а также ресурсы необходимые для тестирования;

• имеет разную степень детализации;

• имеет разный форм-фактор;

• составляется не более, чем на 2-х страницах;

• составляется до начала тестирования.

Оставляю здесь шаблон на тест-план

Пример тест-плана с сайта с сайта www.guru99.com

Тест-кейс

Тест-кейс можно сравнить с рецептом — это последовательность шагов, которые приводят к какому-то результату. Тест-кейс лучше не делать избыточным. Тестировщики чаще всего хорошо знают свой проект, поэтому досконально писать тест-кейс нет необходимости. Тест-кейс должен быть краткий и понятный, так чтобы другой тестировщик, либо другой специалист в команде смог быстро пройти по нему и проверить, что все происходит так, как нужно.

Тест-кейсы можно формировать в последовательный сценарий, чтобы проверить, как игрок пройдет по этому функционалу от начала до конца.

Тест-кейсы можно группировать в смысловые блоки.

Например, если в игре запускается какой-то ивент, формируется набор тест-кейсов для проверки этого ивента.

Тест-кейсы лучше писать по требованиям гейм-дизайнерского документа. Но, если функционал уже готов, а требований тест-кейсов по нему не написано, можно написать уже по факту. Лишним не будет.

Составляющие тест-кейса:

• идентификатор (уникальный номер, по которому вы сможете найти этот тест-кейс и на него сослаться);

• название сценария (какое-то краткое, но ёмкое);

• ссылка на требования ГДД;

• предусловия (опционально, если они требуются для тест-кейса);

• шаги сценария;

• ожидаемый результат;

• фактический результат (опционально).

Чек-лист

Чек-листы можно сравнить со списком покупок, который мы формируем на проверку. Например, чек-лист на Smoke-тест, чтобы проверить, что игра запускается и весь функционал, который должен в игре отрабатывать отрабатывает, иконка приложения соответствует иконке нашего приложения. Также чек-лист может быть составлен на регрессионное тестирование и даже на тестирование требований.

Чек-листы чаще всего составляются без детализации и их можно скомпоновать в наборы и проверять тоже для любого функционала либо нового, либо регрессионного.

Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу.

Небольшой пример из игры нашей студии: есть поле для ввода имени питомца и есть несколько условий на этом поле: имя питомца должно состоять из более чем 2 символов и только в этом случае кнопка из серой неактивной станет зеленой активной и можно будет питомца наименовать. Мы начинаем формировать чек-лист к этому полю если количество символов больше 2 то кнопка принять становится активное, если меньше 2 не активно. Первые 2 пункта чек-листа, которые можно проверить.

На скриншоте мы видим, как игрок из Китая захотел назвать питомца очень коротким ёмким именем и, к сожалению, не смог это сделать и обращался в тех. поддержку. В результате ему пришлось выдумывать более длинное имя.

Ссылка на mindmap чек-лист для мобильной игры:

Баг-репорт

Баг-репорт оформляется, когда баг уже локализован и его можно повторить. Если баг плавающий, нужно пытаться его повторить или занести в систему, где фиксируются баги, как плавающий баг. Ключевой момент, что баг можно повторить и воспроизвести, только тогда его заносят в систему с багами, где хранятся баг-репорты. Если создать и оформить какой-то баг, и разработчик не сможет его воспроизвести, то тут появится множество вопросов.

Поэтому лучше всего сразу проверить на нескольких устройствах, если это возможно и посмотреть на разных операционных системах, на разных разрешениях экрана, то есть максимально локализовать проблему.

В баг-репорте обязательно должны быть:

1. Подробное описание проблемы – что, где, когда случилось.

2. Важность дефекта, который указывает тестировщик, а уже приоритет по исправлению этой ошибки указывает менеджер либо команда из разработчиков.

3. Условия воспроизведения – версия игры, версия операционной системы и другие уникальные условия, которые могут помочь разработчику быстро найти баг, устранить и передать задачу на тестинг.

4. Алгоритм воспроизведения – пошаговые предусловия предусловия, которые необходимы для воспроизведения бага.

5. Доказательства – скрины, видео, логи с устройств.

Скриншоты из разных систем, в которых баг-репорт можно вести. В разных компаниях в разных командах условия могут быть абсолютно разные, и где хранятся баг репорты — также зависит от компании.

Отчет о тестировании

Отчет о тестировании пишется, когда функционал уж проверен и релиз либо предрелиз показывает итог проделанной работы.

Отчет о тестировании может быть представлен как текст, таблица, график или диаграмма, если это позволяет инструмент.

Составляющая отчёта о тестировании:

1. Кто тестировал (состав команды).

2. Когда тестировал (даты проведения тестов).

3. Как тестировал (процесс тестирования, описание применяемых методов и технологий).

4. Какие возникли проблемы и как решились.

Инструкция

Инструкцию можно писать до, во время или после тестирования. Инструкцию никогда не поздно написать. Это помогает как новичкам, так и коллегам, которые работают в одной команде. С помощью инструкции можно быстро сориентироваться в проекте.

Например, вышел новый функционал. Лучше написать инструкцию, как этот функционал проверить, как переключаться, если проверка нового функционала подразумевает переключение между версиями или предусматривает какой-то сложный алгоритм проверки. Это экономит время на объяснения, когда требуется делегировать задачу либо в команду пришел новый человек и нужно его обучить.

Также инструкция помогает выгрузить старое и не потерять. Скорость выпуска релизов в геймдеве довольно высокая и часто есть необходимость вернуться к старому функционалу, который ранее уже  тестировался, но прошло какое-то время и тестируется новый функционал, а нужно вернуться к проверке того старого. Поэтому лучше всего, чтобы было прописано, как  тестировать, где тестировать, что и куда переключать. Лучше всего все в картинках, гифках или видео. Сегодня современные инструменты всё это позволяют сделать быстро и без проблем. Также ели есть возможность сохранять какие-то состояния проекта, состояния продукта, то лучше где-то всё это фиксировать и выкладывать в общем доступе.

Инструкции лучше писать сразу. Это позволяет избежать множество проблем в дальнейшем.

Где хранить:

• Google Docs, Google Sheets

• Cucumber (Hip Test)

• Test IT

• Zephyr, Test Management for Jira

• Qase

• Notion

• TestRail

Геймдизайнерский документ (ГДД, диздок)

В геймдизайнерском документе гейм-дизайнер пишет требования к продукту или к отдельному функционалу.

Детализация у геймдизайнерского документа может быть разная. Форм-фактор также может быть разным.

Существует несколько способов проверки требований к игре: по принципу Что? Где? Когда? или по принципу проверки на полноту, однозначность, непротиворечивость, тестируемость, необходимость, осуществимость.

После того как геймдизайнерский документ готов лучше всего, если его прочитают и вместе обсудят специалист по тестированию, разработчик и сам гейм-дизайнер.

Тестировщику в этом случае следует задавать следующие вопросы: не противоречит ли те требования, которые гейм-дизайнер написал, функционалу, который сейчас есть, не будут ли нововведения противоречить наративу, функциям и механикам, которые есть в игре сейчас.

Требования геймдизайнерского документы должны пониматься всеми однозначно, что исключает какого-либо двоякого толкования.

Важно смотреть на полноту содержания: все ли условия предусмотрены, все ли сценарии, которые могут возникнуть у игрока в связи с новым функционалом продуманы.  

Разработчик смотрит на возможность реализации ГДД.

Также необходимо  продумать, как новый функционал будет тестироваться, после того как разработчик его реализует.

Практическая часть интенсива. Мы попробуем сформировать чек-лист и вопросов гейм-дизайнеру по новому продукту на основе ГДД.

На картинке мы видим 3 скрина игры.

1. скрин – изображение и кнопка Play, при нажатии на которую, мы попадаем в игровой mod

2. скрин – на старте есть какое-то количество жизней и шагов

3. скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.

 Итоги интенсива:

1. Узнали, какие бывают виды документации у тестировщика игр.

2. Обсудили зачем тот или иной документ нужен.

3. Попрактиковались в создании чек-листа.

 Список материалов для самостоятельного изучения:

• Блог Ольги Назиной (Киселевой)

• Форум сайта Software testing

• Блог LernQA 

• Шаблоны документов для тестирования программного обеспечения StrongQA

• Статьи на Habr, DTF

• Конференции (QualityConf, SQADays, …)

• Каналы и чаты в telegram

• Поиск в Google

---

Узнать подробнее о курсе Game QA Engineer можно здесь.

Тестовая документация помогает структурировать работу и фиксировать информацию, которая нужна заинтересованным сторонам на финальном этапе тестирования.

Тестовая документация нужна, чтобы:

• видеть уровень покрытия проекта тестами, не забывая про функционал;
• быстро привлечь к работе новые кадры, если тестировщик внезапно покидает проект – временно или навсегда;
• автоматизировать тестирование: писать скрипты по готовым тест-кейсам куда проще и быстрее.

Кроме того, документация позволяет оценить сроки и реальный объём работ.

Виды тестовой документации

1. Тест-план

Это документ, с которого всё начинается и где описан весь объём работ по тестированию. Удачный тест-план:

• помогает людям вне тестирования понять детали;
• устанавливает объект тестирования, график работы, критерии начала и окончания тестирования, стратегию, риски и список необходимых работ;
• выставляет приоритеты и подчёркивает важные аспекты.

Полноценным считается тест-план, в котором мы подробно прописали все вышеуказанные пункты. Составляет его либо тимлид, либо один из самых опытных тестировщиков, а после тест-план согласовывается со всей командой.

Создать тест-план можно на основе международного стандарта IEEE 829 или разработать документ, максимально исчерпывающе отвечающий на все важные вопросы. А именно:

• объект тестов, используемая веб-среда;
• полный перечень системных функций с указанием необходимого оборудования;
• типы проверок;
• процесс теста, анализ полученной информации по отношению к запланированным фазам разработки на проекте;
• риски и пути их разрешения.

Тест-план зачастую используется на долгосрочных проектах и помогает выстроить доверительные отношения с клиентом, показывая, что именно будет делать команда тестирования.

2. Тестовая стратегия

В целом определяет, как продукт будет тестироваться. Дополняет тест-план и содержит общий подход к тестированию. На краткосрочных проектах стратегия может заменить объёмный тест-план.

При формировании данного документа необходимо разложить весь процесс на следующие пункты:

• подготовка информации;
• разбор информации;
• вынесение решения;
• презентация.

По большому счёту правильная тестовая стратегия:

• обозначает цели;
• показывает, что нужно предпринять для достижения результата.

Тестовая стратегия помогает организовать процесс, понять, какими ресурсами мы обладаем, и как целесообразно ими распоряжаться даже в ограниченных условиях.

3. Тест-кейс

Это один из самых популярных артефактов (у нас в Qualitica уж точно). В нём описывается последовательность действий, как проверить определённую часть функционала и прийти к фактическому результату.

Тест-кейсы составляются, как только готов тест-план. Мы с коллегами всегда следим за актуальностью этой документации, так как благодаря тест-кейсам члены команды могут ознакомиться с программой, не изучая весь код.

Тест-кейсы можно разделить на позитивные и негативные. Позитивные проверяют правильность поведения функций, используя корректные данные. Негативный тест-кейс должен вмещать как минимум один некорректный параметр и проверяет чрезвычайные ситуации.

При написании тест-кейсов, мы, как правило, применяем следующие техники тест-дизайна:

• Эквивалентное разделение. Данный метод позволяет сократить число тестов. Так как для целого класса можно выбрать только одно значение, приняв, что для всех значений в группе результат будет аналогичным.
• Граничные значения. Эта техника тесно связана с предыдущей и основана на предположении, что многие ошибки могут возникать на границах эквивалентных классов.
• Матрица или таблица принятия решений. Эту технику мы применяем для более сложных систем. К примеру, двухфакторной аутентификации. Метод хорош тем, что показывает сразу все возможные сценарии.
• Попарное тестирование (Pairwise testing). Такие кейсы позволяют обнаружить большое количество ошибок при минимуме проверок, потому что мы убираем дублирующие друг друга тесты.
• Причина и следствие. Относится к проверке базовых действий и получению результата. Так мы проверяем все возможности системы, находим дефекты и делаем нашу техническую документацию ещё лучше.

Исчерпывающего тестирования не существует, но опытные тестировщики Qualitica вплотную приближаются к нему, применяя все вышеуказанные техники, потому что мы умеем верно подбирать и комбинировать необходимое в тест-дизайне.

4. Чек-лист

Список, содержащий ряд необходимых проверок для какой-либо работы. В плотной работе команды тестирования чек-лист помогает помнить о важных деталях. Создаём мы его на этапе готовности тест-плана и определения тестовой стратегии.

Он нужен, чтобы:

• организовать рабочий процесс;
• легко проверить выполненную работу.

5. Баг-репорт

Технический документ, без которого не обходится ни одна проверка. Он содержит полное описание дефекта. Включает информацию как о самом баге (короткое описание, серьёзность, приоритет и т. д.), так и об условиях его возникновения.

В зависимости от проекта баг-репорт может составляться в разных баг-трекинговых системах. В Qualitica мы чаще всего пользуемся Jira, Redmine, YouTrack, Trello или просто инструментами для работы с таблицами.

Баг-репорт помогает:

• отследить и описать ошибки в работе проекта;
• воспроизвести проблему;
• понять суть проблемы, её приоритет и важность;
• эффективно избавляться от багов.

6. Отчёт о результатах тестирования

Здесь обобщаются все результаты работ по тестированию. В том числе:

• наглядно показаны проблемы и достижения, дефекты и статистика;
• даются выводы и рекомендации.

Тестовая документация облегчает жизнь проектной команде, а также экономит время на этапах тестирования, сводя их к проверкам, анализу и передаче результатов. Благодаря этому клиенты быстро получают качественно работающий продукт.

Нужно тестирование, за которое можно не переживать? Пишите нам на hello@qualitica.ru, и мы подберём вам лучших специалистов команды. А ещё не забывайте читать блог Qualitica – с нами интересно!

• Что такое тестовая документация
• В чем ее важность
• Какую тестовую документацию используют QA-команды
• Тест-план
• Чеклист
• Тест-кейс
• Сценарий использования
• Баг-репорт
• Требования
• Как все это работает

Как и в любом другом процессе, документация в QA помогает командам организовать свою работу. С ее помощью мы можем стандартизировать процесс, дать определение терминам, установить основные этапы тестирования и держать всех членов команды в курсе дел.

Что такое тестовая документация?

Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д. 

В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных).

В чем важность тестовой документации?

Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.

Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.

И QA-инженеры, и клиенты могут хотеть получить на выходе приложение, вообще не имеющее багов. Но это не достижимая цель, а мечты. Поэтому имеет смысл обсудить, что будет определять конец фазы QA. 

Например, мы можем протестировать весь функционал один раз. Или тестировать приложение до тех пор, пока в продакшене не останется критических ошибок. Или быстро проверить критически важные для бизнеса функции, что позволит успеть к дедлайну.

Как правило, попытки оговорить все это в переписке или телефонных переговорах неэффективны. Все дело в человеческом факторе. У кого-то просто слишком много информации, которую нужно обработать и запомнить. Кто-то может неправильно понять договоренности. В результате у каждого появляется своя интерпретация требований и целей.

Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.

Непонимание того, как и почему должна вести себя та или иная функция, приводит к большему количеству ошибок. Неправильная расстановка приоритетов может привести к пропуску багов и предоставлению неполных отчетов. Примеры можно продолжать и продолжать.

Какую тестовую документацию используют QA-команды?

Наиболее часто используемые документы — это планы тестирования, чеклисты, тест-кейсы, сценарии использования, баг-репорты и спецификации требований.

План тестирования (test plan)

План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта. 

В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.

Чеклист (checklist)

Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик. 

Выглядит чеклист как список функций с указанием статуса — результата проверки. 

Чеклисты могут использоваться вместо тест-кейсов, поскольку их легче подготовить. Но если вам нужно более конкретное описание процедуры, без тест-кейсов не обойтись.

Тест-кейс (test case)

В тест-кейсе содержатся:

• подробное описание шагов и действий, которые тестировщик должен выполнить для тестирования какой-то одной части функционала,
• критерии  прохождения тестов. 

Компании могут использовать разные форматы тест-кейсов, но информация в них всегда очень подробная и конкретная.

Сценарий использования (use case)

Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением. 

Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя. 

При создании юзкейсов тестировщики учитывают требования и бизнес-цели.

Баг-репорт

Баг-репорт предоставляет полную информацию о баге (его описание, серьезность, приоритет и т. д.) и документирует шаги и условия для воспроизведения этого бага. 

Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.

Требования (requirements specification)

Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения. 

В требованиях указываются свойства, качества и особенности разрабатываемой программы. Используя эту информацию, команды могут избежать недоразумений и разногласий.

Как все это работает?

Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей. 

А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.

Чем крупнее проект, тем больше документации нужно. 

Если команда использует для сложного продукта только чеклисты, есть риск неправильного понимания приоритетов и проведения неэффективных тестов. Причина кроется в отсутствии деталей. Чеклист только называет функцию, и каждый тестировщик может интерпретировать объект тестирования и результаты по-своему.

Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет. 

Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.

Аналогично, со временем устаревают и теряют свою актуальность тест-кейсы и сценарии использования. Может появиться новый функционал, который тоже нужно покрыть тестами. И если вы не будете все тщательно записывать, вы рискуете получить бесполезную документацию.

В заключение

Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.

Что касается преимуществ документирования рабочего процесса, то они вполне очевидны. Описанные нами документы помогают упорядочить имеющуюся информацию. Благодаря этому даже новичок в команде сможет легко разобраться, что к чему. И хотя создание документации требует дополнительного времени, ее отсутствие приведет к куда большим временным затратам.

В этой статье мы расскажем о чек-листах, баг-репортах, юзкейсах и других популярных видах тестовой документации

Тестовая документация – это набор документов, который создается на протяжении всего цикла тестирования. 

Документация помогает команде однозначно трактовать шаги, сроки тестирования, результаты, обращаться к этой информации в спорных моментах. Это отчет о проделанной работе тестировщика для менеджеров и клиентов. Объем документации и обязательные разделы в разных компаниях могут отличаться. При этом создание и поддержка такой базы требует большого количества времени и компетенций специалиста. 

В этой статье мы расскажем о наиболее популярных видах документации.

План тестирования

План тестирования (тест-план) содержит критерии начала и окончания тестирования, описание конкретных параметров: что именно подлежит тестированию, с помощью каких техник, на каких платформах будет проверяться функционал.

Выделяют следующие типы тест-планов: 

• По уровням: планы модульного, интеграционного, системного, приемочного тестирования;
• По типам: планы функционального, автоматизированного тестирования; тестирования производительности или юзабилити и т.д;
• Мастер тест-план: комплексный план тестирования всего проекта.

Тест-кейс

Тест-кейс – это набор условий, действий и ожидаемых результатов, направленных на проверку какого-либо функционала. Тест-кейс представляет собой описание одной показательной проверки на соответствие требованиям, прямым или косвенным. Тест-кейсы содержат как положительные, так и негативные проверки. 

Наличие тест-кейсов позволяет:

• Структурировать подход к тестированию;
• Обеспечить полноту тестирования;
• Отслеживать прогресс реализации/выполнения плана;
• Достичь взаимопонимания между заказчиком и командой разработки;
• Хранить информацию для дальнейшего обмена опытом между командами и новыми сотрудниками, для быстрого подключения к проекту;
• Проводить повторное и регрессионное тестирование;
• Повышать качество требований.

Часто тест-кейсы упорядочивают и собирают в наборы – тест-сьют, в котором результат выполнения одного тест-кейса является предусловием для выполнения следующего.

Чек-лист

Чек-лист — список проверок для тестирования ПО. Чек-листы содержат перечень элементов, которые подлежат тестированию: блоки, секции, страницы и другие. 

Классический чек-листы состоят из заголовка, статуса, заметки.

Возможные статусы: “Passed” (пройдено), “Failed” (не пройдено), “Blocked” (заблокировано), “Skipped” (пропущено), “Not run” (не проводился).

Среди преимуществ чек-листов выделяют наглядное и компактное отображение объема проделанных работ, предстоящих работ по тестированию. В них зафиксирован перечень проверок, который необходим для сдачи/приемки проекта.

Важно отметить, что чек-лист не является заменой тест-кейсов. Чек-листы содержат описание направления тестирования, а тест-кейсы – способы, алгоритмы тестирования. Поэтому чек-лист проще в составлении, но сложнее в применении. Опытному тестировщику не составит труда протестировать функционал по чек-листу, а новому специалисту может быть сложно вникнуть в суть функционала без детализации. 

Юзкейс

Юзкейсы (Use case) содержат сценарии взаимодействия пользователя с системой, описание того, что именно делает программа. 

Рассмотрим значение юзкейсов для каждого из участников проекта разработки:

1. Заказчик. В юзкейсах отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования очевидна даже для нетехнического специалиста.
2. Разработчик. В юзкейсах отражается наглядное представление бизнес-логики и поведения системы
3. Тестировщик. Юзкейсы — хорошая основа для формирования тест-кейсов. Это пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки,  которые сложно найти, например, при юнит-тестировании.

Баг-репорт

Баг-репорт – это документ, в котором содержится полная информация о найденном баге (шаги воспроизведения, описание, локализация и т.д.). Подробное описание ошибки поможет в ее быстром устранении и правильной перепроверке. 

При создании баг-репорта стоит локализовать ошибку, проверить её наличие на разных устройствах и версиях ПО, как можно четче описать несоответствие ожидаемому результату. 

Баг-репорт присутствует на любом проекте, независимо  от того, пишутся ли другие тестовые документы. От правильности его составления зависит скорость понимания ошибки и качество отладки. 

Отчет по тестированию

Отчет по тестированию – отчет о проделанной работе с описанием результатов. Может содержать текст, таблицы, графики и диаграммы.

В зависимости от того, для кого предназначен отчет, меняются представление информации и акценты в описании.

У отчетов есть разные варианты:

• Отчет по инциденту содержит описание события, которое произошло во время тестирования и подлежит исследованию;
• Отчет о результатах тестирования. Представляет собой периодический отчет, в котором фиксируется подробная информация о выполнении тестирования и его результатах, а также об оставшейся работе;
• Отчет о ходе тестирования. Документ, в котором подводится итог тестирования, с целью отслеживания прогресса;
• Итоговый отчет о тестировании. В этом отчете содержится полная информация о тестировании, проведенном на протяжении всего жизненного цикла разработки ПО. 

Итак, мы ознакомились с основыми видами тестовой документации. Еще раз отметим, что создание такой базы — трудоемкий, но очень важный этап в жизненном цикле разработки. С ее помощью все участники процесса разработки смогут получить актуальную информацию о состоянии системы, повысить эффективность работы.

A software product is like an airplane: it must undergo a technical check before launch.

Quality Assurance is a necessary step towards launching a successful software product. It is just a small part of all the project work, but nobody said it would be simple.

There are so many types of software testing – automated and manual, exploratory and functional, compatibility, UI/UX,  regression, unit, API, and performance testing. Good luck wrapping your head around all of them!

What is common for all these types, however, is that each requires you to write thorough QA testing documentation. The quality of test documents defines whether your work will prove useful or go in vain.

I’ve written this article to make your life a bit easier. So here it is, your ultimate guide on how to write software QA documentation that will work.

Make a Test Plan and a Test Progress Report

The test plan is a guiding document which outlines the bigger picture of the QA process, and includes a to-do list, strategy, resources, and schedule.

Before creating a QA plan document, ask yourself “What is the purpose of the software solution?” and “What features need to be tested?”. Do not rush into testing every single part of your software. You need to decide what methodologies, technologies, and tools you will use.

The test plan will help you understand the following:

• What are the acceptance criteria?
• What resources do you need? What operating systems, how many copies, and  with what license? Do you need any technical consultants?
• Are your roles and responsibilities well-designated?
• What are testing timeframes?

The test progress report is another part of the QA documentation, which is similar to the test plan but with added data on the current progress. This document lets you and your development team monitor project progress and identify organizational issues, if any.

Create Test Cases

Once you’ve clarified the set of functions that need to be tested in your test plan, you need to create a test case for each part of your software.

Test cases are pretty simple – this QA documentation consists of 7 sections: ID, Test Case, Testing Steps, Expected Result, Status, Actual Result, and Comments.

1. ID is a unique number assigned to your test case.
2. In the Test Case section, you point out the requirement(s) you will be testing and provide a link to it in the specifications document.
3. In the Testing Steps section, you list all the actions needed to complete a test case.
4. In the Expected Result section, you summarize the outcome of a particular test if it is successful.
5. In the Status section, you indicate if a particular step passed or failed testing.
6. In the Actual Result section, you explain the outcome of a failed test.
7. The Comments section is not obligatory, but you can add it to leave some additional notes.

Write a Defect Report

The defect report is an important element of QA documentation. It registers any unwanted issue with your program. It is a crucial element of the project documentation, which navigates you towards getting a bug-free software solution.

Sounds simple, right? Yes, but only until you start documenting. Here, you can see an example of a typical defect report:

The defect report consists of the following sections: identifier, summary, description, steps to reproduce, reproducibility, severity, priority, environment, and attachments.

1. Each particular software issue is assigned a unique number – the identifier. It optimizes navigation through QA documents and facilitates communication between developers, testers, and PMs.
2. In the summary section, you provide a concise answer to three simple questions: what happened, where, and under what circumstances.
3. In the description section, you describe the bug in detail. You should tell about the actual results and the expected ones. It’s useful to provide a link to your software requirements.
4. Then, you write about the steps to reproduce (STR). This shows developers exactly how to reproduce the issue. Don’t miss a step or your report may return to you.
5. In the reproducibility section, you clarify if the bug appears every time you follow the STR. You should use numbers to show approximate chances, for example 7 times out of 10.
6. In the severity section, you explain how much harm the bug may bring to the project. In other words, it shows the technological degree of influence of the defect on the entire system. Even a small issue may badly affect the entire application.
7. Priority shows how important a particular defect report is. Priority can be denoted with the help of  letters – “A” for the most urgent and “Z” for the least urgent, numbers – “1” for the most urgent and “9” for the least urgent, or simply words  like “high”, “medium”, or “low”.
8. In the environment section, you should define which operating systems or browser versions were affected.
9. Finally, the attachments include the list of videos, screenshots, or console logs files added to the defect report.

Keep These Useful Tips for Defect Report Writing in Mind

1. Write a sufficient and adequate summary. It does not matter if it is long or short. What matters is that it should be clear.
2. Have a look at the summary and the description. Do they look pretty much the  same? You must have forgotten to outline expected and actual results in the description and to add the link to requirements.
3. Capture the issue with the help of a screenshot. It may save you and the development team a lot of time. Sometimes, one glance at the picture is just enough to understand the situation.
4. Before reporting the issue, try to reproduce it at least 3 times to be sure that it exists.
5. Report the issue ASAP and notify your project manager or product owner if the issue is major.
6. Check for grammar mistakes in your QA documentation so you’re not taken down by the grammar police.
7. However comical it sounds, make sure that the issue is not a feature – review the documentation again!
8. Do not miss any important information in your Steps to Reproduce.

Submit a Defect Report

Defect reports go through a lifecycle – from the moment you report an issue to the moment the issue is closed.

The first step is to compile and submit the defect report. At this point, the Project Manager or a tech lead decides whether to assign it to a developer or to decline it on the grounds of insufficiency or inadequacy.

After the assigned developer has fixed the bug, you as a QA have to double-check and verify it has been fixed. If yes, you can close the defect report. The best practice is to close it in a week or two.

If the bug is not fixed, you reopen the defect report and send it back to the assigned developer. The bug-fixing process can be a long one, but you have to stay strong until all the defect reports are finally closed.

To Wrap Up

Quality Assurance is a process you simply cannot avoid. Each airplane prior to departure undergoes a technical check. If there is any issue, the aircraft is grounded until the problem is solved.

Similarly, each software product needs to be checked before launch. You cannot afford to deploy buggy software because users will not give your app a second chance.

Do you need to improve the quality of your software?

My company KeenEthics provides solid development and quality assurance services. In case you need an estimate for a similar project, feel free to get in touch.

If you have enjoyed the article, you should continue with What Is Prototyping and Why Do We Need It and Minimum Viable Product: Between an Idea and the Product.

P.S.

The original article posted on KeenEthics blog can be found here: How to Write QA Documentation That Will Work?

---

---

Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started

A software product is like an airplane: it must undergo a technical check before launch.

Quality Assurance is a necessary step towards launching a successful software product. It is just a small part of all the project work, but nobody said it would be simple.

There are so many types of software testing – automated and manual, exploratory and functional, compatibility, UI/UX,  regression, unit, API, and performance testing. Good luck wrapping your head around all of them!

What is common for all these types, however, is that each requires you to write thorough QA testing documentation. The quality of test documents defines whether your work will prove useful or go in vain.

I’ve written this article to make your life a bit easier. So here it is, your ultimate guide on how to write software QA documentation that will work.

Make a Test Plan and a Test Progress Report

The test plan is a guiding document which outlines the bigger picture of the QA process, and includes a to-do list, strategy, resources, and schedule.

Before creating a QA plan document, ask yourself “What is the purpose of the software solution?” and “What features need to be tested?”. Do not rush into testing every single part of your software. You need to decide what methodologies, technologies, and tools you will use.

The test plan will help you understand the following:

• What are the acceptance criteria?
• What resources do you need? What operating systems, how many copies, and  with what license? Do you need any technical consultants?
• Are your roles and responsibilities well-designated?
• What are testing timeframes?

The test progress report is another part of the QA documentation, which is similar to the test plan but with added data on the current progress. This document lets you and your development team monitor project progress and identify organizational issues, if any.

Create Test Cases

Once you’ve clarified the set of functions that need to be tested in your test plan, you need to create a test case for each part of your software.

Test cases are pretty simple – this QA documentation consists of 7 sections: ID, Test Case, Testing Steps, Expected Result, Status, Actual Result, and Comments.

1. ID is a unique number assigned to your test case.
2. In the Test Case section, you point out the requirement(s) you will be testing and provide a link to it in the specifications document.
3. In the Testing Steps section, you list all the actions needed to complete a test case.
4. In the Expected Result section, you summarize the outcome of a particular test if it is successful.
5. In the Status section, you indicate if a particular step passed or failed testing.
6. In the Actual Result section, you explain the outcome of a failed test.
7. The Comments section is not obligatory, but you can add it to leave some additional notes.

Write a Defect Report

The defect report is an important element of QA documentation. It registers any unwanted issue with your program. It is a crucial element of the project documentation, which navigates you towards getting a bug-free software solution.

Sounds simple, right? Yes, but only until you start documenting. Here, you can see an example of a typical defect report:

The defect report consists of the following sections: identifier, summary, description, steps to reproduce, reproducibility, severity, priority, environment, and attachments.

1. Each particular software issue is assigned a unique number – the identifier. It optimizes navigation through QA documents and facilitates communication between developers, testers, and PMs.
2. In the summary section, you provide a concise answer to three simple questions: what happened, where, and under what circumstances.
3. In the description section, you describe the bug in detail. You should tell about the actual results and the expected ones. It’s useful to provide a link to your software requirements.
4. Then, you write about the steps to reproduce (STR). This shows developers exactly how to reproduce the issue. Don’t miss a step or your report may return to you.
5. In the reproducibility section, you clarify if the bug appears every time you follow the STR. You should use numbers to show approximate chances, for example 7 times out of 10.
6. In the severity section, you explain how much harm the bug may bring to the project. In other words, it shows the technological degree of influence of the defect on the entire system. Even a small issue may badly affect the entire application.
7. Priority shows how important a particular defect report is. Priority can be denoted with the help of  letters – “A” for the most urgent and “Z” for the least urgent, numbers – “1” for the most urgent and “9” for the least urgent, or simply words  like “high”, “medium”, or “low”.
8. In the environment section, you should define which operating systems or browser versions were affected.
9. Finally, the attachments include the list of videos, screenshots, or console logs files added to the defect report.

Keep These Useful Tips for Defect Report Writing in Mind

1. Write a sufficient and adequate summary. It does not matter if it is long or short. What matters is that it should be clear.
2. Have a look at the summary and the description. Do they look pretty much the  same? You must have forgotten to outline expected and actual results in the description and to add the link to requirements.
3. Capture the issue with the help of a screenshot. It may save you and the development team a lot of time. Sometimes, one glance at the picture is just enough to understand the situation.
4. Before reporting the issue, try to reproduce it at least 3 times to be sure that it exists.
5. Report the issue ASAP and notify your project manager or product owner if the issue is major.
6. Check for grammar mistakes in your QA documentation so you’re not taken down by the grammar police.
7. However comical it sounds, make sure that the issue is not a feature – review the documentation again!
8. Do not miss any important information in your Steps to Reproduce.

Submit a Defect Report

Defect reports go through a lifecycle – from the moment you report an issue to the moment the issue is closed.

The first step is to compile and submit the defect report. At this point, the Project Manager or a tech lead decides whether to assign it to a developer or to decline it on the grounds of insufficiency or inadequacy.

After the assigned developer has fixed the bug, you as a QA have to double-check and verify it has been fixed. If yes, you can close the defect report. The best practice is to close it in a week or two.

If the bug is not fixed, you reopen the defect report and send it back to the assigned developer. The bug-fixing process can be a long one, but you have to stay strong until all the defect reports are finally closed.

To Wrap Up

Quality Assurance is a process you simply cannot avoid. Each airplane prior to departure undergoes a technical check. If there is any issue, the aircraft is grounded until the problem is solved.

Similarly, each software product needs to be checked before launch. You cannot afford to deploy buggy software because users will not give your app a second chance.

Do you need to improve the quality of your software?

My company KeenEthics provides solid development and quality assurance services. In case you need an estimate for a similar project, feel free to get in touch.

If you have enjoyed the article, you should continue with What Is Prototyping and Why Do We Need It and Minimum Viable Product: Between an Idea and the Product.

P.S.

The original article posted on KeenEthics blog can be found here: How to Write QA Documentation That Will Work?

---

---

Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Автор: Антонина Бжассо

Оригинальная публикация: http://quality-lab.ru/the-purpose-of-test-documentation/

Давным-давно…

Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.

Аргументом для прекращения написания тестовой документации и каких-либо спецификаций стало то, что на выходе убытков было больше, чем прибыли. Спецификация и различная документация себя не оправдывали, потому что требовать высокие цены за небольшие мобильные приложения компания не могла. Да и какие могут быть чек-листы на новую функциональность, когда:

— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.

В итоге приходилось без документации думать о том, что именно и на какие части могло повлиять. В срочном порядке нужно было проводить полноценное исследовательское тестирование за полчаса! При этом, нужно было найти критические для пользователей баги. Полчаса — это максимум времени, потому что выявленные проблемы еще нужно исправлять и перепроверять. Со временем при такой организации работы начинали возникать проблемы:

— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе?.. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.

И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…

Как, что и по каким законам там происходило – не было понятно никому. Особенно новым разработчикам, которым передавали дальнейшую разработку:

Коллеги, я потратил три дня на изучение кода, потому что разработчиков этой программы уже нет, и ничего не понятно. Комментариев в коде мало. Непонятно, для чего какой костыль. Если я начну писать, то сломаю то, что работает. Мне легче это всё переписать заново. Давайте напишем нормально.

Так работают множество компаний. И далеко не все получают хорошие результаты.

Хоть выше описан и неточный рассказ, так как прошло уже много лет и что-то перефразировано, но смысл тот же. Есть компании, которые всё-таки пишут тестовую документацию и активно ею пользуются. Обычно это крупные компании, разрабатывающие многофункциональные масштабные системы. А есть компании, от качества и наличия документации которых могут зависеть жизни людей (например, компания разрабатывает автопилот для самолета). Автопилот можно разрабатывать годами, в итоге один раз выпустив его в свет. Это очень дорогой процесс. Если автопилот будет с багами, то потери будут колоссальными.

Как же сделать так, чтобы продукт получился качественным и хорошо продаваемым? Необходимо начать с документации.

В каком виде и для чего нужна тестовая документация?

Существуют различные виды документации, используемой при тестировании. Каждая из них играет роль в достижении общей цели — создании успешного продукта. Ниже рассмотрим самые распространенные виды документации и причины их использования.

Рабочая проектная документация, используемая тестировщиками

ТЗ (техническое задание) – позволяет донести суть предмета разработки до сотрудников компании. Помогает понять, какой именно функциональностью должен обладать разрабатываемый продукт (иногда с указанием используемых технологий и методов).

Почему необходимо?

• Если ТЗ будет в общем доступе, то сотрудники, плохо пересекающиеся с командой разработки, смогут его посмотреть. Возможно, что при тестировании будет обнаружена какая-то проблема, о которой сообщит тестировщик (например, программа не выполняет то, для чего была создана).

• Новым сотрудникам не нужно будет рассказывать о смысле программы и методах ее реализации. Можно будет быстро ввести в курс дела любого человека.

• ТЗ помогает сотрудникам понять программу лучше. Непонимание разрабатываемого продукта приводит к ошибкам.

• При тестировании не будет возникать попыток проверять лишнее. В первую очередь, проверке подвергнется то, что обязательно должно работать по ТЗ.

• ТЗ дает возможность понять суть разрабатываемого продукта сотрудникам, которые будут представлять готовый вариант реализации публичной аудитории.

ЧТЗ (частное техническое задание) – создается на основе ТЗ. Обычно содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования предмета разработки пользователями, макеты разрабатываемой части предмета разработки, его логику и суть).

Почему необходимо?

• Помогает разработчикам реализовать разрабатываемый продукт точно так, как задумывалось. Помогает понять логику и правила оформления.

• Помогает новым сотрудникам разобраться в крупных и масштабных проектах, так как на некоторые системы нужны недели изучения. Имея под рукой ЧТЗ, сотрудник с легкостью сможет найти в нем необходимую информацию, сразу приступив к тестированию. Не нужно будет привлекать других сотрудников, знающих продукт, тем самым отвлекая их от работы. Очевидная экономия времени!

• Дает возможность примерно оценить трудозатраты на разработку и тестирование еще до начала работ.

• Помогает тестировщикам создать ЧЛ и тест-кейсы до начала работ и тестирования.

ЧТЗ и ТЗ можно отобразить:

• в текстовом виде с картинками
  

• в виде графического шаблона-таблицы
  

• в виде интеллект-карт, UML или подобного алгоритма

  

Проектная документация, подготавливаемая тестировщиками

ЧЛ (чек-лист) – список того, что нужно проверить.

Почему необходимо?

• Помогает планировать сроки окончания работ в будущем и настоящем, т.к. в ЧЛ можно указать, сколько времени необходимо для проверки и сколько было затрачено.

• Хранит историю пройденных тестов. Можно будет легко вспомнить, какие именно тесты проходили с ошибками, и перепроверить именно их.

• ЧЛ с результатами наглядно показывает любому сотруднику компании текущее состояние разрабатываемого продукта. Помогает определить его степень готовности.

• Помогает помнить, что уже было проверено, а что нет.

• Помогает не забыть, какие тесты необходимо выполнить в первую очередь, какие во вторую, какие в третью и т. д. Это рождает уверенность, что за определенное запланированное время самые важные тесты будут проведены, а результаты по ним — получены.

Чек-листы можно записать:

• в виде таблиц (удобно в Google Sheets)
  

• в виде интеллект-карт (удобно в XMind)
  

• в виде списка проверок в специально предназначенной системе (удобно в Sitechco)
  

• в виде списка в текстовом документе, который привычен.

ТК (тест-кейс) – создается на основе ЧТЗ (если оно есть) тест-аналитиками и тестировщиками.
Почему необходимо?

• Совместно с ЧЛ может хранить историю тестирования и отображать, что именно и как тестировалось. Можно убедиться, что та или иная функциональность обязательно была или будет проверена и затронута при тестировании.

• Помогает быстро включить в работу новых сотрудников. Сотруднику не обязательно неделями изучать предмет разработки, ему будет достаточно открыть сохраненный ТК и пройти его по шагам так же, как проходил другой опытный специалист, ранее работавший в компании.

• Помогает увидеть как предмет разработки (программа, сайт и т. п.) должен выглядеть. С имеющимися скриншотами экранов, если они есть, можно будет не забыть о том, что “вон та” кнопка должна быть серой, а не красной.

Тест-кейсы можно отобразить:

• в виде таблицы с текстовыми данными
  

• в специальном сервисе для ведения тест-кейсов (например, в TestLink).

Отчет о тестировании – письменный или медийный отчёт о проделанной работе и ее результате.

Почему необходимо?

• Наглядно отображает, какой именно результат выполненных работ получен.

• Исторически фиксирует информацию. К ней всегда можно будет вернуться и увидеть, что именно было выполнено и что именно получили в итоге.

• Уведомляет о результатах всех, кому важно о них знать. Например, для сотрудников отдела поддержки сообщается о выходе новой версии разрабатываемой программы, а также о самых критических проблемах. Можно будет заранее подготовиться к возникающим жалобам.

• Помогает принимать решение о дальнейших действиях (например, стоит ли выпускать версию программы в текущем состоянии).

Пример отчета в письменном виде:

Как определить, какую именно документацию необходимо внедрить в проект?

Ниже приведем примеры того, когда и какую документацию и средства можно использовать как необходимый минимум.

На проекте до 15 человек (проекты низкой сложности):

• техническое задание (предотвращает неверное понимание задачи разработчиками, т. к. документации нет);

• чек-листы (легко поддерживать, не отнимают много времени);

• отчеты в виде краткого письма или отписки в специальном сервисе ведения проектов, с указанием критических багов для выпуска.

На проекте от 15 до 50 человек (проекты средней сложности):

• техническое задание;

• чек-листы;

• тест-кейсы;

• база знаний (например, в Wiki);

• отчеты в виде письма с приложенным пройденным ЧЛ с указанием критических багов.

Большой проект – от 50 человек и больше (проекты высокой сложности):

• техническое задание;

• частное техническое задание;

• чек-листы;

• тест-кейсы;

• база знаний (например, в Wiki);

• медиа-материалы;

• отчеты в принятом в компании виде (обычно, в виде письма с подробными графиками и приложенными файлами);

• прочее (зависит от типа, целей и нужд компании).

Что из этого выбрать — решать самим сотрудникам, т. к. именно они будут заниматься разработкой и смогут понять, что им нужнее. Все вышеперечисленное — лишь примерное представление и рекомендации.

Что делать, если написание документации занимает много времени?

Опыт показывает, что при работе над небольшим проектом нужно уметь приспосабливаться. Можно видоизменить документацию так, чтобы ее ведение было удобным и не занимало много времени. Например, ТЗ можно сделать в виде презентации или вебинара и получить от разработчиков уточняющие вопросы. Каждый из видов документации обладает своими плюсами и минусами, поэтому нужно экспериментировать и не бояться создавать что-то новое. Все научные открытия совершаются методом проб и ошибок, при этом случаются и неудачи!
Но отрицательный результат – это тоже результат! Нужно уметь им воспользоваться и учесть его в своих дальнейших экспериментах, пока не будет достигнут приемлемый итог. Великолепных вам решений и успехов в написании документаций!

Обсудить в форуме