Home

Статья компании SimbirSoft

Привет! Меня зовут Валерий, я руковожу группой QA Fullstack компании SimbirSoft. В сфере тестирования чаще всего выделяют группы QA-специалистов и SDET. Но сейчас многие компании задумываются об оптимизации расходов, особенно это актуально для проектов с длительным периодом эксплуатации, вроде небольших монолитов или внушительных размеров систем с множеством интеграций и микросервисов. Рано или поздно наступает момент, когда требуется подключать специалистов, которые не только хорошо разбираются в продукте и могут тщательно его протестировать, но и тех, кто могут писать автотесты. Убить двух зайцев сразу помогут QA фулстеки.

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

Что дает подключение QA фулстека на проекты

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

Мы решили обучить QA-специалистов навыкам автоматизации и ввели новую роль в команде QA Fullstack или QA Automation Engineer (QAA). В обязанности QA Fullstack теперь входят такие задачи, как улучшение процессов, контроль качества, тестирование и автоматизация тестирования. Подробнее об этом рассказывали тут.

После подключения к проектам QA фулстеков мы отметили сразу несколько позитивных результатов:

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

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

• Понимание приоритетов и критичности тех или иных проверок на старте автоматизации.

• Возможность проводить тестирование методом белого ящика – знание языка программирования позволяет анализировать код без запуска ПО и предугадывать ошибки.

• Более легкий анализ отчетов о прогоне автотестов – понимание кода автотестов изнутри позволяет приступать к локализации дефектов без задержек на расшифровку результатов прогона.

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

Автоматизация есть? А если найду?

Когда автоматизации ещё нет

В начале своего пути в автоматизацию я работал на проекте, где не было автотестов, но они были очень нужны, так как объём регрессионных тестов был довольно велик. Уже тогда я понимал, что автотесты нам точно понадобятся, поэтому сразу писал такие кейсы, чтобы было легко их автоматизировать. Через некоторое время в нашей команде появился SDET, который без особых сложностей внедрил автоматизацию по написанным мной тест-кейсам. Нам удалось сократить время на изучении тестовой документации и аналитики, а значит сэкономить и бюджет клиента.

Если автоматизация на проекте отсутствует, QA фулстек может подготовить необходимую почву для её внедрения:

• На начальных этапах, когда тестирование выстраивается с нуля, наличие такого специалиста позволяет определять объёмы и план тестирования, а также сами процессы документирования с учетом автоматизации. Благодаря пониманию инструментов тестирования и создания автотестов можно сразу описывать тест-кейсы или фичи по BDD (Behavior-driven development - «разработка через поведение»), чтобы легко и относительно быстро автоматизировать их с меньшими затратами.

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

• Если проект уже в работе, но ещё нет автоматизации, добавление QAA позволит усилить команду тестирования, изменить тест-кейсы и подготовить их для автоматизации.

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

Когда есть автоматизация

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

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

Не менее полезным становится QA фулстек и после внедрения автоматизации:

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

• Также фулстек может взглянуть со стороны на работу тестирования и автоматизации, выявить отклонения и узкие места. Это можно назвать расширенным интеграционным тестированием процессов и их результатов.

Масштаб имеет значение

Если проект небольшой

Моя коллега Елена, ментор по QA Fullstack, приводит свой опыт подключения на небольшой проект, когда нужно было провести полный регресс перед первым запуском в прод.

«После того, как основные задачи по ручному регрессу были закрыты, я проявила инициативу и подключилась на помощь к покрытию проекта автотестами. Так как за время регресса я хорошо познакомилась с системой и у меня было представление о том, какие проверки стоит делать, QA-лид поддержал мою идею. Опыт внедрения QA фулстека посчитали удачным, и теперь в мои обязанности, кроме базовых задач QA, входят: написание автотестов, распределение задач на автоматизацию между QA, ревью мердж реквестов и анализ метрик и отчетов»

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

А если проект внушительных размеров?

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

«Наш проект относится к банковской сфере, в связи с чем нередко возникали сложности при создании некоторых сущностей, таких как клиенты, договора, карты и прочее. Это обусловлено тем, что у команды тестирования не всегда есть доступ к заведению тестовых данных. Перед нами встала задача по автоматизации тестирования бизнес-процесса. Но как сделать это, не имея доступа к данным? Подсветив эту проблему руководителю проекта, позже сам увидел решение. Поскольку я хорошо разбираюсь в большинстве интеграций между сервисами и в системе в целом, у меня сложилось четкое понимание, что можно «замокать», т.е. имитировать взаимодействие с внешними сервисами, не нарушая бизнес-процесс. После создания мок сервера оставалось только настроить интеграцию с ним. Обсудив с разработчиками эту задачу, мы решили доработать один из сервисов следующим образом: написали интерфейсы, отвечающие за каждую интеграцию с ним. Это изменение позволило нам в режиме реального времени переводить интеграции на стаб (заглушку), мок или реальную»

Подключение QA фулстек на большие проекты также позитивно влияет на качество ПО:

• Если в проекте есть множество интеграций, микросервисов и особенностей, то фулстек лучше всего подходит на роль человека, помогающего во взаимодействии между командами: он понимает правила тестирования и работу продукта изнутри и снаружи. А систематизация артефактов в результате работы QAA позволяет командам взаимодействовать более прозрачно и повысить понимание объемов тестирования.

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

Где ещё могут помочь фулстеки?

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

• Если требуется автоматизировать UI-тесты в web-проектах, для QAA не составит труда написать тесты с использованием паттерна проектирования Page object и библиотек Selenium, Selenide или Selene.

• Для автоматизации тестирования REST и SOAP сервисов в API-проектах QA фулстек применяет такие библиотеки, как Rest Assured, Retrofit, OkHttp и Requests.

• На проектах мобильной разработки, где предпочтение отдаётся связкам Appium + Selenium или Appium + Selenide. 

Для каких проектов нецелесообразно подключать QA Fullstack

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

По масштабу и уровню ответственности:

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

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

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

  • Разрабатывать сложную архитектуру.

  • Настраивать многоуровневые CI/CD с downstream и upstream пайплайнами.

  • Управлять командой.

  • Настраивать окружение для запуска автотестов в CI/CD с помощью систем контейнеризации и оркестрации контейнеров.

  • Писать unit-тесты за разработчиков.

  • Автоматизировать нагрузочное тестирование.

Важно понимать, что в последнем случае лучше всего сделать выбор в пользу SDET и DevOps, нежели QAA.

По стеку технологий:

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

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

Вместо вывода

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

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

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

А в ваших командах используется такая роль, как QA фулстек? Поделитесь вашим опытом в комментариях.

Больше кейсов и полезных материалов в наших каналах:

• ВК и Telegram для разработчиков.

• ВК и Telegram для владельцев продуктов и IT-управленцев.