Телеграм канал «QA-Логия»

Удалёнка съедает ROI: неочевидные потери, которые не считает бухгалтер

Мы в агентстве «Найт Стрит» уверены, что затраты на удалёнку обычно считают по очевидной экономии — не нужен большой офис, падают расходы на командировки, нанимать можно по всей стране. С этой стороны всё сходится. Но у распределённой работы есть вторая колонка расходов, которая почти не попадает в расчёты бухгалтера. Сюда идёт лишний созвон там, где хватило бы сообщения, согласование на два дня вместо десяти минут общения в переговорке, новичок, который вникает на проект месяц, а не положенные две недели.

По отдельности это мелочи, но в команде из сотни дорогих специалистов все эти мелочи складываются в миллионы потерянной выручки за год. Спорить, надо ли срочно возвращать всех в офис, мы не будем. Лучше с холодной головой посчитаем, где именно удалёнка бьёт по ROI и что с этим делать. Цифры дальше модельные: смысл не в том, чтобы поверить моим процентам, а в том, чтобы подставить в формулы свои данные.

Читать далее на Habr

⁣Три вопроса, которые middle QA перестаёт задавать себе после года работы — и почему это тормозит рост

Когда дорос до middle QA, показалось, что все важные вопросы решены. Баги ищу, тест-кейсы пишу, с разработчиками спорю — нормально. Но спустя год заметил, что стою на месте. Оказалось, я перестал задавать себе три вопроса — и это незаметно съедало рост.

1. «Почему этот баг вообще появился — и как его можно было предотвратить?»

На junior-уровне радуешься, когда нашёл баг. На middle — когда закрыл задачу. Но после года работы многие перестают анализировать корни. Пропущенная проверка в автотестах? Ошибка в требованиях? Слабая коммуникация на уточнении? Если не спрашивать, остаёшься в роли ловца багов, а не инженера по качеству. Шанс повлиять на процесс улетает.

2. «Как мои тесты влияют на бизнес-метрики?»

Middle QA часто залипают на технику: покрытие, скорость прогона, количество багов. Но забывают спросить, что это даёт продукту. Уменьшает ли работа количество инцидентов в продакшене? Сокращает ли время выхода фичи? Если не связывать тесты с целями продукта, теряешь видимость своего вклада. На собеседованиях это сразу считывается — тебя не видят как стратегического игрока.

3. «Что я могу сделать по-другому, чтобы вырасти через полгода?»

После года легко уйти в рутину: автотесты пишутся, прогоны проходят, баги закрываются. Но рост сам не случается. Если не спрашивать, ищешь точки развития: новый инструмент, разобраться в архитектуре, взять ревью тестов у других. Иначе остаёшься на плато — и через год твой опыт просто «ещё год на той же позиции».

Middle — не статус, а этап, где легко застрять. Возвращайте эти вопросы в ежедневку. Они помогают не просто тестировать, а строить карьеру осознанно. Попробуйте сегодня — спросите себя про последний баг. Удивитесь, сколько нового увидите.

⁣Рутина в QA — штука коварная. Сидишь полгода на проекте, repeat-баги одни и те же: сломалось — починили — упало опять. Искра гаснет. Начинаешь ненавидеть эти баги не потому что они важные, а потому что опять. Работа превращается в один бесконечный круг.

Но вот что я замечал: рутина не равно стагнация. Стагнация — это когда ты с ней смирился как с данностью.

Ошибка, которую я видел много раз: человек превращается в робота. Открывает баги по шаблону, голову отключает. А потом на собеседовании не может вспомнить, что предлагал по улучшению процесса.

Когда тонешь в рутине, теряешь способность анализировать причины. Repeat-баг воспринимаешь как «опять сломалось», а не как симптом кривого кода или архитектурной проблемы. Перестаешь рефлексировать: «Что я делаю, чтобы такого вообще не было?». Soft skills деградируют: с разработчиком общаешься через автомат «открыл-закрыл».

Мне помогали три вещи:

Первое — сдвиг фокуса. Каждую неделю беру однотипную проверку и ищу необычное. Просто кликать скучно, поэтому спрашиваю: «А что, если разработчик изменил логику, а мне не сказал?». Обычный repeat-баг может открыть скрытую регрессию. Мозг переключается с конвейера на следопыта.

