Этой весной Oracle уволил почти 30 000 сотрудников. Председатель совета директоров Ларри Эллисон объясняет это тем, что выиграют те, кто сегодня строит инфраструктуру для ИИ. Компания инвестирует миллиарды в дата-центры — в 2027 году объем таких вложений составит $70 млрд. Увольнения же высвободят до $12 млрд в год, что за несколько лет покроет эти затраты.
Oracle не одинока. В прошлом году Microsoft уволила 15 000 сотрудников, Meta — 8 000. Amazon за два года избавилась почти от 50 000. В сумме без работы остались 165 000 представителей технологического сектора. Хотя масштабы впечатляют, такие сокращения не редкость в переходные времена, когда появляются новые технологии.
Пока тренд заметен на западном рынке, но волна, вероятно, дойдет и до России. Признаки уже есть: сокращение найма, «скрытые» увольнения и заморозка зарплат.
Вчера на код-ревью баг-репорта я чуть не лопнул от смеха и раздражения одновременно. Коллега прислал отчёт с 15 скриншотами, пояснениями в духе "нажал кнопку, курсор моргнул, потом не моргнул, потом снова моргнул" и стеной логов браузера. Разработчик закрыл баг через 3 минуты словами "не воспроизводится, недостаточно данных".
Знакомая ситуация? Мы, тестировщики, часто впадаем в крайности: либо пишем "всё сломалось" без шагов, либо раздуваем отчёт до размеров диплома. Но золотая середина — это баланс между полнотой информации и скоростью принятия решения.
Когда детализация становится вредной?
1. Перегрузка контекстом. Если указать все 50 шагов, включая "открыл браузер, нажал F12" — вы заставляете разработчика тратить время на фильтрацию. Ему нужно только то, что ведёт к багу. Лишнее — шум.
2. Избыточные логи. Один раз я вложил дамп логов за час, хотя баг воспроизводился за 2 секунды. Разработчик искал иголку в стоге сена и попросил сократить логи до момента ошибки.
3. Субъективные оценки. "Интерфейс выглядит ужасно" — не данные, а мнение. Нужны чёткие критерии: пиксели, размер, время в миллисекундах.
Как найти золотую середину?
* Принцип "минимально необходимого". Спросите: "Что разработчику нужно для воспроизведения за 30 секунд?" Шаги — только обязательные. Если баг проявляется после 10 повторов — напишите "повторить 10 раз", но не описывайте каждый.
* Разделите факты и контекст. Факты: "При вводе символа # поле сбрасывает значение". Контекст: "Только в Firefox 120 на macOS". Контекст — в среде или примечаниях, а не в шагах.
* Используйте визуальную иерархию. Скриншот с красной стрелкой и подписью "Ошибка в элементе X" — золото. Каша из 10 обводок — шум. Один баг — один скриншот с чётким указанием.
* Проверяйте время на чтение. Если я трачу больше минуты на понимание отчёта — я переписываю его. Разработчик не будет разбираться дольше.
Мой чек-лист перед отправкой:
- Может ли разработчик воспроизвести баг без дополнительных комментариев?
- Убрал ли я все шаги, не влияющие на воспроизведение?
- Самодостаточны ли скриншоты/логи?
- Не заменил ли я объективные данные субъективными оценками?
Помните: ваша цель — не показать, как много вы натестировали, а помочь разработчику исправить проблему быстро. Детализация — инструмент, а не самоцель. Если отчёт мешает принятию решений — он вреден.
Пробуйте завтра взять свой самый старый баг-репорт и сократить его наполовину. Удивитесь, как много было лишнего.
Удалёнка съедает ROI: неочевидные потери, которые не считает бухгалтер
Мы в агентстве «Найт Стрит» уверены, что затраты на удалёнку обычно считают по очевидной экономии — не нужен большой офис, падают расходы на командировки, нанимать можно по всей стране. С этой стороны всё сходится. Но у распределённой работы есть вторая колонка расходов, которая почти не попадает в расчёты бухгалтера. Сюда идёт лишний созвон там, где хватило бы сообщения, согласование на два дня вместо десяти минут общения в переговорке, новичок, который вникает на проект месяц, а не положенные две недели.
По отдельности это мелочи, но в команде из сотни дорогих специалистов все эти мелочи складываются в миллионы потерянной выручки за год. Спорить, надо ли срочно возвращать всех в офис, мы не будем. Лучше с холодной головой посчитаем, где именно удалёнка бьёт по ROI и что с этим делать. Цифры дальше модельные: смысл не в том, чтобы поверить моим процентам, а в том, чтобы подставить в формулы свои данные.
Три вопроса, которые 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% пользователей кликают мимо, теряем столько-то конверсий».
И не обесценивай себя, когда продакт закрывает баг. Твоя задача не найти всё, а научиться отфильтровывать через призму бизнеса. Тогда из просто «багоискателя» вырастаешь в инженера, который на продукт влияет.
А у тебя было, что продакт закрывал баг, а он потом «выстрелил»? Расскажи в комментариях.