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

⁣Замечаю у коллег всё чаще такую стратегию: застрял в росте - меняй проект. Разработка новая, доменная область свежая, авось и новые скиллы сами подтянутся. И так каждый год. Только вот, по моим наблюдениям, это всё чаще путь не вверх, а по кругу.

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

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

Junior -> Middle. Джуну не хватает системности, ответственности за качество в широком смысле и умения видеть риски на несколько шагов вперёд. Переход на новый проект даёт лишь опыт в разных чек-листах и баг-трекинговых системах. Но это количество, а не качество. Чтобы вырасти в мидла, нужно научиться отвечать на вопросы: "Почему я тестирую именно это?", "Какие нефункциональные риски я упускаю?", "Как мой чек-лист связан с архитектурой приложения?". Новая предметная область не научит рефлексии над собственными подходами.

Middle -> Senior. Мидл уже умеет тестировать сложные фичи. Чтобы стать сеньором, нужно: тащить ответственность за весь процесс, строить коммуникацию, влиять на решения команды и видеть продукт целиком. Смена проекта даёт новые контексты, но если на каждом прошлом проекте ты оставался "золотым исполнителем", а не драйвером изменений, то на новом месте ты снова будешь строить регресс и писать баги. Сеньор растёт там, где он остаётся достаточно долго, чтобы увидеть цикл полного развития и влияния.

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

Практический вывод. Если чувствуешь, что упёрся в потолок, не пили резюме в первую очередь. Остановись. Спроси себя: "Какую именно новую компетенцию я хочу развить?" Если это про системный взгляд - перестань бегать. Начни брать на себя больше ответственности на текущем месте: участвуй в уточнении требований, предлагай метрики качества. Если это про управленческие навыки - стань ментором для новичка на проекте. Смена проекта станет ускорителем, когда уже есть база, а не заменителем развития. А вы как думаете? Что чаще становится триггером к смене работы?

⁣«Почему ушёл с прошлого места?» — вопрос, который валит даже уверенных middle'ов. Рассказываю, как отвечать без потери лица и позиции.

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

Плохие ответы — красные флаги:
* «Там был ужасный менеджмент, ничего не работало».
* «Коллеги некомпетентные, тесты писать не умели».
* «Платили мало, а требовали много».
Такие ответы говорят не о проблемах проекта, а о вас: «Я конфликтный», «Я не умею договариваться», «Я обвиняю других».

Как отвечать правильно: 3 рабочих приёма от реальных собеседований.

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

Второй — фокус на новых задачах для горизонтального роста. Пример: «Мне стало интересно попробовать себя в performance/security или автотесты на API, а на проекте таких задач не было. Я решил целенаправленно искать проект, где это смогу делать профессионально».

Третий — объективные факторы. Работает, если причина реальна: релокация или смена стека. Пример: «Проект перешёл на другую технологию — с Java на C#, и моя экспертиза в Python стала невостребованна. Мы договорились расстаться по соглашению сторон, чтобы я мог развиваться в том, что мне интересно».

Типичная ошибка: говорить только про деньги. Даже если ушли из-за зарплаты, не формулируйте «там платили мало». Свяжите деньги с ценностью: «Я приносил проекту X, но мой уровень вырос, а пересмотр в компании не был предусмотрен».

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

Попробуйте сейчас: напишите свой вариант ответа в комментарии — я скажу, прокатит или нет.

⁣Как я перестал писать длинные чек-листы и начал учить разработчиков самопроверке

Раньше я считал, что идеальный чек-лист - это подробный документ на 200 пунктов. Я тратил часы на расписывание каждого шага: "нажать кнопку", "проверить цвет", "убедиться, что текст не съехал". Разработчики смотрели на это и либо игнорировали, либо пробегали по диагонали. А потом - баги, конфликты, фразы вроде "это не моя зона ответственности".

Однажды я понял: длинные чек-листы не учат разработчика думать. Они учат механически выполнять команды. И вместо контроля качества получается имитация.

Я перестроил подход. Теперь перед сдачей фичи я даю разработчику не список проверок, а три вопроса.

