В мире тестирования программного обеспечения обнаруженный дефект должен быть последовательно воспроизводимым, чтобы тестировщик мог убедительно сообщить о нем, разработчик – четко исправить, а команда контроля качества – уверенно завершить работу.
Однако иногда этот процесс сопряжен с рядом трудностей. В этой статье мы попытаемся осветить проблемы воспроизведения дефектов.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Прежде всего, поговорим о том, что такое “воспроизведение дефекта”.
Если определенная последовательность шагов привела тестировщика в точку, где наблюдается отклонение от ожидаемого поведения, то “шаги для воспроизведения” – это поле дефекта, которое содержит запись именно этой последовательности шагов. Если мы сталкиваемся с одной и той же проблемой каждый раз, когда выполняем эти шаги, то это называется воспроизводимым дефектом.
В дополнение к шагам по воспроизведению могут быть предоставлены дополнительные доказательства, такие как использованные данные, скриншоты или видеозаписи с экрана. Если эта информация окажется непоследовательной или неверной, ошибка может быть отклонена разработчиком и помечена как недействительная, без дальнейшего решения.
По этой причине “шаги по воспроизведению” очень важны. Ниже перечислены некоторые моменты, о которых следует помнить при написании этой части отчета о дефектах.
Как описать шаги воспроизведения:
- Будьте точны.
- Включите корректные данные, использованные во время тестирования, для удобства использования.
- Шаги должны быть расписаны строго по порядку.
- Упоминайте предварительные условия, если это применимо.
- Не пишите составные шаги. Например: Если сценарий требует от пользователя сохранить документ из Microsoft Word, то он должен быть написан так: “Откройте меню Файл и нажмите на кнопку Сохранить”.
- Всегда перепроверяйте свои действия для воспроизведения на новой системе, очищая все cookies и кэш-память.
- Убедитесь, что предложения лаконичные и однозначные.
Неправильно описанные шаги могут не только поставить под угрозу достоверность дефекта, но и повлечь за собой потерю времени на поиски разъяснений и ответов на вопросы, которые не были четко сформулированы.
Почему воспроизведение дефекта так важно?
Говоря техническим языком, если вы не можете воспроизвести ошибку, вы никогда не сможете ее исправить.
Ниже перечислены некоторые факторы, которые определяют, будет ли исправлен дефект:
- Полная детальная информация в баг-репорте.
- Может ли разработчик понять, что дефект возникает при определенных условиях?
- Имеются ли у разработчиков среда, инструменты и точные версии приложений, о дефекте которых сообщают тестировщики?
Что такое “невоспроизводимые” ошибки/дефекты?
Каждый тестировщик наверняка сталкивался с такими ситуациями:
- Ошибка возникала каждый раз на протяжении целого дня, но когда вы сообщили об этом дефекте разработчикам, выясняется, что он больше не воспроизводится.
- Наблюдение проблемы лишь периодически. Предположим, новый пользователь не может добавить товары в корзину только 6 раз из 10. Остальные 4 раза действие завершается так, как ожидалось.
- Проблема наблюдается только при перезапуске приложения.
Во всех этих случаях трудно определить точное состояние и правильно сообщить о нем. Расследование таких проблем/дефектов занимает много времени. Плавающие баги нельзя игнорировать, так как конечный пользователь/клиент может их заметить.
Как воспроизвести дефект?
Несколько действий, которые могут помочь:
- Очистите все кэш-память и файлы cookie во время выполнения сценария.
- Внимательно наблюдайте за каждым шагом.
- Иногда может быть полезен поиск похожих ошибок или паттернов. Будет легче идентифицировать сценарий, если понять закономерность.
- Фиксация каждого шага и других факторов (таких как тестовые данные, среда, системные настройки, скриншоты, журналы сервера и т.д.) будет хорошей практикой для облегчения воспроизведения сценария.
- Проведите несколько проверок, чтобы убедиться в наличии дефекта. Не доверяйте и не сообщайте в дальнейшем на основании одного единственного случая возникновения проблемы.
- Терпение при тестировании является ключевым фактором, так как этот процесс может занять много времени.
Кроме того:
- Даже когда вы проводите исследовательское тестирование, убедитесь, что вы знаете все конфигурации, а также настройки системы.
- Используйте творческий подход, чтобы исследовать приложение различными способами и попробовать необычные сценарии. Но даже в этом случае рекомендуется следовать логическим последовательностям, а не выполнять рандомные действия.
- После обнаружения проблемы всегда рекомендуется проверить ее на различных браузерах/комбинациях операционных систем, различных устройствах (поддерживаемых). Это поможет определить, является ли проблема системной или же она зависит от браузера или устройства.
- Будьте в курсе новых тенденций о различных типах проблем и их возникновении. Это поможет отличить системные, браузерные, продуктовые, внешние проблемы и т.д.
- Вместо того чтобы продолжать попытки воспроизвести возникший дефект, просто проанализируйте выполненные действия, это поможет найти решение.
- Иногда может оказаться полезным обсуждение с другими членами команды или менеджером.
- Помимо скриншотов и видео, можно поделиться своим экраном, чтобы объяснить разработчикам суть проблемы,
- Воспроизводите дефекты более одного раза, чтобы быть уверенным в их наличии. В таких случаях вы будете уверены в результатах тестирования и сможете ответить на вопросы разработчиков.
Заключение:
Из всего обсуждения можно сделать вывод, что очень важно “воспроизвести ошибку” с целью ее подтверждения и дальнейшего исправления. Если дефект не воспроизводится, то усилия по тестированию, затраченные на его поиск, анализ и сообщение о нем будут потрачены впустую.
Для понимания и демонстрации ошибки необходимо иметь подробные и правильно расписанные шаги по воспроизведению, состояние и среду, в которой был найден баг. Невоспроизводимый дефект реально исправить, но это может занять много времени и в целом оказаться очень сложной задачей. Еще одним наиболее важным фактором является правильная коммуникация с разработчиками, без которой действительная ошибка может быть признана недействительной.
Перевод статьи «How to Reproduce a Non-Reproducible Defect and Make Your Testing Effort Worth It».