Как выстроить эффективные процессы тестирования

Доброго дня! Меня зовут Глеб, и я руководитель отдела тестирования в ORS. В компанию я пришел на проект единственным тестировщиком, а впоследствии сформировал отдел тестирования. Расскажу про свой опыт, который может быть полезен специалистам, которые хотят развиваться в сфере тестирования ПО и тем, кто еще не выстроил процессы тестирования внутри команды.

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

Итак, с какими же вопросами может столкнуться QA, который пришел в команду, где ещё не ступала нога тестировщика?

До моего появления в компании роль тестировщиков брали на себя технологи и разработчики. А багтаски в большинстве случаев формировались на уровне “Не работает. Надо, чтобы работало”.

Ключевая задача, которую мне поставили на старте — наладить процессы тестирования. Звучит масштабно, не так ли? Первое время меня одолевало чувство “самозванца”, поскольку я только-только закончил обучение и не утвердился в силе своих профессиональных возможностей. И вот уже мне дают непосильную, на первый взгляд, задачу.

Что делать и как себе помочь, если кажется, что задача не по силам?

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

Хочу выделить ключевые полезности инструмента для каждой стороны:

Инструмент 1-1 для сотрудника — это возможность:

Инструмент 1-1 для руководителя — это возможность:

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

Спустя первый год моей работы в ORS появился амбициозный проект - Travelshop 2.0, который представляет из-себя SPA-приложение. SPA — это веб-приложение, которое загружает одну HTML-страницу и динамически обновляет ее при взаимодействии с пользователем. Например, результат нашей работы уже можно потрогать здесь (на момент выпуска статьи мы подготовили бронирование авиабилетов).

Чем раньше подключается QA в процесс разработки проекта — тем больше возможностей для выявления и исправления проблем, снижения рисков и оптимизации процесса разработки. В конечном итоге это помогает минимизировать общие затраты проекта. Вот почему:

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

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

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

Спустя некоторое время работы пришло понимание, что процесс тестирования надо улучшать: требовалось изменить формат постановки задач, написать качественную документацию по проекту и начать думать в сторону автотестирования. Все мы прекрасно понимаем, что в одиночку с таким не справиться.

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

Симптомы того, что команде пора масштабироваться:

Если вы постоянно сталкиваетесь с нехваткой ресурсов, это может означать, что пришло время для масштабирования. В определенный момент мы столкнулись с проблемой, когда в статусе «тестирование» поток задач начал расти по экспоненте из-за увеличения активности сотрудников QA (подробнее об этом в п.4), поэтому было принято решение привлечь новых людей в команду.

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

В работе закрытие клиентских задач — безусловный приоритет. Однако, команда не должна забывать о своих внутренних нуждах, коем являются коммуникация, брейнштормы, нахождение ответа на вопрос “а как нам выдавать лучше и больше?”. Сигнал о масштабировании и делегировании задач происходит в момент, когда команда (и руководитель конкретно) пренебрегает развитием и качеством внутренних коммуникаций. В итоге это способно демотивировать специалиста. А это, в свою очередь, рискует привести к расставанию

Чтобы привлекать дополнительные руки в проект, необходимо системно пересматривать и пересобирать текущие процессы. Что вы можете сделать в своей команде, чтобы процессы стали эффективнее:

Чем более понятно и структурно описана задача — тем более вероятно ее быстрее передадут в работу. Что мы сделали для прозрачности?

Пообщались с технологами на момент более детального описания задач. Мы ушли от идеологии того, что разработчик лучше нас понимает, как выполнять задачу, в сторону конкретного описания, что именно требуется изменить/добавить, и главное - как это в дальнейшем тестировать. Да, на это требуется ощутимо больше времени и ресурсов, но благодаря тому, что мы освобождали технологов от тестирования, у них это время и появилось.

Дополнительно после постановки задачи, она ревьюится руководителем отдела QA на момент достаточного описания и указания того, как следует её протестировать. Все гениальное — просто.

Регламенты и бумажки должны упрощать нашу жизнь, а не делать ее тяжелее. Конечно, данные в больших масштабах передаются “от поколения к поколению”, но не поленитесь навести порядок и оставить то, что действительно важно в сегодняшнем дне. Как мы помогли себе - создали качественную документацию в Confluence. В документацию вошли:

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

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

Используйте StoryBook для автоматического тестирования компонентов приложения. Этот инструмент в связке с Jest и Playwright позволяет проверять различные сценарии поведения и дальнейшую сборку скриншотов веток до и после внесения исправлений на разных браузерах и разрешениях экрана. Вся отчетность удобно располагается в gitlab, расхождения скриншотов отмечаются красным индикатором. Такой подход позволяет проводить UI-тестирование в кратчайшие сроки, изолированно от ручного тестирования, что, в свою очередь, позволяет более детально отслеживать текущее состояние и поддерживать качество приложения.

Автоматизируйте тестирование API через Postman, в том числе благодаря ChatGPT. Ниже расскажу подробнее, почему не стоит пренебрегать этим инструментом.

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

Ни у кого из нашей команды QA ранее не было опыта написания автотестов. И да, вероятно, ранее, до изобретения этого инструмента, потребовались бы месяцы длительного обучения языку, чтобы написать более-менее сносный скрипт для Postman. Сейчас же на это уходит гораздо меньше времени.

Но надо понимать, что ChatGPT — это не панацея. Без должного знания языка программирования невозможно автоматизировать тестовые прогоны. Он лишь помогает реализовать задуманное. Так почему же круто использовать ChatGPT для решения IT - задач? Я думаю, на этот вопрос лучше всего ответит сам ChatGPT. Ниже его цитата:

Спасибо тебе, ChatGPT.

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

А именно:

Тестирование — это процесс постоянного улучшения. Создание QA-процессов там, где их раньше не было, может быть похоже на игру в песочнице. А вы — тот самый ребенок с лопаткой в руках. И сможете ли вы построить здесь песчаный замок — зависит только от вас.