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

Волна сокращений в IT: к чему готовиться джунам

Этой весной 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 и что с этим делать. Цифры дальше модельные: смысл не в том, чтобы поверить моим процентам, а в том, чтобы подставить в формулы свои данные.

Читать далее на 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% пользователей кликают мимо, теряем столько-то конверсий».

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

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