Не так давно у нас случилась полная неразбериха с тестированием. Быстрый рост проекта, новые команды, новые люди. Неожиданно, всё это негативно повлияло на качество продукта.
В данной статье поделюсь опытом и расскажу, как мы осознали проблему, искали пути её решения и что в итоге нам помогло. История борьбы за качество :)
Для начала, определимся с тем, что такое end-to-end тестирование.
End-to-end (E2E) — это верхушка пирамиды тестирования. Можно сказать, что это конечный этап тестирования. Проводя E2E, мы смотрим, как выглядит функциональность для её конечных пользователей. Всё ли работает так, как планировалось? Все ли потребности пользователя удовлетворяются?
При таком тестировании на первый план выходит именно то, что будет видеть пользователь. Как работает система изнутри, на данном этапе уже не проверяется (т.к. это задачи других уровней пирамиды тестирования). Мы смотрим на картинку в целом.
Немного предыстории
Наш проект появился 2 года назад, когда один из Клиентов крупного Поставщика платформы для проведения электронных экзаменов и сертификаций захотел купить эту платформу и разрабатывать её своими силами.
Основными нашими задачами стало следующее:
-
Поддержание уже имеющегося функционала. Платформа крупная, существует более 20 лет. С её помощью можно пройти весь путь от создания контента для теста до оценки пройденного кандидатом экзамена. Составных частей очень много, и наша задача — следить за их работоспособностью и взаимодействием.
-
Оптимизация уже имеющегося функционала. Как бы ни было хорошо, всегда можно сделать лучше.
-
Разработка нового функционала. Главная причина, по которой появился наш проект. Вышеупомянутый Клиент видел свой вектор развития платформы, поэтому и было принято решение пойти своим путём.
Так мы и начали работать. На старте у нас было всего 2 команды, в каждой по 2 тестировщика. Взаимодействие выстраивалось крайне просто.
Во-первых, у всех есть знание системы (все ребята ранее уже работали с этой платформой).
Во-вторых, нас всего 4 человека, а это значит, что большинство вопросов можно решить на уровне чата. В крайнем случае — созвониться в Teams и обсудить всё голосом. Просто и эффективно.
Работа шла хорошо. Старт получился довольно резкий и многообещающий: мы участвовали в глобальных планированиях, бесперебойно поставляли новые фичи, предлагали свои идеи по оптимизации приложения, трудились над улучшением продукта.
Результат не заставил себя долго ждать — Заказчик оценил наши труды и инициировал расширение. Происходило оно поэтапно, но в конечном счете мы пришли к 5 командам (10 тестировщиков) + стажёры + команды со стороны Заказчика, с которыми также идёт активное взаимодействие.
Мы гордились за себя и свой проект, но, к сожалению, не долго. Мало того, что начал затягиваться регресс, так ещё и после нас находились баги на предрелизном окружении. Ситуация крайне неприятная.
Уже этого было достаточно, чтобы забить тревогу и понять, что нужно срочно что-то менять.
Собравшись со Scrum Master'ами, Delivery Manager'ом и Quality Control командой Заказчика мы начали искать источник проблемы: что же мы упустили?
Проблемы
-
После расширения заметно сократилось межкомандное общение среди тестировщиков. Большая часть взаимодействия была на уровне команды и не выходила за её пределы. Т.е. все «варятся в собственном соку».
-
При планировании упускаются важные, но не очевидные сразу моменты (напомню, у нас только что случилось расширение, и пришло много новых ребят). Это выясняется под конец разработки, быстро делаются фиксы, быстро что-то тестируется — всё в режиме паники.
-
Больше команд — больше фич в релиз. Поскольку у нас довольно большой и сложный проект, над одной и той же областью могут работать сразу несколько команд. А это крайне плодотворная почва для багов.
Выводы:
Нам просто не хватает информации. Тестировщики слабо представляют, что происходит с тестированием в других командах. Получилась ситуация, при которой все вроде бы делают одно и тоже, но настолько по-разному, что получается сплошная путаница.
Решение
Для себя мы поняли, что нужно унифицировать процесс тестирования. Сконцентрировались мы на end-to-end тестировании. Оно у нас было, но каждая команда проводила его по-своему, а результаты нигде не фиксировались. При таком положении дел прозрачности просто нет: совершенно непонятно, что команда посмотрела, а что осталось за рамками ее внимания.
Унифицировать мы решили посредством общедоступного документа, который поможет не только зафиксировать E2E-сценарии, но и будет содержать в себе полезную информацию, которая поможет подойти к тестированию фичи структурированно и системно.
Мы приняли решение создавать такой документ к каждой из фич.То есть ещё на этапе планирования мы начали создавать ещё одну user story — E2E (в дополнение к уже описанным user story, относящимся к этой фиче). В ней по ходу разработки создаётся некий end-to-end тест-план по заданному шаблону.
Далее приведу немного обезличенный пример того, как это может выглядеть. За основу я взяла наш end-to-end тест-план, но опустила некоторые специфичные детали.
Пример структуры:
-
Полезные ссылки, которые могут пригодиться по ходу создания E2E-плана. Что можно добавить:
-
Wiki с инструкцией о том, как взаимодействовать с тест-планом (у нас она была написана параллельно с разработкой самого E2E).
-
Wiki с рекомендации по продукту (product considerations) — справочник о том, какие есть ключевые области приложения, какие требования предъявляются к системе (разрешение экрана, браузеры, языки и т.д).
-
Wiki об обратной совместимости (backward compatibility) — если есть версионность.
-
-
Вопросы, на которые должен отвечать документ:
-
Какие сценарии должны быть протестированы, основываясь на функциональных требованиях к фиче?
-
Какие сценарии должны быть протестированы в рамках обратной совместимости?
-
Какие области продукта были затронуты при разработке фичи?
-
Какие из этих областей наиболее критичны и требуют особого внимания?
-
-
Нефункциональные требования (тут нужно выбрать то, что актуально, и описать, что именно будет тестироваться). Пример нашего списка:
-
Нагрузочное тестирование (Performance / Load testing).
-
Тестирование доступности (Accessibility testing).
-
Тестирование локализации (Localization testing).
-
Кроссбраузерное и кроссплатформенное тестирование (Cross browser and cross platform testing).
-
-
Автоматизированное тестирование (выделить нужное, описать сценарии):
-
Selenium.
-
API / Integration tests.
-
Unit tests.
-
-
Сценарии, которые не входят в данную фичу (out of scope).
-
Ссылки на все тест-кейсы по фиче.
Данный список можно и нужно адаптировать под особенности своего проекта, чтобы эффект от него был максимальный. Наш же список может послужить отправной точкой в ваших поисках :)
Важные примечания:
-
С таким тест-планом можно и нужно начинать работать ещё на этапе планирования фичи, чтобы задать все вопросы как можно раньше.
-
Как только будет готова первая версия, можно дополнительно визуализировать план — создать по нему mind-map. Глянуть на картинку быстрее и проще, чем читать полное описание. Наши Заказчики особенно оценили этот пункт.
-
Ревью тест-плана другой командой повысит прозрачность и поможет найти недочёты.
-
План следует дорабатывать по ходу разработки фичи.
Увидеть первые результаты после внедрения мы смогли уже в рамках ближайшего регресса. К нему мы подошли более подготовленными, что не могло не сказаться положительно на качестве нашего тестирования.
Что нам дали изменения
-
К финалу разработки каждой фичи есть документ, в котором зафиксированы все особенности тестирования.
-
План — это user story, а значит он общедоступен для всех членов команд разработки: Заказчиков, Product Owner'ов и т.д.
-
Благодаря ревью планов, увеличилось взаимодействие между тестировщиками из разных команд; к тому же появилась возможность расшаривать экспертизу по областям.
-
План стал хорошим помощником в планировании задач, количество «неожиданно всплывших нюансов» заметно уменьшилось.
-
Т.к. черновик плана есть уже на этапе планирования, можно показать его Product Owner'у и уточнить, верно ли мы понимаем задачу.
-
К плану всегда можно вернуться и освежить знания по фичам.
Не скажу, что получилось сразу хорошо. К финальной версии мы шли через несколько этапов обсуждений. Весь процесс создания, апробации и оттачивания занял у нас примерно 2-3 месяца.
P.S.:
Так как не все любят перемены, вот небольшой бонус — пара слов о том, как сделать процесс внедрения максимально комфортным (советы капитана Очевидность):
-
Создайте шаблон, если ваша система управления задачами это позволяет. Не все люди встречают перемены с радостью (особенно те перемены, которые влекут за собой дополнительную работу). Но если попробовать облегчить процесс использования нововведений, сопротивления будет меньше.
-
Обсуждайте с командой. Плохая практика — создать что-то «в одного» и кинуть этим в коллег: «Нате, работайте». Обсуждения стоит начать сразу же, как только у вас будет первая версия документа. Чем больше вы вовлекаете людей, тем меньше будет «Фу, опять нам навязывают какую-то бюрократию», и тем больше будет чувства причастности и ответственности за совместные решения.
-
Совершенствуйтесь. Опыт показывает, что с первого раза идеально не бывает. Да и со второго, да и с третьего… Дополнительные встречи-обсуждения после реального использования плана помогут понять, с чем работать хорошо, с чем не очень, что можно улучшить. Проведите несколько таких сессий, чтобы довести ваш документ до его лучшего воплощения. Оно того стоит.
-
При необходимости, создайте wiki. Ссылку на wiki можно поместить прямо в шаблон. Первые месяцы после внедрения это будет очень полезно. Вы получите единый справочник с актуальной информацией, которая будет полезна как настоящим, так и будущим участникам проекта.
-
Ревью. Перед внедрением покажите финальную версию документа тем, кто не принимал участие в его разработке, но всё же будет с ним сталкиваться в работе (например, разработчикам). Свежий взгляд может натолкнуть на новые полезные идеи. Главное — найти инициативного разработчика :)
Заключение
Обсуждения, безусловно, требуют время. Так же как и создание end-to-end тест-плана для каждой фичи, когда он уже введён в эксплуатацию. Но эффект, который мы наблюдаем от внедрения этого документа, с лихвой покрывает все эти усилия. Мы получили прозрачность в тестировании и стандартизацию процесса.
К тому же наша идея понравилась и используется теперь и другими командами Заказчика. Мы все идём по одному пути, вместе ищем узкие места и улучшаем их, стараемся сделать процесс общим, удобным для каждого из его участников.
На этом у меня всё, спасибо за внимание :)