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

Эта статья не для гуру автоматизации, она для тех, кто только начинает свой путь в AQA и очень переживает.

Для обзора хочу кратко обозначить мою начальную позицию и итоги спустя год.

Таким был мой «starter pack»:

  • Не было готового фреймворка, написанных автотестов или какого‑либо решения «из коробки»;

  • Не было старших автоматизаторов, а я — единственный AQA на проекте, к тому же, у меня не было опыта в разработке фреймворка с нуля;

  • Не было чёткого понимания, с чего начинать автоматизацию;

  • Была огромная бюрократическая машина и большой проект;

  • Был пул требований: сделать всё быстро, надёжно и дёшево.

Главная цель: разгрузить ручных QA, чтобы они просто выжили.

И вот что у меня вышло спустя год усердной работы:

  • Освободили время ручных QA. Они смогли заняться техдолгом и обучением по написанию АТ;

  • Покрыли 50% всего регресса автотестами;

  • Повысили доверие бизнеса.

Стартовые условия (середина 2024 года)

Обо мне: До прихода в банк у меня была небольшая практика по написанию автотестов (АТ) на Playwright + TypeScript, которую я совмещала с ручным тестированием. То есть, я не была полным новичком, но серьезных вызовов, а уж тем более опыта построения фреймворка с нуля, у меня не было (здесь UI автотестов не было вообще).

Команда: Кроме меня, было 2 ручных QA и lead QA. У них хватало времени только на рутинные задачи. Опыта в автоматизации у них не было, и возможности заняться обучением — тоже.

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

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

Проект: У нас был исходный большой проект, над которым работало до 100 человек уже около 7 лет, и разработка не останавливалась. Наша команда должна была скопировать этот проект и изменить под текущие бизнес‑задачи. 

Для понимания масштабов: всего у нас было 1300 тест‑кейсов. 80% из них занимали до 20 минут на каждый тест, а еще 20% занимали от 1 часа на каждый кейс.

Кризисные приоритеты: скорость и польза

В идеальном мире мы бы следовали пирамиде тестирования: много юнит‑тестов, меньше интеграционных, минимум UI. Но у нас был свой путь, так как приоритеты были другими:

1. Скорость. Сроки поджимали, баги от исходного проекта всё прибывали и прибывали. Нужно было как можно быстрее начать автоматизировать все многочисленные тест‑кейсы для разгрузки коллег.

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

2. Покрытие «болевых» точек. Фокус — на самые критичные и длинные сценарии, которые ломались чаще всего и отнимали у QA львиную долю времени. Например, у нас был тест‑кейс, который занимал 1.5ч.

Исходя из обозначенных приоритетов, нашим выбором стали сценарные UI тесты и вот почему: 

  • 95% багов были на UI;

  • Основная часть проблем прилетала к нам из исходного проекта;

  • Долгое и дорогое согласование: исправление одного бага могло занимать до полутора недель;

  • Наш ручной смоук имел маленькое покрытие и отнимал до часа рабочего времени.

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

Вот ключевые проблемы, которые мы решали:

Playwright: Как мы затащили недостающие библиотеки в закрытый контур и начали автоматизировать

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

Наш выбор пал на Playwright, и вот почему:

  • У меня уже была небольшая практика с Playwright + TypeScript, что сэкономило время на изучение нового фреймворка и языка;

  • А еще это современный и быстрый инструмент для UI‑тестирования, хорошо подходящий для решения наших проблем с фронтендом.

Казалось бы, установить новую библиотеку — пятиминутное дело.

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

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

Дальше я общалась с командами смежников, AQA, техническими лидами и отделом безопасности. Для меня, «воробушка‑социофобушка», всё это превратилось в настоящий квест.

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

Были и забавные случаи: однажды я написала сотруднику из другой команды, и он ответил: «Привет, да, когда‑то делал, но сегодня мой последний рабочий день, пока, удачи!»

Спустя 2 недели поиска, мне помог инженер из отдела безопасности. Мы созвонились, и он провёл меня и нашего DevOps по правильному процессу добавления библиотеки в банк.

После этого я написала подробную статью «для чайников. А безопасники со временем упростили и весь флоу установки новых зависимостей в банк.»

Выводы:

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

