Почему все так любят велосипеды

Давече обсуждали с Артёмом Ерошенко его новую версию Allure 3.0 задавались вопросом: зачем тестировщикам в 2024 году таблички с тестами, если есть инструменты, которые работают лучше? Но, как показывает практика, велосипеды — это не только о тестировании.

Есть много компаний, которые будто бы созданы на фабрике велосипедов. Для каждого процесса — своё уникальное, трёхколёсное и слегка ржавое. Такое ощущение, что их забанили в интернете, а за слово “Scrum” в офисе сжигают на костре.

Вот мой топ-5 самых популярных:

1. Свои инструменты разработки. “Jira? Нам это не подходит, у нас — ‘Реестр задач 2.0’ в Excel. CI/CD? Мы не гугл - у нас FTP.”, “API тестировать не нужно, клиенты его не видят.” В итоге вместо готовых инструментов — своё родное.

2. Уникальные роли. У вас не Project Manager, а “Координатор зон ответственности”. Вместо тестировщика — “Архитектор проверки” и “Менеджер багов”. Звучит красиво, но на деле никто не понимает, кто за что отвечает. Нанять нового сотрудника? Удачи.

3. Свое планирование. “Scrum нам не надо, а Kanban — это вообще для японцев.” Зато у нас есть “динамическая сессия по согласованию задач”. Это когда задачи записываются в “нашу джиру-табличку”, которая обожает терять строки. Приоритеты прыгают каждые два часа, дедлайны — понятие философское.

4. Сопротивление внешнему опыту. “Вы не понимают нашей уникальности.” Конечно, ведь в других местах никто не видит красоту джира-таблички, которая “держит” всю систему. В итоге нанимают людей, готовых учиться внутренней культуре, вместо того чтобы привносить что-то новое.

5. Оргструктура - я художник, я так вижу. “У нас всё идеально: команды разделены, каждый отвечает за своё.” Но любое движение требует трёх менеджеров, трёх встреч и кучи согласований. Простая задача превращается в интереснейший конкурс.
Что из этого выходит?

Это и есть “искажение уникальности” — удобный способ избегать изменений, маскируя хаос под творчество. Роббинс и Джадж в “Организационном поведении” называют это ловушкой, которая приводит к:

1. Сложностям в росте. Новичков невозможно адаптировать, потому что даже опытным людям сложно объяснить это творчество.
2. Зависимость от героев. Всё держится на 2-3 “Васях”. Ушёл Вася — и его велосипед сразу развалился, так как педали крутить некому.
3. Замедлению бизнеса. Вместо работы над продуктом компания бесконечно чинит свой “уникальный” подход.

Если ты думаешь: “У нас всё работает”, — поздравляю, пока что работает. Но как только начнётся масштабирование или кто-то из ключевых уйдёт, всё это превратится в хаос.

Трушная уникальность — это не велосипеды, а умение адаптировать лучшее под себя.

Все готовы к новогодним корпоративам?

Я на встрече самый глупый

«Я не понимаю весь код, который пишут разработчики, вдруг они подумают, что я дурачек.»

«Кажется, мне просто повезло, когда прошел интервью. Рано или поздно все поймут, что я тут случайно.»

«Как вообще тестировать архитектуру, если я даже не знаю, где она хорошая или плохая?»

Давай начнем с хорошей новости: ты не один. Синдром самозванца знаком почти каждому QA (и вообще профессионалу). И вот еще одна хорошая новость: ты можешь с этим справиться, и я знаю, как.

1. Сомневаешься? Это хорошо. Если у тебя есть синдром самозванца, это значит, что ты осознаешь пробелы в своих знаниях. Это не слабость — это сила. Знание своих слабых сторон открывает дверь к росту. Признай это и составь четкий план: что ты хочешь узнать? Каких навыков тебе не хватает?

2. Ты не обязан быть идеальным. Ты не машина, которая знает всё и сразу. Нормально не разбираться во всех архитектурах или фреймворках автоестов. Не знаешь что-то? Найди эксперта, который знает.

3. Ошибаться — это нормально. Да, ты можешь пропустить баг. Да, твой тест может упасть. Ошибки — это не провал, это часть процесса. Даже у Маска ракеты падают, у тебя тоже есть на это право.

