Одной из активностей в процессе моей работы является проведение собеседований, для подбора новых сотрудников в отдел. Периодически некоторых ребят я прошу составить отчёт о дефекте. Большая часть ребят, включая тех кто проработал в тестировании много лет, не умеют этого делать, а точнее делают это так как могут.
Обычно это похоже на записку общего содержания, а на вопрос «как разработчик понимает, что вы хотели сказать» получаем ответ «он у меня рядом сидит и может у меня спросить». Это возможно допустимо для организации, в которой вся команда из десятка человек, но это недопустимо для компании, в которой сотни разработчиков, специалистов по тестированию и специалистов другого профиля из IT.
В связи с вышеизложенным решил подготовить небольшую памятку для специалистов по тестированию, чтобы они знали на что примерно ориентироваться и куда стремиться. В компаниях, в которых я развиваю направления тестирования мы стараемся прививать практику правильного оформления отчётов о дефектах среди всех специалистов IT (не насильно, а постоянно рекомендуя и показывая на своём примере).
Придерживайтесь приведённых правил составления отчётов о дефектах, если хотите, чтобы разработчики решали оперативно дефекты озвученные вами. Если вы укажете минимум информации, то разработчик не сможет локализовать проблему и отклонит дефект, что повлечёт за собой дополнительную потерю времени на повторное заведение/открытие дефекта и общение с разработчиками. Для того чтобы разработчик мог приступить к исправлению дефекта он должен иметь всю необходимую информацию по дефекту, поэтому заявителю необходимо подробно описать все детали.
Тема или заголовок
Заголовок должен быть кратким и в то же время описывать суть проблемы. В заголовок не надо помещать описание дефекта. Описание будет в описании.
Описание дефекта
Описание должно содержать следующие данные:
- Предусловие. Описание действий, которые необходимо предварительно выполнить или учесть. Это блок, в котором поясняется вводная информация.
- Шаги воспроизведения. Описание последовательности действий, которые необходимо выполнить для воспроизведения дефекта.
- Фактический результат. Результат, который получил заявитель, проделав последовательность действий, которые описаны в блоке «Шаги воспроизведения».
- Ожидаемый результат. Что мы ожидаем получить согласно требованиям, после выполнения определённых действий.
- Дополнительная информация. Необязательный блок, в котором добавляется информация, которая считается важной, и которая поможет оперативно решить дефект.
- Вложение. Прикладываем к описанию снимки экранов и видео (если это возможно), служебные файлы и логи, которые могут быть использованы для воспроизведения и локализации дефекта. Видео полезно прикладывать, когда последовательность действий для воспроизведения дефекта очень длинная и целесообразней снять видео и приложить его, а не описывать всю последовательность на пару листов A4 (в этом случае фиксируются крупные шаги в описании). На скриншотах должно быть выделено место, на которое нужно обратить внимание. Если это скриншоты к шагам воспроизведения, то нужно выделить место куда следует нажать, куда что-то ввести и т.п., а также скриншот должен вставляться в шаге воспроизведения, к которому он относится, а не прикладываться в конце описания. Если скриншот относится к фактическому результату, то должно быть выделено место с самим дефектом.
Остальные атрибуты заполняются на усмотрение заявителя, если они не являются обязательными для заполнения, и согласно установленным в командах правилам. Это могут быть: приоритет, критичность, исполнитель, версия ПО и т.д.
Пример отчёта
Заголовок: Ошибка 404 при переходе в определённые разделы сайта
Предусловия
Открыта страница каталога товаров (URL).
Шаги воспроизведения
- В каталоге навести курсор мыши на категорию «Картриджи».
- В раскрывшемся подменю выбрать пункт «Новинки» (перейти в данный раздел).
- Изучить открывшуюся страницу.
Ожидаемый результат
Открыта страница с новинками раздела «Картриджи» содержащая товары и имеется возможность добавления товаров в корзину.
Фактический результат
Открылась страница (URL\404.html) сообщающая, что страница не найдена.
Дополнительно
Данная ошибка актуальна для разделов «Новинки», «Похожие товары».
Видео
404_ошибка.mp4
Данный вопрос можно изучить просмотрев наше видео:
Здравствуйте, Виктор Владимирович! Благодарю за полезные и интересные обучающие материалы и, конкретно по написанию чек-листов, тест-кейсов и отчета о дефектах. Надеюсь, мне эта информация поможет в написании документации по тестированию.
Знакомлюсь с Вашей замечательной книгой на сайте CoderBooks
«Тестирование программного обеспечения. Основы».Виктор Владимирович Захаров (2024)
Как написать инструкцию для маленького ПО. Совсем маленького. Никто не претендует на Инструкцию Майкрософт.
Если хотите научиться составлять инструкции, то начните с РД 50-34.698-90, ГОСТ 19 и ГОСТ 34.
Это конечно же сухая документация. Можете в яндекс.поиске набрать «Шаблон руководства пользователя по ГОСТ 34» и на первых позициях увидите то что вам нужно.
Как написать инструкцию к ПО, которое надо будет потом тестировать. Можно ли осветить такую тему?
Инструкции (руководства пользователя и администратора) пишут технические писатели и это большая тема с приведением ГОСТ, по которым создаются документы. Тут не статья нужна, а книга.