Важно понимать, что не всякая найденная в системе проблема становится дефектом. Дефект является проблемой, которая либо нарушает функциональность системы в ее текущем понимании, либо не соответствует требованиям программы. Если программа работает нормально и соответствует всем требованиям, значит, у нее нет дефектов. Если программа не соответствует требованиям или не работает нормально, значит, можно говорить о том, что обнаружен дефект.
Например, рассмотрим компанию, создающую совершенно новую версию игры "крестики-нолики". Требования следующие:
1. Игровая доска должна быть три на три квадрата, всего девять смежных квадратов.
2. Первый игрок может поставить значок "Х" (крестик) в один любой квадрат.
3. Второй игрок может поставить значок "О" (нолик) в любой открытый (т. е. еще не занятый крестиками или ноликами) квадрат, тем самым завершая первый ход первого игрока.
4. Затем игроки должны по очереди размещать крестики и нолики (первый игрок, а затем соответственно второй игрок) в свободные квадраты. Игра идет либо до тех пор, пока не останется незаполненных квадратов, и при этом ни в одном ряду, колонке или диагонали не окажутся проставленые значки одного типа (в этом случае объявляется ничья); либо до тех пор, пока целый ряд, колонка или диагональ не окажутся заполнеными значками одного типа, и в этом случае выставлявший значки данного типа (крестик для первого игрока, нолик для второго) оказывается победителем, а его соперник проигравшим.
Это довольно понятные правила игры в крестики-нолики. Теперь давайте рассмотрим случай, когда первый игрок, который должен поставить значок "Х", начинает игру с "О". Это дефект, потому что это нарушает требование 2. Даже если продолжить игру (скажем, второй игрок поставит "Х"), все равно это дефект, потому что это нарушает требование.
Теперь давайте представим, что после бета-тестирования пользователь заявляет, будто игра нечестная, потому что она вынуждает игрока использовать "Х", а ему этот значок не нравится. Пользователь предлагает заменить "Х" на "W", потому что последняя является гораздо более красивой буквой. Это дефект или улучшение?
Это улучшение, потому что система соответствует всем требованиям и работает нормально. То, что пользователю не нравится значок, не является дефектом! И очень важно внести эти изменения — возможно, даже гораздо более важно, чем исправлять существующие дефекты. Улучшения не являются плохими, бесполезными или каким-то видом жалоб, они просто предполагают модификацию существующих требований системы.
Другим примером дефекта стало бы то, если бы игровое поле исчезло после того, как игрок поставил значок в центральный квадрат. Нет никаких особенных требований по этому поводу, но существуют изменяющиеся "неявные требования" к программам, такие как запрет на аварийное завершение (им нельзя вылетать) и зависание, они должны выводить на экране актуальное изображение, реагировать на воздействие и т. д. Эти неявные требования могут изменяться в зависимости от вида системы: например, видеоигра должна реагировать на воздействие в течение 99% всего времени, в то время как для программы прогноза погоды (в которой данные обновляются каждые 30 минут) "реагирование" заключается в том, чтобы просто вывести необходимую информацию.
Могут возникнуть разногласия по поводу того, является ли текущая проблема дефектом или улучшением. Основная причина этих разногласий — как раз эти неявные требования. Если персонаж видеоигры реагирует спустя три секунды после нажатия клавиши, можно сказать, что это довольно долго, даже если нет отдельных требований по производительности. Игроку не очень понравится каждый раз ждать по три секунды. Но какое ожидание после нажатия клавиши является приемлемым? Две секунды? Одна? Сто миллисекунд? Подобным образом можно задаться вопросом: допустимо ли для программы зависать и терять данные, если в системе закончилась память? Для единственного запущенного приложения в вашем телефоне — возможно. Это допустимо принять как достаточно редкое событие, причиняющее небольшой урон обычному пользователю, поэтому добавление обработчика подобной ситуации станет улучшением. Для компьютера-мейнфрейма, на котором запущено ПО, работающее с банковскими переводами, это определенно окажется дефектом. Предотвращение потери данных, даже если это не указано явно в требованиях, является крайне важным для этой области. Понимание тестируемой системы и области ее применения позволяет вам применять интуитивное тестирование ("seat of your pants" testing), т. е. тестирование поведения без формального описания, но основанное на вашем знании системы и области ее работы.
В некоторых случаях различие между дефектом и улучшением может оказаться очень значительным. Если ваша компания разрабатывает авиационный софт для нового истребителя, то очень вероятно, что у вас в скрупулезно рассматривается, что именно является улучшением, а что — дефектом. В таком случае имеются подготовленные требования, принимающие решения арбитры и люди, чьей работой является проектирование и разъяснение требований. Если компания подписала контракт для разработки программы и тщательно придерживается каждой буквы этого контракта, то ее сотрудники будут на всякое обращение заказчика отвечать, что это не дефект, а нечто не покрытое требованиями, а значит, улучшение.
В других случаях граница между дефектами и улучшениями оказывается размытой. Давайте предположим, что вы работаете на некий стартап, в котором недостаточно средств на разработку программного обеспечения, а единственным реальным требованием выступает негласное правило "делайте то, что хочет клиент, или мы банкроты". В этом случае, если клиент хочет что-то, значит, над этим нужно работать без каких-либо вопросов.
Хотя решение, над каким дефектом или улучшением следует работать, почти всегда находится в сфере управления проектом, а не обеспечения качества, взаимодействие с командой QA часто будет полезным. Тестирование ПО всегда позволяет определить влияние найденных дефектов, а также потенциальные риски исправления дефектов, внесения улучшений или же просто найти обходные пути. Обладание этим знанием поможет менеджерам проекта принимать осознанные решения о направлении развития продукта.