2. Ожидаемый результат: будет много игнора. Часто в ответ будет тишина или фраза «не в курсе». И это тоже нормально для больших компаний, так как сотрудники загружены или давно потеряли контекст.

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

Data‑test‑id: Как мы договорились о стабильных локаторах и сэкономили 60 часов в месяц на отладке

Наконец, после добавления Playwright’а в банк, я села за написание автотестов. Открыла DevTools... и неприятно удивилась: «Но ведь тут нет ничего уникального! На форме целых 10 одинаковых селектов — они не отличаются даже placeholder'ами, не говоря уже о специальных атрибутах!»

Идеальным решением было бы добавить атрибуты data‑testid, но быстро мы это сделать не могли, так как требовалось долгое согласование. При этом тест‑кейсы уже были подготовлены, бэклог уже был огромным, начальник ждал результатов, а сроки поджимали.

Атрибуты data‑test* (data‑testid, data‑test‑id)

Атрибуты data‑test* (data‑testid, data‑test‑id) — атрибут для явной маркировки элемента, предназначенный для автоматизации тестирования. Помогает обеспечить стабильность и надежность тестов.

Пока мы согласовывали добавление data‑testid, шло время, нужно было писать автотесты, поэтому временно пришлось городить ужасные и монструозные локаторы. 

Вот пример того, во что превратился поиск обычного поля (очень стыдно 🙂):

this.page.locator('//section[contains(@class, "styles__section")]')

  .filter({

    has: this.page.locator(

      '//div[contains(@class, "field-label")]',

      { hasText: 'Адрес' }

    )

  }).first()

  .locator('.//div[contains(@class, "input-container")]//input') .first();

Ну и чем же плохи подобные локаторы? 

  • Время. На один такой локатор уходило 20 минут — найти, проверить, отладить в разных сценариях. В день нужно было написать 2–3 теста, и до 3–5 часов чистого времени могло уходить только на отладку;

  • Отсутствие надежности. Любое изменение в вёрстке ломало все связанные автотесты;

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

Согласование data‑testid затягивалось, я плодила монстров, и у меня кончалось терпение: количество локаторов росло, тесты усложнялись. Я хотела ускорить процесс, поэтому подготовила наглядные аргументы, и мы с лидом пошли договариваться с нашим директором проекта.

О чем говорили:

  • Объяснила, что работа с хрупкими локаторами в будущем выльется в постоянные падения и flaky тесты;

  • Ранее никто не поднимал вопрос о data‑testid, поэтому директор не был в курсе серьезности проблемы;

  • Мне повезло, так как директор являлся инженером, поэтому, посмотрев на примеры локаторов, сразу же понял масштаб проблемы.

О чем договорились:

  • Директор поднял приоритет добавления data‑testid в переговорах с исходным проектом;

  • Я разработала регламент нейминга наших атрибутов для единого стиля;

  • Разработчикам выделили время на добавление data‑testid, и они сначала добавили их к существующим блокам верстки;

  • А позднее — добавляли атрибуты уже в процессе работы над новыми элементами.

Первые результаты появились через 4 месяца (ушло много времени на согласование с исходным проектом, к тому же, у программистов было много работы и горели свои задачки).

Лайфхак. Как можно ускорить процесс добавления атрибутов:
Попросите фронтенд‑разработчиков научить вас добавлять data‑testid самостоятельно. Это просто. Вместо того чтобы создавать тикет, ждать его оценки, попадания в спринт и выполнения (на что могут уйти дни), при необходимой подготовке вы сможете добавлять 1 атрибут за 5 минут.

Наш план для самостоятельного добавления data‑testid

1. Изучите базу проекта. Выясните, какой фреймворк используется для разработки фронта, изучите азы работы с ним (например, вам может потребоваться установка NodeJs и Git).

2. Получите доступ. Вам понадобится доступ к фронтенд‑репозиторию и базовые инструкции, как устанавливать зависимости и как запускать проект локально (хотя бы в режиме сборки).

3. Договоритесь о созвоне. Попросите фронтенд‑разработчика выделить вам 30–60 минут на пару созвонов для более детального понимания работы.

4. У всех разные регламенты разработки и необходимо знать основы:

  • Где искать место для добавления атрибута: в каких файлах (JSX/TSX, Vue, etc.) править разметку;

  • Как называть атрибут: Узнайте существующие соглашения по именованию data‑testid. Если их нет, можно написать свой регламент (например, [page]‑[component]‑[element]), но обязательно согласуйте его с руководителем или командой фронтенда;

  • «Что трогать можно, а что нет»: где вносить изменения безопасно, где лучше сразу попросить помощи, а где компоненты являются базовыми и их лучше не менять.

5. Начните с малого. Возьмите простой компонент (кнопка, инпут) и добавьте атрибут под наблюдением разработчика.

6. Code Review. Ваши пул‑реквесты с data‑testid должен будет проверять фронтенд‑разработчик, узнайте правила review заранее.

Да, на всю инициативу может уйти до 5–7 рабочих дней. Но это разовые затраты. После этого инструктажа вы перестаете быть зависимыми и станете тем, кто сам создает стабильные атрибуты для автотестов, а не просит их у кого‑то. Это инвестиция в скорость вашей автоматизации.

Про нейминг атрибутов

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

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

Пример хорошего нейминга

  • user‑profile‑edit‑button — понятно, что это кнопка редактирования юзера;

  • user‑profile‑edit‑button — понятно, что это кнопка редактирования юзера;

  • checkout‑page‑payment‑dialog — ясно, что это модальное окно оплаты на странице checkout.

Избегайте общих названий вроде button‑primary или input‑large, они хрупкие и потеряют смысл при изменении стилей.

Пример плохого нейминга

  • right‑plus‑button — слишком абстрактный. Здесь нет понимания, что речь про счетчик в кнопке добавления товаров в корзину.

На просторах интернета есть множество разных подходов для нейминга (kebab‑case, BEM‑стиль, с префиксами), но единого стандарта нет. Мы в команде считаем, что консистентный и единообразный нейминг облегчает написание автотестов на ранних этапах разработки UI. Например, при наличии макета, можно начинать писать АТ параллельно с разработкой.

Выводы и результаты:

  • Время, затрачиваемое на создание одного локатора, сократилось с 20+ минут до 2;

  • Тесты стали значительно стабильнее, а код автотестов — читабельнее. Количество flaky тестов уменьшилось;

  • С регламентом по неймингу data‑testid фронтендеры начали самостоятельно добавлять атрибуты без лишних созвонов;

  • У меня перестало «подгорать » от кривых, длинных и убогих локаторов. Появились силы заняться анализом покрытия АТ и улучшением архитектуры. 

Спасибо, Лёша: Как DevOps настроил запуск тестов из CI и спас меня от простоев

Со временем локальные регрессионные прогоны стали занимать до 1.5ч. Мое виртуальное рабочее место (ВРМ) имело ограниченные ресурсы, из‑за которых все лагало, и у меня не было возможности писать и отлаживать новые автотесты во время прогона. Часто приходилось запускать регресс два раза в день, в такие дни я тратила до 4-х часов на отслеживание запуска, так как из‑за лагов не могла ничего делать, поэтому я не чувствовала себя полезной, смотря на маленькую прибавку к проценту покрытия.

Запуск из CI я не смогла бы сделать самостоятельно, нужна была помощь DevOps, у которого каждая минута расписана, а у меня все горело и времени ждать не было. Я решила временно распараллелить тесты у себя локально. Но результат оказался в 100 раз хуже ожиданий: на ВРМ не хватало ресурсов, тесты выжирали оперативную память и падали. 

Стало ясно, что без помощи не обойтись.

Что было дальше: поныла техническому директору, получила опытного специалиста, поставила задачи. В процессе реализации созванивалась по 8 часов с DevOps’ом, пытаясь все настроить внутри закрытого контура (Лёша, спасибо 🙂)

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

Печатные формы: Как мы автоматизировали тестирование PDF‑документов и сэкономили два рабочих дня на регрессе

Работа шла своим чередом. На созвонах команды QA я все чаще слышала от коллег про какую‑то боль с «печатными формами», да и лид закидывала мысль о том, что надо бы как‑то все автоматизировать, только вот как сделать это в банковских ограничениях?

Под «печатными формами» я подразумеваю шаблоны банковских документов (выписки, справки, договоры), которые автоматически заполняются данными и генерируются в формате PDF.

* сгенерированный пример
* сгенерированный пример

В итоге коллеги сталкивались с такими проблемами:

1. В сумме у нас было около 30 уникальных PDF, и каждая отображалась при своих условиях (например, была форма, логика которой была завязана на изменении целых 20 полей). 

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

Примеры основных кейсов: 

  • ФИО: От очень короткого («Ян Ли») до очень длинного «Станислав‑Олег Владимирович Николаев‑Волынский‑Забродский»;

  • Адреса: Нужно было проверить и «г. Москва», и длиннейший адрес с областью, районом, микрорайоном, улицей и строением. А еще была возможность добавления иностранных адресов;

  • Особые отметки: Специальный статус (например, «Гражданин США») или иные пометки, которые должны быть учтены;

  • Документы: Всего у нас более 30 видов документов, удостоверяющих личность (РФ, иностранные, на право пребывания на территории страны). Каждый из них имеет уникальные особенности заполнения (формат серии, номера и так далее). 

И это все нужно было обязательно проверять! Ведь один кейс, например, с длинным ФИО, мог привести к тому, что вся верстка сломается.

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

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

5. Напомню, что мы всегда зависели от «донорского» проекта, и его обновления периодически ломали наши формы: они переставали открываться, данные не подставлялись, ломалась верстка.

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

Мы выбирали между следующими подходами к автоматизации:

  1. Парсинг PDF и сравнение текста.

    Плюсы: много решений и библиотек
    Минусы: не отлавливает проблемы верстки, требует загрузки сторонних библиотек в контур банка

  2. Скриншотные тесты.

    Плюсы: простое решение, работает «из коробки» Playwright’а
    Минусы: чувствительность к изменению данных

Мы выбрали скриншотные тесты, потому что они давали нам именно то, что необходимо: просто и быстро проверить верстку и данные (без дополнительных ожиданий и согласований).

Спойлер: дальше я расскажу о том, с какими подводными камнями мы столкнулись, выбрав именно такой способ.

Что же такое, эти ваши скриншотные тесты? 

В библиотеке Playwright “из коробки” есть возможность генерировать и попиксельно сравнивать скриншоты с помощью метода «toHaveScreenshot()».

При первом запуске скриншотных тестов Playwright генерирует эталонный скриншот, а при последующих делает скриншот текущего состояния и сравнивает с эталонным.

Хочу вас подбодрить: Playwright имеет дружелюбную документацию вообще и по скриншотным тестам в частности. Это позволит вам быстрее написать первые автотесты.

Несмотря на простоту написания базовых проверок, отсутствие опыта в тестировании печатных форм «выстрелило мне в ногу»:

«Выстрел» 1.

Сначала я хотела по привычке использовать Faker для генерации данных. При написании первого теста я осознала, что они будут падать при каждом прогоне. Проблема в том, что Faker каждый раз генерирует новые ФИО, которые не совпадают с ФИО в эталонном скриншоте. А так как скриншотные тесты проводят сравнение попиксельно, для них это автоматически провал проверки. Из‑за того, что мы запускали прогон только на dev стендах, я решила использовать статичные данные: условного «Васю Пупкина». 

«Выстрел» 2.

Изначально при написании скриншотных тестов я планировала так: делать скриншот самой формы, обрезая все элементы навигации PDF. 

Был риск, что обновление версии браузера могло привести к нестабильности тестов из‑за изменения отображения элементов PDF Viewer’а. Также была вероятность, что при некорректном отображении одной страницы, все тесты на эту форму могли упасть, потому что все страницы дублировались еще и в миниатюре. 

К сожалению, я сразу увидела, что простым способом обрезать элементы навигации не выйдет, потому что они изолированы внутри Shadow dom.

Shadow dom — теневой dom, который прячет всю разметку и стили.

Playwright позволяет находить элементы и взаимодействовать с ними в Shadow dom, но не поддерживает shadow root (closed), с которым нам и надо было работать. Другим решением было затянуть стороннюю библиотеку, которая рендерит PDF без Shadow dom, но мне не удалось, потому что ИБ 🙃

Пришлось выбрать самый очевидный, но не самый гибкий вариант — делать скриншоты по координатам (благо существовало готовое решение подобных проблем). 

Можно вручную подогнать размер окна под размер страницы, а затем вырезать ровно область документа, отсекая лишние элементы просмотрщика (панель навигации, кнопки). Некоторые документы содержали по 2–3 страницы, поэтому для переключения пришлось кликать по миниатюрам, рассчитывая позицию каждого клика.

