Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой статье я дам ряд практических советов по документации исследовательского тестирования при помощи отчетов сессионного тест-менеджмента (SBTM). Тут можно узнать о SBTM больше.

Короткая версия

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

• Включайте детали всего, что вы тестировали, всех своих экспериментов, а также результаты (найденную вами информацию).
• Сделайте отчеты легко доступными для всех в проекте.
• Адаптируйте структуру и содержание ваших отчетов в соответствии с нуждами вашего проекта.

Длинная версия

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

Тест-заметки

Уровень детализации

Когда я впервые попробовала SBTM, у меня было множество вопросов о том, как это "правильно" делается. У меня была странная идея бросить себе вызов и пробовать что-то новое, и в результате я сомневалась в себе и в том, что мои уже имеющиеся знания мне помогут.

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

Эм… что это значит? Когда я впервые пробовала фильтровать свои сессионные отчеты, дабы сделать их максимально релевантными и емкими, я оставила за бортом детали тестов, которые выдали ожидаемые или приемлемые результаты, и сосредоточилась только на том, что пошло не так или вызвало вопросы. Прочая найденная мною (и не менее ценная) информация осталась незадокументированной и была фактически утрачена. Найти информацию и оставить ее при себе так же бессмысленно, как и вообще ее не найти, поэтому "хорошую" информацию тоже надо фиксировать.

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

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

Структура отчета

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

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

Визуальные инструменты и обзор результатов

Я пишу множество заметок в ходе тестирования (если только его объект не просто до смешного, или задача тестирования не заужена искусственно). Нет, правда, огромное множество заметок. Это может стать проблемой, если вы хотите, чтобы другие люди тоже могли прочитать ваш отчет и получить от него пользу. Они не будут читать ваши отчеты, если они чересчур длинны и занимают много времени.

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

Вот пример обзора результатов с иконками из реальной тест-сессии:

Иконки варьируют в зависимости от инструмента, однако суть остается неизменной.

Инструменты отчетности

Меня часто спрашивают, каким инструментом пользоваться для создания отчета о сессии. Это абсолютно не важно, черт возьми! Важна только полная доступность отчета всем участникам проекта – им не должно требоваться много времени на его поиск.

Раньше я пользовалась комментариями в Jira и страницами в Confluence. Я пробовала даже Evernote – на самом деле я терпеть его не могу, но многим нравится. Все зависит от того, что сработает именно для вас и ваших коллег по проекту.

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

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

Гибкость

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

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

Обсудить в форуме