Файл: Отчет по лабораторной работе 9 Поиск и документирование дефектов.docx
Добавлен: 22.11.2023
Просмотров: 230
Скачиваний: 8
| № | Название дефекта | Важность | Алгоритм воспроизведения | Фактический результат | Ожидаемый результат | Приложение |
| 1 | Страница регистрации. Поле «Телефон». Не принимает русский номер телефона (санкции). | Average |
| После ввода номера телефона перебрасывает на ошибку «OpenAI's services are not available in your country.» | Завершение регистрации и переход в ЛК. | Рис.1 |
| 2 | Страница регистрации. Блокирует русский IP-адрес. | Average |
| После ввода пароля сайт автоматически перебрасывает на ошибку «OpenAI's services are not available in your country.» | Переход на ввод номера телефона. | Рис.1 |
| 3. | Главная страница openai.com. Страница входа в аккаунт. | Minor |
| После нажатия на кнопку перебрасывает на ошибку. | Переход на окно авторизации. | Рис.2 |
| 4. | chat.openai.com. Кнопка «+ New Chat» | Minor |
| Кнопка не работает, если не написать чат-боту какое-либо сообщение. | Кнопка создаёт новый чат в колонке. | Рис. 3 |
| 5. | chat.openai.com. Кнопка «Log Out» | Minor |
| После нажатия кнопки перекидывает на страницу с ошибкой. | Переход на страницу авторизации. | Рис.2 |
Рисунок 1Рисунок 2Рисунок 3Вывод: в ходе лабораторной работы нами было протестировано веб приложение, получены навыки описания дефектов.Контрольные вопросы:1. Что такое дефект?Любое отклонение изготовленной продукции от требований, установленных нормативно-технической документацией.2. Какие характеристики необходимо указать при описании дефекта?Описание дефекта включает следующие обязательные поля: 1. Headline – название дефекта. 2. Severity – степень критичности (важность дефекта). 3. Description – алгоритм воспроизведения.4. Result – фактический результат. 5. Expected result – ожидаемый результат. 6. Attachment – прикреплённые файлы (приложение).3. Что такое Headline/Summary в описании дефекта?Цель составления заголовка дефекта – предоставить краткую и в тоже время понятную информацию о том, где, что и в результате чего произошло. Характеристиками качественного заголовка являются краткость, информативность, точная идентификация проблемы.4. На какие три вопроса должен отвечать Headline/Summary?Заголовок дефекта должен отвечать на три вопроса: 1. Где? В каком месте интерфейса пользователя находится проблема. 2. Что? Что происходит или не происходит согласно спецификации или представлению о нормальной работе программного продукта. 3. Когда (при каких условиях)? В какой момент работы программы или по наступлению какого события проблема проявляется. 5. Что такое Severity в описании дефекта?Степень критичности (серьезности, важности) показывает степень ущерба, который наносится проекту существованием дефекта. 6. Какие существуют степени Severity? Приведите примеры.
Critical (критический). Пример - неправильный подсчет итоговой суммы при вводе промокода.
Major (значительный). Пример - не работает система e-mail нотификации.
Average (средней значимости). Пример - «уехал» текст за пределы окна, не работает сортировка.
Minor (незначительный). Введены необязательные для заполнения поля, которых нет в спецификации. Грамматические, пунктуационные ошибки..
Enhancement (предложение по улучшению).Добавить кнопку «Наверх» на длинных формах. Увеличить размер шрифта.
7. Что такое Description в описании дефекта?
Description – это четкий алгоритм, в котором приветствуются короткие, понятные фразы и нумерация.
8. Что такое Expected result в описании дефекта?
Expected result (ожидаемый результат). Цель написания Expected result – привести аргументы разработчикам, как именно должно работать приложение. В Expected result должно быть четкое обоснование, почему именно так должно работать приложение.
9. Зачем нужен Attachment при описании дефекта?
Attachment – это прикрепленный к дефекту файл, дополняющий описание: скриншот, файлы, необходимые для воспроизведения дефекта, логи программы, видео ошибки и т.д. Attachment является 6 вспомогательным средством передачи информации о проблеме. Для всех GUI дефектов attachment обязателен.
10. Какие существуют рекомендации по описанию дефектов?
1. Шаги воспроизведения, фактический и ожидаемый результаты должны быть подробно описаны.
2. Дефект должен быть понятно описан (с использованием общеупотребимой лексики, точных названий программных средств).
3. Необходимо давать ссылку на соответствующее требование, к нарушению которого приводит фактический результат работы программного средства.
4. Если существует какая-либо информация, которая поможет быстрее обнаружить или исправить дефект, необходимо сообщить эту информацию.
5. Окружение (ОС, браузер, настройки и т.п.), под которым возникла ошибка, должно быть четко указано. 6. Создавать дефект и описывать его необходимо сразу же, как только он был обнаружен. Откладывание «на потом» приводит к риску забыть о дефекте или и каких-либо деталях его воспроизведения. Несвоевременное создание дефекта не позволяет проектной команде реагировать на ее обнаружение в реальном времени. 7. После описания дефекта необходимо еще раз перечитать его: убедится, что все необходимые поля заполнены, и все написано верно.