Ценный QA Automation – кто он на самом деле? Загадка от Жака Фреско
Всем привет! Меня зовут Иван и я Head of QA Automation в Skyeng. Я регулярно занимаюсь обучением Manual QA и менторством начинающих QA Automation (далее — QAA) и часто слышу от падаванов вопрос: «А как же мне, собственно, стать QAA?»
Вопрос многогранный. В статье хочу поделиться мыслями на этот счет. Так что присаживайтесь поудобнее, чаек и конфетки при прочтении приветствуются! Также советую захватить валерьянку — некоторым она понадобится при чтении третьего раздела.
Представим, что я Manual QA: каждый день занимаюсь ручным тестированием, пишу тест-кейсы, хожу на планирование, ревьюю требования и тестирую задачи.
Однажды приходит осознание, что нужно расти. Но куда?
Разработка — сложно. Глядя на разработчиков в компании, понимаешь, что вы находитесь на совершенно разных уровнях.
Инфраструктура — сложно. Инфра — это что-то про администрирование, DevOps и вот это вот всё.
Team Lead/Head of QA — рановато. Опыта в менеджменте нет, а набираться его почти негде. Разве что в кросс-проектных задачах.
SDET — Понять бы для начала, чем он занимается…
Автоматизация тестирования — Хм… Программировать особо уметь не надо — пишешь тестики, лутаешь х2 ЗП. Сказка!
Но сказка ли?
QAA — это про программирование
Я часто слышу абсурдное заявление: «QAA не нужны знания программирования». Ха! 80% рабочего времени автоматизатор тратит на написание кода. Конечно, чтобы написать простой тест (особенно, если у вас Behavior-driven development) много знаний не нужно: на английском пишешь сценарии использования продукта, берешь готовые методы.
Но что если у вас амбициозные планы на автоматизацию? Например, писать тесты, которые взаимодействуют с БД и API, строить архитектуру приложения, делать гибкие конфигурации под разные нужды, отправлять результаты тестов в различные агрегаторы, интегрировать тесты с CI/CD и так далее.
Чтобы писать что-то большее, чем тестики, и вырасти дальше, чем Junior, нужно с чего-то начать изучение автоматизации тестирования. И, как ни странно, с программирования!
Чек-лист для старта изучения программирования
Определитесь с языком. Проще, если на проекте уже пишут автотесты на определенном языке. Если нет — берите стек фронта на проекте и не ошибетесь.
Откройте любой бесплатный курс по выбранному языку. Нам нужна база.
Пройдите основные этапы обучения:
Теория программирования
Типы данных и переменные
Методы и параметры
Ветвление
Циклы
ООП
Методы по работе с разными данными. Например, со строками, массивами, объектами и так далее.
Каждый этап закрепляйте задачами. Практика — наше все.
Изучили типы данных и переменные? Играйтесь с ними, поймите, какой тип когда и для чего используется.
Изучили методы и параметры? Пишите простые функции и вызывайте их в любом порядке.
Изучили ветвление? Попробуйте в своих методах делать условия: если параметр === 1, сделай X, иначе Y.
Изучили циклы? Отлично! Просуммируйте 10 чисел идущих подряд, уже результат.
Подошли к ООП? Создайте свой класс, создайте его объект и вызовите какой-нибудь метод (функцию) из него.
А дальше самое интересное — закрепляем базу. Задачи, задачи и еще раз задачи на циклы, массивы, ветвление. Не нужно лезть в числа Фибоначчи и прочее. Да, было бы неплохо, но лучше освоить основное так, чтобы от зубов отлетало.
Я учился программированию в университете и самостоятельно, но это было давно. Сейчас есть много курсов, которые могут частично заменить университет, в которых нет воды и информации ради информации. Не реклама, но я проходил курс по PHP, когда мне нужно было поднимать архитектуру для интеграционных тестов на бэк на Хекслет. Что понравилось — задачки почти на каждый изученный блок, а также задачи повышенной сложности после прохождения раздела. И если решить их самостоятельно, то ощущаешь себя примерно так.
Вывод: если вы хотите попробовать автоматизацию — начните с программирования, чтобы понять — «А надо ли оно мне?». Не бойтесь обращаться за помощью в изучении программирования к «старшим»: автоматизаторам и разработчикам. Поверьте, для них помощь по таким простым задачам — дело пяти минут. Главное — убедитесь, что перепробовали всё возможное самостоятельно.
QAA — это не только про E2E
Думаю, многие из читающих смотрели вакансии на QA Automation, а там: «В супер крутую компанию X требуется QA Automation со знанием <вставь свой стек> для написания E2E-тестов!». Звучит заманчиво? Но есть небольшой подвох, о чём расскажу чуть ниже.
Многие компании считают, что автоматизация тестирования нужна только для замены регрессионного тестирования. Это порождает замкнутый круг:
Нанимаем QAA инженера.
Инженер пишет 30 тестов на 30 тест-кейсов.
После написания 30 тестов инженер перестаёт писать новые тесты, потому что нужно поддерживать старые.
Возвращаемся к первому пункту и умножаем количество кейсов и тестов на количество QAA в проекте.
Принято считать, что E2E-тесты — панацея для ручного QA. Вот сейчас мы автоматизируем 500 тест-кейсов, которые проходим руками 2 дня перед релизом и заживем! Только почему-то через 2–3 месяца на анализ прогонов тестов, их актуализацию и фиксы инженеры начинают тратить не 2 рабочих дня ручного тестировщика, а 5 рабочих дней автоматизаторов, которые стоят на порядок дороже.
— Автоматизирован ли регресс?
— Да.
— Выиграли мы от этого? Ускорили релизный цикл?
— Однозначно нет.
Раньше я тоже скептически относился к такой хайповой штуке как «пирамида тестирования», потому что никогда не видел её практического применения. Да и занимался в основном E2E-тестами, потому что нет предела совершенству. Я постоянно искал способы, как сделать большое количество автотестов стабильными, быстрыми и чтобы прям вах. То есть, чтобы всё тестировалось само. Но потом я понял, что пытаюсь решить следствие, а не проблему.
После этого я пообщался с другими компаниями и понял, что автоматизировать регресс можно и нужно на всех уровнях, так как ускорение тестирования — это не только задача QA. За качество должна быть ответственна вся команда.
С чего начать?
Постараться побороть страх неизвестного. Да, это непросто. Обычно низкоуровневые тесты пишут разработчики и кажется, что это запредельные знания: низкоуровневые фреймворки, взаимодействие напрямую с сервисом (белый или серый ящик), архитектура, докер и тому подобное. Но спешу заверить — это неправда! Отчасти.
Разбираемся с интеграционными (функциональными) тестами на бэке. Правила просты: дергаешь API-метод с нужными параметрами, получаешь ответ и проверяешь его. Всё. Ничего сложного. Один в один как обычно происходит ручное тестирование бэка. Только автоматически!
Конечно, для эффективного теста нужно тщательно подготовить тестовые данные: тест-кейсы, входные параметры (то, что мы передаем в body, например), выходные параметры (то, что ожидаем проверить). Для этого применяем все свои джедайские техники и тест-дизайны, тестируем сначала позитивные, затем негативные сценарии. Есть список проверок? Замечательно! Идём дальше.
Обычно такие тесты пишут на стеке бэка, то есть Java/PHP/Go и прочее. Мы уже знаем базово один язык, умеем писать E2E-тесты, за плечами есть практика. Следовательно, в других языках принцип такой же: пишешь код, он выполняется. Да, отличается синтаксис, название методов для работы с типами данных, но для начала достаточно базы (то, про что я писал в первом разделе).
Определяемся с фреймворком. Обычно используют один и тот же фреймворк для тестирования и юнит-тестов. Например, Codeception. Обычно фреймворки достаточно гибкие и подходят как для юнит-тестов, так и для интеграционных. Принцип один: ожидаемый результат проверяется с помощью assert и expect. Только другие задачи и реализация внутри.
Если уже готового фреймворка для тестирования на уровне сервиса нет, то это плохо. В данной ситуации я бы попросил разработчиков его поднять и написать простейший тест, потому что подводных камней с поднятием сервиса и фреймворка уйма. Дальше по аналогии пишем интеграционные тесты по тест-кейсам и чиллим, ведь мы автоматизировали часть регресса!
Про юнит-тесты говорить в этой статье не буду. Опишу это в будущем, так как еще собираю бест-практисы и сам пишу юниты, чтобы понять их суть до конца: когда надо писать, когда не надо, приоритезация покрытия и так далее. Но скажу, что QAA можно смело подключаться на ревью тестов на предмет соблюдения тест-дизайнов чёрного (без фанатизма) и белого ящика. Например, эквивалентные классы, граничные значения, тестирования базового пути, покрытия условий и подобное. Пока что это просто затравка на будущее;)
Вывод: не боимся погружаться в тесты, ведь тесты они в Африке тесты, просто тестируют разные вещи на разных уровнях. В E2E — пользовательские сценарии, в интеграционных — работу блоков кода на стыке (например, API), в юнитах — конкретные строчки кода, ветки, методы, классы.
QAA — это про QA
Это прямо отдельная категория. Внимание, анекдот.
X: Ваня, привет! Я работаю в колл-центре. Хочу стать QAA. Что мне надо выучить?
Я: Привет, можно попробовать начать с QA.
X: Нет, ты не понял. Я хочу стать именно автоматизатором тестирования!
Я: Есть гипотеза, что для того, чтобы стать автоматизатором тестирования нужно знать тестирование.
X: Тьфу ты, а говорили ты нормальный человек, посоветуешь что-то дельное…
Думаю, пора сделать каминг-аут. Да простят меня мои знакомые, но QA Automation инженер должен быть… Хорошим QA-инженером! Я же говорил про валерьянку? Самое время.
Начну с того, что автоматизатор должен хорошо владеть исследовательским тестированием. Еще на этапе онбординга он должен найти самые важные пользовательские сценарии проекта, которые приносят бизнесу деньги, а клиенту — товар, за который он заплатил. Это навык полезен, когда, например, у проекта нет документации, а понять его как-то нужно.
Автоматизатор должен хорошо знать тест-дизайны, чтобы валидировать тест-кейсы, которые будет покрывать автотестами. Хорош не тот автоматизатор, который покроет 100 тест-кейсов, а который покроет 100 проверок в одном тесте (ауф). Но это не значит, что нужно писать 100 ассертов. Это значит, что с помощью техник тест-дизайна можно сократить количество проверок со 100 до 10 и покрыть только самое важное.
Автоматизатор должен понимать приоритет покрытия того или иного функционала. А точнее задавать вопрос: точно ли мне нужно покрыть этот тест-кейс, а не другой, который более важный? Ведь покрывать надо только важное и критичное, иначе рискуем допустить инцидент и потерять много денег.
Автоматизатор должен обладать сильными софт-скиллами. Этот пункт можно отнести ко всем инженерам, кто работает с кодом. Уже прошло время стереотипов. Сейчас без софт-скиллов никуда. Автоматизатору должен уметь общаться с командой, вести задачу до логического конца, пушить исправление и аргументировать его целесообразность в цифрах.
Автоматизатор — это ещё и хороший проектный менеджер! Приходится считать ROI, VTG, временные ресурсы на рефакторинг, вести проекты — как архитектурные, так и процессные.
С чего начать?
Начать можно со взятия ответственности за качество продуктов, над которыми мы работаем.
Автотесты — это полноценный продукт со своей кодовой базой и правилами. Да, тесты пишутся для обеспечения качества, но и сами по себе они должны быть эталоном качественного кода. И не только кода, но и понимания того, каким образом этот код тестирует пользовательские сценарии.
Вывод: Теснее познакомиться с QA. Автоматизация — это лишь инструмент и часть QA.
Финал
В статье постарался сломать некоторые стереотипы о QAA и открыть глаза на вещи, которые не замечают даже опытные QAA. Термин «автоматизация тестирования» гораздо глубже, чем может показаться, и включает в себя всевозможные процессы по автоматизации рутины. Иногда автоматизация тестирования может закрывать потребности в автоматизации бизнес-процессов QA, ведь разные боты и обвязки тоже влияют на качество продукта и его ТТМ.
На этом всё. Stay tuned, всех люблю!
