Программная ошибка – это изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программы и фактических.
Дефект – это ошибка или неточность, которая может быть (может и не быть) следствием сбоя в работе программы.
Дефект – это поведение программы, затрудняющее, или делающее невозможным достижение целей пользователя или удовлетворение интересов участников.
Дефект – это несоответствие требованиям или функциональным спецификациям.
Где можно найти баги:
- Требования
- Архитектурная документация
- Код
- Дизайн
Кто может обнаружить дефект:
- Программист
- Тестировщик
- Технический писатель
- Менеджер проекта
После обнаружения дефекта составляется отчет об ошибке. Отчет об ошибке – это технический документ, который составляется с целью:
- Предоставить информацию о проблеме, ее свойствах и последствиях.
- Классифицировать проблему по важности и скорости устранения.
- Помочь программистам обнаружить и устранить источник проблемы.
Отчет об ошибке (баг-репорт) – это один из основных результатов работы тестировшика.
Формула хорошего баг-репорта:
- Что мы сделали?
- Что получили?
- Что должны были получить?
- Обнаружен
- Назначен
- Исправлен
- Проверен
- Закрыт/открыт заново
Атрибуты отчета о дефекте:
- Идентификатор
- Дата
- Краткое описание (что, где и при каких условиях)
- Подробное описание (ожидаемый результат, фактический результат, ссылка на требование)
- Шаги воспроизведения (1. Перейти по ссылке www.omg.org 2. Ввести в поле «логин» значение «admin» 3. Ввести в поле «пароль» значение «abcd» 4. Кликнуть левой кнопкой мыши по кнопке войти. Баг: В левом верхнем углу вместо логотипа пустое место.)
- Воспроизводимость (указывается частота воспроизведения дефекта (всегда или иногда)) (пройти шаги воспроизведения минимум три раза).
- Важность (на сколько серьезна ошибка). Критическая - дефекты вызывают крах системы, либо повреждения данных. Высокая - серьезные ошибки, например потеря данных пользователя, падение некоторой части функциональности программы, падение браузера. Средняя – ошибки, затрагивающие функции приложения, но их можно обойти. Низкая – ошибки, не мешающие работе с приложением (опечатки).
- Срочность (как быстро необходимо исправить ошибку). Наивысшая присваивается ошибка, наличие которых делает невозможной дальнейшую работу над проектом. Высшая – нужно исправить в самое ближайшее время. Обычная – исправляется в порядке общей очереди. Низкая – если остается время.
- Симптом. Косметический дефект (опечатки, поврежденные картинки, не тот шрифт и т.д.). Повреждения/потеря данных. Проблема в документации. Некорректная операция. Проблема инсталляции. Ошибка локализации. Нереализованная функциональность. Низкая производительность. Крах системы. Неожиданное поведение. Недружественное поведение. Расхождение с требованием, под этот симптом попадает почти любая ошибка, но рекомендуется его писать только тогда, когда другие симптомы не подходят. Предложения по улучшению. Дополнительные атрибуты: возможность обойти баг, дополнительная информация и приложения (скриншот, видео).
Преимущества хорошего отчета об ошибках:
Хороший отчет об ошибках помогает сократить количество ошибок, отклоненных, или открытых заново. Ускорить устранение ошибки. Сократить стоимость исправления ошибки. Повысить репутацию тестировщика.
Баг-трейкинговые системы
Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.
Главный компонент такой системы — база данных, содержащая сведения об обнаруженных дефектах. Эти сведения могут включать в себя:
- номер (идентификатор) дефекта;
- короткое описание дефекта;
- кто сообщил о дефекте;
- дата и время, когда был обнаружен дефект;
- версия продукта, в которой обнаружен дефект;
- серьёзность (критичность) дефекта и приоритет решения[1];
- описание шагов для выявления дефекта (воспроизведения неправильного поведения программы);
- ожидаемый результат и фактический результат;
- кто ответственен за устранение дефекта;
- обсуждение возможных решений и их последствий;
- текущее состояние (статус) дефекта;
- версия продукта, в которой дефект исправлен.
Кроме того, развитые системы предоставляют возможность прикреплять файлы, помогающие описать проблему (например, дамп памяти или скриншот).
TRELLO – построена на основе доски, все функции находятся на одном экране. Слишком простая и не предназначена для больших команд. Задачи не имеют номера, что затрудняет контроль.
YouTrack – доска и диаграмма очень удобные, статусы и приоритеты можно выделять для наглядности.
JIRA AGILE – данную систему называют «№1». Она обладает наиболее широкой функциональностью среди других систем. Идеально подходит для крупных проектов с большим штатом тестировщиков, одновременно можно работать под различными операционными системами, создавать и вести схемы безопасности для каждого из проектов.
TARGETPROCESS – система очень дорогая. Доска удобная, размещение задач сделано по принципу trello, приспособлено к большим командам и большому количеству задач. Разработчики ставили цель сделать программу более простой и удобной в использовании, но количество функций урезали.
Процесс баг-трекинга
1. Создаваясь, сообщение, обязательно имеет ответственного
2. Каждому дефекту определяется приоритет важности, возможно добавить комментарий
3. Сообщениям устанавливаются статусы «в процессе», где указывается время начала и окончания работы.
