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

Миф 2: «Автоматизация — это священный Грааль. Ручное тестирование скоро умрет» Достаточно холиварный вопрос. Многие считают, что ручное тестирование это некоторый промежуточный этап, рудимент. Реальность? Ручное тестирование не умрет в ближайшее время точно. Есть exploratory testing, usability, тестирование в условиях "а что если так сделать" и куча сценариев, которые автоматизировать — себе дороже. Кроме того, зачастую автоматизацией сложно вычислять ошибки бизнес-логики. Автоматизация — это мощный инструмент, а не религия. Она экономит время на регресс, но не заменяет мозги и любопытство.

Миф 3: «QA это скучно, там не надо программировать / чтобы быть хорошим QA надо очень хорошо уметь в код» Две крайности, оба не правы. По факту, золотая середина есть всегда. Базовое понимание кода (что такое цикл, условие, как посмотреть логи) — must-have. Писать сложные фреймворки с нуля — нужно далеко не на всех проектах. Часто хватает готовых решений и скриптов. Главное — понимать, как и зачем работает твой софт, даже если ты не автоматизатор, но тебе хочется что-то заскриптовать или улучшить, ты всегда найдешь, где это применить. Если это не твое, то разнообразной работы хватает за глаза, нет предела совершенству!

Миф 4: «QA тормозит релизы и его присутствие на проекте номинально» Вроде как это мнение уже атавизм, но из общения с коллегами местами такое встречается у менеджеров на проектах. 🤡 На самом деле, QA это про качество релизов, а не их отсутствие. Да, мы можем сказать "стоп", когда понимаем что продукт полетит к пользователям с багом или вообще поломает весь прод. Но наша задача найти и обозначить все риски, которые влечет за собой релиз и помочь команде выбрать safest path. Мы не против релизов. Мы за качественные релизы. И, как правило мы не можем наложить вето на поставку, а просто обозначаем риски и напоминаем об ответственности.

Бонус: «Не миф, а данность - во всем всегда виновато тестирование» Наверное, это самая неприятная и может быть опасная для новичков данность. Чаще всего за баги будут винить вас и психологически, особенно в начале карьерного пути это очень тяжело, так как ты много времени тратишь на свою работу, а тебя тычут носом за то, что ты упустил "очевидную" проблему. Но чаще всего очевидной она становится, тогда, когда уже "выстрелила". Раз уж речь о мифах, то на проекте это ощущается как бой с гидрой, тебе постоянно приходится отбиваться от нападок, "отрубая" одну голову проблем. На ее место после очередного релиза вырастает новая проблема и новые нападки, но со временем понимаешь, что это часть работы, начинаешь приводить более качественные доводы, лучше документировать результаты своей работы и стоять на своих решениях.

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

Есть что вам интересно было бы узнать о работе или может есть чем поделиться из своего опыта, было бы интересно почитать 👇👇👇