Что как правило указывается в тест плане

Как составить тест-план? Для начинающего тестировщика

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

Для себя я отметил следующие важные пункты при составлении тест-плана.

Основные пункты:

1 Краткое изложение проекта

В нескольких предложениях описать зачем и для кого этот продукт.

2 Понятная структура тест-плана

Расположить в правильном порядке все пункты тестированию

3 Сроки тестирования

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

4 Программы и методы тестирования

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

5 Технические требования

Например: Рассказать какие компьютеры или телефоны будут участвовать в тестировании (их характеристики)

6 Структура тестируемого проекта (Описать например какой функционал будет протестирован)

Описать все страницы проекта, какие функции там есть.

7 Результат тестирования

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

Полезные статьи с примерами и описанием как составить тест-план

Примеры тест-кейсов

Полезные видео с примерами составления

Источник

говориМ о тестировании
простым языком

Тест план: как составлять

Форматы

Отображать тест план можно разными способами:

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

Рекомендации по написанию

Что должен содержать хороший тест план:

Описание объекта тестирования: системы, приложения, оборудования.

Список функций и описание тестируемой системы и её компонент в отдельности.

Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования.

Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.

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

Результаты тестирования удовлетворяют критериям качества продукта: требования к количеству открытых багов выполнены, выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF), выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB) и т.д.

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

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

Структура

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

1-я страница:

— шапка (логотип и адрес компании),

2-я страница:

— история документа, которая представляет собой таблицу изменений. Эта таблица содержит столбцы: дата, версия, описание, автор.

3-я страница:

4-я страница и далее:

— операционные системы, браузеры,

— критерии начала тестирования,

— критерии выхода из тестирования,

Предпоследняя страница:

— сколько человеко-часов планируется на различных этапах (дата начала и окончания). Например, на тест-дизайн, выполнение тестов, анализ тестирования, отчеты.

Последняя страница:

— выводы и рекомендации.

Также в тест план могут входить следующие данные:

— жизненный цикл бага,

— ссылки на документы или стандарты,

Рецензия и утверждение

Для увеличения ценности тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Примерный список участников проектной группы:

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

Шаблоны и примеры

Каждая методология или процесс диктуют свои форматы оформления планов тестирования.

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

Обычный документ

Шаблоны, которых можно придерживаться:

Майнд-карта (mind map)

Несколько примеров, как именно можно использовать майнд-карту

Дашборд

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

Excel или другая таблица

В таблице можно запросто отобразить любые списки тестов или описание сценариев, с которыми мы намерены работать на данном проекте.

Доска для записей – Trello

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

Создание тест плана повышает качество продукта за счет перечисления деталей и списка проверок, а также позволяет проанализировать, насколько успешно были проведены все этапы тестирования.

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

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

Источник

Что как правило указывается в тест плане

Что пишут в блогах

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Автор: Майкл Болтон (Michael Bolton)

Перевод: Ольга Алифанова

Вопрос, что должно входить в тест-план, можно интерпретировать двояко – во-первых, как вопрос про «план», а во-вторых, как вопрос о документации планирования. Начнем с плана.

Я пользуюсь моделью эвристической тест-стратегии (скачайте ее и ознакомьтесь) для генерации идей, связанных со стратегией. Эвристики – это ненадежные методы решения проблем и принятия решений, «эвристический» – прилагательное, означающее «(ненадежно) способствующий обучению». «Эвристический» здесь играет тройную роль – модифицирует «модель» (все модели эвристичны), «стратегию» (и они тоже), и «тест» (все тесты – эвристики). Эта модель представляет из себя набор ключевых слов-эвристик и связанных с ними вопросов. Слова я знаю наизусть, запомнить их несложно – особенно при помощи мнемоник, указанных в документации курса, и небольшой практики.

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

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

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

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

Аудитория документации может включать:

Документация тест-планирования может иметь форму:

В приложениях к курсу Rapid Software Testing есть отличные примеры документации тест-плана – от набросков и общих описаний до детальных документов. См. страницы 47-166. Пример общей процедуры также можно найти здесь. Обратите внимание на комментарий на странице, ссылающейся на него:

«Я создал эту процедуру для Microsoft, чтобы они могли наилучшим образом убедиться, что приложения, заявляющие о совместимости с Windows 2000, действительно совместимы с ней. Документация процедуры занимает шесть страниц. Насколько мне известно, это первая опубликованная процедура исследовательского тестирования. Она используется вместе с другой, неисследовательской процедурой (занимающей 400 страниц) для проведения сертификационных тестов. Интересно отметить, что мои шесть страниц – это примерно треть всех задач по тестированию».

Итак, как же должен выглядеть документированный тест-план? По умолчанию, я считаю, ответ – никак, потому что тест-план – это идеи, а при переводе идей в другой формат надо чем-то жертвовать. Однако, возможно, поделиться своими идеями будет нелишним, поэтому ответ по умолчанию – необязательно финальный ответ. Финальный ответ – это «как наиболее дешевая репрезентация идеи, которая может достаточным образом сохранить эту идею или передать ее другим». Возможно, это очень расплывчатый ответ – особенно в части «достаточным образом». Тут следует помнить следующие важные момента:

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тест-кейс

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

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

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

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

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

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

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

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

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

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

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

Пример тест-кейса

Чек-лист

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

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

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

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

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

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

Баг-репорт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструкция

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

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

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

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

Где хранить:

Google Docs, Google Sheets

Zephyr, Test Management for Jira

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник