Автор: Кассандра Ланг (Cassandra H. Leung)

Оригинал статьи
Перевод: Ольга Алифанова

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

Первая часть – мой ответ на вопрос "Как вы узнаете, что вам тестировать?", заданного в клубе Министерства Тестирования.

1. Получите инструктаж.

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

Держа это в уме, я начала тестирование приложения с просьбы об инструктаже. Я обратилась к разработчику – он же продакт-оунер, генеральный директор, соучредитель – в общем, он выполнял все технические роли в их команде-тандеме.

Вот что мы обсудили во время инструктажа:

• Предназначение продукта, его миссию и цель.
• Текущее состояние дел (текущая стадия жизненного цикла продукта, готовые фичи, известные баги, наиболее важные фичи или области, области низкого приоритета).
• Чем я могу быть полезна (скажем, что конкретно меня просят протестировать, какой вид информации команда хочет получить, с ответами на какие вопросы тестирование сможет помочь).
• Получение доступа к базе данных и админ-панели, а также к самому приложению.
• Ключевые контактные лица, у которых я могу проконсультироваться.

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

• Как мне предоставить обратную связь?
• Какой уровень деталей желателен?
• Как мы будем отслеживать баги?

Я подробнее остановлюсь на этом в четвертой части этой мини-серии статей.

Некому вас проинструктировать? Сделайте это сами! Приложение, которое я тестировала, было создано всего лишь двумя людьми и у него не было документации. Но если вас наняли тестировать продукт, обычно у него существует хоть что-то, что можно изучить самостоятельно. Как я писала в Клубе МТ, это может быть:

• Официальная продуктовая документация.
• Юзер-стори и баг-репорты.
• Публичная маркетинговая информация.
• Справка и поддержка.

Все перечисленное – богатый источник идей, что именно нужно тестировать.

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

2. Составьте собственное впечатление.

Теперь вы получили представление о том, что это за продукт, и что конкретно вам нужно сделать (это часть инструктажа, посвященная вопросу "чем я могу быть полезен", что в ряде случаев можно понять и самостоятельно). Настало время перейти непосредственно к продукту и поработать с ним самостоятельно.

Если вы тестируете конкретную юзер-стори или баг-репорт, то они в основном и будут влиять на цель и фокус вашего тестирования. Но как быть, если перед вами чистый лист, если вам дана полная свобода действий, или (как часто бывает в начале нового проекта) вам просто сказали "посмотри на приложение, может, что найдется".

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

Я здорово описала его в той статье (верьте, я знаю, о чем говорю):

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

Мне очень нравится проводить туры лягушатника в новом для меня ПО, потому что это быстрый и эффективный способ для:

• Сбора первых впечатлений о продукте в целом.
• Понимания, насколько продукт интуитивно понятен, и насколько ясны/неясны его цель и функциональность.
• Определения, что привлекает мое внимание и побуждает разобраться подробнее.
• Сбора информации для принятия решений о том, как декомпозировать продукт, темы и риски (к примеру, фичи, UX, безопасность данных, пустые пространства, сообщения об ошибках, брендирование).
• Поиска вдохновения для тест-идей, и распределения этих идей по подходящим категориям.
• Разделение этих идей, областей, тем, и т. д. на контролируемые тест-сессии с тест-чартерами.

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

• Что вас удивило?
• Чего не хватало?
• Что вам понравилось?
• Соответствовало ли ваше впечатление о продукте тому, как он рекламируется?

3. Исследуйте различные способы использования, риски, и темы.

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

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

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

Исследуя ключевые фичи и варианты использования, я обращала внимание на:

• То, что сразу бросилось мне в глаза (то есть то, что могло сразу же понравиться или не понравиться пользователям – и, следовательно, повлиять на их решение использовать продукт далее).
• То, на что я обращала внимание в ходе работы, и что отвлекало меня или заставляло задуматься (к примеру, поведение, которое и в первый раз было странноватым, а со временем надоедало все больше и больше; странное поведение элемента, предназначения которого я не понимала).
• То, как действия или данные в одной фиче или области взаимодействуют или влияют на другую фичу или область.

Даже самое простое приложение может содержать множество переплетающихся путей. Будьте бдительны, ищите, где могут заискрить провода или рухнуть мосты – иными словами, ищите зависимости!

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

4. Используйте ретест, как благоприятную возможность

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

Во время ретеста держите в голове:

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

Задавайте вопросы об исправлении, рефакторинге, или что вы там тестируете:

• Как они внедрялись?
• Имеет ли изменение или нововведение что-то общее с функцией А?
• Пользуются ли этим кодом другие фичи?

5. Используйте данные

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

• В пользовательских официальных и неофициальных сообщениях о проблемах.
• В ревью продукта.
• В логах ошибок.
• В статистике мониторинга и использования.

Так как приложение, которое я тестировала, еще не увидело свет, и у него не было логов и мониторинга, эти данные были мне недоступны, однако было бы упущением не упомянуть этот источник идей. Это также хороший способ расширить тестирование, так как использование мониторинга и логов как вспомогательного инструмента часто рассматривается как "сдвиг вправо" или "тестирование на проде" (что не значит, что до релиза не надо тестировать).

Помните о цели тестирования

Надеюсь, это была полезная информация, которая поможет разобраться, что тестировать в вашем собственном проекте. Главное, всегда помните, что цель тестирования – поиск информации. Пусть именно эта цель направляет ваше тестирование.

Найдя информацию, зафиксируйте ее и поделитесь ей с командой, чтобы ее можно было использовать для повышения качества продукта.

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