В своем докладе на конференции TestDriven Conf 2022 Станислав Васенков предлагает за минуту создать из ручного теста проект с автотестами в боевой инфраструктуре. О том, как разрабатывался генератор, можно узнать из интервью. Кроме того, мы обсудили актуальные проблемы современного тестирования и поговорили о том, почему искать тестировщиков для компании должен не HR, а инженер, говорящий с кандидатом на его языке.  Меня зовут Станислав Васенков, живу в Черногории. Прошел путь от ручного тестировщика до руководителя направления автоматизированного тестирования в интеграторе. Сейчас работаю с несколькими компаниями. Кроме того, развиваю онлайн-школу по автоматизации тестирования. При ней функционирует фриланс-биржа и небольшое кадровое агентство по подбору специалистов в штат. В основном деятельность QA-инженера сосредоточена внутри самой компании, и всей экспертизой, необходимой ему для работы, он овладевает на этом уровне. Но когда начинается автоматизация тестирования, приходится окунуться в чудный мир хаоса, в котором не на все вопросы можно самостоятельно найти ответы. Тем более сейчас, когда библиотеки растут и нередко ломается обратная совместимость. Кроме того, комбинация каких-то библиотек может не работать, и везде есть свои нюансы. О таких вещах оперативнее всего можно узнать из чатов со специалистами индустрии. Когда в Telegram стали возникать первые сообщества по QA, я создал группу по автоматизации тестирования @qa_automation и развиваю ее уже пятый год. Мне удалось выстроить в комьюнити особенную культуру: на вопрос по тому или иному инструменту в чате отвечают очень быстро, как stackoverflow-online. Причем нередко создатели этих инструментов. Плюс там обсуждают новые релизы библиотек и актуальные проблемы. Я стараюсь, чтобы по каждому более-менее ключевому инструменту/подходу был свой отдельный чат. Если этого чата нет, я могу найти основателя библиотеки и предложить ему создать его. Или просто добавляю в уже созданный чат, передав права администратора. Одновременно рекламируя, что у этой библиотеки наконец-то появилась своя группа для общения, и в ней вам ответят и помогут. Полный список чатов можно найти здесь. Поработав в найме, я ощутил множество недостатков рынка обеспечения качества и оказания услуг в аутсорсе. Оценив потребности и возможности рынка, я выработал определенный технический подход, который позволяет идти по протоптанному пути и оказывать услуги, предельно минимизируя технические и организационные риски. Я строю свой бизнес вокруг комбинации Selenide, Allure TestOps и Selenoid. Это позволяет существенно экономить на покрытии рисков и быстрее зарабатывать.  Сейчас я работаю в трех направлениях: Обучение. Фриланс-биржа. Подбор кандидатов в штат. Я ставлю на первое место одну достаточно интересную метрику. «Метрика №1», как я ее для себя называю — это скорость закрытия позиций в команде. То, насколько быстро получится найти на рынке инженера, который сможет обеспечить необходимые бизнесу процессы. Мы готовим людей, которые могут выйти и свернуть горы внутри компании. Не буду разводить холивары, но у меня был приличный опыт пресейлов по продаже услуг банкам, крупным ритейлам, и всем-всем-всем операторам. И я заметил, что в основном в автоматизации тестирования творится какой-то хаос: оверинжиниринг, фреймворки, в которых сложно разобраться, половина тестов не работает, и так далее.  У нас сформировался технический подход, позволяющий быстро обучить человека, чтобы он как можно скорее начинал закрывать потребности. Я бы даже сказал, что мы учим не на тестировщиков, а тому, как решать конкретные задачи бизнеса. У нас достаточно интересно выстроен процесс проверки домашнего задания. Обучение стартует раз в полтора месяца и идет три месяца. Тем самым, половину срока учебы сохраняется атмосфера здоровой дедовщины. Так после занятий людям приходят задачи на разработку, они решают их, а другим нужно сделать проверку — ревью. Третьей группе достается approve, то есть проверка того, что в итоге разработалось. И здесь никто не мешает помимо школьных задач давать коммерческие.  Пока биржа работает в полузакрытом режиме. Мы готовы браться далеко не за все задачи. При разработке автотестов есть ряд подготовительных этапов. Это создание репозитория для хранения кода, разработка фреймворка, настройка инфраструктуры, подключение отчетности (включая добавление скриншотов, видео и т.д.), настройка уведомлений в мессенджеры (telegram, slack и т.д.). Всё это разовые задачи. Я их автоматизировал и сделал из этого сервис, который позволяет достаточно быстро развернуть полноценный проект по автоматизации, включающий код, инфраструктуру, отчетность и уведомления. Например, заходим на start.autotests.cloud и пишем какой-нибудь ручной тест на сайт, допустим, нашей конференции: Открываем сайт. Выбираем 29 апреля в расписании.Проверяем что в списке докладов есть «Автоматизируя автоматизацию тестирования». Нажимаем кнопку «Automate it!» и начинается магия. Создается полноценный репозиторий в GitHub с настройкой удаленного браузера, параллелизацией и т.п. Генерируются дополнительные автотесты, создается сборка в Jenkins. Тесты уже запущены параллельно и бегут в Selenoid. Спустя примерно минуту формируется отчет в Allure. Приходит уведомление в Telegram. В нашей внутренней Jira создается тикет. Это заготовка, полуфабрикат. Но этот полуфабрикат просто нужно «поставить в микроволновку» — добавить Xpath/CSS по вкусу, немного знаний Selenide и вы автоматизатор. Есть и второй вариант — ручной тест, который мы написали, может уйти в работу тестировщикам нашей школы. А они автоматизируют его.  На конференции я сделаю упор на первом варианте. Это крутой конфигуратор, которым мы сейчас пользуемся и постоянно улучшаем. Он бесплатный, код в открытом доступе (github), можно воспользоваться им в любой момент. Инфраструктурой тоже можно пользоваться (в разумных пределах — jenkins, selenoid). Как обычно работают рекрутинговые агентства? Они мониторят рынок и пытаются закрывать компании по стеку: «У вас написано про Python. Мы нашли человека, который когда-то на Python писал». Мы не оказываем услуги аутсорса, а подбираем кандидата в штат из тех, кого мы хорошо знаем. У нас есть студенты, которые пришли за карьерным развитием. Мы с ними общаемся и ведем их с начала обучения. Есть немало тех, кто уже давно в профессии, есть ручные тестировщики, которые хотят перейти в автоматизацию. Они давно на борту и прекрасно понимают все IT-процессы. Немало и работающих инженеров по автоматизации тестирования, которые пришли систематизировать свои знания и научиться чему-то новому. Хочется верить, что у нас больше клиентоориентированность за счет того, что мы лучше понимаем тех, кого «продаем». Ведь HR-сотрудники обычно не имеют ни технического бэкграунда, ни общего языка с кандидатами. Но надо понимать, что вакансию нередко нужно продавать и инженеру. Несмотря на то, что специалист видел ее, он может не решиться написать сам, чтобы пообщаться. Мы объясняем студентам, что это за вакансия, помогаем подготовиться к собеседованию и развеиваем их страхи. В первую очередь кадровый голод. Все понимают, что тестирование необходимо, всем нужен тестировщик, но ты пойди его найми.  Кроме того, есть еще одна проблема: засилье некачественного образования, вводящего людей в заблуждение. Студенты берут кредиты, чтобы отучиться непонятно где и непонятно чему. Конечно, как следствие, мы видим изобилие на начальной позиции и дефицит реальных профессионалов на рынке.  Следующая проблема более специфичная. Из чего сейчас состоит продукт? Это значительно выросший по сложности фронтенд. Если раньше это был jQuery и Bootstrap, то сейчас это React и Rocket Science. Кроме того, усложнилась культура бэкенда. Если раньше это был просто PHP, то сейчас мы видим отказоустойчивость, ClickHouse, Postgres, nosql рядом, комбинации с очередями, свои нюансы микросервисов, различные протоколы и постоянный рефакторинг. Ну и конечно, есть такая проблема как DevOps. И к ней такая ключевая бизнес-метрика, как скорость доставки: «Даешь 10 релизов в день!». Итого  фронтенд, бэкенд, DevOps и YAML-девелопмент требуют все больше и больше скорости.  В этих условиях тестирование становится блокирующим фактором. Если раньше спокойно тестировали новую версию продукта в течение месяца, сейчас этот процесс не закрыть условно и 1000 тестировщиками  — автоматизация нужна как никогда. Когда мы хотим идти в гору, то заранее прикидываем свой маршрут и то, как мы себя застрахуем. Но, разрабатывая продукты и закладывая в бюджет их разработку, далеко не всегда задумываются о тестировании. А ведь это тоже часть процесса; код автотестов такая же неотъемлемая часть продукта, как и основной код. Хотя в краткосрочной перспективе может показаться, что автотесты требуют слишком много ресурсов, в долгосрочной вы определенно выигрываете. Конференция выстроилась из нескольких связанных по сути докладов. В первую очередь, речь идет о Selenide с Appium — это автотесты на все три платформы из одного репозитория. Мы очень удивились, что у Кипра развитое IT. С точки зрения маркетинга конференция провалилась, и провалилась бы еще сильнее, если бы не киприоты. Они купили половину билетов, и конференцию пришлось срочно полностью переводить на английский язык. Сама конференция ушла в минус. Но спикеры, которые в ней тогда участвовали, сейчас принимают участие в жизни школы. Можно сказать, что это был хороший предпродакшен. Потому что это отдельная профессия. Для этого нужны другие инженеры, которые должны обладать иными качествами. Здесь отдельный инструментарий и свой бурно растущий мир. Это отдельный культурный слой, и он вполне заслуживает своей хардкорной конференции. 28-29 апреля в Москве впервые пройдет TestDriven Conf 2022  — профессиональная конференция для senior тестировщиков и QA-инженеров.  Она будет посвящена всем вопросам автоматизации в тестировании и рядом. Расписание и тезисы докладов уже на сайте. И можно забронировать билеты по выгодной цене — чем ближе к конференции, тем будет дороже. До очередного повышения цен осталось 4 дня! Контент-редактор