А еще было несколько фейлов:

Фейл 1. После успешного создания первых тестов, я, окрыленная прогрессом, пошла показывать их команде. Но выпала в осадок, когда мне сказали: «Так тут же дата, весь прогон будет падать, если его запустить на следующий день?!»

Из‑за радости от увиденных зеленых галочек, я действительно просмотрела этот момент. Пришлось маскировать дату, чтобы она не попадала на скриншот и не вызывала падение (к счастью, сделать это довольно просто).

Фейл 2. При очередном прогоне скриншотные тесты стали внезапно падать. Я провела ресерч, но не сразу нашла причину, ведь изменений в коде не было. Разгадка оказалась максимально очевидной: на наших рабочих станциях обновили браузеры, и это повлияло на рендеринг PDF файлов.

Так я влетела в банальную ошибку, забыв про неизменность окружения. Скриншотные тесты должны запускаться в контролируемой среде, которая не подвергается изменениям извне. В нашем банке браузеры и ОС контролируются компанией, и периодически обновляются. Поэтому надо было найти вариант, при котором я бы могла запускать прогон в браузере с контролируемым обновлением. И решением стал браузер chromium (спец. версия chrome для разработчиков).

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

Но! Это был наш первый работающий шаг и самый быстрый способ потушить горящую проблему. И именно он позволил нам при регрессе сократить время с 2-х дней до 2-х часов на проверку печатных форм и разгрузить ручных QA.

Тут мой лид сказала написать, что это «неидеальное решение» сэкономило больше всего времени и нервов команде. И ручные QA ценят эти проверки больше всего

Отчет из Jira: Как мы показали бизнесу пользу автотестов и сделали это за два часа

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

Это все было ясно команде, но бизнес‑заказчики не видели и не понимали, какую конкретно пользу приносят автотесты. 

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

В него входили: 

  • Количество багов, найденных автотестами за неделю;

  • Количество автотестов, написанных за неделю;

  • Количество тест‑кейсов, ожидающих автоматизации;

  • Процент покрытия автотестами по отдельным бизнес‑процессам;

  • Общий процент автоматизированных регрессионных сценариев на текущий момент.

Я хотела сделать свою часть отчета автоматизированной и выбрала самое простое и доступное решение: встроенные диаграммы в Jira. Их я вставляла в статью в Confluence.

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

Пример:
Статус: «готово к автоматизации».
Функциональная область: «создание клиента».

Именно благодаря регламенту удалось быстро настроить и сохранить фильтры в Jira. Я использовала «Отчет в виде круговой диаграммы» из‑за простоты и наглядности.

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

Пример отображения отчета
Пример отображения отчета

В результате бизнес перестал задавать вопросы «А что делают ваши автотесты?». Ценность моей работы стала измеримой и видимой.

Итоги

Итак, вот к чему я пришла через 8 месяцев коктейля из страха, гнева, радости и продуктивной работы:

  • Автоматизировали 50% всего регресса. Это значит, что половина всех ручных проверок теперь гоняется автоматически без участия ручных QA. Мы быстро получаем инфу о целых половине сценариев, а сроки регресса сократились на 50%;

  • Освободили время ручным QA. Вместо бесконечного регресса у коллег появилось по 3-5ч. в неделю на технический долг и обучение автоматизации;

  • Я получила новый сайд‑квест — обучение ручных QA написанию автотестов;

  • Повысили доверие бизнеса. Сделали понятный отчет для бизнеса по автоматизации.

❤️ Благодарности команде: 

  • Техническому директору. Влад, спасибо за внимание к проекту и заботу о команде. Отдельное спасибо за помощь в согласованиях. Благодаря тебе, они проходили быстро и безболезненно, ускоряя мою работу;

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

  • Ручным QA. Дима и Маша, спасибо за внимательность к мелочам и адаптацию тест‑кейсов под автоматизацию;

  • DevOps. Лёша, спасибо за твою бесконечную экспертизу во множестве вопросов, а еще за помощь в запуске моих АТ)

А всем, кто только начинает писать первые автотесты, желаю успехов. Со временем этот процесс точно начнет приносить положительные эмоции и пользу!