Облако — большой и сложный продукт, поэтому и процесс тестирования может растянуться… Всем привет! На связи Галина Чупрова, главный инженер по тестированию Облака Рег.ру. В какой-то момент мы с командой поняли, что чем раньше начать тестирование — тем меньше багов получим на выходе. В статье расскажу про этапы, которые помогут устранить «узкие горлышки» в процессе проверки качества продукта и подключить команду с первых шагов проекта. Будет полезно тем, кто начинает путь в тестировании или хочет по-новому взглянуть на процессы в своих командах. Поехали проходить этот квест!
Навигация по тексту:
Особенности тестирования в облаке
Начнем того, что Облако Рег.ру — это платформа, объединяющая в себе различные IaaS-, PaaS-, SaaS- и BaaS-решения. Поэтому тестирование — важная часть в жизненном цикле выпуска новых продуктов. Чтобы всё шло гладко и без багов, мы внедряем его на каждом этапе разработки и эксплуатации. Получается, работаем на опережение: тестируем не только готовую реализацию, а подключаемся на проверку документации и дизайн-макетов.
Тестирование в нашей команде разделено на несколько этапов:
Тестирование документации (бизнес-требования, ТЗ, макеты).
Подготовка тестовой документации (тестовые сценарии).
Ревью тестовой документации.
Тестирование.
Автоматизация тестирования.
Итак, у нас появляется новый продукт — с чего начать процесс тестирования.
Шаг 1: тестирование документации
Мы выбрали для себя такую схему тестирования, когда QA-команда подключается на ранних порах запуска проекта. Первый этап начинается со знакомства с подготовленной архитекторами и бизнес-подразделениями документации. На что здесь нужно обратить внимание:
бизнес-требования и ТЗ не должны противоречить друг другу;
требования должны быть однозначны и пониматься одинаково всеми;
документация должна быть полной с описанием сценариев и контрактов;
возможность тестирования новой функциональности;
актуальность — если в процессе обсуждений договоренности изменились, важно сразу фиксировать это в документации.
В процессе анализа требований мы готовим план тестирования, чек-лист тестирования и приступаем к проверке макетов. Методом проб мы определили критерии для проведения ревью дизайн-макетов, которые помогают оценить их максимально полно:
макеты должны соответствовать описанным требованиям;
полнота — отражены все требуемые состояния и переходы;
удобство использования — пользователю должно быть удобно и понятно, как пользоваться новой функциональностью;
актуальность — убедиться, что после ревью и уточнения деталей внесли все необходимые изменения;
интеграция в уже существующую функциональность панели управления.
На этом этапе мы дополняем тестовую документацию и не забываем задать уточняющие вопросы о макетах. Здесь закладывается фундамент всего процесса: критерии начала и окончания тестирования, риски и предполагаемое время работ. В чек-листе формируется список необходимых действий, включающий в себя проверку новой функциональности и регрессионное тестирование.
Дальше начинаются «подготовительные работы». А мы к этому моменту уже успели наиболее глубоко погрузиться в новую фичу и дать реальную оценку времени тестирования, с учетом подготовки тестовых сценариев.
Шаг 2: подготовка тестовой документации
Следующий этап — подготовка тестовых сценариев, а также уточнение деталей и формирование всей сборки кейсов для тестирования. Сборка включает не только проверку новой функциональности, но и регрессионные тесты (тут не забываем про принцип — исчерпывающее тестирование недостижимо).
Чтобы сформировать тестовые кейсы, возможны два типа сценариев: позитивные и негативные. Позитивные проверяют работу системы в нормальных условиях — пользователь знает, как выполнять действия без ошибок. Негативные же направлены на проверку корректности обработки ошибок. Посмотрим на примере: допустим, пользователь меняет пароль.
Позитивный сценарий: пользователь открывает шторку смены пароля, вводит валидное значение, сохраняет изменение — повторная авторизация с новым паролем успешна.
Негативные сценарии:
Пользователь открывает шторку смены пароля, вводит невалидное значение (например, пароль содержит недопустимые символы), нажимает на кнопку «Сохранить» — получает ошибку. Важно, чтобы пользователь получил корректную ошибку и понял, как ее исправить. Если она не обрабатывается, и шторка просто закрывается, то тут явно нужна доработка.
Пользователь открывает шторку смены пароля, вводит валидное значение, наживает «Сохранить» — в этот момент происходит сбой соединения. В таком случае пользователь также должен получить понятную ошибку, что произошел сбой соединения — новый пароль не был сохранен и нужно повторить попытку.
Это примеры самых простых сценариев, но в зависимости от сложности функциональности таких кейсов может быть множество. Кроме типа сценария при написании кейсов применимы следующие типы тестирования: функциональное и нефункциональное тестирование. Теперь посмотрим, что у нас включает в себя каждый из них.
Функциональное и нефункциональное тестирование
Функциональное тестирование основано на функциях, которые должна выполнять система. Оно производится на всех уровнях: модульное, интеграционное, системное и приемочное тестирование.
Как правило, модульное (unit-тесты) находятся в зоне ответственности разработчиков — здесь проверяется работоспособность каждого отдельного компонента. Их взаимодействие контролируется на уровне интеграционного тестирования — это могут быть как интеграционные тесты, так и ручное тестирование QA-командой. На этому уровне чаще всего проверяется API. Системное тестирование включает в себя полную проверку продукта с использованием подготовленных сценариев — смотрим, корректно ли работает система. Приемочное тестирование, как правило, проводится заказчиком. Здесь важно не выявить дефекты системы, а оценить готовность функциональности к релизу.
Нефункциональное тестирование определяет, как работает система. Мы оцениваем удобство использования и кроссбраузерное тестирование: как ведет себя система в разных операционных системах и версиях браузера.
Шаг 3: проектирование тестов и их методы
При проектировании тестов мы используем известные методы, которые помогают в работе: метод «черного ящика», «белого ящика» и тестирование, основанное на опыте.
При методе «черного ящика» мы не знаем о внутренней структуре системы и основываемся на спецификациях. Здесь в ход идут проверенные техники тест-дизайна: эквивалентное разбиение, граничные значения и сценарии использования. При методе «белого ящика» мы знаем, как работает система и, чаще всего, у тестировщика есть доступ к коду. Тестирование, основанное на опыте, зависит от погружения тестировщика в продукт — когда мы можем предположить, где скрыты ошибки.
Это лишь несколько методов, но какой же лучше использовать? Ответ: все. При выборе нужно учитывать сложность разрабатываемой функциональности, доступную документацию и опыт тестировщика. Комбинация методов обеспечивает большее покрытие тестами — применение только одного не обеспечит достаточного уровня. В нашем случае мы стремимся к 100% покрытию тестами, чтобы качество продуктов не страдало.
«Чем больше сила, тем больше ответственность» — учитываем, что с развитием облачной платформы и тестировщикам нужно осваивать новые подходы и глубже изучать услуги. Например, при заказе облачного сервера, недостаточно просто заказывать его из панели управления — нужно уметь работать с сервером, чтобы подготовить релевантные тестовые сценарии и обеспечить требуемое покрытие.
Шаг 4: ревью подготовленной тестовой документации
Каждый тестировщик команды обладает большей экспертизой в определенной части продукта, поэтому подготовленная документация отправляется на ревью остальным тестировщикам команды. Мы делаем это, чтобы не пропустить важные проверки и поправить или дополнить тест-кейсы до начала тестирования.
На этом этапе кейсы могут согласовываться не только между тестировщиками, но и, при необходимости, отправляться на ревью опытному разработчику. После внесения всех правок мы собираем набор тестовых сценариев — у нас он называется Test Run.
Итак, тестирование!
После всех подготовительных шагов начинается самый долгий этап — само тестирование. Почему же самый долгий?
время тестирование напрямую зависит от количества тестовых сценариев, а их число может быть внушительным, например, 50 или около 100 кейсов;
отчетность. При проведении тестирования обязательный критерий — это результат проведенной проверки согласно сценарию. Он позволяет оценить процент прохождения тестов и количество найденных дефектов;
найденные дефекты. Нашли — локализуем его и фиксируем шаги воспроизведения. Это позволит разработчику быстрее понять, какой кусок кода нужно проверить. После проводим повторное тестирование;
регресс. При внесении изменений нужно убедиться, что новая функциональность не сломала другие функции. Для этого используем как ручные, так и автоматизированные проверки.
Отсюда и вытекает значительное время разработки новой фичи и нашего основного этапа — тестирования.
Финишная прямая: пишем и запускаем автотесты
Для сокращения времени регрессионного тестирования можно использоваться уже готовые сборки автотестов, которые запускаются в тестовой среде и на продакшене.
Сценарии автоматизированного тестирования включают в себя наборы повторяющихся проверок. Они позволяют оценить ошибки в полученном отчете и исключить человеческий фактор. В нашей команде сформировались определенные наборы тестовых сценариев, которые привязаны к той или иной функциональности панели, а также общая smoke-сборка. Smoke-сборка включает в себя только базовые сценарии всего продукта.
При разработке новой функциональности, формируется список сценариев, которые нужно и можно автоматизировать. Почему можно? К сожалению, не все сценарии можно автоматизировать — это зависит от используемого фреймворка и доступности тестовой среды. В идеальном мире автоматизировать кейсы нужно сразу после этапа тестирования. На практике это не всегда возможно, поэтому для тестировщика команды мы заводим задачу на автоматизацию.
Инструменты для тестирования
Я рассказала о подходах, которые мы используем при тестировании облачных продуктов, а теперь поговорим немного про основные инструменты для тестирования.
TestRail
После подготовительных этапов тестирования мы получили набор тестовых сценариев. Как собрать их все вместе и оформить? Тут нам на помощь приходит TestRail. Подробнее о выборе инструмента в этой статье рассказала моя коллега. Лишь кратко подсвечу, как мы работаем с TestRail.
Обязательный критерий при подготовке к тестированию — описание тестовых сценариев в TestRail. Для чего это нужно:
переиспользование кейсов при тестировании следующих продуктовых фич и регрессионного тестирования;
подключение другого тестировщика к процессу тестирования;
структурированное и понятное оформление — всегда прописан ожидаемый результат выполненного действия;
обозначение, на каком уровне будет обеспечено тестовое покрытие — по пирамиде тестирования (unit, e2e, integration или ручное тестирование).
Из подготовленных кейсов собирается Test Run, который включает в себя: новые тестовые сценарии, сценарии для регрессионного тестирования и интеграционные кейсы.
Плюсы, которые мы видим в Test Run:
оценка пройденных/оставшихся кейсов для тестирования. В Test Run можно отследить количество успешно пройденных кейсов (Passed), количество кейсов с багами (Falled), количество кейсов на ретест (Retest), количество пропущенных кейсов из-за отсутствия возможности протестировать в тестовой среде (Skipped), количество кейсов временно заблокированных для тестирования (Blocked), а также общее количество оставшихся кейсов (1 / 75 untested (1%) и общий процент пройденных успешно кейсов 93%);
возможность отметки только упавших шагов кейса;
сохранение результата тестирования (пройденный Test Run не удаляется из TestRail и к нему всегда можно вернуться);
выгрузка отчета в формате PDF (отчет можно выгрузить в любой удобный момент времени и прикрепить к тестируемой задаче).
С ростом продукта и количества кейсов в TestRail мы столкнулись с проблемой появления дублирующихся записей. Но решение здесь простое: актуализировать кейсы, а не писать новые. Давайте рассмотрим на примере «Мастера заказа». Существует кейс для проверки функциональности «Мастера заказа» в текущей реализации, выпущенной на продакшен — новой фичей мы добавляем возможность клиенту самостоятельно решать, нужен ли пользователю для сервера плавающий IP-адрес. В таком случае нам не нужно писать новый кейс для проверки раздела — после релиза старый кейс станет не актуальным, нужно обновлять существующий. Для этого включим в него проверку добавления в заказ плавающего IP-адреса.
Swagger
Swagger — это набор инструментов и спецификаций, предназначенных для разработки, документирования и тестирования RESTful API. У Swagger есть графический интерфейс (Swagger UI), позволяющий разработчикам и пользователям взаимодействовать с API через web-браузер. UI-интерфейс достаточно прост для понимания, а описанная документация ускоряет процесс тестирования.
Таким образом, при тестировании достаточно указать все необходимые поля, выполнить запрос и проанализировать ответ на соответствие описанному в архитектуре контракту.
Итоги
Так происходит процесс тестирования в нашей команде. Для себя мы поняли, что чем раньше QA подключается к проекту, тем больше вероятность не пропустить возможные ошибки. Ведь тестирование — важный этап в релизном цикле любого продукта, когда нужно работать на опережение и вовремя обнаружить и исправить дефекты.
Описанный процесс мы внедряли не сразу и постепенно. Поэтому даже сейчас мы вносим в стратегию команды небольшие корректировки, которые помогут сделать процессы еще понятнее и ускорят работу. Может показаться, что при таком объеме работ в каждом из этапов тестирование может растягиваться и блокировать даты релиза, но это не так. Процесс тестирования начинается при готовности документации одновременно с началом подготовки к разработке и чаще всего заканчивается до выпуска самой первой задачи взятой в работу командой разработки.
Для себя мы определили такие плюсы подхода:
уменьшается вероятность пропустить возможные баги;
сокращается время этапа тестирования, ведь тестовая документация уже готова;
большая часть спорных вопросов решается до начала разработки и тестирования;
увеличивается погруженность тестировщиков в новый продукт.
Спасибо, что дочитали! Буду рада обсудить в комментариях, как у вас строится процесс тестирования?