Пять простых шагов для создания профессионального отчёта тестирования ПО
Подготовка QA-отчётности — это этап разработки, на котором результаты тестирования доводятся до сведения участников проекта. На основании этих документов выполняются корректирующие действия и принимаются решения о том, достаточно ли качество продукта для его выпуска.
Кроме того, QA-отчёты существенно влияют на распределение бюджета компании. Руководители основываются на полученных данных, увеличивая размер инвестиций в проект или сокращая ресурсы. Поэтому информативные и точные доклады в процессе разработки ценятся на вес золота.
Итак, какие обязательные компоненты должен включать в себя образцовый QA-отчёт? И какие атрибуты придают ему ценность в глазах менеджера?
Во-первых, добивайтесь максимальной простоты при написании своего отчёта. Если это возможно, не используйте слишком сложную лексику и большое количество сокращений. Добавьте в документ таблицы и диаграммы, а также скриншоты выявленных блокирующих дефектов. Это поможет вам систематизировать записи, чтобы исполнительный директор мог сразу же обратить внимание на те их них, которые имеют наибольшее значение. Также рекомендуется из раза в раз использовать один и тот же шаблон отчёта, чтобы ваш руководитель сразу знал, где в документе искать интересующую его информацию.
Во-вторых, убедитесь в правильности данных. Всегда перепроверяйте свой отчёт перед отправкой, чтобы избежать грамматических и фактических ошибок. Обращайте особое внимание вашего руководителя на критические отклонения. Не пытайтесь скрыть назревшие проблемы, чтобы сохранить свою репутацию. Чем раньше будут обнаружены ошибки, тем выше вероятность того, что они будут исправлены без каких-либо последствий.
В-третьих, всегда помните, кто получатель вашего отчёта. Сфера интересов QA-менеджера отличается от того, на что обращает первостепенное внимание заказчик. Проблемы, вызывающие озабоченность команды разработчиков, мало волнуют отдел по работе с клиентами. Принимайте это в расчёт и видоизменяйте свой документ в зависимости от того, кто его конечный получатель.
В-четвертых, включите в отчёт основные показатели, такие как:
Если вы отчитываетесь перед руководителем компании, вы также можете привести в документе информацию, которая напрямую определяет доход. Это может быть прибыльность клиентов, когда возможные риски влияют на отношения между компанией и заказчиком. Вы также можете указать общее количество и сложность задач, чтобы помочь менеджеру сформировать представление о работе QA-отдела.
Наконец, учитывайте деловую сторону вопроса. Вы можете “утопить” своё отчёт в многочисленных цифрах и неопровержимых статистических данных. Однако без динамики и чёткого «призыва к действию» этот документ так и останется абстрактным для тех, кто принимает решения. Так что не стесняйтесь направлять ваших руководителей по нужному пути, давая оценку представленной информации и предлагая конкретные шаги.
Существует ещё несколько полезных приёмов, которые придадут вашей работе принципиальную практическую ценность. Больше информации о том, как повысить эффективность QA-процессов, вы можете получить на странице нашего QA-коммьюнити.
Наши исследования показывают, что даже очерёдность расположения данных в документе имеет значение. Докладчик анализирует результаты тестирования и участвует в определении их стратегической ценности для всего проекта в целом. В конце концов, именно он обращает внимание аудитории на срочные вопросы, которые ставят под угрозу качество продукта, доверие клиентов и предполагаемую прибыль.
Отчётность в тестировании
Отчётность — сбор и распространение информации о результатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации).
К высокоуровневым задачам отчётности относятся:
Отчёт о результатах тестирования — документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущей ситуации с тест-планом и принятия необходимых управленческих решений.
К низкоуровневым задачам отчётности в тестировании относятся:
Качественный отчёт о результатах тестирования обладает многими свойствами качественных требований, а также расширяет их набор следующими пунктами:
Отчёт о результатах тестирования создаётся по заранее оговорённому расписанию (зависящему от модели управления проектом) при участии большинства представителей проектной команды, задействованных в обеспечении качества.
Большое количество фактических данных для отчёта может быть легко извлечено в удобной форме из системы управления проектом. Ответственным за создание отчёта, как правило, является ведущий тестировщик («тест-лид»). При необходимости, отчёт может обсуждаться на небольших собраниях.
Отчёт о результатах тестирования предоставляется:
Отчёт о результатах тестирования включает следующие разделы:
Логика построения отчёта о результатах тестирования
Для того, чтобы отчёт о результатах тестирования был действительно полезным, при его создании следует постоянно помнить об универсальной логике отчётности:
Выводы должны быть:
Рекомендации должны быть:
Definition of Done
Вы это уже сделали?
Что отвечать на такой вопрос рядовому сотруднику? Варианта два, но и два пути, которые данному работнику могут и не понравиться. Если он отвечает «да», то это означает, что он может взять еще работу на исполнение, а потом окажется, что ему нужно доделать старую. Также если он отвечает «нет», то его могут посчитать медлительным и он тормозит процесс.
Такой вопрос обычно задается бесчисленное количество раз при разработке какого-либо программного продукта, да и, в целом, во время рабочего процесса. В этих моментах, как и в любых других, должна быть оптимизация способная минимизировать или исключить полностью негативные стороны этого процесса. Вообще, понимание выражения «Definition of Done» в полной мере понятна людям, знакомыми с философией Scrum. Определенно сделанная задача – это та задача, которая не нуждается в доработках, но тут встает законный вопрос: «А как оценить, что задача действительно выполнена?»
Definition of Done на страже нашего спокойствия
На самом деле, на страже общего спокойствия. Мы действительно можем не понять до конца степень законченности нашей задачи, однако оповестить команду, что же мы все-таки сделали, обязаны. Definition of Done, как и всё в Scrum, должно быть лаконично, поэтому зачастую отводится для этого одно предложение, однако это не единственный вариант.
Для примера приведем несколько выполненных задач с использованием Definition of Done:
Как видно, любое описание начинается с “done=”, что дает понять, на что обращать внимание. Вообще, в листе принято писать такие результаты, которые можно проверить. Нет смысла описывать мысли, ведь, скажем, «done = придуман внешний вид интерфейса корзины» звучит странно и никак это проверить нельзя.
Желательно, изначально разработать список правил, которые будут описывать Definition of Done, чтобы все в команде писали в одном стиле. Это приведет к более быстрому пониманию того, что хотел передать коллега.
Еще одним из знаменитых способов записи Definition of Done — является простой список.
В заключении, хочется сказать, что не стоит пренебрегать Definition of Done, ведь это приводит не только к осознанию того, что было сделано, но и к тому, как это нужно сделать в будущем. Благодаря использованию Definition of Done все будут стараться делать задачи более четкими и конкретными, чтобы потом гордо сказать: «Точно сделано!». Помимо этого, набор рейтинга в Velocity будет гораздо выше.
В большинстве своем, мы привыкли к графикам идущими вверх, что означает положительную динамику, однако они могут идти и вниз и также показывать положительную динамику. Одним из таких ярких примеров является Диаграмма сгорания задач (Burndown chart). Само сочетание «Burn Down» дословно переводится как «гореть вниз» и это действительно так. Данный график является основным средством для отслеживания выполненных задач в спринте или во всем проекте. Хотя, по сути, он может использоваться как угодно, но мы его рассматриваем внутри методологии Scrum.
Пример Диаграммы сгорания задач:
Синим цветом на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и следует опираться.
Красным цветом отмечена реальная история выполнения задач.
По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные часы, количество задач и так далее.
По шкале X отмечают количество дней до окончания Sprint.
Как может показаться на первый взгляд, данная диаграмма сгорания задач / Burndown chart служит всего лишь для самоконтроля и самоотчета, однако ее использование может рассказать об очень многом.
Читаем Диаграмму сгорания задач / Burndown chart
Начнем с примеров негативных результатов как ведения графика, так и самой работы команды и закончим более качественными.
1. Burndown Chart: Слишком рано
е
По диаграмме сгорания задач/Burndown chart отчетливо видно, что команда все задачи выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает ряд совершенных проблем:
В случае такой проблемы, чаще всего Scrum Master спрашивает команду о возможности добавления дополнительных задач из Product Backlog.
2. Burndown Chart: Опоздали
Также один из видов негативных диаграмм сгорания задач.
Одной из возможных причин здесь может быть постоянное добавление новых задач во время спринта, что увеличило нагрузку.
Второй частой проблемой является недоделанность задач, когда задачи сделаны наполовину. Такие задачи, как выразился Джефф Сазерленд, являются хламом.
В такой ситуации, на Daily Scrum Meeting обязательно нужно говорить о проблемах, мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла выше, сразу надо решать проблему – это также один из постулатов методологии Scrum.
3. Burndown Chart: Без оценок
Может быть даже команда и работала, только забыла или не захотела использовать диаграмму сжигания задач, что является прямо сказать дурным тоном и противоречит эффективной работе. Команда не может контролировать себя, не может совершенствоваться и так далее.
4. Burndown Chart: Конечная оценка
Собственно, ситуация равна предыдущей. Не смотря на законченный Sprint, все итоговые оценки были внесены в диаграмму сгорания в самый последний день после завершения работы. Это равносильно тому, когда вообще законченные задачи не вносятся. По данному графику невозможно сделать вывода о правильности работы команды и, даже более того, можно предположить, что команда не стремится к развитию.
5. Burndown Chart: Zero
Отсутствие показателя реальных задач в диаграмме не является поводом считать, что работа не производилась, ведь она могла быть просто не оценена. Как и в предыдущих пунктах, такая позиция не позволяет контролировать работу собственной команды и совершенствоваться.
6. Burndown Chart: Релаксирующая команда
Этот пример диаграммы сгорания задач уже значительно лучше, нежели другие, ведь в нем можно увидеть, как усовершенствовать команду. Возможные проблемы здесь такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой.
7. Burndown Chart: Совершенствование
Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в самом начале были трудности, но во время Daily Scrum Meeting все вопросы вскрывались и Scrum Master исправлял работу, ведя команду к цели.
Также, возможно, группа делала принципиальное ускорение для достижения цели.
Еще одной причиной, к примеру, может быть то, что команда брала дополнительные задачи.
8. Burndown Chart: Опыт
На лицо опытная группа, которая, после начала работы, сразу исправляет все возникающие трудности и совершенствуется так, что резко переходит к активному сжиганию.
9. Burndown Chart: A++
Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как строится идеальный график =).
Матрица соответствия требований (Requirements Traceability Matrix)
Это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы.
Матрица соответствия требований используется QA-инженерами для валидации покрытия требований по продукту тестами.
Цель «Traceability Matrix»:
Данный тестовый артефакт является неотъемлемой частью тестирования.
Тестовая документация и анализ требований
В преддверии старта курса «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
скрин – на старте есть какое-то количество жизней и шагов
скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.
Итоги интенсива:
Узнали, какие бывают виды документации у тестировщика игр.
Обсудили зачем тот или иной документ нужен.
Попрактиковались в создании чек-листа.
Список материалов для самостоятельного изучения: