Автор: Любовь Тарасова, инженер по контролю качества компании EastBanc Technologies

Оригинальная публикация

Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.

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

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

0. Разберемся на берегу

Зачем нужна стратегия тестирования?

• Для организации процесса в условиях ограниченных ресурсов. Поэтому для начала неплохо бы осознать, какими ресурсами мы располагаем.
• Для того, чтобы все участники проекта понимали роль тестирования, что оно может дать, какие профиты мы с этого получим. Чтобы у всех были равные ожидания и понимание, что вообще происходит в области контроля качества. А также для выявления возможных проблем, которые неизбежно станут очевидными в процессе обсуждения.

Кто составляет стратегию?

В первую очередь, конечно же, QA и обязательно менеджер проекта.

Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!

1. Какие типы тестирования будем применять на проекте и почему

В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.

Тестирование установки версии

В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.

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

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

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

Тестирование производительности

На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.

Регрессионное тестирование

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

Интеграционное тестирование

Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.

Тестирование локализации

Здесь важно ответить на вопросы о проекте:

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

Кроссбраузерность и кроссплатформенность

Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.

Подобным образом необходимо разобрать все остальные типы тестирования:

• Функциональное (проводим или нет),
• Приёмочное (кто его проводит и каким образом),
• UX/UI (каковы объективные критерии хорошего интерфейса)
• Модульное и юнит (кто пишет контракт-тесты, кто пишет юнит-тесты и пишем ли их вообще),
• Тестирование безопасности (кто гарантирует безопасность данных, и насколько система устойчива ко взлому),
• Отказ и восстановление (как поведет себя система в экстренных обстоятельствах)

и другие.

2. Приоритеты в тестировании

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

В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).

3. Окружения для работы

Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.

4. Работы тестировщика на проекте

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

Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.

Например, это могут быть:

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

5. Тестовая документация на проекте

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

• какую тестовую документацию будем вести на проекте,
• будем ли писать тест-кейсы,
• ведем ли чек-листы
• и как часто обновлять эту документацию.

6. Каким образом генерируются тестовые сценарии

Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:

• какими техниками тест-дизайна имеет смысл пользоваться. В рамках этого пункта полезно составить список объектов, с которыми работает приложение, и их классы эквивалентности.
• какие эвристики и банальный жизненный опыт помогают придумать сценарии тестирования для конкретного проекта. Для мобильных приложений удобно использовать стандартные эвристики, например, “I SLICED UP FUN”.

7. Порядок работы с трекером

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

Проговорите с командой ключевые моменты:

• Как мы будем отличать ошибки, найденные нами, от ошибок, найденными заказчиками (и надо ли нам их различать),
• Как оформлять доработки,
• Надо ли отличать доработки, которые мы придумали сами, от тех, которые попросил сделать заказчик. Каким образом?
• В какой статус ставить ошибку, если она не повторилась,
• Какой статус считать конечным.

(Подробнее о способах описывать баги и userstory мы писали в этой статье).

8. Критерии начала и окончания тестирования

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

На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.

9. Инструменты для работы

Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.

Стоит обсудить такие вопросы:

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

10. Оценка качества проекта и инструменты мониторинга

В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:

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

Заключение

Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.

• Важно понимать, что стратегия не должна быть самоцелью — это лишь инструмент, который позволяет достичь наших целей.
• Вполне нормально, что не всегда сразу получается ответить на все поставленные вопросы. Это повод ещё раз поговорить с заказчиком или пользователями продукта.
• Проект растет, и если вчера заморачиваться с производительностью было рановато, то завтра возможно будет уже пора. Поэтому после составления стратегии важно её регулярно актуализировать и пополнять и доводить изменения до команды.
• После написания стратегии обычно становится понятно, где провалы в тестировании и что надо сделать. Это повод поставить задачи, смотреть динамику и… обновить стратегию через какое-то время.