Тестировщики из Авито запустили подкаст — и у них есть что сказать
«Не воспроизводится» ведут Оля Шнайдер и Сережа Атрощенков — практикующие QA-инженеры, которые каждый день работают с тем, о чём собираются говорить. В выпусках они разбирают реальные темы мира тестирования: ручное и автоматизированное тестирование, работа с ИИ, карьерный рост, отношения с командой, work-life balance — и всё, что обычно остаётся за закрытыми дверями ретро.
Идея простая: дать инженерам место, где можно честно обсудить профессию. Чтобы каждый знал, что он не один.
🎧 Слушайте выпуски подкаста на всех подкаст-платформах:
💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».
Добро пожаловать в мир тестирования. Баги прилагаются.
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
Представлен ресурс для тестировщиков с различными сервисами для автоматизации в одном месте: конверторы, json валидаторы, генераторы uuid и ещё десятки приятных мелочей.
1 апреля 19:00 Собеседование с умом: секреты успешного подбора QA-талантов Погрузимся в секреты успешного подбора талантов, изучим эффективные техники интервьюирования и разберем, как выявить не только технические навыки кандидата, но и его личные качества, которые могут стать залогом успешной работы в QA команде.
2 апреля 20:00 Поиск работы JS-автотестером в 2026 году: как выделиться на рынке работодателя Разберём, как изменилась ситуация на рынке труда для JS-автотестеров в 2026 году и какие стратегии действительно работают при поиске работы. Поговорим о том, как адаптировать резюме под разные рынки, на что обращают внимание HR и технические интервьюеры, и как повысить свои шансы получить оффер.
7 апреля 20:00 Модульное (unit) тестирование в 1С Познакомимся с современными инструментами модульного тестирования. Разберем несколько «неудобных» для тестирования примеров. А также научимся автоматизировать запуск тестов.
14 апреля 20:00 Внедрение автотестирования с участием искусственного интеллекта Этот урок — практическое руководство для тех, кто хочет выстроить устойчивую стратегию авто-тестирования, а не просто «добавить тесты». Мы отдельно разберем, как использовать ии-инструменты в автотестах: где они реально помогают, а где создают иллюзию эффективности.
16 апреля 20:00 ИИ для тестировщика: инструменты, которые уже меняют профессию Разберём, какое место ИИ занимает в работе тестировщика сегодня, какие инструменты действительно помогают ускорять работу и повышать качество, а какие остаются маркетинговым шумом. Узнаем, как ИИ может стать ассистентом QA-инженера в ручном и автоматизированном тестировании.
Онлайн инструменты для тестировщиков без регистрации и смс
Каждый тестировщик (как мне кажется) каждый день в своей работе использует генераторы uuid, конвертеры, регулярные выражения и json валидаторы. И если у нас нет самописных скриптов, то где то в закладках есть любимый инструмент (обычно разный для каждого из этих действий)
Я решил собрать все в одном месте. Ничего революционного, просто удобно, когда не нужно прыгать по вкладкам. Есть и валидация JSON по схеме, и разбор JWT, и ещё куча мелочей, которые в работе всплывают постоянно.
Мы возвращаемся с новым форматом QAчественного общения — антимитапом для тестировщиков.
Когда: 27 марта Где: Санкт-Петербург, offline only
В этот раз сделали два зала и два настроения:
🔥 Test core Пространство вызовов, острых тем и адреналина. Сарказм приветствуется, личные нападки — запрещены.
Будут холивары: «Hard Skills для QA — это про инструменты или про понимание систем?», «Как меняется профессия QA с приходом AI».
💆♀️ Debug Зал для размышлений и рефлексии. Здесь не доказывают, а задаются вопросами и делятся гипотезами. Тот самый safe space, чтобы подумать о будущем QA.
Будут дискуссии: «Как принять свою роль и стать хорошим тестировщиком», «ИПР: развитие специалиста — это задача компании или специалиста?».
Вы сами выбираете маршрут. Можно передвигаться между залами и собирать инсайты с двух полюсов или остаться в одном пространстве и погрузиться в его формат.
Playwright в 2026: новый стандарт UI‑автоматизации
На протяжении последних нескольких лет Playwright из альтернативного инструмента превратился в де‑факто стандарт для UI‑автоматизации в современных веб‑приложениях.
Основная причина тому — архитектурный сдвиг. В отличие от Selenium, который опирается на WebDriver и добавочный слой взаимодействия с браузером, Playwright работает напрямую через DevTools‑протокол. Это устраняет лишние абстракции и снижает накладные расходы на взаимодействие.
На практике это дает три ключевых эффекта:
Стабильность
Встроенный механизм auto‑waiting и синхронизации с состоянием DOM значительно снижает количество flaky‑тестов. Инженеру больше не нужно вручную управлять ожиданиями и обрабатывать race conditions.
Производительность
Благодаря прямому взаимодействию с браузером и встроенной поддержке параллельного выполнения, Playwright демонстрирует более быстрый feedback loop в CI/CD пайплайнах.
Developer Experience
Инструмент предоставляет полноценный набор средств чуть ли не из коробки: trace viewer, codegen, network interception, изоляция через browser contexts. Это снижает порог входа и ускоряет разработку тестов.
При этом важно понимать: Playwright не является «серебряной пулей». Он не делает плохую архитектуру тестов хорошей, не отменяет необходимость в грамотной декомпозиции сценариев, и не заменяет стратегию тестирования.
Но в условиях 2026 года, где доминируют SPA, асинхронные интерфейсы и требования к скорости CI, Playwright лучше соответствует реальным условиям эксплуатации.
Вывод: если вы проектируете систему автоматизации с нуля — Playwright является рациональным выбором по умолчанию.
Если у вас уже есть зрелая Selenium‑инфраструктура — решение о миграции должно приниматься на основе метрик (flaky rate, время выполнения, стоимость поддержки), а не трендов.
Что почитать начинающим тестировщикам: 6 материалов для погружения в тестирование
Привет, Хабр! Мы приготовили подборку, которая поможет глубже погрузиться в тестирование. Внутри — обзоры профессиональной литературы, популярных инструментов и библиотек, а также советы от команды Selectel. Бонус — бесплатный курс по мобильному тестированию от опытных тестировщиков.
Android-эмуляторов — десятки. Чтобы вам было проще выбрать, мы сравнили восемь популярных решений. Разобрали особенности каждого и объяснили, для каких задач они подходят.
Мобильное тестирование — это не просто «веб в миниатюре», а отдельный мир со своей архитектурой, устройствами, операционными системами и ограничениями. В статье рассказали об особенностях мобильных платформ, с которыми тестировщики сталкиваются на практике.
Бесплатный курс от экспертов Selectel, Ozon, Спортс" и не только. Он подходит как новичкам, так и практикующим тестировщикам, которые хотят систематизировать знания. На начало марта доступна первая часть курса, но совсем скоро появится и вторая.
Тестирование — кропотливый труд, особенно для начинающих специалистов. Но задачу можно упростить, если прокачать знания и внедрить подходящие инструменты.
Мало стартового набора? Держите дополнительную порцию интерактивных тренажеров, баз знаний, книг и курсов — проверенных ресурсов, к которым можно возвращаться в любой момент.
Если вы устали от бесконечных циклов «получить приложение → найти баг → отправить на доработку → повторить», предложите команде AI-инструменты для прототипирования. В статье рассказали, как мы используем этот подход.
44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?
Календарь AQA собесов за декабрь
Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее. Вакансий меньше, требования выросли, конкуренция усилилась.
Особенно часто это можно услышать от специалистов из QA/AQA: Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.
Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.
Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.
И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.
Причём: Во-первых, всё это происходило параллельно с основной работой. Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.
Во-вторых, это был декабрь. Если смотреть на рынок найма в IT, конец года традиционно считается не самым активным периодом: компании закрывают бюджеты, команды уходят в отпуска, процессы замедляются.
Тем не менее календарь получился очень плотным.
Иногда у него было по несколько интервью в день: HR, технички, финалки, снова HR.
А если представить его лицо 11го декабря — то лучше не надо)
P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.
И что по итогу? Оправдались ли такие усилия?
Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.
Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)
Всё-таки в подобной ситуации очень быстро прокачиваются навыки интервью. С каждым новым собеседованием ответы становятся точнее, технические вопросы разбираются быстрее, а уверенность растёт.
В итоге этот кандидат получил 6 офферов.
Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.
На мой взгляд, это хороший пример того, как сейчас устроен рынок.
Да, он действительно стал сложнее. Да, требования выросли.
Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.
Те, кто активно выходят на рынок, много собеседуются, анализируют обратную связь и продолжают двигаться дальше — как правило, всё равно получают результат.
А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».
Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.
Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂
В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)
Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA
В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.
Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум: 1. ВАСЯ: ВК, Альфа, Сбер, Яндекс 2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа 3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс
В целом есть множество различных вариаций и аббревиатур, но нет одной единственно правильной. Почему - везде есть свои проблемы и преимущества. Всё в большей степени зависит от проекта. Внутри одной и той же компании может быть и круто, и очень плохо. Поэтому и нет четкого списка "топ компаний", все оценивают по разным критериям.
Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?
Чего стоит попасть туда (насколько это сложно)
У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.
Если говорить про автоматизацию тестирования и смежные роли, картина выглядит иначе. Я скажу больше, выходя на рынок как AQA - вы с большей долей вероятности попадете именно в бигтех.
Автоматизация сегодня - одна из самых востребованных зон в крупных компаниях. Большой продукт, частые релизы, много интеграций - без автотестов это сложно поддерживать.
Плюс последние годы усилили тренд на оптимизацию затрат. Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.
Поэтому спрос на автоматизаторов в бигтехе стабильно высокий. И в этом смысле двери туда открыты куда шире, чем кажется со стороны.
Где лучше и стоит ли оно того
Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US. И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.
Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.
Проекты могут быть плохие и хорошие как в бигтехах, так и в мелких компаниях. Да, в бигтехах часто процессы получше, но это далеко не всегда так. Ну а хороший оффер могут дать и там, и там.
В общем, тут стоит выбирать по сумме условий и не руководствоваться именем компании, т.к. оно часто ничего не значит.
Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.
Что в сухом остатке
При прочих равных условиях кроме записи в резюме работа в бигтехе не дает ровным счетом ничего. Везде всё по разному и может оказаться так, что в стартапе проект будет в миллион раз лучше по всем параметрам. Ну а строчку в резюме всегда можно придумать, если так уж хочется.
Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы! В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)
Вышел наш новый подкаст #Криптонит_говорит про тестирование! Мы обсудили тренды профессии, поговорили об образовании в этой сфере и узнали, почему разрыв между разработкой и тестированием сокращается (и так будет и дальше).
Смотрите и слушайте выпуск на любой удобной платформе:
Приглашаем тестировщиков на митап. Вместе с Moscow QA подготовили три ярких доклада:
Помогите, flaky!
Екатерина Лахтина, тимлид QA UGC в 2ГИС, поделится подходом, который помогает находить и устранять flaky‑тесты, снижать ручную работу и добавлять автоматизацию.
Как прокачать автотесты с 0 до keyword-driven
Анастасия Нестерова, QA Engineer, расскажет, какие методы пробовали, где спотыкались и как в итоге выстроили процесс на стеке Playwright + TypeScript.
Вайб‑кодинг в тестировании с позиции менеджера
Виктория Дежкина, менеджер направления, поделится плюсами и минусами нового подхода в тестировании: как влияет на команду, какие есть риски и стоит ли вообще пробовать.
Как я написал 87 000 сопроводительных писем - про разработку помощника для поиска работы.
Сразу уточню - писал сопроводительные само собой не сам. Мы с командой работаем над ИИ-ассистентом для поиска работы и эти 87 000 писем были отправлены пользователями сервиса в рамках бета-тестирования.
За этой цифрой - месяцы экспериментов, правок и неудачных гипотез. В этом посте поделюсь, с какими сложностями мы столкнулись и как их решили.
Задача
Изначально мы хотели решить довольно простую на первый взгляд проблему: автоматизировать написание сопроводительных писем.
Но быстро стало понятно, что «просто генерировать текст» - бессмысленно.
Цель изменилась. Нужно было не просто прикладывать письмо к отклику, а сделать его:
релевантным конкретной вакансии
не шаблонным
не выглядящим как типовой текст нейросети
понятным для HR за несколько секунд
И вот тут начались сложности.
С чем столкнулись
Шаблонность моделей. Даже при хорошем промптинге тексты начинали повторяться по структуре и формулировкам.
Разные ожидания HR. Кто-то предпочитает краткость, кто-то - структуру, кто-то - конкретные достижения в цифрах.
Изменяющиеся требования вакансий. Один и тот же стек может быть описан по-разному, и формальное совпадение по ключевым словам не гарантирует релевантности.
Ограничения платформ. Изменения на стороне hh влияли на логику работы системы, и часть архитектуры приходилось пересобирать.
В какой-то момент стало ясно, что проблема глубже.
Главный вывод
После десятков тысяч писем стало очевидно:
Проблема не в том, что сопроводительные «плохие». Проблема в том, что в них не видно релевантности.
HR тратит на письмо буквально несколько секунд. Если за это время не становится понятно, почему кандидат подходит - письмо закрывается.
Поэтому мы изменили подход.
Система теперь не «пишет красиво». Она сначала сопоставляет требования вакансии с опытом пользователя и только потом формирует текст, где это соответствие явно показано.
Что изменилось в результате
После 87 000 отправленных писем тексты стали короче, конкретнее, привязанными к требованиям вакансии, менее шаблонными.
Ну а параллельно дорабатывались и другие части системы:
фильтрация релевантных вакансий
автоматизация откликов
работа с онлайн-тестами
механизмы приоритизации
Что по итогу имеем сейчас
Проект находится в стадии бета-тестирования. Мы продолжаем собирать фидбек и корректировать логику, особенно в части сопоставления опыта и требований.
История с сопроводами по большей части пройдена, но осталось ещё множество аспектов для улучшений.
Кому интересно - могут попробовать бота бесплатно. В блоге можно найти более подробную информацию. Также там пишу про развитие проекта и проблемы, с которыми сталкиваемся.
Когда в Android-проекте ≈800 модулей и 37 000 unit-тестов, полный прогон на CI легко превращается в полдня ожидания. У нас было ровно так: больше 3 часов на полный запуск — и ощущение, что локально это вообще не вариант. А потом команда нашла настоящие причины тормозов и довела прогон до 12 минут.
Бесплатный мини-курс для специалистов по ручному тестированию. От нейросети до тест-кейса: практическое применение ИИ в тестировании.
Привет, Хабр! Я — Николай Корнетов, ведущий инженер-тестировщик в IBS. Мы с коллегами записали бесплатный мини-курс об использовании искусственного интеллекта для задач ручного тестирования.
Курс состоит из 8 видео. В них я расскажу, как нейросети могут упростить и автоматизировать вашу работу: разберу принципы работы больших языковых моделей и их ограничения, покажу на реальных примерах, как ИИ помогает ревьюить документацию, создавать чек-листы и тест-кейсы, придумывать тестовые данные и решать другие задачи.
Все уроки курса — на нашем сайте. Смотри видео, применяй новые знания на практике и делись своими впечатлениями в комментариях.
Когда я вижу очередной лендинг какого-нибудь IT-курса, у меня каждый раз возникают два одних и тех же вопроса. Они касаются самого интересного - видеоотзывов выпускников.
Вопрос №1. Большинство IT-школ ежегодно набирают сотни и тысячи студентов. По статистике трудоустройств с лендингов этих же школ сотни и тысячи выпускников должны ежегодно получать офферы.
Почему тогда на сайтах курсов обычно лишь 5-10 видеоотзывов от выпускников, а не сотни?
Вопрос №2. Главная гордость любого новичка - это его первая IT-компания. Он долго и упорно учился, искал работу и, наконец, начал свою карьеру в IT. И ему, скорее всего, хочется поделиться своей радостью со всем миром.
Почему тогда даже этот десяток выпускников в видеоотзывах обычно ничего не говорит про самое важное - в каких именно IT-компаниях они теперь работают?
Пришлось отдуваться за коллег - хотя по сравнению с ними мы очень маленькие и никогда не набирали больше 75 студентов в год.
На рынке сейчас царит жуткая путаница между совершенно разными AI-QA-ролями. Получилось так, что я прошла через все три роли. Если вы планируете карьерный переход, то вот в чем разница между ними:
1️⃣ QA Engineer с инструментами ИИ Цель: Эффективность. Реальность: Вы тестируете традиционный детерминированный продукт. Вы просто используете ChatGPT для генерации тест-кейсов или Cursor/Claude Code для автоматизации. Это «вайб-кодинг» для старых добрых задач.
2️⃣ AI QA Engineer Цель: Базовая проверка интеграции. Реальность: Тестирование того, как чат с LLM работает внутри условной CRM-системы. Вы проверяете, вежлив ли бот и не «поехал» ли интерфейс. Вы всё ещё используете ассерты (asserts), просто с небольшим «привкусом» нейросетей.
3️⃣ ML Evaluation Engineer (Инженер по оценке ML-моделей) Цель: Управление хаосом в недетерминированных моделях. Реальность: Вы не используете ассерты; вы используете статистические метрики. Инструменты: Фреймворки для оценки (например, LM Evaluation Harness), модули метрик на Python.
Почему третий вариант — это совсем другое:
Вероятность > Детерминизм: Вы не проверяете, что . Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
Стоимость как метрика: В ML Eval затраты токенов так же важны, как задержка (latency). Если ваш агент «умный», но стоит $2 за запрос — вы провалили тест.
Скорость решает всё: Здесь быстрая 7B-модель может выиграть у медленной 70B. Тестирование производительности здесь не «доп. опция», а база.
Не смогли смириться с поражением - и к чему нас это привело. Как мы воскресили ИИ-помощника для поиска работы
Привет, Хабр.
В декабре наш ИИ-ассистент для поиска работы фактически перестал работать. Изменения на стороне платформ, ограничения, поломанные сценарии - всё то, из-за чего большинство подобных проектов обычно закрываются или уходят в «заморозку».
Самый логичный вариант был простой:
«Ну ок, рынок поменялся, едем дальше».
Но мы решили иначе.
Мы не смогли смириться с тем, что квалифицированные специалисты по-прежнему тратят часы жизни на клики, шаблонные отклики и бесполезную рутину. Поэтому вместо точечных фиксов мы решили не чинить старое, а пересобрать всё с нуля.
Так начался путь к OfferMate 2.0.
Главная мысль оказалась неожиданно простой:
Автоматизация должна быть не только быстрой, но и естественной.
Настоящий цифровой ассистент должен вести себя как человек:
выбирать вакансии осмысленно;
работать с паузами и приоритетами;
не выглядеть как бот;
и не ломаться при реальной нагрузке.
Именно вокруг этого принципа мы и пересобрали архитектуру продукта.
Что теперь умеет OfferMate 2.0
🤖 Отклики только на релевантные вакансии Ассистент анализирует ваш опыт и требования работодателя и выбирает вакансии, которые действительно подходят, а не просто совпадают по ключевым словам.
👤 Имитация человеческого паттерна поведения Система воспроизводит действия пользователя: паузы, разную скорость, приоритеты. Это делает работу максимально естественной и безопасной.
✍️ Персонализированные сопроводительные письма Каждое письмо формируется под конкретную вакансию и компанию - на основе вашего опыта и требований позиции.
📈 Контроль и аналитика Пользователь видит, что происходит в системе, и может управлять стратегией поиска.
🧩 Новые функции
автоматическое прохождение онлайн-тестов;
поддержка одновременных откликов с нескольких аккаунтов.
Про релиз
12 февраля в 12:00 мы открываем доступ к OfferMate 2.0.
Первая волна будет ограничена 50 пользователями, а доступ открыт на 3 дня. Это осознанное ограничение - чтобы сохранить стабильность системы и быстро собрать качественную обратную связь.
Поучаствовать в тестировании в числе первых можно будет в нашем телеграм канале, в нём делимся всеми новостями проекта:
В процессе тестирования верстки быстро становится понятно: один и тот же интерфейс может выглядеть аккуратно на макете, но разваливаться на практике. Чаще всего это проявляется в длине текста, переносах строк, состояниях элементов и отступах.
Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.
1️⃣ С чего начинаем тестирование верстки?
При тестировании верстки мы сначала наполняем блоки разными текстовыми данными. Это сразу показывает, где интерфейс начинает ломаться. Дальше проверяем:
максимально короткие значения — точка, пробел;
максимально длинный текст, который можно ввести;
соответствие ограничениям из постановки — например, максимально доступно 64 символа.
Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.
2️⃣ Почему проверяем текст с пробелами и без?
Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.
Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.
Для таких проверок удобно использовать максимально широкие буквы:
для кириллицы — «Щ»;
для латиницы — «W».
Это простой способ увидеть помещается ли текст, переносится ли он корректно на следующую строку и не вылезает ли за контейнер.
3️⃣ Что проверяем в макете?
Например, в макете Figma мы смотрим:
И, конечно, отступы между всеми элементами по вертикали и горизонтали.
4️⃣ Как проверяем реализацию?
В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.
Computed удобнее — отображаются итоговые значения после применения всех CSS-правил: размер шрифта, высота строки, цвета, отступы.
Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.
5️⃣ Что важно знать о состояниях элементов?
Чаще всего это кнопки. В DevTools можно вручную включить состояния:
:hover
:active
:focus
Позволяет увидеть нужный цвет, проверить границы и сравнить с макетом, даже если мышь сейчас не наведена на элемент.
6️⃣ На что еще обращаем внимание?
Отступы могут быть реализованы через padding (внутренний) и margin (внешний).
Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.
7️⃣ Когда удобно считать руками, а когда — линейкой?
Иногда проще посмотреть padding и margin и сложить их значения. Но если блоки визуально хорошо видны, помогает линейка: измеряем расстояния не только в браузере, но и вообще на экране.
Для текста и иконок лучше ориентироваться на границы блоков и отступы, а не пытаться измерять «на глаз».
При этом в тестировании верстки почти всегда появляется вопрос баланса: где достаточно базовых проверок, а где уже начинается избыточный pixel perfect.
Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными?
Почему хороший тестировщик — это не тот, кто нашел больше всего багов
В тестировании легко попасть в простую ловушку — начать измерять свою ценность количеством найденных багов. Чем больше тикетов, тем полезнее работа. На первый взгляд логика кажется железной.
На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.
Количество багов ничего не говорит само по себе
Сто найденных дефектов могут означать две совершенно разные вещи:
продукт реально нестабилен;
тестирование началось слишком поздно.
Если баги находятся пачками в самом конце разработки, это не успех, а симптом. Хороший тестировщик старается сделать так, чтобы часть проблем не доходила до баг-трекера вообще.
Сильный тестировщик думает раньше, чем тестирует
Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.
что здесь может пойти не так;
где система уже ломалась;
какие изменения самые рискованные.
Человек, который подключается к обсуждению требований и дизайна, часто предотвращает больше дефектов, чем тот, кто просто проверяет готовую фичу.
Баг-репорт — это не обвинение
Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.
Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:
понятно, что сломалось;
понятно, как воспроизвести;
понятно, почему это важно.
Чем меньше эмоций и больше контекста — тем лучше работает процесс.
Автотесты — это не самоцель
Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.
Хороший тестировщик задает другие вопросы:
ловят ли эти тесты реальные проблемы;
можно ли им доверять;
не мешают ли они менять код.
Иногда удаление десятка бесполезных автотестов приносит больше пользы, чем написание сотни новых.
Хороший тестировщик думает о пользователе, а не о сценарии
Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.
Он кликает не туда, вводит странные данные, прерывает процессы и возвращается позже. Умение выйти за рамки сценариев отличает опытного тестировщика от формального.
Качество — это ответственность всей команды
Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.
Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.
Карьерный рост в тестировании — это не про инструменты
Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.
Гораздо важнее:
умение анализировать систему;
понимание, где искать проблемы;
способность говорить с разработчиками и бизнесом на одном языке.
Именно это делает тестировщика ценным, а не список технологий в резюме.
В итоге
Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:
помогает находить проблемы раньше;
думает о рисках, а не о галочках;
пишет понятные баг-репорты;
работает с командой, а не против нее.
Такие люди редко кричат о своих результатах. Но именно благодаря им продукт перестает ломаться в самых неожиданных местах.
. Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
