Серьезный тестировщик

Перестаньте искать лучшую компанию. Ищите подходящее давление Читать...

Soft skills в IT: почему я против? Читать...

Одна за всех? Как я организовала более 100+ встреч QA-комьюнити и не выгорела Читать...

Матрица трассируемости: Навигатор тестировщика Читать...

Анти-метрики: как убить мотивацию команды (и продукт заодно) Знакомая картина: в компанию приходит новый менеджер, открывает Jira и понимает, что ему не хватает контроля. Нужно срочно всё оцифровать, повесить на стену огромный дашборд и привязать к нему премии. Идея звучит логично: то, что нельзя …

Анти-метрики: как убить мотивацию команды (и продукт заодно) Знакомая картина: в компанию приходит новый менеджер, открывает Jira и понимает, что ему не хватает контроля. Нужно срочно всё оцифровать, повесить на стену огромный дашборд и привязать к нему премии. Идея звучит логично: то, что нельзя измерить, нельзя улучшить. Но в разработке и QA это правило часто дает сбой, который в экономике называют «Эффектом кобры» (когда решение проблемы делает только хуже). 1. Премия за количество заведенных багов Это классика. Казалось бы, чем больше багов нашел QA — тем он молодец. Что происходит в реальности: Тестировщики начинают генерировать мусор. Вместо того чтобы завести один понятный баг «Едет верстка в корзине на мобилках», человек заводит 10 разных тикетов: «Едет кнопка», «Едет текст», «Съехал плейсхолдер»... А еще в ход идут орфографические ошибки в админке, которую видит полтора человека. В итоге бэклог раздувается до космических масштабов, ПМ седеет на грумингах, а разработчики начинают тихо ненавидеть QA-отдел. И главное — критичные бизнесовые ошибки в этом спаме просто теряются. 2. Нормо-тесты: количество пройденных тест-кейсов в день Метрика с завода, где норма — выточить 50 деталей за смену. Что происходит в реальности: Люди перестают проводить сложное, исследовательское тестирование, потому что на него уходит уйма времени, а галочки в условном TestRail сами себя не поставят. Начинается дробление: вместо одного хорошего End-to-End сценария пишется двадцать примитивных (зашел на сайт — галочка, ввел логин — галочка). Вы получаете красивый зеленый график выполнения плана и... дырявый релиз в проде. 3. KPI разработчику на отсутствие возвратов (Re-open rate) Идея: «Давайте наказывать программистов, если тестировщик возвращает задачу на доработку. Пусть пишут без багов с первого раза!» Что происходит в реальности: Вся разработка уходит в тень. Тестировщик находит баг, но чтобы не портить карму разработчику (ведь они же в одной лодке, вместе потом пиво пить), он не переводит тикет в Jira. Он пишет ему в личку: «Саня, тут отвалилось, поправь по-братски в тихую». Процесс становится абсолютно непрозрачным. Никто не знает реального статуса задач, история ошибок не сохраняется, а Саня седеет от потока левых правок мимо спринта. 4. Погоня за 100% Code Coverage в автотестах Красивая цифра для отчета руководству. Что происходит в реальности: Автоматизаторы начинают писать тесты ради тестов. Появляются скрипты, которые просто вызывают функции, но внутри у них нет ни одного assert (проверки результата). Код покрыт метрикой, график показывает 95%, менеджеры пьют шампанское. Ровно до тех пор, пока полностью «покрытый» модуль не рухнет на живых пользователях. Что делать вместо этого? Любая цифра, привязанная к зарплате конкретного человека, рано или поздно будет скомпрометирована. Люди не злые, они просто адаптируются к правилам игры. Если хотите мерить эффективность QA и разработки, смотрите на командные метрики, ориентированные на бизнес: — Escaped Defects (баги, улетевшие в прод). — Lead Time (время от идеи до релиза, без учета подковерных перекидываний таски туда-сюда). — Индекс счастья пользователей (оценки в сторах, отзывы, обращения в саппорт).

Вредные советы QA: Как завалить релиз и стать главным врагом команды Если вам наскучило мирное существование в IT, вы устали от корпоративной вежливости разработчиков (и их шуточек про то, что QA только и умеют, что ломать) — пора действовать. Специально для тех, кто хочет привнести в скучный спри…

