The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Традиционное понимание программного дефекта (или “бага”) заключается в том, что это нечто негативное, которого мы хотим избегать в наших проектах. Мы хотим, чтобы наши проекты были “без багов”. Наши клиенты просят нас разрабатывать программное обеспечение без ошибок. И мы, как пользователи, ожидаем, что программное обеспечение будет работать без багов.
Но давайте взглянем на баги с другой стороны. В XDSD мы говорим, что “баги приветствуются”. Это означает, что мы призываем все заинтересованные стороны находить баги и сообщать о них. Мы хотим, чтобы наша команда видела баги как нечто, что нам нужно в наших проектах. Почему?
Потому что мы понимаем, что есть две категории багов: видимые и скрытые. Чем больше багов становится видимыми, тем больше мы можем их исправить. Больше исправленных багов означает меньше причин для беспокойства наших пользователей. Обнаруживая баги, мы делаем их видимыми.
Это основная задача тестировщика программного обеспечения - сделать баги видимыми.
Очевидно, их видимость положительно влияет на качество продукта. Это потому, что мы можем исправить их до того, как пользователи начнут жаловаться.
Для того, чтобы мотивировать всех членов команды делать видимыми больше багов, мы платим за их обнаружение. В проектах XDSD мы платим 15 минут за каждый найденный баг (независимо от того, кто их находит и где).
Мы идем еще дальше. В XDSD мы планируем наличие скрытых ошибок в каждом проекте. Мы делаем это, опираясь на наш опыт с предыдущими проектами и экспертную оценку.
Допустим, мы начинаем разрабатывать веб-систему, которая похожа на ту, над которой мы работали в прошлом году. Мы знаем, что в предыдущем проекте наши пользователи и команда сообщили о 500 ошибках.
Логично предположить, что в новом проекте будет примерно такое же количество ошибок. Таким образом, наша задача - сделать эти 500 ошибок видимыми до того, как они попадут на производственную платформу и наши пользователи начнут на них жаловаться. Поэтому мы делаем это одной из целей проекта: “обнаружить 500 ошибок”.
Конечно, наша оценка может быть неверной. Тем не менее, у нас есть исторические данные по нескольким десяткам проектов, и во всех из них количество ошибок близко к 500. Таким образом, нахождение 500 ошибок в проекте обычно является реальностью - мы можем использовать это как цель.
Давайте попробуем определить ошибку (или программный дефект) недвусмысленным образом. Что-то может быть отмечено как ошибка и в дальнейшем оплачено тогда и только тогда:
это относится к уже реализованной функциональности
это можно исправить в разумные сроки
он не дублирует уже сообщенную ошибку
Воспроизводимость ошибки очень важна. Следовательно, ответственность за то, чтобы убедиться в воспроизводимости ошибки, лежит на том, кто ее сообщает. Пока не будет доказано, что ошибка может быть воспроизведена, это не является ошибкой, за которую можно получить вознаграждение.
Ошибка не является задачей; она должна относиться к существующей функциональности. Кроме того, должно быть объяснение того, как и когда существующая функциональность не работает должным образом.
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-01-09 at 18:11