Второе — не сводить обратную связь к «я забагал». Повторный баг — это повод предложить автотест или пойти к разработчику и спросить: «Почему код написан так, что он падает? Может, проблема глубже, в архитектуре?». Ты перестаешь быть пассивным исполнителем.

Третье — искусственные ограничения. Ставлю таймер: 30 минут на стандартные проверки, но параллельно выписываю гипотезы, что еще может сломаться. Через месяц так накидал 5 предложений по регрессионному набору — их взяли в работу.

По поводу AI — тут ловушка. Он сгенерирует тест-кейсы, но про твою мотивацию не подумает. Если скормить ему всю рутину, перестанешь замечать паттерны, которые ведут к росту. Именно человек видит неудобные баги, ломающие сценарий. Рутина может эту внимательность развить, если не позволить себе уснуть.

Repeat-баги — это маркер. Если они одни и те же месяц, значит, что-то не так. Пора бить тревогу и предлагать коренное решение, а не просто тушить пожары.

А ты как с этим справляешься? Может, есть фишки, которые переворачивают подход к рутине.

6 ошибок в метриках дефектов, из-за которых QA теряет контроль над качеством

Когда дашборд зеленеет, число багов падает, а команда получает похвалу — это может быть ловушкой. Через пару недель прод ловит инцидент на ровном месте. Так бывает, если метрики дефектов становятся целью для отчёта и подменяют реальное управление качеством.

В статье разобрано шесть типовых ошибок. Первая — количество багов как личный KPI. Это заставляет QA скрывать дефекты или не заводить их вовсе, чтобы выглядеть лучше в глазах руководства. Вторая — доля переоткрытых задач. Эту метрику легко обойти красивой статистикой: если закрыть баг без реального воспроизведения, процент переоткрытых останется низким, хотя проблема никуда не делась. Третья — игнорирование сегментации дефектов. Например, когда все баги складываются в одну корзину, теряется понимание, какие из них критичны для прода, а какие — косметические. Четвёртая — фокус на проценте закрытых багов без учёта времени их жизни. Пятая — неиспользование плотности дефектов: метрика, показывающая количество багов на единицу кода, часто упускается, хотя именно она выявляет проблемные модули. Шестая — стремление к нулю открытых багов. Это иллюзия: некоторые дефекты невозможно закрыть, их нужно документировать и взвешивать риски.

Каждая из этих ошибок ведёт к тому, что реальное качество продукта ухудшается, а цифры на дашбордах остаются зелёными. Статья предлагает пересмотреть подход к метрикам: не гнаться за красивыми отчётами, а использовать метрики для честного анализа состояния продукта.

Читать далее

⁣Роль продукта в тестировании: как понять, что ты поймал настоящий баг или просто «пофиг» для бизнеса

Каждый, кто работает в тестировании, через это проходил. Находишь баг, аккуратно описываешь шаги, прикладываешь логи. А продакт смотрит и говорит: «пофиг, так и задумано». Или просто закрывает задачу. Бесит. Но если присмотреться — продукт это не про идеальный код, а про бизнес.

Первое, что стоит усвоить: баг и ошибка в коде — не одно и то же. Багом я называю то, что мешает пользователю сделать то, зачем он пришёл. Или мешает бизнесу заработать. Если кнопка «Купить» не работает — это баг, и его надо фиксить вчера. Если съехал отступ на пиксель — скорее всего, пофиг. Если только вы не тестируете интерфейс для дизайнеров с лупой.

Как отличить одно от другого? Настоящий баг ломает логику. Пользователь не может завершить сценарий, теряет деньги или время. А «пофиг» — это косметика, редкий кейс у пары человек из десяти тысяч, или то, что можно отложить без последствий.

Продакт обычно считает так: «Сколько мы потеряем, если не починим?» Вопрос, который стоит задавать себе: «Сколько пользователей от этого пострадает?» Если ответ «единицы» — готовься, что баг закроют. Даже если технически он выглядит критичным.

