Как выглядит хороший чек лист qa engineer excel
В преддверии старта курса "Game QA Engineer" публикуем текстовую расшифровку онлайн-интенсива, который провела Надежда Чертовских — руководитель отдела QA в компании BeresnevGames и преподаватель OTUS.
Цели интенсива:
познакомиться с основными видами тестовой документации;
проанализировать документ от game-дизайнера;
попрактиковать составление чек-листа.
Для начала давайте обсудим такой животрепещущий вопрос: почему сегодня на курсе «тестировщик игр» мы обсуждаем документацию?
Как тестировщик, который целый день только в игры играет и сообщает разработчикам об обнаруженных ошибках, связан с документацией? Какая вообще работа у тестировщика игры? Какие у тестировщика могут быть документы?
Существует распространённое заблуждение, что тестировщик игр целый день только и делает, что в игры играет. Но на самом деле это не так. Тестировщик в геймдеве точно такой же тестировщик, как и в любой другой сфере, и работает точно по такому же принципу, но продукт у него не web-страничка, не application на операционной системе, а игра (мобильная, консольная, десктопная).
Тестирование может быть автоматизированным и ручным
На интенсиве мы поговорим в целом об артефактах тестирования, с которыми работает тестировщик:
План тестирования (Test Plan)
Тест-кейс (Test Case)
Баг-репорт (Bug Report)
Отчёт о тестировании (Test Report)
Из этого мы можем сделать вывод, что тестировщик не только читает требования, которые подготовили к продукту, но и сам генерирует документы.
В ходе интенсива мы более подробно поговорили о 6 типах документов, которые перечислили выше, обсудили, какие из них полезные, какие используются чаще, какие меньше и составили чек-лист по требованиям.
План тестирования
План тестирование (далее ПТ) или тест-план – это большой документ, который чаще всего описывает весь объем работ по тестированию проекта либо части проекта (например, релиза или предрелизного билда). ПТ описывает, что будет тестироваться, в какие сроки, какими инструментами, какая команда, обязанности и ответственности каждого члена команды. Также часто в ПТ включается стратегия тестирования, график релизов на несколько ближайших спринтов. В зависимости от команды бывает разная степень детализации ПТ и его могут делать разные люди в команде. В каких-то компаниях ПТ делает менеджер, в каких-то middle-тестировщик, либо senior-тестировщик, либо тимлид отдела тестирования.
Всё, что мы далее обсудим по документам, которые генерирует тестировщик, может отличаться от компании к компании, от команды к команде. В зависимости от команды и компании форм-фактор всех документов может быть либо уже обговорён и установлен, либо, если вы приходите первым QA специалистом на проект, то вы сами устанавливаете, как удобно вам.
Форм-фактор у тест-плана может быть разный (схема, интеллектуальная карта и т.д.) и зависит от того, как команде будет удобнее взаимодействовать с документами.
Чаще всего ПТ требуется именно для людей, которые принимают решения по проекту, чтобы они поняли, что в следующий момент мы делаем: релизим билд или нужно подвинуть сроки, добавить к тестированию, убавить к каким-то другим срокам. И лучше всего не делать ПТ огромным, чтобы человек, который будет его читать, смог осилить весь объём. Если посмотреть примеры тест-планов в интернете — часто это одностраничная схема, чтобы все в общем и целом понимали, какой объем тестирование предстоит. Обычно план тестирования делается до начала тестирования и до момента релиза.
Таким образом План тестирования:
описывает стратегию тестирования, цели, график, оценку, результаты, а также ресурсы необходимые для тестирования;
имеет разную степень детализации;
имеет разный форм-фактор;
составляется не более, чем на 2-х страницах;
составляется до начала тестирования.
Тест-кейс
Тест-кейс можно сравнить с рецептом — это последовательность шагов, которые приводят к какому-то результату. Тест-кейс лучше не делать избыточным. Тестировщики чаще всего хорошо знают свой проект, поэтому досконально писать тест-кейс нет необходимости. Тест-кейс должен быть краткий и понятный, так чтобы другой тестировщик, либо другой специалист в команде смог быстро пройти по нему и проверить, что все происходит так, как нужно.
Тест-кейсы можно формировать в последовательный сценарий, чтобы проверить, как игрок пройдет по этому функционалу от начала до конца.
Тест-кейсы можно группировать в смысловые блоки.
Например, если в игре запускается какой-то ивент, формируется набор тест-кейсов для проверки этого ивента.
Тест-кейсы лучше писать по требованиям гейм-дизайнерского документа. Но, если функционал уже готов, а требований тест-кейсов по нему не написано, можно написать уже по факту. Лишним не будет.
Составляющие тест-кейса:
идентификатор (уникальный номер, по которому вы сможете найти этот тест-кейс и на него сослаться);
название сценария (какое-то краткое, но ёмкое);
ссылка на требования ГДД;
предусловия (опционально, если они требуются для тест-кейса);
фактический результат (опционально).
Чек-лист
Чек-листы можно сравнить со списком покупок, который мы формируем на проверку. Например, чек-лист на Smoke-тест, чтобы проверить, что игра запускается и весь функционал, который должен в игре отрабатывать отрабатывает, иконка приложения соответствует иконке нашего приложения. Также чек-лист может быть составлен на регрессионное тестирование и даже на тестирование требований.
Чек-листы чаще всего составляются без детализации и их можно скомпоновать в наборы и проверять тоже для любого функционала либо нового, либо регрессионного.
Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу.
Небольшой пример из игры нашей студии: есть поле для ввода имени питомца и есть несколько условий на этом поле: имя питомца должно состоять из более чем 2 символов и только в этом случае кнопка из серой неактивной станет зеленой активной и можно будет питомца наименовать. Мы начинаем формировать чек-лист к этому полю если количество символов больше 2 то кнопка принять становится активное, если меньше 2 не активно. Первые 2 пункта чек-листа, которые можно проверить.
На скриншоте мы видим, как игрок из Китая захотел назвать питомца очень коротким ёмким именем и, к сожалению, не смог это сделать и обращался в тех. поддержку. В результате ему пришлось выдумывать более длинное имя.
Ссылка на mindmap чек-лист для мобильной игры:
Баг-репорт
Баг-репорт оформляется, когда баг уже локализован и его можно повторить. Если баг плавающий, нужно пытаться его повторить или занести в систему, где фиксируются баги, как плавающий баг. Ключевой момент, что баг можно повторить и воспроизвести, только тогда его заносят в систему с багами, где хранятся баг-репорты. Если создать и оформить какой-то баг, и разработчик не сможет его воспроизвести, то тут появится множество вопросов.
Поэтому лучше всего сразу проверить на нескольких устройствах, если это возможно и посмотреть на разных операционных системах, на разных разрешениях экрана, то есть максимально локализовать проблему.
В баг-репорте обязательно должны быть:
Подробное описание проблемы – что, где, когда случилось.
Важность дефекта, который указывает тестировщик, а уже приоритет по исправлению этой ошибки указывает менеджер либо команда из разработчиков.
Условия воспроизведения – версия игры, версия операционной системы и другие уникальные условия, которые могут помочь разработчику быстро найти баг, устранить и передать задачу на тестинг.
Алгоритм воспроизведения – пошаговые предусловия предусловия, которые необходимы для воспроизведения бага.
Доказательства – скрины, видео, логи с устройств.
Скриншоты из разных систем, в которых баг-репорт можно вести. В разных компаниях в разных командах условия могут быть абсолютно разные, и где хранятся баг репорты — также зависит от компании.
Отчет о тестировании
Отчет о тестировании пишется, когда функционал уж проверен и релиз либо предрелиз показывает итог проделанной работы.
Отчет о тестировании может быть представлен как текст, таблица, график или диаграмма, если это позволяет инструмент.
Составляющая отчёта о тестировании:
Кто тестировал (состав команды).
Когда тестировал (даты проведения тестов).
Как тестировал (процесс тестирования, описание применяемых методов и технологий).
Какие возникли проблемы и как решились.
Инструкция
Инструкцию можно писать до, во время или после тестирования. Инструкцию никогда не поздно написать. Это помогает как новичкам, так и коллегам, которые работают в одной команде. С помощью инструкции можно быстро сориентироваться в проекте.
Например, вышел новый функционал. Лучше написать инструкцию, как этот функционал проверить, как переключаться, если проверка нового функционала подразумевает переключение между версиями или предусматривает какой-то сложный алгоритм проверки. Это экономит время на объяснения, когда требуется делегировать задачу либо в команду пришел новый человек и нужно его обучить.
Также инструкция помогает выгрузить старое и не потерять. Скорость выпуска релизов в геймдеве довольно высокая и часто есть необходимость вернуться к старому функционалу, который ранее уже тестировался, но прошло какое-то время и тестируется новый функционал, а нужно вернуться к проверке того старого. Поэтому лучше всего, чтобы было прописано, как тестировать, где тестировать, что и куда переключать. Лучше всего все в картинках, гифках или видео. Сегодня современные инструменты всё это позволяют сделать быстро и без проблем. Также ели есть возможность сохранять какие-то состояния проекта, состояния продукта, то лучше где-то всё это фиксировать и выкладывать в общем доступе.
Инструкции лучше писать сразу. Это позволяет избежать множество проблем в дальнейшем.
Где хранить:
Google Docs, Google Sheets
Cucumber (Hip Test)
Zephyr, Test Management for Jira
Геймдизайнерский документ (ГДД, диздок)
В геймдизайнерском документе гейм-дизайнер пишет требования к продукту или к отдельному функционалу.
Детализация у геймдизайнерского документа может быть разная. Форм-фактор также может быть разным.
Существует несколько способов проверки требований к игре: по принципу Что? Где? Когда? или по принципу проверки на полноту, однозначность, непротиворечивость, тестируемость, необходимость, осуществимость.
После того как геймдизайнерский документ готов лучше всего, если его прочитают и вместе обсудят специалист по тестированию, разработчик и сам гейм-дизайнер.
Тестировщику в этом случае следует задавать следующие вопросы: не противоречит ли те требования, которые гейм-дизайнер написал, функционалу, который сейчас есть, не будут ли нововведения противоречить наративу, функциям и механикам, которые есть в игре сейчас.
Требования геймдизайнерского документы должны пониматься всеми однозначно, что исключает какого-либо двоякого толкования.
Важно смотреть на полноту содержания: все ли условия предусмотрены, все ли сценарии, которые могут возникнуть у игрока в связи с новым функционалом продуманы.
Разработчик смотрит на возможность реализации ГДД.
Также необходимо продумать, как новый функционал будет тестироваться, после того как разработчик его реализует.
Практическая часть интенсива. Мы попробуем сформировать чек-лист и вопросов гейм-дизайнеру по новому продукту на основе ГДД.
На картинке мы видим 3 скрина игры.
скрин – изображение и кнопка Play, при нажатии на которую, мы попадаем в игровой mod
скрин – на старте есть какое-то количество жизней и шагов
скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.
Итоги интенсива:
Узнали, какие бывают виды документации у тестировщика игр.
Обсудили зачем тот или иной документ нужен.
Попрактиковались в создании чек-листа.
Список материалов для самостоятельного изучения:
Привет, Хабр! Анастасия Асеева-Нгуен (эксперт по инженерным практикам в Tinkoff Group) приглашает специалистов по тестированию на бесплатный Demo-урок «Метрики», который пройдёт в рамках нового профессионального курса OTUS — «QA Lead». А мы публикуем статью Анастасии Шариковой — руководителя отделом тестирования в Bookmate.
Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.
Сегодня речь пойдет о чек-листах — отличном универсальном инструменте, который может помочь в повседневных задачах QA специалистам любых уровней. Обратимся к теории и вспомним, что есть и особый вид тестирования, который их использует:
Тестирование на основе чек-листов — метод создания тестов, основанный на опыте, при котором опытный тестировщик использует высокоуровневые списки.
К сожалению, многие забывают, что чек-листы можно использовать не только как подготовительный этап к дальнейшему написанию тест-кейсов, но и сами по себе. Зачастую они даже могут их заменить целиком, и о вариантах их использования и плюсах и минусах будет написано далее.
Варианты использования чек-листов
Как верно было написано у С. Куликова в «Тестирование программного обеспечения. Базовый курс»
… тестировщику приходится работать с огромным количеством информации, выбирать из множества вариантов решения задач и изобретать новые.
— и во многих случаях действительно прекрасным инструментом и для разработки, структурирования проверок и для многих других задач QA специалист может использовать чек-листы. Давайте рассмотрим поподробнее некоторые варианты:
Ad-hoc/Исследовательское тестирование — структуризация идей и задач в случае проведения таких видов тестирования+ отметка для себя о том, что уже проверено.
Тестирование на основе чек-листов — довольно популярный метод создания тестов, основанный на опыте, при котором опытный тестировщик использует высокоуровневые списки. Список в данном случае содержит пункты, которые нужно отметить или запомнить, или состоит из набора правил или критериев, согласно которым верифицируется нужный программный продукт.
Mind Maps — несмотря на то, что чаще всего чек-лист выглядит как перечень блоков, секций, страниц, других элементов, которые следует протестировать, он может быть и визуализирован в виде майнд карт. А еще их можно не только составлять самим, но и находить уже готовые, что позволит сэкономить время и посмотреть на задачи проверок свежим взглядом.
«Групповое» тестирование — фичи, сложные задачи, командная работа, во всех этих случаях можно использовать списки для синхронизации проверок в группе, работающей над одной задачей.
Приемка задач — и в этом контексте мы можем говорить и про визуализацию стадий тестирования, и про визуализацию готовности взятия задачи в работу. В первом случае мы можем составить список, пример которого можно найти, например, тут . Во втором случае мы можем создать, например, чек-лист в таске в Jira, который будет требовать наличие документации, макетов, информации об окружении и прочей важной информации для перевода задачи в статус Testing.
Информирование менеджмента — зачастую проще выслать ссылку на постоянно обновляемый чеклист, который покажет процент выполнения, чем ежечасно отвечать на вопросы в духе “А когда? А сейчас уже проверили?”
Матрицы трассируемости - по сути основой этой матрицы и будет служить чек-лист. Подробнее о примере, можно почитать, например, тут.
Планирование тестирования - один из вариантов составления тест-планов, который вполне имеет место.
Конечно, это не весь список возможностей, но уверена, что-то из этого многие смогут применить у себя на проекте, особенно в небольших командах.
Способы составления чек-листов
Тут ваши возможности почти что безграничны - списки могут быть и структурированными, и многоуровневыми, и в свободном порядке - главное, чтобы формат был удобен лично тем, кто будет их использовать. По сути, их формат будет во многом зависеть от того, зачем вы их составляете и того, какой инструмент вы решили для этого использовать. Ну и конечно не стоит забывать о том, что их важное преимущество - возможность к многократному переиспользованию.
Преимущества и сложности в использовании
Рассмотрим основные преимущества и сложности, которые могут появиться при использовании чек-листов для различных кейсов и задач:
Плюсы:
Гибкость - этот вид проверки может быть использован во всех уровнях и типах тестирования, хоть и в разной форме, помимо этого, его легко адаптировать под нужды конкретной задачи.
Простота создания и поддержки - создать, использовать и поддерживать контрольный список несложно, помимо этого существует довольно много легкодоступных инструментов, но их я рассмотрю в конце статьи.
Удобно использовать в команде и вне ее - чек-листы можно использовать не только внутри команды, например для совместного тестирования одной фичи, но и как источник информации для команд разработки, заинтересованных в информации, так и для руководства.
Простота визуализации - легко понять, что уже готово, что не готово, оценить возможность передачи задачи в работу, например или изучить продукт или его часть на наличие и состояние критических проблем без траты времени на поиск в jira или подобных системах.
Расширение тестового покрытия за счет отличий при прохождении - тут и возможность избежать “парадокса пестицида” (подробнее можно почитать у автора термина), и возможность по-разному комбинировать проверки, в случае тестирования, например. функционального.
Минусы:
Недостаточная для некоторых целей детализация - например, внутри команды содержание будет понятным, но внешним заказчикам или руководству может быть непонятна суть пунктов списка.
Возможность различной интерпретации - QA инженеры с различным опытом могут выполнять одинаковые задачи, используя различные подходы, что может быть одновременно и плюсом и минусом.
Не всегда удобно для отчетности - ложные системные компоненты, функции и их взаимодействие сложно или даже невозможно проиллюстрировать с помощью чек-листов.
Не подходят для новичков и джунов - если опытный сотрудник без проблем может понять, что следует проверить, проконтролировать и учесть с помощью списков, так как он обладает достаточными знаниями о проекте, с новичком или джуниором есть вероятность, что такого уровня документации будет мало.
Инструменты
Как итог, перечислю одни из самых популярных инструментов для составления чек-листов:
Trello — тоже имеет функционал составления чек-листов в рамках задач.
Google.Sheets — этот инструмент в представлении не нуждается. Тем не менее это, конечно, не единственное решение с таблицами, Exсel тоже подойдет!
To Do — перерождение Wunderlist и отличное решение для чек-листов, особенно для личного использования.
Miro — а вот тут будет удобно создавать уже Mind Maps.
Jira — в этом случае есть много вариантов встраивания под разные задачи + доп. Инструменты, такие как этот.
Знаете еще крутые инструменты и кейсы использования? Пишите в комментариях!
Интересно развиваться в данном направлении? Запишитесь на бесплатный Demo-урок «Метрики», а также приходите на другие Demo-уроки для QA-специалистов:
«Основы puppeteer» — трансляция в рамках курса «Автоматизация тестирования на JavaScript»
В предыдущей статье я рассказывала, как в нашей компании проходит первая стадия тестирования проекта — анализ. Сегодня расскажу о следующем этапе — проектирования и документирования тестов.
Этот этап опционален. На некоторых проектах нет задокументированных требований, и тогда зачастую поддержка тестовой документации является единственным разумным способом хранения и передачи знаний о продукте. Иногда тестовую документацию требует заказчик, иногда мы пишем ее для себя. Иногда, если у нас есть хорошо написанные требования, мы отказываемся от документирования тестов в пользу экономии ресурсов.
Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.
Чек-листы vs Тест-кейсы
Чек-лист отличается от тест-кейса степенью подробности. В чек-листе вы не встретите подробных шагов кейса, для использования чек-листа при тестировании очень много информации нужно держать в голове в момент прогона тестов и знать логику работы приложения на отлично.
В нашей компании всегда использовались чек-листы, поскольку на написание тест-кейсов уходит неоправданно много времени, и они тяжеловесны — на прочтение кейса и его осознание тоже уходит время. Кроме того, не стоит забывать про эффект пестицида — баги кода имеют свойство приспосабливаться к тестам. При использовании чек-листа сохраняется некоторая свобода действий, а тест-кейсы этой свободы полностью лишают, увеличивая упомянутый выше эффект. Однако, при прогоне чек-листа в седьмой раз за последние сутки перед релизом часть функциональности, заложенной под одним пунктом чек-листа, теряется по причине человеческого фактора.
Было принято решение расширять чек-листы и делать их подробнее. Так тестировщик, в беспамятстве прогоняющий фичу перед релизом, не забудет проверить ошибки сети в ответ на каждый запрос, не потеряет проверку какой-нибудь «неважной» кнопки или какого-нибудь одного статуса из двенадцати. Так мы пришли к написанию подробной юзер-стори, полностью покрывающей фичу приложения, но по факту являющей собой один громадный тест-кейс.
Плюсы такого подхода:
- чек-лист подразумевает непрерывное выполнение его тестировщиком. Соответственно, все кейсы расположены в порядке, удобном для прогона, и времени на переход к следующему кейсу не тратится
- чек-лист покрывает большое количество пользовательских сценариев
- чек-лист содержит как позитивные, так и негативные кейсы. Проверяет восстановление после ошибок и прерываний, что в случае мобильных приложений очень важно
- чек-лист подразумевает длинные сессии, что повышает вероятность обнаружения утечек памяти и навигационных проблем
- информация о требованиях поступает тестировщику последовательно, что дает лучшее понимание логики работы приложения
- чек-лист подразумевает декомпозицию по экранам приложения и сильно завязан на дизайн. Соответственно, все изменения в дизайне подразумевают изменения в чек-листе
- с учетом, что кейсы такого чек-листа должны быть связаны в единую стори, а кейсов в одном чек-листе может быть до двух сотен, поддерживать его сложно
- эффект пестицида значительно повышается
- чек-лист не может заменить требования для разработчиков — разрабатывать по таким требованиям неудобно
- чек-лист довольно долго писать и из-за его громоздкости его не всегда удобно использовать — по факту он пригождается только в финале перед релизом
Таблицы vs Деревья
Однажды я выпила поливитаминов, и меня осенило, что вместо того, чтобы хранить тесты в табличных форматах, куда удобнее использовать деревья, а точнее, вложенные списки. Ведь при написании той самой большой юзер-стори мы так часто сталкиваемся с проблемой, что не знаем, где расположить альтернативные действия. Например, когда у нас несколько кнопок на алерте. Чтобы проверить каждую из них, нам приходится прописывать вызов этого алерта несколько раз. Вместо этого мы могли бы подвесить проверку каждой из кнопок к вызову алерта.
В целом идея была в том, чтобы прописывать те же самые пользовательские сценарии в виде дерева, в котором переход — это действие, а узел — это состояние, в котором оказывается приложение после этого действия. По факту диаграмма состояний-переходов, только объектами выступают экраны приложения. Каждая ветвь такого дерева — тест-кейс.
Когда стали пробовать, столкнулись с проблемами. Оказалось, что привычная нам декомпозиция по экранам приложения не работает: опираться на дизайн при проектировании тестов неудобно. Ветки дерева росли далеко в глубину, и это было неудобно визуально. В погоне за сценарием мы воротили циклы. А еще стало понятно, что отказаться от таблиц нельзя.
Решение крылось в смене подхода к декомпозиции, большей осознанности и отказе от «решений по умолчанию». Древовидная структура тестовой документации действительно удобна, поскольку дает большую свободу при проектировании. Вид декомпозиции определяет, что именно станет узлами нашего дерева. А это в свою очередь определяется особенностями продукта и приоритетами заказчика.
В целом, плюсы использования древовидной структуры:
- структура такой документации в итоге очень гибкая и позволяет вести как чек-листы, так и тест-кейсы в зависимости от нужд проекта
- дерево представляется в виде вложенных списков: у узлов дерева есть некоторый порядок, что сохраняет возможность последовательной и структурированной передачи информации о требованиях тестировщику в случае отсутствия на проекте задокументированного ТЗ
- такая структура позволяет спроектировать тестовую документацию, которую можно передать разработчикам вместо ТЗ
- временные затраты на написание чек-листов и тест-кейсов снижаются, поскольку структура позволяет избежать копипасты
- такая структура тестовой документации требует тщательного проектирования и предварительной аналитики — при плохом проектировании все упомянутые выше плюсы теряются
Итоговые паттерны
Экраны приложения
Источником знаний является навсхема. Первый уровень дерева составляет список кейсов навсхемы, который обычно соответствует разделам приложения. Далее к ним подвешивается список экранов каждого раздела, к каждому экрану — список его состояний. В каждом узле дерева, начиная с третьего уровня, может содержаться чек-лист в табличном формате, описывающий каждый элемент дизайна и способы взаимодействия с ним. Если элементы дизайна сложные и имеют много состояний или на экране есть повторяющиеся элементы, можно декомпозировать еще глубже. Таким образом, одна ветвь дерева описывает жизненный цикл одного экрана.
Ниже в качестве примера приведена общая схема рассуждений при декомпозиции раздела заказов агрегатора авиабилетов.
К листьям этого дерева крепим короткие чек-листы. Так к каждому листу «навбар» линкуем чек-лист на элементы навбара для текущего экрана:
А к каждому листу «секция запланированные поездки» линкуем чек-лист на проверку части списка с активными заказами:
Критерии для выбора такого паттерна следующие:
- UI является приоритетным для заказчика
- минимум бизнес-логики на клиенте
- для приложения характерны кастомные элементы дизайна и анимации, сложные жесты
- на проекте нет других задокументированных требований кроме навсхемы
Объекты/действия
При таком подходе ориентируемся не на навсхему, а на документацию АПИ и клиентскую бизнес-логику. Негативные и позитивные кейсы разбиваем по разным веткам. Желательно, чтобы элементы одного уровня дерева отвечали на один вопрос, но можно оставить это ограничение только для одного уровня иерархии.
Такая схема крайне удобна в тех случаях, когда у нас есть активное влияние пользователей друг на друга, что порождает сложные сценарные цепочки. Примером может служить чат. Относительно предыдущего подхода такую документацию легче поддерживать, поскольку изменения в логике случаются реже, чем в дизайне.
Ниже приведен пример общей схемы рассуждений при декомпозиции по принципу объект/действие.
В такой схеме дополнительным бонусом является возможность использовать ее как карту для исследовательского тестирования и для смоук-теста. Степень подробности тестирования можно регулировать, отсекая при прогоне уровни дерева, поскольку каждый следующий уровень уточняет предыдущий. При углублении в ветвь дерева — углубляешься в функциональность.
Например, для уже упомянутого чата схема документации будет выглядеть примерно так:
Критерии выбора такого паттерна:
- цель — протестировать функциональность
- сложная бизнес-логика
- частые правки дизайна
- стратегия тестирования на проекте подразумевает сочетание скриптового и исследовательского тестирования
На базе Use cases
Бывают ситуации, в которых нерентабельно декомпозировать функциональность и проектировать тесты по двум описанным ранее схемам. Например, если мы хотим покрыть тестами длительную работу с приложением – как в случае с лентой соцсети или прослушиванием музыки в бекграунде. Или когда фича завязана на сценарии с малым количеством альтернатив – например, оформление подписки на контент. В таком случае пользуемся третьим паттерном, основанном на пользовательских сценариях.
Сначала декомпозируем функциональность по use-кейсам. Определяемся с тем, какие действующие лица могут участвовать в процессе работы с приложением и какие цели они могут перед собой ставить. За это будут отвечать первые два уровня нашего дерева. Далее пытаемся найти все возможные входные условия, которые могут повлиять на отработку сценария по достижению текущей цели, и структурируем их в дереве. Их так же удобнее всего делить на позитивные и негативные. Далее к каждому листу подвешиваем сценарный чек-лист на проверку функциональности, отвечающей за достижение цели.
В качестве примера ниже приведена схема для музыкального плеера с функцией загрузки треков для прослушивания офлайн:
Здесь ко всем листьям позитивного сценария подвешиваем чек-лист, который нужно будет прогонять в условиях разных подключений к сети:
Бывает так, что при продумывании возможных use-кейсов цели пользователей получаются очень глобальными. Например, в уже упомянутом агрегаторе авиабилетов цель «купить билет» может поставить в тупик обилием возможных вариантов предусловий и количеством шагов, которые необходимо пройти для достижения цели. Кроме того, в таком приложении очень многое зависит от поведения сторонних систем, что накладывает некоторые ограничения на определение всех предусловий и однозначно выполняемого сценария. Предложения поступают от разных авиакомпаний и могут измениться в любую минуту. В каждый момент времени невозможно гарантировать, что покупка билета пройдет успешно, поскольку этот билет может оказаться куплен, пока мы заполняли данные для брони.
Решение первой проблемы заключается в более детальной декомпозиции. То есть большую цель «купить билет» можно разбить на маленькие цели, соответствующие шагам оформления — «ознакомиться с предложениями», «заполнить данные пассажиров», «оплатить заказ». И далее находить набор возможных предусловий, действий пользователя и результатов для этих маленьких целей.
Решение второй проблемы менее очевидно. Это в целом ограничение use-кейса — в случае, если поведение системы не определяется действиями пользователя однозначно, возникают проблемы с покрытием и проектированием use-кейсов. Для себя решили, что в таких ситуациях мы стараемся прописать все возможные варианты поведения систем, неподвластных пользователю, как предусловия, и тем самым снижаем неопределенность результата выполнения сценария. Либо используем другую схему проектирования тестовой документации.
Критерии выбора такого паттерна:
- для заказчика приоритетом является корректная работа определенных пользовательских сценариев
- приложение содержит экраны, на которых пользователь проведет много времени, потребляя контент
- приложение содержит фичи, заключающиеся в отработке линейного сценария
- стратегия тестирования на проекте подразумевает скриптовое тестирование
- простая бизнес-логика, легко покрываемая use-кейсами
Отталкиваемся от цели
Мы сменили инструмент и выработали новые подходы к ведению тестовой документации, но от старых подходов не отказывались. Выбор стратегии зависит от потребностей на проекте и приоритетов заказчика. Если логика приложения простая и проект длится недолго, то обычно достаточно стандартных чек-листов на функциональность с минимальной подробностью. Если проект большой, сложный и без требований, то на часть фич стоит написать полноценную «древовидную» документацию. Если на проекте есть хорошо задокументированные требования, то иногда можно не тратить время на написание тестов по функциональности, зато можно уделить больше внимания нефункциональному тестированию (производительности, безопасности) и систематизировать его – опять же, если есть соответствующая договоренность с заказчиком. Или задокументировать только «рискованные» тесты. Юзер-стори все равно пишем почти всегда, но уже не такие подробные — как приемку для заказчика или как смоук-тест, а проведенная до этого работа по декомпозиции помогает нам быстро проектировать сценарий и правильно расставлять приоритеты.
Наличие тестовой документации на проекте позволяет зафиксировать информацию о требованиях, заранее продумать и структурировать тесты, снизить порог вхождения в проект нового тестировщика, снизить риски пропуска ошибок из-за человеческого фактора. Однако, написание и поддержка тестовой документации требуют ресурсов, которые не всегда возможно или не всегда оправданно тратить.
Зачастую на проектах, вы будете писать не тест-кейсы, а чек-листы. Они пишутся либо в специфическом софте, например HP ALM (HP QC), Zephyr for JARA, либо, самое популярное - Google drive, Excel. Определенного формата создания чек-листов не существует. Каждая команда сама для себя решает, как им удобнее хранить и описывать тесты, и насколько детально всё описывать.
Введение в чек-листы
Чек-лист (checklist) — документ, описывающий набор (список) проверок или идей.
Люди используют список проверок в повседневной жизни, как в быту, так и на рабочем месте для организации деятельности и процессов. Особенно актуально и важно в сферах, требующих повышенного внимания и нетривиальных задач. Помогает не упустить наиболее сложные моменты в больших проектах.
В тестировании списки проверок называются чек-листами. Чек-листы создаются QA инженерами на основе заявленных требований, опыта и знания тестировщиков системы. Частым явлением стало тестирование на основе чек-листов в проектах.
Преимущества чек-листов в сравнении с тест-кейсами:
- оперативное написание и легче поддерживать;
- гибкость в модификации полей и действий тестировщика;
- списки проверок выстроены в порядке приоритета;
- наглядное отслеживание выполненных проверок тестировщиком;
- удобен при отсутствии требований и спецификаций к проекту;
- разбивает задачу на множество подзадач, упрощая и акцентируя внимание на деталях;
- предотвращает «эффект пестицида», так как каждый тестировщик вводит свои данные;
- экономит средства фирмы.
«Эффект пестицида» — постоянное повторение одних и тех же шагов тест-кейса приводит к снижению его эффективности, так как при регулярном прогоне тестовых сценариев дефекты перестают находиться.
Чек-лист – отличный мотиватор для продуктивности и мотивации тестировщика, понимающий и видящий свой прогресс тестирования.
Необходимо учитывать некоторые нюансы чек-листов:
- поддерживать логичность и последовательность чек-листа;
- формировать взаимосвязанные проверки для тестирования;
- учитывать приоритеты проверок;
- в первую очередь проводить тесты по позитивным сценариям, в конце по негативным.
Статусы проверки чек-листа:
- passed — проверено, соответствует ожидаемому результаты, работает согласно заявленным требованиям. Комментарий необязателен.
- failed — поведение системы не соответствует ожидаемым требованиям, найден дефект. Пишется комментарий, желательно указывается ИД бага в багтрекенговой системе.
- blocked — выполнить проверку невозможно, имеются обстоятельства (дефект, модуль, компонент), которые блокируют дальнейшую проверку. В комментарии указывается причина.
- skipped — тест пропущен. Возможно, отсутствует необходимый модуль для проверки, который будет не реализован. В комментарии указывается причина пропуска.
- draft - тест пропущен, либо не начат. Отсутствует объект тестирования, который будет реализован позже. Комментарий не обязателен.
Правила составления чек листов
- Каждый пункт – одна процедура
В чек лист добавляют отдельными позициями:
- Позиции в чек листе желательно писать в утвердительной форме
- Определиться с целесообразным количеством позиций в чек листе
На разных интернет ресурсах и книгах советуют, что для оптимального чек листа достаточно до 20 пунктов. Мы не совсем согласны с схожими мнениями. Временами необходимо разбить чек лист и до 50 пунктов, в случае с проверкой страниц сайта, кнопок, ссылок. Неуместно создавать 5 индивидуальных чек-листов взамен одному. Далее по оглавлению приводим пример аналогичного списка проверок.
Примеры различных видов чек-листов
Четких критериев для создания чек-листа не существует. Количество столбцов, значения, строки зависят от конкретной специфики реализуемого проекта или устоявшиеся порядки в команде тестировщиков.
1. Минимальный чек-лист состоит из 3-х столбцов ID («Номер»), Tester Actions («Проверка», «Действия тестировщика»), Actual Result («Результат»):
По необходимости в чек-лист добавляется поле Comment («Комментарий»):
2. Чек-лист может быть разбит на более детализированные задачи:
3. Чек-лист расширяется при необходимости проводить тестирование в различных тестовых средах:
4. Чек-листы используются для различных версий проекта, системы, модуля. Для удобства, используется несколько вариантов, либо создается новый файл в каталоге с именем версионности, либо добавляется новое поле:
5. Чек-лист может содержать порядок действий(инструкций) для тестировщика по необходимости:
6. Зачастую будете сталкиваться с чек-листами, содержащими поле Expected Result («Ожидаемый результат»):
Пример чек-листа проверки страниц на сайте
Материалы для скачивания:
Заключение
Создание чек-листов в тестировании очень полезный навык для QA инженера. Даже, если на вашем проекте он не предусмотрен, старайтесь применять для своей выгоды и собственных целей. Спустя время, вы убедитесь, насколько он помогает в проведении тестировании, особенно при написании тестов и регрессе.
Чтобы попрактиковаться в составлении чек-листов в виде доски Kanban, советуем ознакомиться с продуктом от atlassian под названием "Trello":
- реализация в веб-версии, мобильном приложении;
- абсолютно бесплатен для нескольких пользователей;
- возможна интеграция с Jira и Confluence;
Линейка продуктов atlassian очень популярна в сфере разработки и тестирования приложений. Рекомендуем начинать изучение и практику, как тестировщику, именно в ней.
Тест-кейс один из самых популярных видов документации для тестирования. Документацию на основе кейсов пишут тестировщики(QA инженеры) или тест-дизайнеры. Для вас не составит особого труда в понимании документа, если вы хотя бы раз в жизни читали инструкцию или руководство к сборке комода.
Тест-кейс(test-case) – документ, описывающий шаги, параметры, условия, необходимые для проверки ожидаемого результата тестируемого модуля, системы, либо её части.
Тест-кейс - документ, который содержит в себе набор шагов для проверки одного ожидаемого результата.
Поговорим про структура у классического тест-кейса и в каких программах его обычно создают, например, в Word, Excel, txt.
Цели написания тест-кейса
Не на всех проектах готовы поддерживать тестовую документацию в виде тест-кейсов. Для этого необходимо преследовать определенные цели.
Плюсы и достоинства использования тест-кейсов на проекте:
Минусы и недостатки использования тест-кейсов на проекте:
Атрибуты тест-кейса (test-case)
Как и во всех видах документации, у тест-кейсов имеется ряд атрибутов для оформления.
Обязательные требования для написания тест-кейса:
- ID (Идентификатор тест-кейса) – уникальный номер документа, присваивается зачастую автоматически.
- IDEA(Идея) – Какую именно идею мы хотим проверить. Зачастую информация из поля "Идея" переносится в Title.
- Title(Наименование тест-кейса) – краткое описание проверки.
- Steps (Шаги выполнения тест-кейса) – сценарий(шаги) для выполнения тестового сценария.
- Expected result (Ожидаемый результат) – результат, который должен получиться по итогу выполнения сценария. Описывается для каждого шага в кейсе.
- Actual result (Фактический результат) – добавляется напротив ожидаемого результата каждого шага. В случае успешного прохождения шага тест-кейса, ставится отметка «Passed». Некоторые проекты игнорируют данный атрибут, добавляя фактический результат только в случае проваленного теста.
- Comment (Комментарий) – дополнительная информация тестировщика после выполнения тест-кейса.
- Status (Статус) – результат(Статус) прохождения тест-кейса. Добавляется тестировщиком после прохождения тест-кейса.
Необязательные атрибуты для тест-кейса:
- DATA (Тестовые данные) – значения, данные, табличные данные, необходимые для проверки. Могут быть в виде таблицы, либо вынесены в отдельный файл.
- Priority (Приоритет тест-кейса) – приоритет выполнения, очередность.
- Enviroment (Окружение) - тест-кейс является специфичным для проверяемого окружения.
- Type (Тип тест-кейса) – ставится отметка «Позитивный» или «Негативный» сценарий. Помогает распределить, отсортировать и понять тестовые сценарии, написанные согласно требованиям.
- Pre-condition (Предусловия) – необходимые действия, которые надо выполнить перед выполнением тест-кейса. Например, регистрация, авторизация, скачивание файла и так далее.
- Post-condition(Постусловия) – действия, которые необходимо сделать по окончанию выполнения тест-кейса. Например, очистить данные, удалить записи, файлы и так далее.
Помните! В шагах тест-кейса глаголы пишутся в инфинитиве. Правильно: "Нажать", "Кликнуть", "Осмотреть", "Получить". Неправильно: "Нажмите", "Перейдите", "Примите".
Статусы проверки тест-кейса:
- passed — проверено, соответствует ожидаемому результаты, работает согласно заявленным требованиям. Комментарий необязателен.
- failed — поведение системы не соответствует ожидаемым требованиям, найден дефект. Пишется подробный комментарий.
- blocked — выполнить проверку невозможно, имеются обстоятельства (дефект, модуль, компонент), которые блокируют дальнейшую проверку. В комментарии указывается причина.
- skipped — тест пропущен. Возможно, отсутствует необходимый модуль для проверки, который будет не реализован. В комментарии указывается причина пропуска.
- draft - тест пропущен, либо не начат. Отсутствует объект тестирования, который будет реализован позже. Комментарий не обязателен.
- work in progress – переводится в случае длительного выполнения. Чаще всего статус пропускают и ставят конечный результат «failed», «passed» или «blocked».
Пример тест-кейсов на проверку загрузки файла
Предположим, QA инженеру прислали требования на загрузку файлов.
П 1. На странице галереи необходимо добавить поле для загрузки файлов в формате png, jpg, gif.
П 2. Для загрузки файлов пользователь должен быть авторизован.
П 3. Максимальный размер файла 5МБ.
П 4. Пустое поле запрещено отправлять.
После применения различных техник тес-дизайна, получаем тест-кейсы:
*Для формата jpg получится аналогичный тест-кейс.
Набор тест-кейсов
В документации тестирования существует понятие набора, тест-сьюта, тест-комплект тест-кейсов (test suite, test case suite).
Набор тест-кейсов (test case suite, test suite) — сочетание тест-кейсов, объединенных по общему признаку проверки модуля, версии, системы.
Подобное нигде не описано, в каком формате документов должно храниться, как должно выглядеть. Суть заключается в том, что тест-сьют - это документ, который содержит набор тестов, предназначенных для проверки смежной функциональности.
Заключение
Тест-кейсы – основная почва для проведения тестирования. Зачастую проекты понемногу отказываются от данного вида документации из-за её существенных недостатков, самый главный из них «Время=деньги», отдавая предпочтение расширенным чек-листам. Но он по прежнему остаётся в лидирующих позициях.
Читайте также: