QA Сhannel

Три фреймворка, три архитектуры, один и тот же вопрос на каждом планировании: что берём? 🤔 Selenium не знает контекст приложения, общается через внешний WebDriver, отсюда Thread.sleep(3000) во всех легаси-проектах. Cypress живёт внутри браузера, топовый DX, но cross-domain переходы (SSO, платёжки) до сих пор боль. Playwright сразу строился под современный веб: auto-waiting, изолированные контексты, mocking из коробки. ⚡️ Самое интересное — во что выбор выливается через год. Посчитал на примере: команда с 3000 тестов на Selenium теряет четверть ставки инженера в неделю просто на разбор флаков. Playwright это лечит архитектурно, но миграция 3000 тестов — это не спринт, а 10+ недель на двух стеках одновременно. Про эту цену молчат в 90% сравнительных статей. 📉 Вывод простой: вопрос не «что лучше», а «что соответствует вашей системе и сколько вы готовы заплатить временем за архитектурный выигрыш». Разбор с кодом, схемами и расчётами: [https://habr.com/ru/articles/1073646/] А у вас был случай, когда выбор фреймворка на старте аукнулся через год?

Мысли, посетившие моих коллег, которые вроде бы старые, но не теряют актуальности)) Казалось бы, тестирование пушей одна из самых скучных задач: отправил, получил, кликнул, готово. Но в финтехе цена ошибки может быть не время, а деньги. Как пример — сломанный или кривой диплинк в уведомлении о резком росте цены, и трейдер не успел закрыть позицию. Не просто мелкая багулька. А чья-то реальная потеря. Поэтому маленьких или неважных вещей не бывает. И даже диплинк уже не просто URL, а контракт между бизнесом и пользователем. А задача тестировщика в этом всём — не только проверить, что «ссылка работает», но и заметить продуктовые конфликты. Например: что важнее в конкретном сценарии, безопасность или удобство? В итоге тестирование не только чек-лист. Это ещё и умение думать о продукте и пользователе. Работа, которую никто не замечает, пока она сделана хорошо. Знакомо? 😉

Креативный подход

Последнее время стало заметной проблемой у меня и моих коллег лидов. Мы всё чаще замечаем одну неприятную закономерность, чем активнее команды внедряют AI, тем больше «невидимой» работы появляется у тех, кто отвечает за качество. И это очень похоже на то, что описывает автор статьи на Хабре. ИИшка действительно ускоряет разработку. Код появляется быстрее, ревью закрываются быстрее, задач в спринте становится больше. На дашбордах всё красиво. Но появляется нюанс, кто-то должен проверить, что всё это действительно работает. Поймать глюки AI + написать и прогнать нужные сценарии. Разобраться, почему автотест зелёный, а поведение системы нет. Увидеть риски. И задать тот самый неудобный вопрос "А мы точно хотим это?"😂 И вот эта работа все чаще для показателей эффективности перестает попадать в отчеты, ине учитывает затрат времени. В статье автор называет это проблемой невидимого валидатора, когда инженеры постоянно доводят результат AI до состояния Готово в Prod и становятся невидимками в команде. Для QA это особенно знакомая история. Мы можем ускорить генерацию автотестов с помощью AI. Можем быстрее анализировать требования, создавать тестовые данные, писать чек-листы. Но скорость генерации ≠ качество проверки И если после внедрения AI у команды стало больше результата, но вместе с ним выросло количество ручной валидации, ревью, разборов и «разруливания» последствий, то возможно, мы просто перенесли стоимость работы из одного места в другое и добавили затраты на токены 🤖 Автор предлагает четыре идеи, которые, на мой взгляд, отлично ложатся и на QA: 👉 Закладывать валидацию в capacity, а не считать её «ну это же просто проверить» 👉 Измерять не только найденные дефекты, но и предотвращенные проблемы 👉 Распределять экспертизу. Если все сложные проверки постоянно делают одни и те же QA/лиды команда становится зависимой от нескольких людей 👉 Передавать проверки разным членам команды, а не оставлять её постоянно на одном и том же тестере. Решая проблему по трансформации специалистов в постоянный quality gate и подтягивая остальных) И вот здесь для меня главный вывод Выгорание не всегда следствие слишком большого количества задач. Иногда оно возникает потому, что человек месяцами делает критически важную работу, которую никто не видит. В статье есть очень точная мысль: скорость не то же самое, что устойчивость. Мне кажется, QA сейчас особенно важно обсуждать не заменит ли AI тестировщиков?, а: кто будет проверять работу AI, как мы будем оценивать эту работу и как не превратить самых сильных QA в бесконечный слой ручной валидации заменив поиск багов за разрабчиками, в поиск за ИИшечкой А у вас уже появилось ощущение, что после внедрения AI работы стало меньше на бумаге, но больше в реальности?

Хороших выходных 👽

Пу пу пу

