Оформление Баг (дефект) репорт . Инструментальные средства фиксирования багов.
"Т естирование программного продукта "
Оформление Баг (дефект) репорт . Инструментальные средства фиксирования багов.
Ход работы:
1. Изучить теоретические положения о тестировании ПО, 2 часа
2. Выполнить создание и тестирование программных модулей и оформить баг-репорт, 3 часа
3. Оформить данную часть работы в отчет по учебной практике, ответить на контрольные вопросы, 1 час
Документирование тестирования
Дефект (или баг) — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы. Например: невозможно сохранить данные после заполнения анкеты.
Ошибка — действие человека, которое может привести к неправильному результату. Например: ввод букв в поле для ввода даты (должны приниматься только цифры) с последующим сохранением данных.
Отказ (failure) — отклонение компонента или системы от ожидаемого результата, выполнения, эксплуатации. Например: при переходе на следующую страницу анкеты данные предыдущей страницы затираются.
Классификация багов:
Функциональные дефекты — в этом случае приложение функционально работает не так, как задумано. Например:
- не сохраняются изменения данных в профиле;
- не работает добавление комментария;
- не работает удаление товара из корзины;
- не работает поиск.
Визуальные дефекты — в этом случае приложение выглядит не так, как задумано.
- текст вылезает за границы поля;
- элемент управления сайтом наслаивается на нижестоящий элемент;
- не отображается картинка.
Логические дефекты — в этом случае приложение работает неправильно с точки зрения логики.
- можно поставить дату рождения «из будущего», а также несуществующие даты — 31 февраля, 32 декабря и т.п.;
- можно сделать заказ, не указав адрес доставки;
- логика поиска работает неправильно.
Дефекты контента
- орфографические и пунктуационные ошибки;
- картинка товара не соответствует карточке товара;
- конвертация валют идет по неправильному курсу (калькулятор считает правильно, но при программировании указан неверный курс).
Дефекты удобства использования — в этом случае приложение неудобно в использовании.
- отсутствие подсветки или уведомления об ошибке при некорректно заполненных полях формы;
- сброс всех данных при ошибке заполнения регистрационной формы;
- перегруженный интерфейс.
Дефекты безопасности — в этом случае могут быть затронуты пользовательские данные, есть риск падения системы и т.п.
- можно получить логин, пароль в результате использования SQL-инъекций;
- неограниченное время жизни сессии после авторизации.
Отчет об ошибке (Bug Report) — это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. Нельзя просто взять и задокументировать найденный дефект. Прежде всего, важно выполнить локализацию. Например, если дефект может затрагивать другие части системы, то это обязательно нужно отобразить в баг-репорте, предварительно проверив эту гипотезу. Также необходимо очень подробно описать все условия и шаги, чтобы разработчик смог этот баг проверить и в него поверить.
Как же искать ошибки в системе таким образом, чтобы разработчикам было предельно понятно, откуда эти дефекты взялись и как их исправлять? Следует придерживаться определенного плана действий.
1. Перепроверка дефекта
Нужно проверить себя еще раз: воспроизвести баг снова при тех же условиях. Если ошибка не повторилась при очередном тестировании, то нужно разобраться, точно ли были соблюдены все действия и шаги воспроизведения, приведшие к этому результату. Возможно, дефект появляется только при первоначальной загрузке системы (при первом использовании). Для того, чтобы более точно определить условия воспроизведения ошибки, необходимо эту ошибку локализовать.
2. Локализация дефекта
Чтобы локализовать баг, необходимо собрать максимальное количество информации о его воспроизведении:
Выявить причины возникновения дефекта. Например, не проходит восстановление пароля. Необходимо выявить, откуда приходит запрос на сервер в неверном формате — от backend либо frontend.
Проанализировать возможность влияния найденного дефекта на другие области. Например, в одной из форм, которую редко используют, возникает ошибка при нажатии на кнопку «Редактировать». Если в качестве временного варианта решения проблемы скрыть кнопку, это может повлиять на аналогичную форму в другом окне/вкладке, к которой пользователи обращаются чаще. Для качественного анализа необходимо знать, как работает приложение и какие зависимости могут быть между его частями.
Отклонение от ожидаемого результата. Нужно проверить, соответствует ли результат тестирования ожидаемому результату. Справиться с этой задачей помогает техническое задание (в частности, требования к продукту), где должна быть задокументирована информация о тестируемом ПО и его функционировании. Пропускать этот шаг при тестировании не следует: если специалист недостаточно опытен, не зная требований, он может ошибаться и неправильно понимать, что относится к багам, а что нет. Внимательное изучение документации позволяет избежать таких ошибок.
Исследовать окружение. Необходимо воспроизвести баг в разных операционных системах (iOS, Android, Windows и т.д.) и браузерах (Google Chrome, Mozilla, Internet Explorer и др.). При этом нужно проверить требования к продукту, чтобы выяснить, какие системы должны поддерживаться. Некоторые приложения работают только в определенных ОС или браузерах, поэтому проверять другие варианты не нужно.
Проверить на разных устройствах. Например, desktop-приложение предназначено для использования на компьютерах, поэтому зачастую нет необходимости тестировать его на мобильных устройствах. Для смартфонов в идеале должна быть разработана отдельная мобильная версия, которую, в свою очередь, нет смысла тестировать на компьютерах. Кроме того, есть web-приложения, которые могут работать и на компьютерах, и на мобильных устройствах, а тестировать их нужно на всех типах устройств. Для тестирования можно использовать эмулятор той или иной среды. Мобильную версию приложения нужно тестировать на нескольких устройствах с разной диагональю экрана. При этом можно руководствоваться требованиями к ПО, в которых должно быть указано, с какими устройствами это ПО совместимо.
Проверить в разных версиях ПО. Для того, чтобы не запутаться в реализованных задачах, в разработке используют версионность ПО. Иногда тот или иной баг воспроизводится в одной версии продукта, но не воспроизводится в другой. Этот атрибут обязательно необходимо указывать в баг-репорте, чтобы программист понимал, в какой ветке нужно искать проблему.
Проанализировать ресурсы системы. Возможно, дефект был найден при нехватке внутренней или оперативной памяти устройства. В таком случае баг может воспроизводиться на идентичных устройствах по-разному.
3. Фиксирование доказательств
Доказательства воспроизведения бага нужно фиксировать при помощи логов, скринов или записи экрана.
Логи (лог-файлы или журнал) — это файлы, содержащие системную информацию работы сервера или компьютера, в них хранят информацию об определенных действиях пользователя или программы. Опытному разработчику бывает достаточно посмотреть в логи, чтобы понять, в чем заключается ошибка. Обычно логи прикрепляют к баг-репорту в виде .txt-файла.
Live-логирование – это снятие системных логов в режиме реального времени. Для этого можно использовать следующие программы: Fiddler (все для тестирования трафика устройство-сервер), Visual Studio для Windows (гайд), iTools (все для тестирования IOS), Xcode для iOS, Android Debug Monitor, Android Studio для Android и др.
Скрин (снимок) экрана. При ошибках в интерфейсе снимок помогает быстрее разобраться в проблеме. Программ для снятия скриншотов очень много, каждый QA-специалист может использовать те, которые ему наиболее удобны: Jing, ShareX, Lightshot и др. (Quality Assurance engineer — это специалист по обеспечению качества, деятельность которого направлена на улучшение процесса разработки ПО, предотвращение дефектов и выявление ошибок в работе продукта)
Скринкаст (англ. screen – экран, broadcasting – трансляция) – это запись видеоизображения с экрана компьютера или другого цифрового устройства. Это один из самых эффективных способов поделиться тем, что происходит на экране монитора. Таким способом QA-специалисту легко наглядно показать ошибки в работе любого программного продукта. Сделать запись с экрана помогут незаменимые инструменты любого QA-специалиста: Snagit, Monosnap, Movavi Screen Capture, Jing, Reflector (позволяет вам отражать экран ваших мобильных устройств на экране вашего компьютера) и др.
Рекордер действий. Программные средства дают возможность воспроизвести все записанные движения мышки и действия, производимые на клавиатуре компьютера. Примеры программ – Advanced Key and Mouse Recorder для desktop-платформ.