#тест_дизайн
Полезное из Contributors Guide to Writing a Good Bug и Bug Writing Guidelines (by Mozilla)
Уже писала тут, что Mozilla предлагает репортить баги, найденные в их продуктах.
Для этой цели у них есть Contributors Guide to Writing a Good Bug и Bug Writing Guidelines.
Многие из советов пригодятся и начинающим тестировщикам, и участвующим в бета-тестах, и тем, кто просто хочет отточить скилл написания баг-репортов.
Ниже привожу то, что мне показалось полезным (перевод вольный, с моими дополнениями).
1. Перед тем, как репортить баг, убедитесь, что он воспроизводится больше чем на одном устройстве с той же операционной системой, а также в новом профиле и в безопасном режиме (это не инкогнито, это режим, в котором отключены расширения и настройки)
2. При описании бага также стоит обратить внимание на:
* версию браузера,
* установленные расширения,
* воспроизводится ли баг повторно по описанным шагам,
* есть ли флоу для обхода проблемы
* работает ли функционал как запланировано (видимо, намекают на возможную проблему в бизнес-логике)
3. Настоятельно советуют: для каждого бага открываем отдельный баг-репорт
4. Если баг воспроизводится нестабильно, стоит это указать (тут понадобятся все известные детали того, как его воспроизвести)
5. Перепроверьте, актуальная ли у вас версия приложения (может баг уже пофиксили)
6. Summary (оно же заголовок/краткое описание):
* около 10 слов,
* должно быть коротким и отличать этот баг от остальных,
* должно описывать проблему, а не предлагаемое решение
7. Шаги воспроизведения - самая главная часть баг-репорта.
Важно указывать, каким конкретно способом вы взаимодействовали с приложением (например: не "открыть gmail в отдельном окне", а "кликнуть на такую-то иконку, зажать такие-то hot keys, вставить в адресную строку ссылку https://mail.google.com/")
8. В ожидаемом/фактическом результатах описываем наблюдения (открыто то-то, отображена такая-то ошибка), а не суждения типа "работает некорректно"/"не работает"
9. В зависимости от типа бага вероятнее всего потребуется предоставить доп.детали. Например, для проблем с использованием памяти в Firefox можно сгенерить репорт на вкладке about:memory. Там же (For specific types of bugs) есть советы на случай зависаний, чрезмерного использования CPU и проч.
10. Крайне желательно указать наиболее раннюю из версий, в которой воспроизводится баг.
11. Предлагается следующая структура репорта:
1) Summary (краткое описание/заголовок)
2) Component (часть приложения, в которой обнаружена проблема)
3) Version (наиболее ранняя из версий с багом)
4) Operating system
5) Description (в котором: overview, build id, additional builds and platforms)
6) Steps to reproduce
7) Actual results
8) Expected results
Там же рекомендуют статью Как эффективно сообщать об ошибках от Simon Tatham, в которой есть занятные примеры.
Полезное из Contributors Guide to Writing a Good Bug и Bug Writing Guidelines (by Mozilla)
Уже писала тут, что Mozilla предлагает репортить баги, найденные в их продуктах.
Для этой цели у них есть Contributors Guide to Writing a Good Bug и Bug Writing Guidelines.
Многие из советов пригодятся и начинающим тестировщикам, и участвующим в бета-тестах, и тем, кто просто хочет отточить скилл написания баг-репортов.
Ниже привожу то, что мне показалось полезным (перевод вольный, с моими дополнениями).
1. Перед тем, как репортить баг, убедитесь, что он воспроизводится больше чем на одном устройстве с той же операционной системой, а также в новом профиле и в безопасном режиме (это не инкогнито, это режим, в котором отключены расширения и настройки)
2. При описании бага также стоит обратить внимание на:
* версию браузера,
* установленные расширения,
* воспроизводится ли баг повторно по описанным шагам,
* есть ли флоу для обхода проблемы
* работает ли функционал как запланировано (видимо, намекают на возможную проблему в бизнес-логике)
3. Настоятельно советуют: для каждого бага открываем отдельный баг-репорт
4. Если баг воспроизводится нестабильно, стоит это указать (тут понадобятся все известные детали того, как его воспроизвести)
5. Перепроверьте, актуальная ли у вас версия приложения (может баг уже пофиксили)
6. Summary (оно же заголовок/краткое описание):
* около 10 слов,
* должно быть коротким и отличать этот баг от остальных,
* должно описывать проблему, а не предлагаемое решение
7. Шаги воспроизведения - самая главная часть баг-репорта.
Важно указывать, каким конкретно способом вы взаимодействовали с приложением (например: не "открыть gmail в отдельном окне", а "кликнуть на такую-то иконку, зажать такие-то hot keys, вставить в адресную строку ссылку https://mail.google.com/")
8. В ожидаемом/фактическом результатах описываем наблюдения (открыто то-то, отображена такая-то ошибка), а не суждения типа "работает некорректно"/"не работает"
9. В зависимости от типа бага вероятнее всего потребуется предоставить доп.детали. Например, для проблем с использованием памяти в Firefox можно сгенерить репорт на вкладке about:memory. Там же (For specific types of bugs) есть советы на случай зависаний, чрезмерного использования CPU и проч.
10. Крайне желательно указать наиболее раннюю из версий, в которой воспроизводится баг.
11. Предлагается следующая структура репорта:
1) Summary (краткое описание/заголовок)
2) Component (часть приложения, в которой обнаружена проблема)
3) Version (наиболее ранняя из версий с багом)
4) Operating system
5) Description (в котором: overview, build id, additional builds and platforms)
6) Steps to reproduce
7) Actual results
8) Expected results
Там же рекомендуют статью Как эффективно сообщать об ошибках от Simon Tatham, в которой есть занятные примеры.