Ошибки оформления и формулировок:
⚜️ Плохие summary. Формально, эта проблема относится к оформлению, но фактически она куда опаснее: чтение отчёта о дефекте и осознание сути проблемы начинается именно с краткого описания. Суть отчёта о дефекте: ответить на вопросы «что?», «где?», «при каких условиях?».
⚜️ Идентичные краткие и подробные описания (summary и description). Да, изредка бывают настолько простые дефекты, что для них достаточно одного краткого описания (например, «опечатка в имени пункта главного меню “File” (сейчас “Fille”)»), но, если дефект связан с неким более-менее сложным поведением приложения, стоит продумать как минимум три способа описания проблемы:
⭕️ краткий для поля «краткое описание» (его лучше формулировать в самом конце размышлений);
⭕️ подробный для поля «подробное описание» (поясняющий и расширяющий информацию из «краткого описания»);
⭕️ ещё один краткий для последнего шага в шагах по воспроизведению дефекта.
🔱 Отсутствие в подробном описании явного указания фактического результата, ожидаемого результата или ссылки на требование, если они важны и их представляется возможным указать.
🔱 Игнорирование кавычек, приводящее к искажению смысла. Как Вы поймёте такое краткое описание, как «запись исчезает при наведении мыши»? Какая-то запись исчезает при наведении мыши? А вот и нет. Оказывается, «поле “Запись” исчезает при наведении мыши». Даже если не дописать слово «поле», кавычки подскажут, что имеется в виду имя собственное, т.е. название некоего элемента.
🔱 Общие проблемы с формулировками фраз на русском и английском языках.
🔱 Лишние пункты в шагах воспроизведения.
🔱 Записи экрана в виде «запись всего экрана целиком». Чаще всего нужно сделать запись какого-то конкретного окна приложения, а не всего экрана. Даже если важно захватить больше, чем одно окно, практически любой графический редактор позволяет отрезать ненужную часть картинки.
🔱 Записи экрана, на которых не отмечена проблема. Если обвести проблемную область красной линией, то это в разы повысит скорость и простоту понимания сути проблемы в большинстве случаев. Или включись записи курсора и его щелчков.
🔱 Откладывание написания отчёта «на потом». Стремление сначала найти побольше дефектов, а уже потом их описывать приводит к тому, что какие-то важные детали (а иногда и сами дефекты!) забываются. Если «на потом» измеряется не минутами, а часами или даже днями, то проектная команда не получает важную информацию вовремя. Вывод простой: описывайте дефект сразу же, как только обнаружили его.
🔱 Пунктуационные, орфографические, синтаксические и им подобные ошибки.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте
⚜️ Плохие summary. Формально, эта проблема относится к оформлению, но фактически она куда опаснее: чтение отчёта о дефекте и осознание сути проблемы начинается именно с краткого описания. Суть отчёта о дефекте: ответить на вопросы «что?», «где?», «при каких условиях?».
⚜️ Идентичные краткие и подробные описания (summary и description). Да, изредка бывают настолько простые дефекты, что для них достаточно одного краткого описания (например, «опечатка в имени пункта главного меню “File” (сейчас “Fille”)»), но, если дефект связан с неким более-менее сложным поведением приложения, стоит продумать как минимум три способа описания проблемы:
⭕️ краткий для поля «краткое описание» (его лучше формулировать в самом конце размышлений);
⭕️ подробный для поля «подробное описание» (поясняющий и расширяющий информацию из «краткого описания»);
⭕️ ещё один краткий для последнего шага в шагах по воспроизведению дефекта.
🔱 Отсутствие в подробном описании явного указания фактического результата, ожидаемого результата или ссылки на требование, если они важны и их представляется возможным указать.
🔱 Игнорирование кавычек, приводящее к искажению смысла. Как Вы поймёте такое краткое описание, как «запись исчезает при наведении мыши»? Какая-то запись исчезает при наведении мыши? А вот и нет. Оказывается, «поле “Запись” исчезает при наведении мыши». Даже если не дописать слово «поле», кавычки подскажут, что имеется в виду имя собственное, т.е. название некоего элемента.
🔱 Общие проблемы с формулировками фраз на русском и английском языках.
🔱 Лишние пункты в шагах воспроизведения.
🔱 Записи экрана в виде «запись всего экрана целиком». Чаще всего нужно сделать запись какого-то конкретного окна приложения, а не всего экрана. Даже если важно захватить больше, чем одно окно, практически любой графический редактор позволяет отрезать ненужную часть картинки.
🔱 Записи экрана, на которых не отмечена проблема. Если обвести проблемную область красной линией, то это в разы повысит скорость и простоту понимания сути проблемы в большинстве случаев. Или включись записи курсора и его щелчков.
🔱 Откладывание написания отчёта «на потом». Стремление сначала найти побольше дефектов, а уже потом их описывать приводит к тому, что какие-то важные детали (а иногда и сами дефекты!) забываются. Если «на потом» измеряется не минутами, а часами или даже днями, то проектная команда не получает важную информацию вовремя. Вывод простой: описывайте дефект сразу же, как только обнаружили его.
🔱 Пунктуационные, орфографические, синтаксические и им подобные ошибки.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте