Что входит в тест план

Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

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

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

Blogposts:

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

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

Автор: Майкл Болтон (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

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

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

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

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

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

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

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

Источник

За план тестирования замолвите слово

Приветствую участников уважаемого сообщества.

Я работаю тестировщиком (интернет-магазин). Вектор – управление тест-кейсами, QA — менеджмент, JUnit — тестирование, автоматизация, программирование на Java. Мне хотелось бы поделиться с коллегами своим опытом. Может, кому пригодится.

Предмет статьи – план тестирования и инструментарий для его составления.

Итак, есть задача – протестировать работу мобильной версии сайта на фронте. Есть собственное желание – оставить потомкам и коллегам вменяемый мануал по тестированию, когда не надо будет придумывать, что бы такое потестить. Я за взаимозаменяемость, универсальность и наглядность! Постулат – структура сайта должна быть представлена в виде дерева для облегчения восприятия и получения перспективы.

Пошаговый процесс построения дерева для плана тестирования:

1. Первый уровень: указание раздела «Страницы» и глобальные элементы (сквозные элементы – элементы шапки, подвал).
2. Второй уровень: перечисление страниц.
3. Третий уровень: перечисление общих свойств страницы и ее особых состояний (например, полная или пустая корзина).
4. Четвертый уровень:
— указание раздела «Элементы»,
— указание раздела «События» для страницы,
— перечисление крупных блоков элементов (например, блок товарных подкатегорий с большим количеством элементов),
5. Пятый уровень: перечисление типов элементов (текстовые блоки, ссылки, поля, кнопки, чекбоксы, счетчики, формы, фото, баннеры, иконки, значки, капча…).
6. Шестой уровень: перечисление названий элементов, относящихся к соответствующему типу элемента (например, названий полей для типа элемента «Поле»).
7. Седьмой уровень: указание на предмет тестирования по конкретному элементу и на раздел «Действия» / «События» для описания функционального тестирования:
7.1. Текстовый блок (конкретный):
— верное расположение на странице,
— корректный формат текста,
— корректное отображение верстки,
— элемент нельзя изменить,
…
7.2. Ссылки:
— верное расположение,
— возможность нажать,
— наличие нужного текста,
— нажатие не вызывает ошибку,
— ссылка ведет на нужную страницу,
— элемент нельзя изменить,
…
7.3. Поля:
7.3.1. Верное расположение,
7.3.2. Корректный формат,
7.3.3. Элемент нельзя изменить,
7.3.4. Действия (набор зависит от типов данных, которые содержатся в данном поле – например, числа, — и функционала элемента – например, поле для ввода):
7.3.4.1. Принимает верное значение.
7.3.4.2. Принимает ложное значение.
7.3.4.3. Не принимает текст.
7.3.4.4. Не принимает спецсимволы.
7.3.4.5. Не принимает инъекции.
7.3.4.6. Не принимает / интерпретирует число в другой системе исчисления.
7.3.4.7. Не принимает формулы и операции деления на 0.
7.3.4.8. Не принимает / интерпретирует в целое дробное число,
…
7.4. Кнопки:
7.4.1. Верное расположение,
7.4.2. Возможность нажать,
7.4.3. Наличие нужного текста,
7.4.4. Элемент нельзя изменить,
7.4.5. Действия:
7.4.5.1. Вызывает необходимую форму / запускает определенный процесс.
7.4.5.2. Нажатие не приводит к возникновению явной ошибки текущей страницы или в результатах процесса.
7.4.5.3. Нажатие не приводит к перемещению на другую страницу.
7.4.5.4. Нажатие не приводит к зависанию,
…
7.5. Чекбоксы / флаги:
7.5.1. Верное расположение,
7.5.2. Возможность выделить / снять выделение,
7.5.3. Элемент нельзя изменить,
7.5.4. Действия:
7.5.4.1. Выделение не приводит к возникновению ошибки на текущей странице.
7.5.4.2. Выделение не приводит к запуску постороннего процесса.
7.5.4.3. Выделение не приводит к зависанию,
…
7.6. Счетчики:
— верное расположение,
— отображение целого числа (количества единиц товара),
— корректный формат отображения,
— элемент нельзя изменить,
— соответствие числового значения счетчика исходной величине,
…
7.7. Формы:
7.7.1. Верное расположение,
7.7.2. Корректный формат отображения,
7.7.3. Элемент нельзя изменить,
7.7.4. Элементы:
7.7.4.1. Поля
7.7.4.2. Кнопки
7.7.4.3. Ссылки
…
7.7.5. События:
7.7.5.1. Очистка полей формы после отправки данных.
7.7.5.2. Очистка полей формы после обновления страницы.
…
7.8. Фото (с механизмом просмотра увеличенной фотографии):
7.8.1. Верное расположение,
7.8.2. Корректное отображение,
7.8.3. Возможность нажать,
7.8.4. Элемент нельзя изменить,
7.8.5. События:
7.8.5.1. Нажатие приводит к появлению увеличенной фотографии,
7.8.5.2. Нажатие не приводит к какой-либо ошибке,
…

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

Что даст мне удобное представление плана тестирования?
— перспективу (предстоящий объем работ);
— понимание структуры тестируемого объекта (и не обязательно сайта – даже ракеты);
— понимание степени покрытия тест-кейсами объекта тестирования;
— представление о том, тестирование чего я могу автоматизировать;
— в конце концов, +1 к ЧСВ (шутка).

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

Мой самолет с крыльями – это XMind 6.

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

Да, у меня уже есть некоторое представление об объемах тестирования. Его будет много…
Первое, с чего я начал, указание раздела «Страницы» и глобальные элементы (сквозные элементы – элементы шапки, подвал):

Дальше — перечисление страниц:

Далее (см. Третий уровень – выше) – перечисление общих свойств страницы и ее особых состояний (например, полная или пустая корзина):

Далее (см. Четвертый уровень) — перечисление общих свойств страницы, событий для нее:

Далее — перечисление типов элементов (текстовые блоки, ссылки, поля…):

Далее – перечисление названий элементов, относящихся к соответствующему типу элемента:

И последний основной уровень – седьмой: указание на предмет тестирования по конкретному элементу и на раздел «Действия» / «События» для описания функционального тестирования:

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

И так для каждой страницы. Да, требуется время на составление. А как же еще? Зато теперь я имею на руках карту, которую смогу проецировать на мобильную версию в случае ее обновления — немного подкорректирую. А что мне даст удобное представление плана тестирования – прошу прочесть выше.

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

Все изменения по файлу программы можно учитывать с помощью Git’а.

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

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

Источник