Перевод статьи «Test smart: how to solve dilemmas as QA?».
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 17.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
За годы работы в тестировании я не раз сталкивалась с дилеммами, которые влияют на динамику команды и итоговый результат продукта. И что самое интересное — эти сценарии встречались почти в каждой команде, где я работала. Именно такие паттерны чаще всего и мешают прийти к общей цели — создать по-настоящему прорывной продукт. В итоге идеальный продукт остаётся в голове владельца продукта, а команда выпускает совсем не то, о чём мечталось.
Некоторые команды ставят видимость работы выше реальной ценности, в спешке спринтов забывают о качестве и подходят к тестированию без чёткой стратегии. Знакомо? Добро пожаловать в реальность QA.
Видимость важнее ценности?
Во многих командах признание получают самые заметные участники, даже если их вклад объективно равен вкладу более сдержанных коллег. Типичный пример — ежедневный стендап: больше внимания достаётся тем, кто говорит больше.
В своей статье инженер Приянка Джайн приводит кейс с двумя коллегами, выполнявшими одинаковую задачу. Один активно публиковал статус-апдейты, инициировал обсуждения и демонстрировал вовлечённость. Второй молча реализовал решение и сдал качественный код. Оба достигли результата. Однако «образцовым командным игроком» признали лишь первого.
Во многих корпоративных культурах видимость путают с реальной ценностью. Если ты часто высказываешься, считается, что ты вносишь вклад. Если молчишь — будто бы нет. Поэтому экстравертов продвигают чаще, чем интровертов.
Если вы единственный QA в команде, вам необходимо быть заметным и активно высказываться. Иначе ваш вклад останется незамеченным, критичные баги проигнорируют, а качество продукта никого не будет волновать. Кто-то даже может задаться вопросом, чем вы вообще занимаетесь — ведь вы не пишете код.
Интровертам в таких условиях сложнее, однако в динамичной среде действует негласное правило: высокая коммуникационная активность усиливает влияние на процессы и повышает ценность специалиста в глазах команды.
Читайте также: Почему QA — это не просто тестирование в Agile проектах
Качество как ориентир. Или всё не так однозначно?
Принято считать, что качество — главный ориентир для продуктовой команды. Это то, к чему нужно стремиться и чем нужно управлять системно. Иначе готовы ли пользователи терпеть постоянные баги и несоответствия? Вряд ли кто-то мечтает увидеть, как продукт теряет аудиторию. Но всегда ли качество выступает тем самым «оракулом», который всё определяет?
Однажды у меня возник спор с разработчиком по поводу фичи. Он настаивал, что вместо выпадающего списка нужно сделать переключатель, потому что «так выглядит более модно». Я предложила визуализировать оба варианта в прототипе и протестировать их. В контексте нашего конкретного кейса дропдаун оказался более уместным решением.
После короткой совместной сессии тестирования разработчик согласился. Мы сэкономили время на возможной переделке. (Тогда ИИ ещё не был настолько развит. Сейчас я бы использовала AI-инструмент, чтобы быстро визуализировать оба варианта для команды и сократить время на дискуссию.) В итоге все остались довольны — и команда, и пользователи, которые оперативно получили доработанную версию продукта.
Мышление, ориентированное на качество, не возникает автоматически — его необходимо формировать. Одной из ключевых ролей QA является продвижение этой культуры внутри команды. Осознание приоритета качества приводит к тому, что команда начинает системно работать над предотвращением дефектов ещё до релиза. В конечном счёте, качество — это результат совместной работы всей команды, а не отдельной функции.
Нужна ли стратегия тестирования?
Как только в команде появляется QA-инженер, все ожидают, что проблемы с качеством решатся по щелчку пальцев. Однако в одиночку добиться значимых результатов практически невозможно.
До моего прихода в одну из команд — назовём её X — у них не было выстроенного процесса тестирования, и команда не чувствовала уверенности перед релизом. За день до запланированного выпуска начиналась привычная паника. Осознанного отношения к качеству ещё не было. Общий настрой звучал примерно так: «Тестирование? У нас на это нет времени. Ты же QA — вот и придумай что-нибудь!»
Всё это напоминало хаттифнатов из книги Туве Янссон — существ, которые бесконечно двигались к горизонту, не думая о последствиях. Только в нашем случае расплачивались качеством продукта.
За месяц нам удалось выйти на серьёзный разговор о текущем состоянии продукта и о том, как выпускать его более качественно. Команда сформировала QA-процесс, включающий разные уровни тестирования: End-to-End, API, Unit. В качестве основы мы использовали Agile Testing Quadrants — инструмент, впервые представленный Джанет Грегори и Лизой Криспин, который помог выбрать подходящие техники тестирования под задачи команды X. После этого качество продукта заметно выросло.
Прежде чем строить систему обеспечения качества, команде полезно провести мозговой штурм и определить, как именно должен работать QA-процесс. Важно заранее договориться, как измеряется качество: какие виды тестирования применяются и каким образом обеспечивается тестовое покрытие.
Важно обсудить текущее состояние тестирования и решить, как предотвращать баги, а не только исправлять их. После таких сессий появляется понятный QA-процесс — и релизы перестают быть стрессом.
Если вы регулярно сталкиваетесь с подобными дилеммами, стоит помнить, что каждая из них решаема. В условиях agile-разработки важно усиливать свою коммуникационную позицию и ясно обозначать риски. Если в интенсивных спринтах приоритет качества размывается, возвращайте его в повестку и вовлекайте команду в тестирование. Если же процессы выглядят несистемно, инициируйте обсуждение тестовой стратегии и сформируйте её совместно. В конечном итоге именно QA способен задать правильный вектор. 🙂