Что именно ты изменил? - требует осознания кода. Какие сценарии могут сломаться? - развивает критическое мышление. Как ты это проверил? - вынуждает показать доказательства: скриншоты, логи, тесты.

Результат: баги стали находить раньше, а не в день релиза. Разработчики перестали сваливать ответственность - они начали проговаривать риски сами. А я экономлю часы на рутинной регрессии.

Что делать, если внедрить такой подход сложно? Начинайте с малого: предложите для одной фичи вместо чек-листа провести мозговой штурм. Покажите выгоду: меньше переделок - быстрее доставка. Не давите: если разработчик упорно просит чек-лист, дайте короткий (10-15 пунктов) и постепенно сокращайте.

Главная ошибка новичков: копировать мои вопросы дословно, не адаптируя под команду. Например, если разработчики не пишут юнит-тесты, вопрос "как ты это проверил" вызовет раздражение. Адаптируйте: "Покажи, что код работает в браузере".

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

Недостатки метода (честно): Нужна хорошая коммуникация. Если команда не готова к диалогу, сначала настройте контакт. Медленнее на старте: первые фичи могут потребовать больше обсуждений, чем проверка по чек-листу. Не подходит для регрессионных блоков, где нужно быстро убедиться, что ничего не сломалось.

Как я пришел к этому выводу: Я проработал 5 лет на проекте, где каждый релиз сопровождался 50-страничным чек-листом. Разработчики сдавали баги, тестировщики находили новые, сроки горели. Когда я предложил сократить чек-листы, мой лид сказал: "так исторически сложилось". Я ослушался - и через месяц команда сама попросила не возвращаться к старому подходу.

Совет для роста: начните с малого - замените чек-лист на 3 вопроса для одной фичи. Через месяц сравните количество багов от разработчиков и время на тестирование. Увидите разницу.

P.S. Не выкидывайте все чек-листы - они спасают при регрессии. Но для самой фичи научите разработчика самопроверке. Это даст больше, чем любой документ.

⁣Тупик скиллов: почему ты перестал расти на middle и как из него выйти без смены проектов

Знакомо? Ты уже уверенно тащишь задачи, но внутри - ощущение, что упёрся лбом в стену. Всё, что можно было выучить на этом проекте, вроде выучено. А свалить на другой проект или дёргаться с поиском не хочется - и так норм.

Почему так бывает? Частая штука: middle путает «делаю работу» с «расту». Когда ты перестаёшь подолгу смотреть на процессы, не задаёшь вопросы «а почему так?», а просто закрываешь тикеты - ты не развиваешься. Ты становишься надёжным исполнителем, но не специалистом, который двигается выше.

Вот что можно попробовать без смены проекта.

* Ищи слепые зоны. Посмотри на проект как на систему рисков, а не список багов. Например, часто ли падает тестовое окружение? Есть данные, которые уходят в прод без проверки? Обычно такие вещи висят в зоне «не моя забота». А senior’ы этим и отличаются - залезают туда, где не просили.

* Автоматизируй не ради фреймворка, а ради выгоды. Вместо «надо выучить новый инструмент» спроси: «Какая рутина сжирает 80% времени?». Может, написать скрипт для генерации тестовых данных или бота для напоминаний о регресс-прогоне.

* Учи других. Это звучит банально, но работает - собери чек-лист граблей для новичков, прочитай мини-воркшоп по тест-дизайну. Когда объясняешь, вылезают твои собственные дыры.

* Дневник решений. Просто записывай раз в день одну нестандартную ситуацию: что сломалось, как искал причину, что сделал бы иначе. Через месяц перечитай - удивишься, сколько нового уже накопилось.

* Не гадай. Вместо «вроде работает» используй модели. Добавили новый API - проверь не только его, но и обратную совместимость, нагрузку, безопасность. Интуиция хороша, но она же и тормозит.

Что обычно тормозит:
- надежда, что новый инструмент сам вытянет рост;
- замыкаться только на тестировании и не лезть в процессы команды;
- думать, что на скучном проекте негде расти - всегда есть куча серых зон.

Для меня middle - это не галка в резюме, а точка выбора. Если перестать искать проблемы только в багах, а начать смотреть на процессы, даже самый «серый» проект даст кучу поводов расти.

Волна сокращений в 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