Тестирование 31/10/2022

Как начать работу над новым проектом, если ты — тестировщик-автоматизатор: пошаговая инструкция

QA Team Lead и TechLead в NIX

На входе в проект существует несколько неочевидных аспектов. О подходах к знакомству с продуктом и старте работы QA много полезного рассказал в этой статье мой коллега, QA Lead Александр Фиалка. Кое в чем наши мысли пересекаются, но я все равно рекомендую прочитать его материал — там много полезных советов для мануальных тестировщиков. А этот текст больше заинтересует автоматизаторов.

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

Начнем с советов Junior QA

Знакомство с проектом

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

Бизнес-домен. Если техлиду понимание домена и бизнеса клиента помогает качественно написать стратегию тестирования, то автоматизатору важно разобраться в этих вопросах по другим причинам. Когда вы будете писать новые тесты или будете придумывать способы тестирования конкретной функциональности, вам нужно четко понимать суть приложения. Спросите себя: как часто будут использовать определенную функцию? Регулярно в течение дня или раз в месяц? Так вы узнаете реальное значение скорости для обработки этой функциональности. Если пользователь обращается к ней редко, то вряд ли ее медленная реакция вызовет у него раздражение.
Стек разработки. Автоматизатор должен уметь читать код. Расспросите техлида, на чем разрабатывается ваш продукт и можно ли изучить его «изнанку». Если запрета нет, обязательно делайте это. Начали изучать продукт, и вдруг что-то непонятно? Обратитесь за разъяснением к разработчикам. Подобная коммуникация в команде — это хороший мягкий старт для начинающего. Опытные коллеги помогут разобраться, как, скажем, работает валидация или как тригнуть ошибку, которую не удается провести через API. И таких полезных разговоров будет множество.

Стек автоматизации. Это мастхэв. Возможно, еще до начала работы над ежедневными тасками вам понадобится изучить что-нибудь новое.

Участие в создании стратегии

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

В качестве автоматизатора вы можете помочь техлиду в нескольких моментах:

Ревью. Не думайте, что вы недостаточно опытны или мало знаете, из-за чего не можете высказаться по поводу стратегии тестирования. Будьте уверены: сейчас вы на своем месте и имеете достаточно знаний для понимания стратегии и осознания того, все ли вам нравится.

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

Начало автоматизации

Настроить окружение. С более или менее готовой стратегией вы четко понимаете, какие инструменты будете использовать.
Освоить инструментарий. Вдруг есть что-то незнакомое, и вы до сих пор его не изучили — сделайте это.
Получить скоуп задач. Если есть тестовый план, то все указано. Если есть только тест-стратегия, уточните у тест-лида, какой из абстрактных инженеров в этом документе именно вы. Будьте откровенны в обсуждении задач. Не понимаете чего-либо или не умеете — так и скажите об этом. Хороший техлид не будет ругать вас за правду, а поможет добраться до нужного профессионального уровня.

Онгоинг-задача

С этого момента начинается основная работа автоматизатора, запасайтесь энергетиками! Ваша работа состоит из двух ключевых задач:

«Е#!&$ть кодяру». Я «замьютил» в тексте глагол, но суть вы поняли. После вхождения в проект вы должны делать именно это. Пишите, пишите и снова пишите код, чтобы покрывать микросервисы, бэкенд, фронтенд и все остальное.
Подсвечивать проблемы. Если заметили что-нибудь эдакое, выносите на обсуждение. Сбои в организационных процессах? Не работает фреймворк или его неудобно использовать? Тесты на вашем стеке получаются нестабильными? Все проблемы нужно обсуждать с командой и техлидом, чтобы изменить ситуацию к лучшему.

Переходим к советам техлидов автоматизации

Знакомство с проектом

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

Бизнес-домен. Что делает приложение, в какой сфере применяется и в чем суть бизнеса заказчика. Почему это так важно? Представьте себе какую-нибудь новую программу, которая нужна для взаимодействия пользователя с некоторыми гаджетами. Предположим, вы ограничитесь только этой информацией и впоследствии научились регистрировать девайсы, выстраивать QA-процессы и запускать тесты. Но потом узнаете, что предполагаемых устройств — не одно и даже не десять, а миллионы! Соответственно, все ваши инвестиции и инструменты должны быть совсем другими. И сейчас у вас просто нет способности работать с такими массивами данных. Поэтому мой совет: с самого начала узнавайте все детали о бизнес-домене и целях продукта.

