Всего один пропущенный баг может обойтись в миллионы – или, что еще хуже, подорвать доверие пользователей. Многие QA-инженеры, занимающиеся ручным или автоматизированным тестированием, неосознанно совершают ошибки, которые ставят под угрозу качество ПО и надежность тестов. Может быть, вы тоже допускаете эти ошибки?
1. Мы наняты, чтобы сообщать о багах, а не скрывать их
QA-инженеры часто сталкиваются с неожиданным поведением системы, которое не описано в User Story или критериях приемки. Если вы не уверены, всегда документируйте и сообщайте о проблеме. Четкий отчет поможет стейкхолдерам определить, является ли это дефектом, отсутствующим требованием или ожидаемым поведением.
Если проблема сложна или непонятна, не стесняйтесь назначить встречу с руководителем. Это может быть реальная ошибка, известная проблема или что-то, что запланировано к исправлению в будущем. Кто знает?
Лучше обратить на это внимание сейчас, чем потом услышать от менеджера вопрос, почему QA-специалист это не заметил.
2. Найдите креативные способы предоставления доказательств тестирования
Доказательства тестирования в баг-репортах предоставляют разработчикам конкретные данные для воспроизведения и устранения проблем. Особенно в сложных сценариях важно мыслить нестандартно и находить креативные способы представить эти доказательства. Это может значительно упростить понимание причины проблемы и обеспечить её эффективное устранение. Ниже приведены некоторые примеры:
При тестировании доступности QA-инженеру необходимо продемонстрировать, что порядок навигации по клавиатуре работает неправильно. Хотя такие инструменты как ARC Toolkit или Accessibility Insights могут автоматически визуализировать навигацию, иногда лучше сработает простой подход. Можно использовать встроенную экранную клавиатуру и инструмент для записи экрана, например Snagit, чтобы зафиксировать проблему в процессе.
QA должен предоставить доказательства того, что функциональность была протестирована. Он сделал множество скриншотов, но понял, что прикреплять отдельные .png-файлы к User Story неудобно — названия файлов часто неинформативны. В итоге он решил собрать все скриншоты в один Word-документ с понятными заголовками и описаниями — так владельцу продукта проще просматривать результаты.
В нагрузочном тестировании метрики не всегда стабильны — время отклика может отличаться даже при одинаковых скриптах, данных и окружении. Отличный способ сравнить показатели «до» и «после» — использовать графики. Они наглядно показывают разницу и тренды, упрощая анализ улучшений или откатов. Метрики можно отслеживать автоматически через Grafana и InfluxDB или вручную в Excel — оба подхода эффективны.
3. Всегда проверяйте сообщения о багах, даже если сами с ними не сталкивались
Когда кто-то упоминает о баге, в чате или личном сообщении, не игнорируйте это. Даже если вы сами не сталкивались с этой проблемой, важно провести расследование и убедиться, что это действительно проблема. Возможно, причина в неправильной настройке на стороне пользователя, но в любом случае поиск первопричины проблемы демонстрирует хорошее понимание тестируемой системы.
4. Не создавайте тест-кейсы, которые просто повторяют пункты из критериев приемки
Я видел на нескольких проектах, как QA просто копировали пункты из критериев приемки и использовали их как тест-кейсы. Критерии приемки — это отличная отправная точка для создания тест-кейсов, они задают основу для того, что необходимо протестировать. Однако прямое использование этих пунктов как тест-кейсов может иметь свои недостатки.
Недостаточная детализация: критерии приемки часто формулируются широко. Тест-кейсы же требуют конкретных шагов и данных. Прямое использование критериев может привести к созданию чересчур обобщённых тест-кейсов.
Недостаточная чёткость: тест-кейсы должны чётко отражать, что именно проверяется. Формулировки критериев приемки не всегда обеспечивают такую степень конкретики.
Упущенные крайние случаи: критерии приемки могут не охватывать все возможные сценарии, особенно крайние случаи и негативное тестирование.
Потеря детальных данных: тест-кейсы включают предусловия, постусловия, тестовые данные и ожидаемые результаты. Использование только названия из критериев приемки не позволяет полноценно зафиксировать всю эту важную информацию.
5. Избегайте поломки существующих тестов при внедрении новых
Поломка уже существующих тестов при добавлении новых — серьёзная проблема, указывающая на недостаточную внимательность инженера по автоматизации и нестабильность тест-сьюта. В больших командах сопровождение тест-сьюта может занимать до 50% времени QA-инженера, особенно если новые тесты реализованы некачественно и вызывают частые сбои и отладку.
Каждый новый тест должен аккуратно интегрироваться, не затрагивая существующую функциональность. Игнорирование этого правила делает автоматизацию ненадёжной и снижает доверие к тестам. Чтобы избежать таких проблем, всегда тщательно проверяйте изменения — например, запуском регрессионных тестов в CI/CD-пайплайне.
6. Важность хороших практик программирования в автоматизации
Инженеры по автоматизации должны относиться к своему коду с той же строгостью и тщательностью, как и разработчики ПО. Применяя принципы чистого кода, они делают скрипты автоматизации не только функциональными, но и масштабируемыми, понятными для всей команды. Хорошо структурированный фреймворк автоматизации улучшает взаимодействие в команде и повышает надежность тест-сьютов.
Относитесь к коду автоматизации тестирования как к полноценному продукту.
Здесь на помощь приходит ИИ. Инструменты вроде GitHub Copilot или Amazon CodeWhisperer могут существенно упростить работу. Ниже — полезные подсказки для таких ассистентов:
Улучши читаемость этого файла
Сделай код более понятным
Напиши комментарии к этому классу
Есть ли в этом коде признаки “code smell”?
Какие методы берут на себя слишком много задач?
Соответствует ли код принципу DRY?
7. Даже опытные инженеры по автоматизации должны документировать свою работу
Высокий уровень навыков в автоматизации — это важно, но отсутствие документации по реализованным решениям может привести к серьёзным проблемам. Без чётких описаний повторно используемые функции могут быть неправильно поняты, использованы не по назначению или вовсе проигнорированы командой.
Документация в общем доступе — будь то wiki, файл README или встроенные комментарии — помогает другим участникам команды дорабатывать, исправлять или оптимизировать скрипты при необходимости.
Обмен знаниями необходим, чтобы фреймворк автоматизации был устойчивым и эффективным — иначе возникает зависимость от одного специалиста.
Здесь также можно использовать инструменты ИИ, такие как GitHub Copilot, ChatGPT и другие.
8. Избегайте излишней сложности при создании повторно используемых методов
Создание повторно используемых методов — важная практика в автоматизации, но чрезмерная абстракция может привести к нечитаемому и слишком сложному коду.
Избыточная сложность в автоматизации тестирования затрудняет понимание, повторное использование или модификацию существующих скриптов, что в итоге снижает эффективность вместо того, чтобы её повышать.
Найти правильный баланс между повторным использованием и простотой — ключ к успеху. Стремитесь создавать методы, которые упрощают внедрение тестов, не добавляя ненужных уровней сложности.
Хорошо структурированный и читаемый код автоматизации улучшает сопровождение и ускоряет процесс отладки, гарантируя, что тестовые скрипты останутся масштабируемыми и доступными для всей команды.
9. Анализ сбоев в автотестах — зона ответственности QA-инженера
Для инженера по автоматизации регулярный просмотр отчётов и разбор причин падений тестов — неотъемлемая часть работы.
Фраза вроде «У меня всё работает» — не вариант: она показывает отсутствие ответственности и желания решать проблемы. Вместо этого важно брать инициативу, разбираться в первопричинах и совместно с командой устранять сбои.
Эффективная отладка не только демонстрирует профессионализм и техническую компетентность, но и помогает лучше понять систему. Каждый сбой — это возможность повысить устойчивость автотестов и извлечь урок.
Некоторые распространенные причины сбоев тестов в CI/CD:
Конфликты при использовании общих тестовых данных — Параллельный запуск или изменение одних и тех же данных разными тестами может вызывать несогласованность.
Некорректная очистка после тестов — Если тест не сбрасывает тестовые данные или состояние системы, это может привести к неожиданным сбоям в последующих тестах.
Изменения конфигурации — Некоторые тесты изменяют настройки системы, что может повлиять на последующие выполнения, если они не были восстановлены должным образом.
Таймауты и проблемы синхронизации — Сбои могут быть вызваны низкой производительностью среды, отсутствием ожиданий или нестабильной работой UI.
10. Будьте в курсе последних новинок в сфере QA
Сфера QA постоянно развивается и сообщества прекрасно справляются со сбором информации о новых техниках, инструментах и стратегиях. Оставайтесь в курсе событий, читая профессиональную литературу, блоги и рассылки.
Наконец, “Правило двух минут” — маленькая привычка для больших достижений в QA.
Правило двух минут напоминает, что если задача занимает меньше двух минут, её нужно выполнить немедленно. Вот несколько маленьких задач, которые могут привести к важным результатам:
Уточнение локатора
Документирование проблемы
Рефакторинг кода
Обновление документации
Запуск быстрого теста
Любая другая маленькая задача, которая приходит на ум
Выполняя такие задачи сразу, вы уменьшаете количество пунктов в своём списке дел.