Я работаю тестировщиком (интернет-магазин). Вектор – управление тест-кейсами, 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’а.
Можно посадить коллегу или новенького на место тестировщика и дать ему такой план для ознакомления со структурой сайта и процессом тестирования. Мой способ ни в коем случае не заменяет системы управления тест-кейсами, а всего лишь добавляет ее.
Все данные публикации, касающиеся описания структуры плана, являются общими для большинства сайтов интернет-магазинов, поэтому не несут какой-либо коммерческой тайны.
ТЕСТ ПЛАН(Test Plan) — это документ, в котором описывается планирование процесса тестирования. Он содержит рекомендации для процесса тестирования, такие как подход, задачи тестирования, потребности в окружающей среде, требования к ресурсам, график и ограничения.
Как только вам поручат протестировать новый продукт, вы должны подумать о том, как написать тест план проекта. Что входит в созданный тест план для тестирования? Какие шаги нужны, чтобы составить тест план? Мы поговорим в данной статье! Здесь мы обсудим ответы на эти вопросы, а также предоставим для скачивания образец тест плана.
Содержание
Разработка тест плана: кто отвечает за создание?
План тестирования создается для организации проверки соответствия продукта, установленным стандартам. Как правило, составление тест плана делает Test lead, но при взаимодействии с другими членами команды.
Test lead
Product Manager
Написание тест плана
Предлагает тестовую стратегию
Ведет переговоры с заказчиком
Утверждает тест план
Определяет критерии качества
Test lead описывает объем тестирования, используемые методы тестирования, ресурсы, необходимые для тестирования, и график запланированных тестовых мероприятий. Таким образом, тест план и тест стратегия в нем, ложатся полностью на плечи Тимлида.
Что такое тест план?
Определение понятию мы давали в начале статьи, поэтому повторим простыми словами тест план – это всеобъемлющий документ, который описывает все необходимое для успешного выполнения тестирования, например, тест план приложения или тест план программы, отвечает на такие вопросы:
Следует отметить, что тест планы не могут быть одинаковыми! Это значит, что при схожей структуре они все равно будут отличаться. Также, также нужно помнить, что бывают разные виды тест планов. Охарактеризуем распространенный тест план и разделы тест плана дальше.
Структура тест плана
Различные команды могут придумать разные разделы, которые будут включены в план тестирования. Тем не менее, за основу можно использования шаблоны тест планов сайта, а потом дополнять его всем необходимым, чтобы он соответствовал вашим требованиям. И так перейдем, непосредственно к базовым пунктам. Учитывая специфику тематики, тест план для тестирования пример будем перечислять на английском.
Использовать даже стандартизированный шаблон тест плана лучше, чем не составлять его совсем, наличие плана тестирования придаст вашей команде больше уверенности.
Примечание:
Вышеперечисленные пункты будет содержать наш тест план для тестирования сайта, который можно скачать внизу страницы. А теперь давайте разберемся, зачем нужно разрабатывать тест план сайта или любого другого проекта.
Зачем создавать тест план?
Возможно, многим интересно, почему необходимо время и усилия создавая шаблоны тест планов сайта, приложения или программы. Намного проще просто перейти к тестированию и начать работу.
Тестирование — важный процесс, который контролирует и определяет качество продукта. Если вы хотите выпустить продукт без критических ошибок и уложится в запланированный график, вам нужен хороший план тестирования, чтобы это произошло. Разработанный к началу тестирования тест план сайта — пример и показатель профессионализма команды. Помимо этого, качественный Test Plan предлагает множество преимуществ:
К перечисленному нужно добавить то, что тест планом можно делиться с вашим клиентом, чтобы дать ему представление о процессе тестирования и почувствовать уверенность.
Как написать хороший тест план?
Надеюсь, на этом этапе вы убеждены, что тест план тестирования управляет успешным процессом тестирования и осведомлены, какие пункты он должен содержать. Теперь нужно понять, как написать хороший план тестирования. Как правило, написать качественный тест план можно, выполнив следующие шаги:
1. Проанализировать продукт
Первым шагом к созданию плана тестирования является анализ продукта, его функций и функциональных возможностей, чтобы получить более глубокое понимание. Кроме того, изучите требования к бизнесу и то, чего клиент хочет достичь от конечного продукта. Понимать пользователей и использовать возможности тестирования продукта с точки зрения пользователя.
2. Разработка стратегии тестирования
После того как вы проанализировали продукт, вы готовы разработать стратегию тестирования для разных уровней. Ваша стратегия тестирования может состоять из нескольких методов тестирования. Соблюдая правила использования и бизнес-требования, вы решаете, какие методы тестирования будут использоваться.
Например, если вы создаете тест план, пример на русском веб-сайте с тысячами онлайн-пользователей, вы включите «Нагрузочное тестирование» в свой план тестирования. Точно так же, если вы работаете на веб-сайте электронной коммерции, который включает онлайн-транзакции в денежной форме, вы будете подчеркивать безопасность и тестирование на уязвимость.
3. Определить область действия
Хороший план тестирования четко определяет область тестирования и границы. Вы можете использовать документ спецификации требований, чтобы определить, что включено в область действия и что исключено. Составьте список «Проверяемые функции» и «Возможности, которые тестироваться не будут». Это сделает ваш тест план конкретным и полезным. Вам также может потребоваться указать список результатов. Например, если вы выполняете нагрузочное тестирование приложения, вам необходимо указать предел максимальной и минимальной нагрузки тестируемых пользователей.
4. Разработка графика
Сознавая стратегию тестирования и сферу действия, вы можете разработать график тестирования. Разделите работу на тестирование и оцените необходимые усилия. Вы также можете оценить необходимые ресурсы для каждой задачи. Теперь вы можете включить график тестирования в свой тест план, который поможет вам контролировать ход процесса тестирования.
5. Определите роли и обязанности
В хорошем тест плане четко перечислены роли и обязанности команды тестирования и менеджера команды. Раздел «Роли и обязанности» вместе с «графиком» рассказывает всем, что делать и когда делать.
6. Предвидеть риски
Ваш тест план будет неполным без ожидаемых рисков, методов смягчения и ответов на риск. Существует несколько типов рисков при тестировании программного обеспечения, таких как расписание, бюджет, умения, знания и тд.
Тест план: пример
Для написания данного тест плана использовался шаблон. Так как, это один из простых способов не начинать с нуля и не упустить важные пункты. Просмотр заполненного тест плана позволит вам структурировать информацию для ее применения в будущем. Ниже вы можете тест план скачать в форматах: excel и pdf.
Тест план тестирования интернет сайта (type pdf, docx)
В преддверии старта курса «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
скрин – на старте есть какое-то количество жизней и шагов
скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.
Итоги интенсива:
Узнали, какие бывают виды документации у тестировщика игр.
ТЕСТ ПЛАН (Test Plan) — это документ, в котором описывается планирование процесса тестирования. Он содержит рекомендации для процесса тестирования, такие как подход, задачи тестирования, потребности в окружающей среде, требования к ресурсам, график и ограничения.