Стек разработки. Вы должны хотя бы примерно понимать, на каком языке и с помощью каких технологий создается приложение. Иногда разработчики готовы поддерживать ваши тесты, но не хотят учить новый стек. Для них взаимодействие с командой автоматизаторов в этом вопросе должно быть быстрым и безболезненным. Признаю, подобная ситуация не настолько распространена, как хотелось бы. Тем более не стоит упускать такую возможность. Зная стек разработки, вы сможете выбрать подходящий стек и для автоматизации. Это значительно упрощает взаимодействие с девелоперами и повышает эффективность работы.
Стек автоматизации. Этот пункт больше относится к действующим проектам, где поддерживаются автотесты. Здесь вам нужно знать, чем пользовались ваши предшественники.
Навыки QA-команды. Узнайте, с кем вы работаете и что умеют ваши люди. Их скиллы важны не только для реализации текущих решений, но и с перспективой на будущее. Ваши коллеги могут знать определенные языки программирования, уметь проводить пока ненужные на этом проекте виды тестирования или опыт в родственной доменной зоне. Впоследствии их опыт может пригодиться и вам.
Рабочие процессы. Какие тикеты используются в Jira? Где они размещаются и как двигаются по доске? Когда можно брать функциональность в тестирование, а когда заканчивать разработку, запускать code freeze и регрессии? Возможно, позже вы скорректируете эти процессы, но на старте ознакомьтесь с тем, что есть.
Доступные ресурсы. Я имею в виду железо и софт. Какие программы можно выбрать? Есть ли у вас возможность покупать платные библиотеки или использовать только общедоступные версии? Возможна ли регистрация почтовых ящиков в нужном количестве? Какой бюджет выделен на необходимые ресурсы? Ответы на эти вопросы помогут в планировании дальнейшей работы.

Подготовка драфта стратегии тестирования

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

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

Чем тестовая стратегия отличается от тест-плана?

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

Сложно ли сформировать стратегию?

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

Зачем нужна стратегия?

В небольшом проекте, где тесты просты, стратегия может и не пригодиться. Иногда достаточно на словах передать коллегам или стейкхолдерам, куда вы двигаетесь. И все равно я советую иметь задокументированную стратегию. Как минимум, вы сэкономите время на разъяснениях. Проще подготовить документ — а дальше он будет помогать и даже в чем-то защищать вас. Например, от менеджмента, который может регулярно интересоваться целями того или иного тестирования. В ответ вы спокойно сможете ссылаться на утвержденную руководством стратегию. С течением времени что-то может меняться, но заапрувленный документ снимает с вас часть ответственности и дает простор для маневра.

При разработке автомейшен-стратегии ответьте на следующие вопросы:

Кто? Речь идет не о конкретном человеке с именем и фамилией, а об абстрактном инженере на проекте. Вы должны сформулировать четкие критерии этого специалиста. Какие виды тестирования он может делать? Какие скиллы ему нужны? Какой у тестировщика Definition of DoneНабор критериев, которые позволяют понять, сделано ли то, что было целью.? Сколько вам вообще нужно автоматизаторов на проекте того или иного уровня? Так вы можете собрать оптимальную команду.
Что? Здесь пригодится упомянутое выше понимание доменной области. Что вы собираетесь проверять? Какие виды тестирования нужны для этого? Будут ли проводиться перформанс-тесты?
Как? Этот вопрос касается методов достижения целей. Как будет организована работа в команде QA? Как будет проходить взаимодействие с проектной командой? Как будут писаться функциональные тесты? Будут ли привлекать автоматизаторов к написанию юнит-тестов и т.д.

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

Инвестигейт инструментов

Имея драфт стратегии, можно присматриваться к конкретным инструментам и программам для запуска тестов. По-моему, этот этап самый интересный.

Ведь нам, автоматизаторам, всегда полезно изучить и испытать на практике что-нибудь незнакомое.

При заходе на проект сценарии инвестигейта инструментов могут отличаться в зависимости от состояния проекта — он стартует или уже какое-то время продолжается. В целом порядок действий таков:

Выучить имеющиеся тулзы. Это справедливо только для работающих проектов. Прежде всего, стоит узнать, с чем сейчас работают автоматизаторы. Так, с одной стороны, вы оцените имеющиеся инструменты и поймете, подходят ли они для решения ваших задач. С другой стороны, сможете аргументированно предложить что-то другое.
Попробовать новые. Подберите инструменты, которые подходят для ваших задач и целей. Если речь идет о существующем проекте, обязательно сравните результаты новых инструментов с уже использующимися командой.
Затестить и предложить команде. Поделитесь результатами испытаний новых инструментов. Расскажите об этом QA-команде, менеджеру, заказчику. Не забывайте об аргументах в пользу того или иного инструмента.
Помогите другим QА овладеть новыми инструментами. Если предложенные вами тулзы оказались эффективными и их утвердили в проекте, научите остальные команды пользоваться ими.
Отслеживайте результаты. Если возникают проблемы при использовании выбранных инструментов, не теряйте времени и смело меняйте решения.

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

