Существует 2 шкалы для определения значимости дефекта, severity и priority, серьезность и приоритет. Если с определением приоритета все более-менее просто, то с определением серьезности нередко возникают ошибки.
Существует 5 градаций серьезности дефекта:
- S1 Блокирующий дефект. Его выбирают, когда не удается запустить программу или авторизоваться в системе.
- S2 Критический дефект. применяется в остальных случаях, когда с программой работать невозможно, она не выполняет основные функции.
Если нарушена бизнес-логика, то в этом случае так же необходимо помечать дефект как критический. Мы ведь не можем продавать в Интернет-магазине товары с нулевой суммой, работать в убыток.
Еще одна ситуация, когда дефект является критическим, это проблема безопасности. В этом случае также нельзя продолжать работать с программой, т.к. возможна кража личных данных клиентов, платежных реквизитов и т.д.
Если во время работы некоторой функциональности программы происходит "падение" сервера, то эта проблема будет также критической, т.к. не будет выполняться функциональность программы. - S3 Значительный дефект, не относящийся к основной функциональности, но вносящий серьезные помехи в работу программы. Может быть также ошибка в работе некоторых частей бизнес-логики: не удаляются товары из корзины, неправильно отображается количество товаров при верной сумме, отрицательные значения сумм при выполнении некоторых операций и т.д.
- S4 Незначительный дефект, не влияющий на работу основных функций программы, но мешающий пользователю, например, подсказка к кнопке при наведении курсора мыши частично перекрывает саму кнопку, из-за этого ее трудно нажать.
- S5 Тривиальный дефект, к которым относятся не только незначительные ошибки в работе пользовательского интерфейса, но и ошибки в работе сторонних сервисов и библиотек. Конечно, если вылетает программа из-за обновления стороннего сервиса, то для пользователя это неприятно и он обвинит в этом Вашу программу, хотя в ней исправлять нечего и для программиста эта ошибка будет тривиальной, к которой он может написать корректное сообщение об ошибке и предложить варианты ее устранения самим пользователем. Если программист напишет, куда обращаться, то пользователь все равно позвонит Вам и предстоит с ним объясняться по чужим ошибкам. Но это уже работа техподдержки и менеджмента, а не тестировщика и программиста.
Приоритет дефектов бывает высокий, средний и низкий, и зависит от срочности исправления. Срочными считаются ошибки, причиняющие значительный дискомфорт пользователям, и это не всегда критические ошибки. Серьезность и приоритет дефекта могут быть разными.
К среднему приоритету дефекта относятся ошибки, связанные с проблемами, нарушающими логику работы приложения, но не по критическому пути, т.е. основные функции работают нормально, а в остальных частях программы или кнопка не нажимается, или вообще отсутствует, или элементы окна частично перекрываются и т.д.
И наконец, низкий приоритет имеют дефекты, исправление которых необязательно, т.к. программа все равно будет работать, но при более низком показателе юзабилити, что может вызывать незначительный дискомфорт пользователей программы. Зачем же тогда заводить в систему трекинга такие дефекты? Если у программиста будет время, то он все равно исправит эти ошибки, т.к. забота о пользователях, как правило, в приоритете у сотрудников компании, и конкуренция на рынке программного обеспечения всегда высокая.
Спасибо, что дочитали до конца. Подпишитесь, чтобы не пропустить другие полезные материалы для подготовки к конкурсу на вакансию тестировщика и к самой работе.