Типичная ошибка джуниоров — считать, что любой баг надо фиксить немедленно. Если дефект не влияет на конверсию или удержание — продакт вправе сказать «пофиг». И это не про то, что ты плохо проверил. Это про разницу между ошибкой в коде и ошибкой в продукте.

Что с этим делать? Пара вещей, которые работают у меня.

* Перед тем как заводить баг, спрашиваю: «Почему это важно для пользователя?» Если ответ абстрактный — скорее всего, приоритет низкий.
* Потом смотрю в аналитику. Если баг ловит 5 из 10 000 — не трачу время на многостраничное описание.
* И аргументирую бизнес-цифрами: «Из-за этого 20% пользователей кликают мимо, теряем столько-то конверсий».

И не обесценивай себя, когда продакт закрывает баг. Твоя задача не найти всё, а научиться отфильтровывать через призму бизнеса. Тогда из просто «багоискателя» вырастаешь в инженера, который на продукт влияет.

А у тебя было, что продакт закрывал баг, а он потом «выстрелил»? Расскажи в комментариях.

⁣AI-инструменты, которые искажают реальные баги: когда генерация тестовых данных создаёт ложную уверенность

Я часто вижу, как QA-инженеры, особенно junior, попадаются в ловушку "магии AI". Берут инструмент, генерирующий тестовые данные по описанию требований, и расслабляются. Кажется, что все под контролем. А потом продакшен падает из-за граничного случая, который AI не заметил.

AI-генерация данных - штука полезная, но и зона риска. Она искажает картину реальных багов.

Во-первых, AI учится на "идеальных" данных. Он знает, как выглядит типичная строка, дата, email. Но баги живут в аномалиях. AI не сгенерирует строку с нестандартным Unicode-символом или дату 29 февраля 2023 года, если проект этого не требует. Он создает комфортную "прическу" для данных, а не реальную грязь, на которой падает система.

Во-вторых, инструменты игнорируют бизнес-контекст. AI может сгенерировать 1000 корректных заказов на складе, но не поймет, что 500 из них - просрочка, а 300 - без цены. Вы тестируете функционал, думая, что данные корректны, а система работает как идеальная.

В-третьих, ложная уверенность. Автотесты на AI-данных зеленые, но вручную их никто не проверяет. Баг "товар не отображается при нулевом остатке" маскируется AI-генерацией, которая не создала таких записей.

Решения:
* Не доверяйте AI без ручной проверки. Каждый сгенерированный набор анализируйте на граничные условия.
* Используйте AI как черновик, а не финал. Проверяйте, где могут быть дыры.
* Тестируйте на "грязных" данных: аномальные символы, кривые даты, пустые поля, переполнения.
* Смешивайте AI (80% базиса) и ручную генерацию (20% "бомб" из опыта продакшена).

AI - молоток. Если им забивать шурупы, стена кривая. Генерация без контроля создает иллюзию покрытия, а не защиту. Будьте умнее: проверяйте, где AI слеп, и закрывайте дыры руками.

Анатомия парного доклада: как мы собирали «PROvoke» на Analyst Days. Часть 1 — подготовка

На прошлых Analyst Days авторы с Татьяной Маркиной зашли на территорию, где обычно стараются не светиться — тему манипуляций и провокаций в системной аналитике и IT. Они решили сделать парный доклад, чтобы показать не только результаты, но и сам процесс взаимодействия в аналитике на сцене.

Подготовка к такому выступлению потребовала особого подхода. Сначала была задумка сделать воркшоп о манипуляциях, но это было бы слишком сложно для формата конференции. Поэтому решили переделать в доклад с элементами интерактива. Весь путь от идеи до сцены занял около нескольких месяцев, включая несколько итераций согласования содержания.

Ключевым решением стал выбор сценария: решили строить выступление вокруг реального кейса, но с долей театрализации. Каждый из докладчиков взял на себя определенную роль, чтобы проиллюстрировать типичные конфликты в команде. Это позволило погрузить зрителей в атмосферу рабочей дискуссии, не скатываясь в сухую теорию. В итоге получился формат, который авторы назвали «PROvoke», балансирующий между обучением и развлечением.

Читать на Хабре