Как составить стратегию тестирования: версия настоящих инженеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дано	Решение
Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей.	Имеет смысл запланировать volume-тестирование с большими объёмами данных.
Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика.	Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду.
Приложением пользуется несколько человек в неделю, объём данных минимален.	Тестирования производительности не требуется.

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

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

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

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

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

Дано	Решение
Данные по продажам из портала передаются в аналитическую систему.	Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге.

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

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

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

Дано	Решение
В системе предусмотрено 2 языка: русский и английский.	Имеет смысл обсудить, каким образом мы будем понимать, интерфейс на каком языке показывать пользователю.
Заказчик просит сделать приложение мультиязычным.	Стоит ответить себе на вопросы, каким образом будем верифицировать тексты, откуда мы возьмём тексты на арабском, как будет адаптирован экран для текста, который пишется справа налево.

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

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

Дано	Решение
Пользователями мобильного приложения являются сотрудники по всей стране.	Смотрим существующую статистику использования платформ нашего приложения и принимаем решение, на каких из них будем тестировать.
У нашего приложения корпоративные пользователи на стационарных машинах.	Скорее всего, мы сможем порекомендовать использование только одного браузера. И тем самым сократим время на тестирование и поддержку кроссбраузерности.

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

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

и другие.

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

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



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

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

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

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

Дано	Решение
На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности.	Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA).
Регулярно проводятся сессии бета-тестирования.	Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение.

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

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

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

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

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

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

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

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

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

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

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

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

Дано	Решение
На страховом проекте пользователь (агент) должен провести осмотр машины, в процессе которого необходимо сделать фотографии и загрузить их на сервер. Здравый смысл подсказывает, что в гаражах вряд ли есть wifi. А порой, там нет и мобильной связи.	Значит, надо проверить приложение не только при работе с 3G, но и при отсутствии связи как таковой.
Любое действие пользователя в мобильном приложении авиакомпании — это часть некоего сценария. Например, нельзя выписать билет, не создав предварительно бронь.	Поэтому логично использовать технику «сценарии использования».

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

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

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

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

Дано	Решение
Тестировщик создаёт bug. Разработчик не может его воспроизвести, переводит в статус rejected.	Тестировщик перепроверяет задачу и ставит статус Closed (конечный), если ошибка и правда ушла, либо уточняет описание и возвращает в New.
Заказчик ставит задачу на доработку. Разработчик понимает, что ему не хватает данных для реализации.	Разработчик переводит задачу в статус Feedback.

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

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

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

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

Дано	Решение
На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования.	Считаем задачу проверенной, если мы прошли все пункты чек-листа.
На проекте ведется работа по спринтам.	Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше.
На проекте составлен список функциональности по приоритетам.	Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка.
На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом.	Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5).

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

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

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

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

Дано	Решение
Для описания реализованной функциональности решили использовать mind-maps.	Ребята в команде работают на разных платформах, поэтому нужно выбрать такой формат файла mind-map, с которым можно работать и в винде, и в линуксе, и на маке.
Мы договорились, что нам нужна автоматизация на проекте.	Значит, нам нужны инструменты, которые позволят подготавливать тестовые данные (например, накатывать скрипты на БД), позволят осуществлять запуск в рамках конвейера (например, newman), позволят создавать заглушки (например, WireMock).

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

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

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

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

Заключение

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

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