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

Honelako gehiago

СРМ: ВХОДЯЩАЯ ЗАЯВКА Все входящие обращения попадают в СРМ-систему (в редких случаях, МОП самостоятельно создает карточку клиента в СРМ и заносит исходные данные о заявке), распределение заявок по МОП происходит согласно правилам (см. РАСПРЕДЕЛЕНИЕ ЗАЯВОК)

Артем Артем‑k egina

МЕГА Я

Student I Linguista‑k egina

Решение квадратных уравнений

Дядченко Денис‑k egina

Нейронная сеть

CM man‑k egina

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

Фактический результат (Actual Result)

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

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

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

Шаги воспроизведения (Steps To Reproduce)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начальные условия (Precondition)

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

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

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

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

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

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

Формирование заданий на исправление ошибок и повышение качества функционирования веб-страниц

7. Вложения

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

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

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

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

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

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

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

Жизненный цикл бага

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

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

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

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

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

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

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

Виды багов

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

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

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

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

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

Вложения (Attachments)

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

Ожидаемый результат (Expected Result)

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

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

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

баг по шаблону

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

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

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

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

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

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

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

Описание ошибки (Summary)

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

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

На что стоит обратить внимание при описании дефекта?

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

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

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

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

Баг-репорты

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

Баг-репорт

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