Playwright ни в чем не виноват 😂 Попалась годная статья про миграцию с Selenium на Playwright: статья на Habr Главный тезис очень знакомый: команды мигрируют не тесты, а способ мышления, который годами формировался вокруг WebDriver. Фреймворк новый, а голова старая 😄 Особенно узнаваемые анти-паттерны: → Thread.sleep(2000) после каждого шага «на всякий случай». Хотя Playwright сам умеет ждать, пока элемент станет доступен для действия. → Общий BrowserContext на класс тестов вместо нового контекста на каждый тест. В Java приходится контролировать самому ошибся, и получаешь флаки, которые потом неделями списывают на «инфраструктуру». → Логин через UI в каждом тесте вместо storageState. 500 тестов = 500 прокликиваний формы логина. И достаточно поменять форму и падает полсьюита. В статье таких ошибок семь, плюс чек-лист из 15 пунктов. И цифры там вполне реальные: в одном из кейсов E2E-прогон сократили с 35 до 7 минут. Понравилась и честная оговорка автора: большинство этих практик вообще-то не эксклюзив Playwright. То же самое можно сделать и в Selenium просто там многое приходится собирать и дисциплинированно поддерживать самому. Короче, при миграции недостаточно заменить WebDriver на Playwright. Нужно ещё заменить мышление 😅 Кто уже мигрировал с Selenium на Playwright сколько из этих семи ошибок нашли у себя? И какая оказалась самой болезненной?

требуется тестирование 😎

Прокачивал слабые стороны 5 лет. Фатальная ошибка 😂 Есть исследование, которое переворачивает всё, что нам говорят на курсах и тренингах «как стать тимлидом». Если у вас низкий балл по компетенции, например, по стратегическому видению, и вы вложите месяцы, чтобы подтянуть её для восприятия вас как лидера, это не изменит вообще ничего. Ноль. Вы просто стали чуть менее плохим. А «чуть менее плохих» тысячи. 📉 Зато если взять то, что у вас УЖЕ хорошо получается, и докрутить до выдающегося уровня, кривая лидерства взлетает вертикально 🚀. Для QA-лидов это особенно больно читать, потому что мы обожаем работать над слабостями. Плохо доносите статус до менеджмента? Идём на курс презентаций 🎤. Не умееете управлять конфликтами? Читаем книжку 📚. А по факту, если у вас уже топовая экспертиза и команда реально видит, что вы шарите глубже всех в продукте, то усиление именно этого куда мощнее, чем закрытие многих пробелов 💪. Ещё зацепила фраза про фатальные недостатки которые перечёркивают любую экспертизу. Ты можешь быть гением в тестировании, но если унижаешь людей за баги, твой технический авторитет работает против тебя 📉. Практический совет из статьи, который реально можно применить сегодня: спросите у команду не «что мне улучшить», а «вспомни момент, когда я повлиял на нас так, что результат оказался лучше, чем мы ожидали, и что именно я тогда делал» ✨. Ответ покажет вашу реальную суперсилу, а не список того, что вам вежливо посоветуют подтянуть. Настоящий момент проверки лид не в кивании всеми на планёрке. А когда кто-то говорит "я не согласен", а ты не давишь должностью, но разбираешься "через расскажи почему" Статья полезна, если ведёте команду или метите в QA Lead, но и для понимания своего лида. Может, он не «плохой менеджер», а просто управляет через должность, потому что другого рычага у него пока нет. А может, у него как раз есть та самая суперсила, просто вы её не замечали, потому что искали идеальность по всему и сразу 🔍.

Ребята выложили свой фреймворк для тестов на Go, буквально 60 тысяч уникальных тестов на 500+ сервисов, боевка, которая уже несет реальную нагрузку внутри компании 🚀. Идея понятная так как Go отличный язык для сервисов, но из коробки для больших e2e-сценариев его стандартная библиотека скудновата. И иногда веселая организация в сьюты) Раньше чинили через Allure-Go, но фреймворк и отчётность оказались настолько склеены между собой, что расширять стало больно 😖. Решили переписать с нуля и сразу модульно 👍🏻. Что реально цепляет в реализации: так это Testo не тащит зависимости, только стандартная библиотека 🛠. А плагины подключаются буквально через встраивание структур:

type T struct {
    *testo.T
    *allure.PluginAllure
    *PluginParallel
}

Написал плагин один раз и вот у тебя уже автомат для всех тестов, без копипасты и разноса по каждому файлу. Отдельно понравилась параметризация: тест принимает параметры, а фреймворк сам прогоняет все комбинации и в Allure это разъезжается на отдельные тесты с понятными названиями. Ноль магии, чистый Go ⚡️. И вишенка на торте — хуки BeforeAll/AfterAll в стиле "включили печь перед сменой, выключили после" 🔥. Вроде игрушечный пример, а на деле ровно то, что нужно для настройки инфраструктуры перед тяжёлым regression-прогоном 💪. Ссылка на репозиторий (он открыт) в статье, лицензия Apache-2.0, а документация и примеры на месте 📚. Кто пишет автотесты на Go сталкивался с болью от "мало отчётности из коробки", или у вас уже был свой велосипед под это? 🤔