Коммуникация

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

Коммуникация в проекте происходит по трем направлениям:

Со своими командами. Даже если у вас пока одна команда, организовать коммуникацию следует так, чтобы вовремя поступали необходимые отчеты для понимания ситуации на проекте. Лучше построить коммуникацию не техлида с командами, а команд с техлидом. Тогда рабочие процессы будут стабильными.
С другими командами. В больших проектах это могут быть вендоры из других стран. И с их командами вы тоже будете пересекаться. Главное не упустить время и сразу познакомиться с коллегами. Иначе в какой-то момент перестанете понимать, что вообще делают партнеры. Это может отразиться и на отношении клиента к вам. Потому всегда старайтесь быть на связи с посторонними командами. Идеально, если вам удалось подружиться. В конце концов, вы работаете над одним продуктом, так что у вас должны быть общие темы для рабочих и неформальных разговоров.
С менеджментом. В любой проектной иерархии есть кто-нибудь и над вами: лид, Рroduct Owner или заказчик. Общение с этим человеком должно быть не менее слаженным, чем с командами. Основа такой коммуникации — те же отчеты команд. Вы как техлид собираете всю информацию, обрабатываете ее и трансформируете в понятный менеджменту формат. В результате руководитель должен понимать, что вы делаете и как хорошо вы это делаете. От этого фактора зависит многое от отношения к вашей команде и продолжения работы до готовности расширить проект и внедрять новые решения (которые вы тоже можете предложить).

Итак, у нас есть четкое понимание стратегии тестирования. Самое время поведать все команде.

Запланируйте митинг с коллегами

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

Начинайте внедрять тесты

Автоматизаторы должны уметь запускать ваши тесты, знать, когда это делать и какой результат ожидать.

Стратегия должна стать основным ориентиром в работе автоматизаторов. Прежде чем перейти к написанию окончательного документа, получите апрувы от тестовой и проектной команд, от менеджмента и заказчика. Все правки и пожелания должны быть учтены. Готовый документ опубликуйте на вашем рабочем спейсе и предоставьте доступ всем задействованным в проекте людям: от QA и разработчиков до аналитиков и заказчика.

Онгоинг-задача

Следите за трендами

Приведу несколько вопросов, которые помогут вам понять ситуацию на проекте:

Как эффективно тесты находят баги?
Многие ли дефекты потом находят QA Manual?
Попадают ли какие-нибудь баги в продакшн и фиксируются там клиентами?
Как часто встречаются нестабильные тесты?
Насколько быстро тесты проверяют новое окружение, когда его внезапно задеплоили?

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

Следуйте стратегии

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

Обновляйте документ

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

Собирайте фидбеки

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

Обучайте команду

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

Выращивайте менторов

Ни один техлид не может постоянно заниматься исключительно обучением новых людей. Потом придется искать ресурс для стратегических задач. Поэтому параллельно с предыдущим пунктом техлид должен научить того, кто будет потом обучать других. Сначала вам может показаться, что только вы знаете, как правильно учить людей работать с конкретным проектом. Вы ведь его чуть ли не сами строили! Но будем откровенны: качество обучения и эффективность работы команды никак не проседает, если в ней будут другие менторы, такие же, как вы, квалифицированные специалисты. Здесь следует научиться делегировать обязанности и дать возможность другим членам команды профессионально расти.

Репорты

В завершение скажу еще одну важную задачу техлида — сбор репортов. Они должны были быть полными и поступать в нужный момент времени.

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

Вы можете сами придумать, как автоматизировать сбор репортов, или обсудить разные способы с командой. Это может оказаться классной технической задачей «со звездочкой». Настройка процесса займет некоторое время, но инвестиция вполне оправдана. А потом инженеры будут нажимать условно одну кнопку раз в неделю — и репорт будет готов. Если же автоматизация невозможна, попробуйте хотя бы упростить этот момент. Предложите команде собирать короткие репорты — быстро и вручную. Только обратите внимание: информации в собранных метриках должно быть достаточно для менеджеров.тест