понедельник, 28 сентября 2009 г.

Правила работы с багами (баг репортами).

В этом посте хочу поделиться с некоторыми устоявшимися у нас правилами и требованиями, которые необходимо соблюдать при постинге багов в багтрекнговые системы, при верификации фиксов и т.д. Не говорю, что они подойдут всем и во всем, но столкнувшись с проблемами, я решил превентировать их в будущем введением именно такого регламента.
Вообще каждая багтрекинговая система содержит в себе достаточно всяких требований, условий и так далее. Но иногда, в чем я убедился, этого не совсем достаточно, особенно для новичков в тестировании.

Работа с дефектами:

1. Вся работа с дефектами должна быть в соответствии с требованиями TFS (Напомню, что это наш основной инструмент). 1. Каждый дефект репорт в багтрекинговой системе: 1) имеет уникальный номер ID; заголовок (краткий, но максимально информативный для поиска и ориентации по нему); важность; срочность; ссылки на связанные дефекты, ТС, требования (обязательно для дефектов требований, спека), документацию (при необходимости); описание (что, где и когда именно не работает(работает неправильно));набор шагов для воспроизведения (необходимо указывать максимально короткую последовательность из возможных, то есть проводить доподлинное выявление дефекта, его локализацию), если существуют другие способы появления этого же дефекта- необходимо их указать (например, в комментариях); к какому приложению и\или его области дефект относится, в каком билде найдет, в какой билд вошел фикс; статус (в каком состоянии он находится, кто в данный момент времени над ним работает, кто автор, кто ответственные);комментарии, историю изменений. 2) описывает уникальное состояние приложения (на данный момент времени). 3) должен содержать максимальное количество (уникальной) информации о дефекте (xml, скрины, графические файлы и тд).
Остановлюсь на заголовке подробнее. Правильный заголовок должен отражать суть дефекта, быть таким, чтобы по нему можно было найти дефект поиском, в то же время- кратким и емким. Если это исключение, значит пишем, что "исключение при...", а не "появляется сообщение с исключением..". Второй вариант допустим при дефекте вывода не того сообщения, которое должно быть, например.

2. При проверке фикса, помимо самого дефекта должно проверяться минимальное окружение (метод эд хок). Этим пунктом хотелось бы предотвратить ситуации, когда дефект пофиксен, но существует аналогичный\похожий дефект (или даже не один), которые легко находятся. Но не перебором граничных, "интересных" значений, например, а включением мозга. При котором строятся попытки, варианты того, в каких случаях можно еще получить схожее поведение программы и добиться получения дефекта.

3. Недопустимо повторение дефектов в системе багтрекинга. Перед постингом необходимо убедиться в отсутствии такового же дефекта в системе, используя поиск. При необходимости- открыть заново с соответствующим комментарием.

4. Каждый дефект репорт должен содержать описание только одного дефекта. при отклонениях должен быть создан другой репорт (за исключением некоторых случаев, которые будут оговариваться отдельно). Здесь имеется ввиду то, что нельзя запихивать несколько дефектов в один репорт. Не путать с одним дефектом и несколькими путями (возможностями) его проявления.

5. В сложных ситуациях когда дефект "мигрирует" или "изменяется" (либо из одной области приложения в другую, либо изменяется поведение и тд) нужно закрыть старый дефект (с комментарием) и открыть новый. Иногда встречаются такие ситуации, когда шаги для воспроизведения дефекта становятся мало похожи на первоначальное описание.

6. Верификацию фикса проводит автор дефекта. Ad hok ("вокруг этого дефекта")- можно тестировать не обязательно автору. Довольно противоречивый пункт. Однако есть мнение, что никто кроме автора не знает сам дефект лучше, какие-то подробности, нюансы (хотя они должны бить прокомментированы).

7. При нахождении дефекта необходимо проверить все возможные способы его получения и смежные области. То есть необходимо подумать и проверить- где этот дефект или его влияние) могут быть найдены еще.

8. При описании дефекта следует иметь ввиду, что при проверке фикса следует проверять все возможные (логически реализуемые) варианты проявления дефекта (в зависимости от ОС, окружения и тд.). Но не следует перегружать описание дефекта перечислением этих вариантов. Достаточно указать на достаточно(!) различные варианты.

9. Количество шагов для воспроизведения должно быть минимальным, но достаточным (дефект должен быть максимально локализован).

10. Необходимо проводить регулярные bug review, bug status review.

11. Описание дефектов необходимо дополнять достаточным количеством скриншотов.

12. Как правило каждый дефект имеет свое влияние на выполнение\невыполнение ТС\TS и др. Поэтому должен содержать ссылки на зависимые элементы.

13. Что нужно проверять при проверке фикса\новой фичи: 1. проверять, что то, что сделали (написали\пофиксили) разработчики, работает вообще. 2. проверять, что то, что сделали (написали\пофиксили) разработчики, работает корректно. 3. проверять, что то, что сделали (написали\пофиксили) разработчики, не ломает существующий, корректно работающий функционал.

14. Проверка фикса (и не только): 1. В первую очередь производится попытка воспроизведения бага (по описанным шагам). 2. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.). 3. Проверка этих областей. 4. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)). 5. Проверка этих методов. Минимальное свободное тестирование (сугубо специфично): 6. Проверка работы с некорректными данными (например, сохранение, поиск по ним). 7. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт). 8. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными обязательными полями). 9. Если, например, тестируется установка дистрибутива или импорт данных, имеет смысл использовать виртуальные машины для одновременной проверки разного функционала или параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и бытрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).

А так же читаем про управление дефектами на http://software-testing.ru/library/testing/bug-tracking?layout=default