Привет, меня зовут Тимур. Уже более 10 лет я занимаюсь тестированием ПО. Начинал свой карьерный путь с 2013 года стажером тестирования ЭДО, затем занимался автотестированием, совмещая с наставничеством в юридически значимом документообороте, а последние три года курирую процессы QA в ИТ-компании TAGES. За время своей работы в айти у меня накопилось множество мыслей об отношениях между Dev и QA. Кажется, что эта тема для многих непростая, поэтому решил порассуждать о ней в формате небольшой статьи.
Полагаю, заголовок может показаться несколько провокационным, но он вполне отражает суть того, о чем пойдет речь. Представьте себе отношения, когда один человек всегда предлагает идеи, а другой только соглашается, но не проявляет инициативу или не вносит свой вклад. В таком формате многое теряется, поскольку взаимодействие ограничивается минимальными формами общения.
Это легко сравнить с ситуацией, когда QA и DEV взаимодействуют, но не эффективно, потому что не занимаются совместным улучшением и развитием процесса. А иногда, наоборот, отношения этих двух направлений выстраиваются гармонично: все понимают свои задачи и стремятся достичь общего результата — качественного итогового продукта.
Прошу не гиперболизировать приведенные ниже советы и рекомендации. Инициативность и самостоятельность — это лишь первая ступень к личному и профессиональному росту. Возможно, часть из приведенных идей вам уже знакома, например, о важности поддержки связи между разработчиками и QA-инженерами, или о том, что QA-инженер может помочь в поиске и воспроизведении ошибок. Однако не всегда эти практики применяются систематически.
В этой статье мы рассмотрим, как QA и разработка могут помочь друг другу, поговорим о налаживании совместной работы, а также развеем главные мифы вокруг QA, в которые верит часть разработчиков.
Проблема: «собственные ограничения» в своей зоне ответственности
Каждая роль в процессе разработки ПО имеет свою зону ответственности. Но нередко эти зоны пересекаются, и в такие моменты важно приложить общие усилия, если вы не хотите столкнуться с недопониманием в команде.
Например, разработчик может внедрить новую фичу, но без должного тестирования или информации о ее возможных рисках, это может привести к ошибкам на проде. Устранить большинство негативных последствий в таких случаях можно с помощью активного взаимодействия: раскрывайте или запрашивайте максимально полный контекст, уточняйте детали, проверяйте решения и заранее позаботьтесь о потенциальных рисках. Главная цель — понимание того, чем разработчик может быть полезен QA, и наоборот.
Все мы знаем, чем занимается QA-инженер: его основная задача — это помощь разработчику и команде в повседневных задачах в рамках релиза. Однако нередко QA-инженер вовлечен и в процессы, выходящие за рамки его ответственности. Например, он помогает в анализе архитектуры, консультирует по вопросам функционала или даже участвует в создании документации. В таких случаях он становится не просто исполнителем, а активным участником разработки. Как следствие — это приводит к перегрузке и затруднениям в разделении зон ответственности.
Разработчики же, в свою очередь, тоже вынуждены выходить за пределы своей роли, особенно в сложных проектах. Например, они могут помочь в создании инструментов для тестирования, улучшении логирования или даже в предоставлении данных для воспроизведения ошибок.
Но не стоит воспринимать все это как нечто плохое. Такая синергия очень полезна, и для создания по-настоящему качественного продукта она должна проявляться на всех этапах проекта.
Итак, давайте подробнее разберемся, как обе стороны могут активно помогать друг другу, какие инструменты и практики могут улучшить их взаимодействие и как избежать проблем, которые часто возникают из-за нехватки коммуникации.
Чем QA может помочь разработчикам
1. Dataset для воспроизведения ошибок
QA-инженер зачастую помогает разработчику подобрать данные для воспроизведения ошибок. Это может быть как простая задача, так и более сложная, где необходимо найти причину, подобрать нужные данные или воспроизвести ошибки, которые сложно локализовать.
2. Детали для воспроизведения
QA-инженер предоставляет пошаговые инструкции для воспроизведения ошибки, делая акцент на важных деталях: версия ПО, окружение, шаги, которые были предприняты. Это помогает ускорить процесс поиска и устранения проблем.
3. Логи и скриншоты
Важный инструмент для быстрого понимания проблемы — это логи и скриншоты. Они позволяют разработчикам сразу увидеть, что пошло не так.
4. Живое общение и пример воспроизведения
Бывают случаи, когда описания ошибки и шагов для воспроизведения недостаточно. В таких ситуациях помогает живое общение, демонстрация проблемы «в реальном времени».
5. Запросы на проверку
Иногда необходимо просто уточнить, как работает определенная часть системы, перепроверить или выяснить, изменилось ли что-то после последнего релиза.
6. Демо проекта
QA-инженер, благодаря своему глубокому знанию системы, может создать демо-версию продукта для обучения новых сотрудников или для ознакомления с проектом.
7. Онбординг новых сотрудников
Для новых членов команды погружение в проект становится значительно проще, когда QA помогает с настройкой окружения и объясняет детали работы. Обычно именно он знает проект лучше всех, поэтому такой онбординг может быть наиболее эффективным.
8. Запросы от других ролей
QA-инженер также может помочь не только разработчикам, но и аналитикам или дизайнерам, обеспечивая точность информации и помощь при тестировании.
Все это лишь основные моменты, в которых QA может оказать помощь разработчику и команде. На практике их гораздо больше, и сами они существенно глубже, чем могут показаться.
Чем разработчик может помочь QA
Представьте, что вы QA. Как бы вы тестировали и что вам кажется наиболее сложной и объемной задачей?
1. Внедрение пасхалок
Речь, конечно же, не о потаенных местах в играх для самых любопытных геймеров, а о создании скрытых функций в приложении — секретных командах. Они позволяют проверить сложные нестандартные сценарии, которые требуют дополнительных усилий для тестирования.
2. Инструменты для тестирования
Разработчик может предоставить утилиты и инструменты для тестирования, которые помогут QA-инженеру быстрее находить ошибки и понимать, как работает система. Например, это могут быть средства для мониторинга, генерации тестовых данных или подсказок.
3. Конфигурация окружения
Чтобы например провести нагрузочное или «поломать» приложение, можно создать дополнительные окружения, которые смогут влиять на функциональность, но не будут использоваться в прод-контуре. Это поможет упростить обеспечение качества, например, при проверке работы с датами или интеграциями.
4. Скрипты для тестирования
Написание скриптов, которые генерируют тестовые данные или выполняют определенные операции, может значительно ускорить процесс тестирования за счет подготовленных скрипов, особенно в случае трудных логик, ведь подготовка этих скриптов тоже занимает время — если они уже есть, то зачем их делать дважды?
5. Self-testing: протестируй сам
Простое, но действенное правило — протестируй приложение перед тем, как отдать его в тестирование. Это снизит количество багов на ранней стадии и сэкономит время всей команды.
6. Как тестировать (How to test)
Разработчики могут заранее предоставить информацию о том, какие части приложения требуют особого внимания при тестировании. Это поможет QA-инженеру быстрее выявить самые критичные баги.
7. Передача знаний QA
Если какая-то часть функционала или настройка системы может быть сложной для QA, будет полезно провести обучение или инструктаж, чтобы минимизировать запросы на помощь в будущем.
8. Логи
Детальные и легко читаемые логи — это золото для QA-инженеров. Чем больше информации, тем проще найти источник проблемы и устранить ее.
9. Понимание логики на уровне кода
Важно, чтобы разработчики объясняли логику изменений в коде. Это помогает QA лучше понять, какие изменения были внесены и как они могут повлиять на функциональность.
10. Локаторы для автоматизации
Разработчики могут добавить в код тестовые id или атрибуты для элементов интерфейса, что упрощает автоматизацию тестирования — можно будет обращаться к элементу сразу по id.
Например, <button data-test=«login-button»>Войти</button>..
Таким образом, обе роли отлично дополняют друг друга и тем самым способствуют созданию более качественного продукта. Но не будем на этом останавливаться, пойдем дальше и рассмотрим еще одну интересную практику, которая заслуживает того, чтобы быть не отдельным пунктом в приведенных списках, а целым разделом.
Shift Left Testing: лучший друг для QA и Dev
Для налаживания взаимодействия тестировщиков и разработчиков существует еще один эффективный подход — Shift Left Testing (SLT). Это концепция, предполагающая тесное взаимодействие между QA и DEV на ранних этапах разработки.
Что такое Shift Left Testing и зачем он нужен
Shift Left Testing подразумевает, что тестирование начинается еще на самых ранних стадиях жизненного цикла разработки — этапе планирования и проектирования. Вместо того чтобы ждать завершения разработки и приступать к тестированию в конце, как это обычно бывает, команды тестировщиков подключаются к процессу с самого начала.
В отличии от традиционной модели, Shift Left акцентирует внимание на качестве на начальных этапах разработки
Такой подход дает массу преимуществ:
1. Раннее выявление дефектов
Ошибки, найденные на ранних стадиях разработки, исправляются значительно быстрее и дешевле, чем те, которые обнаруживаются в конце разработки или после релиза. При реализации функционала одна ошибка может повлечь цепочку других новых проблем, поэтому исправление на ранних стадиях разработки выгоднее.
2. Снижение рисков и затрат
Уменьшается вероятность возникновения ошибок на стадиях приемочного тестирования и неправильной реализации функционала за счет применения SLT. В свою очередь, это помогает экономить ресурсы команды для исправления ошибок.
3. Тестировщик как активный участник
QA-инженер не только «ищет» ошибки, но и активно помогает разработчикам на всех этапах, начиная с проектирования, создания мока, написания автотестов и проверки реальной реализации.
4. Подготовка и планирование
QA заранее изучают и анализируют тот функционал, который планируется к реализации. Это позволяет им создавать моки, обновлять тест-кейсы и быть готовыми к возможным проблемам.
Внедрение Shift Left Testing помогает сделать взаимодействие между QA и Dev более слаженным и менее конфликтным за счет раннего взаимодействия, что положительно влияет на качество конечного продукта и ускоряет весь процесс разработки.
Другие заблуждения, с которыми сталкиваются все участники команды
Невозможно избежать недоразумений, особенно когда речь идет о таких сложных и многозадачных процессах, как разработка ПО. Часто на проекте возникают заблуждения, способные затруднить работу. Например, неправильные ожидания от работы QA или Dev могут привести к конфликтам или, наоборот, к недостаточной инициативности с обеих сторон. Чтобы избежать таких ловушек, важно развеять несколько мифов, с которыми сталкиваются все участники команды. Давайте рассмотрим самые распространенные из них и поймем, как можно улучшить взаимодействие и повысить эффективность работы.
1. «Отчеты автотестов только для QA»
На самом деле отчеты необходимы всей команде: разработчикам для проверки своего кода, менеджерам — для оценки стабильности сборки, а PM — для понимания статуса релиза.
2. «Инциденты заводит только QA»
Это заблуждение. На самом деле инциденты может заводить любой участник команды, если это поможет сэкономить время и ускорить поиск решения.
3. «QA допустил ошибку на проде»
Ошибка на продакшн-сервере — это общая проблема всей команды. Важно анализировать причину и работать над предотвращением таких ситуаций в будущем.
4. «QA всегда прав»
Не забывайте, что QA тоже люди, и иногда мы можем что-то упустить. Не стесняйтесь давать нам обратную связь и корректировать наши ошибки.
Заключение
Подводя итог, я бы хотел подчеркнуть, что успешное сотрудничество между Dev и QA — это ключ к качественному результату. Слаженная работа этих двух ролей помогает избежать множества проблем, ускоряет процесс разработки и повышает общий уровень продукта. QA — это не инквизитор, а партнер. Воспринимайте его как друга, а не как жесткого критика.
Автор: Тимур Юсупов (QA-инженер TAGES)