Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к 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 для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:
- Каким образом мы будем отслеживать ошибки в проде,
- Каким образом будем собирать обратную связь от пользователей,
- Каким образом будем собирать статистику использования наших фич.
| Дано | Решение |
|---|---|
| После релиза новой фичи системы настраиваются мониторинги использования (например, количество продаж услуги). | Снижение показателей является триггером для расследования. Возможно, фича работает не так, как ожидалось, или мы не реализовали часть сценария. |
| Мы настроили в программе мониторинг скорости выполнения основных операций. | Критерием качества работы будет то, что при наплыве пользователей скорость выполнения не падает. |
Заключение
Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.
- Важно понимать, что стратегия не должна быть самоцелью — это лишь инструмент, который позволяет достичь наших целей.
- Вполне нормально, что не всегда сразу получается ответить на все поставленные вопросы. Это повод ещё раз поговорить с заказчиком или пользователями продукта.
- Проект растет, и если вчера заморачиваться с производительностью было рановато, то завтра возможно будет уже пора. Поэтому после составления стратегии важно её регулярно актуализировать и пополнять и доводить изменения до команды.
- После написания стратегии обычно становится понятно, где провалы в тестировании и что надо сделать. Это повод поставить задачи, смотреть динамику и… обновить стратегию через какое-то время.
Автор: eastbanctech