Заключение

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

Так что не бойся своих сомнений — это нормально. Именно они делают тебя профессионалом.
У тебя всё получится, дружище. 🚀

Пишите в ChatGPT - «based on you know about me, draw a picture of my life»

У меня получилось вот так - нравится 🙂

Как писать в чат тестировщику, чтобы всех выбесить

Если ты нормальный QA, ты знаешь, что вся команда ждёт именно тебя. Разработчики, менеджеры — все живут в ожидании твоего финального вердикта: “работает или нет?”. Но давай честно: просто сообщать результат скучно. Настоящий мастер QA превращает мессенджеры в инструмент хаоса, где каждый твой месседж становится точкой напряжения. Расскажу, как это делать правильно.

1. Меншены — наше всё. @developer — это слишком просто. Активно пользуйся @here и @everyone, чтобы все знали, что твой баг — это самая важная проблема на планете.

2. Пиши с пассивной агрессией. Вместо скучного “баг воспроизводится” пиши: “Ну, как обычно, не работает”. С лёгкой ноткой разочарования в человечестве — это важно.

3. Кидай скриншоты с тостера. Если ты всё-таки решил прикрепить скриншот, убедись, что это фото монитора под углом, снятое на старый телефон. И не забудь обвести баг пальцем, который закрывает половину экрана.

4. Скидывай логи без комментариев. Не трать время на объяснения. Пусть команда сама разбирается в том, что значат эти 10 000 строк текста. Это их проблема, а не твоя.

5. Никакого контекста. Просто напиши: “кнопка не работает” — и пропади. Пусть они сами разберутся, какая кнопка, где она находится и что вообще происходит.

6. Капс — твой лучший друг. “ВСЁ ЛЕЖИТ!!!!!!!!!!!” — идеальное сообщение. Добавляй побольше восклицательных знаков и побольше слова “СРОЧНО”, чтобы команда почувствовала реальный драматизм ситуации.

7. Заводи баги прямо в чате. Зачем таск-трекеры, если можно просто написать: “это надо чинить” или “сделайте как в ТЗ”? Чёткие инструкции — для слабаков.

8. Разбивай сообщения. Если у тебя есть мысль из 10 слов, отправь каждое слово отдельным сообщением. Это поможет держать команду в тонусе и сделает чат настоящим полем битвы.

Потому что спокойная команда — это скучная команда. Великие продукты рождаются в состоянии лёгкой ярости, а ты — ключевой двигатель этого состояния. QA, который умеет писать в чат так, чтобы всех довести, — незаменимый инструмент в любом проекте. 😉

Супергерои только в фильмах

Мне не раз встречались незаменимые Васи, которые занимались всем кроме своей работы. Вася тебе и тестировщик, и архитектор, и продакт, и дизайнер, и просто душа компании. Если у команды проблемы, он будет впервых рядах: всё проверяет, за всех думает, подстраховывает. В команде где есть такой Вася всё начинает крутиться вокруг него. Он закрывает дыры, берёт на себя кучу задач, спасает релизы.

Что происходит с такой командой?

1. Команда похожа на беспомощных детей. Никто не принимает решений, все бегают к Вася.
2. В тестах срач. Хлам вместо структуры, автоматизация на нуле, релизы только через ручное тестирование. Разобраться может только Вася.
3. Команда не растет. Вместо процессов — культ Васи, который подменяет систему собой и блокирует рост.

И вот в команду приходит Head Даня. Он хочет сделать нормально: выкинуть хлам, сделать метрики, написать авто-тесты, построить процессы. И сделать так, чтобы работало всё без Васи и даже без Дани. Но Вася, конечно, не одобрит. Он искренне верит, что без него всё рухнет, ведь кто, если не он? Этот хаос, в котором он чувствует себя незаменимым, для него кажется необходимым, а любые изменения — угрозой его статусу супергероя. Ведь если всё станет прозрачно и системно, Васе придётся признать, что команда может работать без него, а ему наконец то заняться своей работой.

Что делать с Васей?

Если у вас в команде Вася, вот план:

