Контроль правильности работы RSS-каналов и механизмов кросспостинга.

это технический документ, который подробно описывает ошибку в работе программы, приложения или другого ПО. Его составляет тестировщик, чтобы разработчикам было понятно, что работает неправильно, насколько дефект критичен и что нужно исправить.

часть рабочего процесса. В них фиксируют наличие ошибки, назначают ответственного за исправление. Если сообщить об ошибке в рабочем чате, о ней скорее всего забудут. Каждый член команды подумает, что ошибку исправит другой, и в итоге она так и останется в коде.

Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.

Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.

Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.

Описать несоответствие ожидаемому результату. Чтобы сопоставить то, как работает программа сейчас, с ожидаемым результатом, начинающим специалистам лучше свериться с технической документацией и техническим заданием, где подробно описано, как все работает в идеале.

Попробуйте в паре предложений описать суть дефекта, а также когда он появляется и в чем выражен. Правильное и качественное описание также позволяет сразу понять проблему и приступить к ее исправлению. Пример плохого описания: Жму «Отправить сообщение», а в ответ тишина.

Пример хорошего описания: При нажатии на кнопку «Отправить сообщение» в заполненной форме обратной связи ничего не происходит. Аналогичное поведение, если форма не заполнена.

Заголовок ошибки (Title)

По сути это краткое описание найденной ошибки. Его задача — в понятной и простой форме передать смысл найденной ошибки.

Наиболее эффективным описанием считается описание, которое отвечает на три вопроса:

— Что произошло?

— Где появилась ошибка?

— Когда или при каких условиях найден дефект?

Также важно, чтобы заголовок был именно кратким, т.е. он должен содержать максимально полную и, в то же время, краткую информацию об ошибке.

Результат, который должен быть при выполнении шагов. В идеале, его можно найти в ТЗ (техническом задании). На практике, ТЗ бывает не всегда и ожидаемый результат определяется либо здравым смыслом, либо по аналогии.

Пример плохого ожидаемого результата: Что-то должно произойти.

Пример хорошего ожидаемого результата: Сообщение отправляется либо система сообщает о невозможности его отправки.

При необходимости тестировщики прикладывают скриншоты или видео воспроизведения ошибки. Также могут прикладывать логи выполнения программы. При соблюдении правил оформления баг-репортов, ваша работа станет более эффективной.

• Функциональные. Возникают, когда фактический результат работы не соответствует ожиданиям: не получается опубликовать комментарий на сайте, добавить товар в корзину или открыть страницу.

• Визуальные. Это случаи, когда приложение выглядит иначе, чем задумано: кнопка накладывается на текст, не отображаются картинки или текст выходит за пределы окна.

• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).

• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.

• Дефекты безопасности. Случаи, когда из-за ошибки в коде данные пользователей (почты, пароли, фото, информация о платежах) могут быть доступны третьим лицам.

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.

• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.

• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.

• Закрыт (Closed) — баг устранен и больше не воспроизводится.

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».

• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.

• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, может выглядеть следующим образом:

1. Заголовок ошибки

2. Описание ошибки

3. Начальные условия

4. Шаги воспроизведения

5. Ожидаемый результат

6. Фактический результат

7. Вложения

В случае, если есть специфичные действия или шаги воспроизведения достаточно объемные, то указываются начальные условия. Например:

1. Быть авторизованным в системе.

2. Находиться на главной странице.Пример плохих начальных условий: Находиться на сайте.

Пример хороших начальных условий:

1. Страница «Контакты»,

2. Платформа и устройство не имеют значения.

Шаги, при которых повторяется найденная ошибка. Например:

1. Нажать на кнопку “Войти”

2. Ввести “Имя пользователя” и “Пароль”

3. Нажать на кнопку “Ок”Убедитесь, что у вас нет лишних или ненужных шагов воспроизведения, которые будут отвлекать и тратить время команды.Пример плохих шагов:

1. Зайти на сайт,

2. Зайти на страницу обратной связи,

3. Поставить курсор в поле Имя,

4. Ввести имя,

5. Поставить курсор в поле e-mail,

6. Ввести действующий e-mail,

7. Навести курсор на Отправить сообщение,

8. Щелкнуть по Отправить сообщение.

Пример хороших шагов:

1. Заполнить поля формы обратной связи,

2. Нажать на копку «Отправить сообщение»

Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.

Пример плохого фактического результата: Ничего нет.

Пример хорошего фактического результата: Сообщение не отправляется, не появляется ошибка об отправке. После нажатия на кнопку ничего не происходит.