Вредные советы QA: Как завалить релиз и стать главным врагом команды Если вам наскучило мирное существование в IT, вы устали от корпоративной вежливости разработчиков (и их шуточек про то, что QA только и умеют, что ломать) — пора действовать. Специально для тех, кто хочет привнести в скучный спринт немного хардкора, я подготовил этот гайд. Следуйте этим простым советам, и уже через неделю с вами перестанут здороваться у кофемашины. Совет №1. Краткость — сестра таланта Никогда не прикрепляйте к баг-репортам скриншоты, видео и уж тем более эти занудные логи. Идеальное описание бага должно выглядеть так: «Кнопка не работает». Какая кнопка? В каком окружении? Под каким пользователем? Пусть разработчик сам догадается. В конце концов, он же программист, пусть поработает головой. Если начнет задавать вопросы, отвечайте холодно: «Я всё проверил, у меня падает». Совет №2. Пятница, 17:55 — время для магии Вы нашли критичный баг (например, не проходит оплата) еще в среду? Потрясающе. Ни в коем случае не заводите его сразу! Подождите до вечера пятницы. Дождитесь момента, когда тимлид уже надел куртку, а DevOps занес палец над кнопкой Deploy. И вот тут врывайтесь в чат с капслоком: «СТОП РЕЛИЗ!!! МЫ ТЕРЯЕМ ДЕНЬГИ!». Ощущение собственной власти и паника в глазах команды — бесценны. Совет №3. Ставьте Blocker на всё подряд Сполз пиксель в футере на странице «Пользовательское соглашение»? Это, несомненно, Blocker. Выскочила не та орфографическая ошибка в модалке? Critical! Заведите 40 минорных багов с высочайшим приоритетом и требуйте их немедленного исправления. Если ПМ попытается перенести их в бэклог, устраивайте драму и говорите: «Мы выпускаем сырой продукт, я под этим не подпишусь!». Совет №4. Воспитание токсичностью Никогда не пишите в комментариях к задаче нейтральное «Ожидаемый результат не совпадает с фактическим». Вы же живой человек, проявите эмоции! Используйте фразы: «Ты опять всё сломал», «Как это вообще прошло ревью?», «Я бы даже с закрытыми глазами написал код лучше». Это отлично укрепляет командный дух и повышает мотивацию разработчика всё переделать (нет). Совет №5. Ни шагу за пределы чек-листа Тестируйте строго, как робот. В таске написано «Проверить ввод email»? Вводите. То, что при этом отвалилась половина базы данных и разлогинило всех пользователей — не ваша проблема. Об этом в требованиях ничего не сказано. Ваша совесть чиста, таска протестирована, можно идти пить смузи. Совет №6. Сомневайтесь во всём (особенно в дизайнерах) Если баги закончились, начните тестировать дизайн на здравый смысл. Придите к UI/UX дизайнеру и полчаса доказывайте ему, что зеленый цвет этой кнопки недостаточно «продающий», а пользовательский путь вообще придуман инопланетянами. На аргументы о проведенных A/B тестах и аналитике делайте снисходительное лицо и отвечайте: «Ну, я как пользователь вам говорю — это неудобно». А если серьезно: каждый из нас хоть раз в жизни случайно следовал хотя бы одному из этих пунктов (особенно второму, когда баг действительно находился в последнюю минуту).

Классификация QA: 5 типов тестировщиков, которых вы точно встречали (или узнаете в них себя) Говорят, для разработчиков все тестировщики на одно лицо: это такие душные ребята, которые приходят в пятницу вечером и говорят «Тут кнопочка на два пикселя съехала, релизить нельзя». Но мы-то с вами знаем…

Классификация QA: 5 типов тестировщиков, которых вы точно встречали (или узнаете в них себя) Говорят, для разработчиков все тестировщики на одно лицо: это такие душные ребята, которые приходят в пятницу вечером и говорят «Тут кнопочка на два пикселя съехала, релизить нельзя». Но мы-то с вами знаем правду. Внутри QA-комьюнити есть своя жесткая экосистема. Давайте честно пройдемся по типам тестировщиков, с которыми мы работаем каждый день. 1. Бюрократ (Он же "Инквизитор требований") Валидольный кошмар аналитиков. Этот человек не приступит к тестированию, пока у него не будет утвержденного ТЗ на 50 страниц, подписанного кровью продакта. Как работает: Заводит баг, если запятая в ТЗ стоит не там, где в интерфейсе. Тест-кейсы расписаны так подробно, что по ним можно запустить ядерный реактор. Любимая фраза: «Этого нет в спецификации, я не буду это проверять». Польза для команды: Спасает проекты в кровавом энтерпрайзе и финтехе, где цена ошибки — миллионы. В стартапах обычно выгорает за месяц. 2. Адепт Хаоса (Манки-тестер от Бога) Антипод Бюрократа. Он открывает фичу, и у него тут же чешутся руки нажать все кнопки одновременно. Пока остальные вдумчиво проверяют регистрацию с валидным email, Адепт Хаоса вставляет в поле ввода эмодзи баклажана, сворачивает браузер, отключает интернет и пытается отправить форму. Как работает: Никаких тест-кейсов, только интуиция и исследовательское тестирование на максималках. Любимая фраза: «Слушайте, а если зажать Alt, кликнуть правой кнопкой и обновить страницу... Смотрите, база легла!» Польза для команды: Находит самые дикие, отбитые и дорогие баги в проде, до которых автотесты в жизни не додумаются. 3. Сектант Автоматизации Считает ручное тестирование пережитком Средневековья. Если нужно проверить, работает ли один несчастный чекбокс — он потратит три дня, чтобы написать фреймворк на Playwright, поднять докер-контейнеры и настроить CI/CD пайплайн. Как работает: Периодически стопорит релизы, потому что «тесты флакают». Зато когда всё настроено, работает как часы. Любимая фраза: «Тут ручного регресса на 10 минут, но дайте мне неделю, я всё автоматизирую». Польза для команды: Незаменим на долгих проектах. Главное — вовремя бить его по рукам, когда он пытается автоматизировать одноразовую промо-страницу. 4. QA-Сыщик (Несостоявшийся разраб) Он не пишет баг-репорты в стиле «Я нажал, и вылезла ошибка». Он пишет поэмы. К тикету всегда приложены: скриншот из DevTools, ответ от бэкенда с выделенным 500-м статусом, кусок лога из Kibana и, возможно, скрин куска кода на гитлабе, где именно ошибся разработчик. Как работает: Разработчики его одновременно любят (не надо гадать, почему упало) и ненавидят (потому что он лезет в их код). Любимая фраза: «Фронт ни при чём, вызов апишки отваливается из-за того, что в базе этот юзер без флага active». Польза для команды: Радикально сокращает время на фикс багов. Идеальный кандидат на позицию QA Lead. 5. Познавший Дзен (Уставший Senior) Человек, который видел столько горящих релизов, что его пульс не поднимается выше 60 даже когда валится прод. Он знает слабые места системы лучше, чем те, кто её архитектурил. Как работает: Вместо того чтобы прогонять 500 тест-кейсов, он делает 3 проверки в нужных местах и находит критичный баг. Остальное пропускает со словами «и так работать будет, не лезьте туда». Любимая фраза: «Это не баг, это исторически сложившаяся фича. Заводите в бэклог, поставим минор и забудем». Польза для команды: Хранитель сакральных знаний. Спасает от паники и учит джунов не заводить баги на любую ерунду. А к какому типу относите себя вы?

