Жизненный цикл дефекта.

После обнаружения дефекта тестировщик (или тот, кто нашел дефект) должен доложить об этом. Доклад может иметь различные значения в зависимости от организации и серьезности дефекта. По сути, это означает, что особенности дефекта должны быть отмечены там, где он будет рассматриваться в будущем заинтересованными лицами проекта — другими тестировщиками, разработчиками, менеджментом и т. д. В большинстве случаев у команд имеются программы по отслеживанию дефектов, но доклад о дефекте может быть простым, как пометка ошибки при помощи старомодной ручки и бумаги.
При тестировании программного обеспечения по множеству причин важно отслеживать всю информацию, которая практически необходима. Во-первых, чем больше информации доступно, тем более вероятно, что этот дефект удастся воспроизвести. Представьте, что у вас отказывает система только при установке определенных переменных среды, но вы не уточняете их в докладе о дефекте. Когда разработчик, которому поручено заниматься исправлением дефекта, начнет работу, он может пометить его комментарием "у меня всё работает", поскольку система работала, как и задумано, вне зависимости от того, что делал разработчик. Без знания этих переменных среды воспроизвести дефект не удастся.
С другой стороны, можно зайти слишком далеко. Обычно нет необходимости описывать каждый запущенный в системе процесс в случае обнаружения опечатки. Степень подробности описания дефекта будет зависеть от самого дефекта и области, в которой вы работаете. Однако существуют определенные данные, которые окажутся полезными во многих случаях. В следующем разделе будет описан шаблон дефекта для того, чтобы эти данные не забывались. Напоминая регистрирующему дефект о том, что именно нужно включить в сообщение, позволит ему не пропустить важные шаги или информацию и тем самым минимизировать чрезмерную коммуникацию по данному дефекту в процессе его исправления. Чек-листы (от англ. checklist — котрольный список) и подобные шаблоны являются очень важными мощными инструментами в ситуациях, где цена ошибки в работе крайне высока.
Когда получен доклад о дефекте, его жизнь только начинается. Подобно тому как в разработке программного обеспечения существует "жизненный цикл ПО" — начинающийся с требований, дизайна и т. д., продолжающийся эксплуатацией и поддержкой и заканчивающийся "концом жизни" программы, — дефекты тоже имеют свой жизненный цикл. Он выглядит следующим образом:
1. Открытие.
2. Доклад.
3. Сортировка/назначение.
4. Исправление.
5. Верификация.
Когда тестировщик или другой пользователь впервые сталкивается с дефектом и распознает его, это стадия "Открытие". В некоторых случаях после этого может ничего не произойти — пользователь проигнорирует дефект или решит, что он не стоит дальнейшего изучения. Однако для профессионального тестировщика такой путь неприемлем — работа тестировщика заключается в определении качества программного обеспечения, и это включает в себя обнаружение дефектов и сообщение о них.
Вторая стадия — заполнение информации о дефекте, как правило, стандартизованным способом. Для этого нужно потратить некоторое время и выяснить, что именно сделал тестировщик, чтобы выявить проблему, что должно было произойти и что именно ожидалось. Помните, что роль тестировщика — в нахождении проблем и их воспроизведении, а не в выяснении, какой именно участок кода стал причиной. Этим тоже можно заняться — и часто приходится, если у тестировщика имеются необходимые технические знания, — но это не является его основной задачей. Если тестировщик погружается слишком глубоко в код, он или она испытает соблазн написать, что нужно для исправления дефекта, вместо того, чтобы сфокусироваться на том, что собой представляет дефект. Помните, как и в требованиях, дефект — это что именно неправильно, а не то, как это исправить.
После обнаружения дефекта кто-то должен принять решение, тратить ли ресурсы на его исправление, и если стóит это делать, то как расставить приоритеты в случае, когда дефектов окажется слишком много. Это называется сортировкой. В английском языке это слово (triage) происходит от медицинского термина, определяющего приоритет в обслуживании пациентов в зависимости от степени их ранения или заболевания. Так часто делается, когда единовременно появляется слишком большое количество жертв, чтобы медицинский персонал позаботился о них. Например, после сильного стихийного бедствия больница может быть переполнена пациентами: у некоторых из них легкие травмы, у других — серьезные, а у третьих — настолько тяжелые ранения, что пострадавших невозможно спасти. В таких случаях госпиталь может начать сортировать поступающих пациентов и немедленно обслуживать пострадавших с серьезными, но излечимыми ранениями, и устанавливать более низкий приоритет для тех, у кого небольшие травмы, и тех, кого навряд ли спасут, даже если приложат все усилия.
Хотя подобная драматичная сортировка редка в медицинском мире, в сфере разработки программного обеспечения она встречается необычайно часто. Как правило, оказывается, что найденных дефектов гораздо больше, чем времени у разработчиков на их исправление. Соответствующие заинтересованные лица решают, какие дефекты должны быть исправлены с учетом имеющихся ресурсов, и устанавливают приоритеты в зависимости от того, как быстро эти дефекты могут быть исправлены и сколько боли они доставляют пользователям программы. В некоторых организациях ответственность за выбор дефектов, которыми нужно заниматься в первую очередь, лежит на разработчиках — именно они решают, какие дефекты наиболее легки для исправления, и снимают основную боль у пользователей программы. Такой тип работы хорош тогда, когда разработчики глубоко понимают нужды пользователя, например когда они работают над инструментом для разработки программного обеспечения и сами являются его пользователями.
После того как дефект передан разработчику или группе разработчиков, этот разработчик исправляет его. Зачастую после этого добавляется автоматизированный тест, чтобы покрыть ту ситуацию, при которой произошел дефект, и избежать повторения подобного в будущем. И хотя разработчик непосредственно близок к создаваемому им программному обеспечению, окончательное решение о том, был ли дефект исправлен, принимается не им. Подобно тому как некоторые люди не могут увидеть ошибки в написанных ими текстах, разработчик может не заметить совершенно другую ошибку, которая появилась из-за исправления, или то, что некоторые граничные случаи не были покрыты. Обязательный анализ кода (code review) поможет несколько улучшить ситуацию, но обычно окончательное решение по поводу того, что дефект исправлен, принимает тестировщик. Так как одним из ключевых аспектов работы тестировщика является независимый обзор качества ПО, он может предоставить более объективное и беспристрастное определение того, был ли исправлен дефект надлежащим образом или нет.
Таким образом, после исправления дефекта программу необходимо вернуть команде тестирования для проверки данного исправления. Разработчик или разработчики могли не протестировать все граничные случаи или же могли создать другие проблемы своим исправлением. Тестировщик может независимо проверить, что исправление действительно устранило дефект и не стало причиной возникновения других дефектов. Конечно, в некоторых случаях могут появиться другие дефекты, особенно если первый блокировал появление последующих. Например, если имеется опечатка в приветственной странице, которая появляется после авторизации, а дефект не позволяет пользователям авторизоваться, тестировщик все равно должен проверить исправление, позволяющее пользователям пройти авторизацию. То, что опечатка на приветственной странице была обнаружена после возможности залогиниться, не связывает сущности этих дефектов. Даже дефект, который вызывает связанные дефекты, иногда может быть верифицирован. В продолжение нашего примера с неработающей формой входа: если исправление позволит пользователям авторизоваться, но при этом не будет проверяться пароль, ситуация может рассматриваться как улучшение, и регистрируется второй дефект по проблеме с паролем.