1. Покажите Васе, что его подход больше не работает. Скажите, что продукту нужна самостоятельная команда, а его гиперопека тормозит развитие и команды и самого Васи. Сделайте ему свой индвидуальный план развития.
2. Начинайте менять систему без него. Стройте процессы, формируйте метрики, перерабатывайте тесты, внедряйте автоматизацию. Покажите, команде, что она может работать без Васи.
3. Если Вася не меняется — прощайтесь. Да, всем будет грустно. И вы словите немало хейта при этом решении. Но знаете что? Команда быстро забудет и задышит, а продукт начнёт развиваться быстрее.

Вывод

Вася — как старая футболка: уютно, удобно, но давно пора заменить. Да, поначалу команде будет не хватать его советов и шуток. Но уже через пару итераций работать станет легче, а продукт начнёт расти.

А Вася? Он будет скучать и, возможно, где-нибудь напишет, что “Даня всё разрушил”. Только команда уже научилась жить без “супергероя”. И ей теперь намного лучше.

Плюшкины в тестировании

Думаю каждый из нас читал Мертвые души и знаком с Плюшкиным. В куашке таких полно - тех, кто хранитель древних тестов, возрастом с компанию. Держатся за них “а вдруг пригодятся”, даже если никто никогда не откроет их после написания. Это превращаются в священный “черный ящик”, который держит “того самого Васю”. Потом Вася уходит, приходит Вова, выбрасывает всё и автоматизирует заново.

Почему это проблема? Потому что тесты, как и хлам у Плюшкина, не решают задач, а захламляют ваш Allure. План “писать тесты на всё” или “автоматизируем все баги” — это утопия, которая осталась в 2010-х. QA — это не про перепись продукта, а про минимизацию рисков.

Меня часто спрашивают: “Что делать с хламом в тестах и самими Плюшкиными? Как разрулить?” С удовольствием расскажу.

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

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

3. Если ты руководитель Плюшкина - помоги ему провести уборку. Задавай правильные вопросы: “Какой набор тестов нужен для этой фичи?” или “Что проверяет этот тест?”. Если ответа нет — отправляй всё в архив или на удаление. Тесты — это инструмент, а не музейная коллекция. Генерирует хлам дальше? Увольняй.

4. Если Плюшкин - это ты, поздравляю. Наслаждайся своей коллекцией. Генерируй по тыще тестов в спринт, никогда их не прогоняй и гордись, что в твоём царстве никто, кроме тебя, не может разобраться. Пусть коллеги ценят твои сакральные знания.

Как стать лучше 99% QA на рынке
За сотни собеседований, которые провел я видел много классных ребят, но слабых QA. Большинство их проблем, что их фокус на инструментах и задачах, а не на цели сделать лучше. Они пишут фреймворки, находят ошибки, формируют отчёты, но от крутых ребят ждут куда больше. Когда ты называешь себя QA - ты должен быть гарантом, что продукт качественный на каждом его этапе. Ты не исполняешь инструкции, а предотвращаяешь проблемы на всем цикле разработки от Discovery до Delivery.

Я выделаю 3 основные вещи, которые должен знать QA, чтобы стать крутым:

1. Ты не ищешь баги — ты делаешь так, чтобы их не было. Вникай в требования и задавай вопросы на этапе обсуждения. Предлагай тест-кейсы ещё до начала написания кода. Концентрируйся на устранении причин ошибок, а не только на их выявлении.

2. Ты автоматизируешь свою работу, а не тесты. Сфокусируйся на автоматизации рутинны: регресса, метрик, отчетов. Оптимизируй свои процессы, чтобы больше времени уделять качеству архитектуры и работы с пользователями. QA измеряется не количеством автотестов, а скоростью с которой поставляются новые (качественные) релизы.

3. Ты — лучший друг Продакта. Вместе с Продактом анализируйте риски, обсуждайте компромиссы. Поддерживай баланс между качеством и сроками, помогая бизнесу зарабатывать. Работай так, чтобы стать для Продакта союзником, а для бизнеса — важным активом.

Если сейчас ты подумал: «на кой мне это? я просто тесты пишу», — окей, пиши дальше и скоро придёт кто-то, кто делает всё это, и тебя заменят. Если же ты подумал: «Ну да, я и так это знал», — круто, ты на правильном пути. Только вот одно дело знать, другое — делать. Делай всегда.

Если хочешь стать действительно QA, а не Тестировщиком — начни использовать эти советы.