Промпт-инжиниринг для QA: как не стать лишним? Слушайте, давайте без воды. «ИИ нас всех заменит» — эту мантру мы слышим из каждого утюга уже года два. Спойлер: пока никто никого не заменил. Ручные тестировщики всё так же кликают кнопочки, автоматизаторы всё так же борются с падающими (по непонятной…

Промпт-инжиниринг для QA: как не стать лишним? Слушайте, давайте без воды. «ИИ нас всех заменит» — эту мантру мы слышим из каждого утюга уже года два. Спойлер: пока никто никого не заменил. Ручные тестировщики всё так же кликают кнопочки, автоматизаторы всё так же борются с падающими (по непонятной причине) тестами, а релизы всё так же иногда едут в прод с багами. Но кое-что всё-таки поменялось. Разница между QA, который использует нейросети, и тем, кто принципиально их игнорирует, стала заметна. И дело тут не в том, что первый — киборг, а второй динозавр. Дело в банальной скорости работы. Промпт-инжиниринг звучит сложно, как будто мы тут проектируем двигатели для ракет. На самом деле это просто умение нормально поставить задачу железной коробке, чтобы она не выдала тебе галлюцинацию. Давайте разберем на примерах, как перестать использовать ИИ как дорогую игрушку и сделать его своим «электронным джуном». Забудьте про запросы вида «Напиши мне тест-кейсы» Это самая частая ошибка. Вы кидаете в чат ссылку на таску из Джиры и пишете: «Сделай проверки». Нейронка, конечно, постарается. Она выдаст вам простыню позитивных сценариев, которые вы и так бы придумали за три минуты, пока пили кофе. ИИ — это помощник без контекста. Откуда ему знать, что у вас бэкенд отваливается по таймауту, если в корзине больше 100 товаров? Откуда ему знать, что пользователи чаще сидят с древних андроидов? Формула нормального промпта для QA: Роль + Контекст продукта + Конкретная задача + Ограничения/Формат. Пример 1. Анализ требований (когда аналитик «немного забыл» корнер-кейсы) ❌ Как не надо: «Проверь эти требования: [текст]» ✅ Как надо: «Ты — въедливый Senior QA Lead в финтех-проекте. Вот требования к новой фиче "Оплата по QR-коду". Найди в них логические дыры, противоречия и неучтенные негативные сценарии. Особое внимание обрати на потерю сети в момент транзакции и истечение срока жизни сессии. Ответ дай в виде маркированного списка с оценкой критичности каждого пункта.» Чувствуете разницу? Вы задали фокус. ИИ не будет писать банальщину, он пойдет искать дыры в логике. Пример 2. Генерация тестовых данных (рутина, которую пора делегировать) ❌ Как не надо: «Придумай 10 тестовых юзеров» ✅ Как надо: «Сгенерируй JSON с массивом из 20 объектов 'User'. Мне нужны граничные значения: слишком длинные email-адреса, имена со спецсимволами и иероглифами, отрицательный баланс кошелька, возраст меньше 18 лет. Формат: [{"name": "", "email": "", "balance": 0, "age": 0}]. Только JSON, без лишнего текста.» Всё, вы сэкономили себе полчаса на выдумывание «Васи Пупкина» с емейлом из 256 символов. Пример 3. Когда автотесты падают Вместо того чтобы полчаса втыкать в логи и стэк-трейс ошибки консоли, скормите их в GPT. ✅ Формат запроса: «Я пишу автотест на Playwright + TypeScript для проверки авторизации. При выполнении падает ошибка [вставляем логи]. Элемент на странице есть, но клик не проходит. Подскажи 3 возможные причины, почему тест флакает, и напиши варианты обхода, включая ожидание состояния элемента, а не только таймаут.» Так где же граница между нами и ИИ? Нейросети всё ещё ужасны в одной вещи — они не понимают бизнес-ценности. Они не знают, что этот минорный баг с цветом кнопки взбесит CEO, а вот эта критичная (по логам) ошибка в легаси-модуле вообще никого не волнует, потому что им пользуются три с половиной человека. ИИ не умеет договариваться с разработчиками о том, как лучше исправить дефект. ИИ не чувствует продукт с позиции пользователя. Поэтому, чтобы не оказаться лишним, нужно перестать конкурировать с машиной в скорости написания тест-кейсов. Конкурировать нужно в экспертизе, умении видеть систему целиком и... умении правильно формулировать запросы к этому самому ИИ. Рассматривайте нейросеть не как замену себе, а как экзоскелет. Вы по-прежнему управляете движением, просто теперь можете поднимать гораздо больший вес.

Сам свой код и тестируй: кто [на самом деле] должен искать баги Читать...

Испытательный срок в IT не работает Читать...