Должны ли разработчики проверять корректность своих фиксов?
Проблема обсуждалась неоднократно на форуме проекта it4business.ru , в блогах и т.д. Попробуем разобраться в ситуации.
Априори предполагаем наличие здравого смысла в организации процесса и ясность смысла проверок всем ясна. Итак, если проверки необходимы, то их кто-то должен делать- либо сами разработчики, либо тестировщики. Рассмотрим 2 варианта: 1- тестировщиков на проекте не достаточно; 2- тестировщиков достаточно для того, чтобы смотреть еще и за результатами фиксов, несмотря на то, что времени на тестирование всегда не хватает. Второй утопический случай можно смело отбросить) и поставить вопрос так: должны ли разработчики сами проверять не только корректность конкретного фикса, но и некоторое минимальное окружение вокруг этого фикса (бага)? То есть ограничиваться ли автору фикса проверкой только лишь того конкретного бага\проявления бага, который указан в баг репорте? Или все-таки включить мозг, попробовать другие действия, окружение и т.д.
Понятно, что квалифицированный, профессиональный разработчик должен это делать, но часто приходится слышать такие вещи как "острая нехватка времени", "не приоритетная задача", "потом".
В случае, когда тестировщиков на проекте более-менее достаточно для того, чтобы проверять каждый фикс более подробно, выход из ситуации можно обеспечить количеством. Чем больше количество тестировщиков,- тем больше времени (в среднем) можно уделить на проверку конкретного фикса бага.
Но что делать, если тестировщикам итак катастрофически не хватает времени? Вариант- расширить проверку фиксов разработчиками. (Допустим, что нет возможности нанять еще тестировщиков, что часто случается в последнее время). Ежу понятно, что этим мы жертвуем временем на разработку (кодирование). Но в целом, при подсчете общего затраченного времени (и того, которое я, как тестировщик, затрачу на поиск всех нюансов (проявлений) каждого бага, и на переоткрытие бага в баг трекинговой системе, и на объяснения с разработчиком и многое другое) картина будет выглядеть не столь ужасно, если не будет происходить тех действий, выполнение которых можно было бы предусмотреть и избежать. Я здесь не имею ввиду кривые баг репорты, нелокализованные дефекты и другие "косяки" тестировщиков. Имеется в виду только ограниченность проверки разработчиком. Если цель- иметь пусть "меньший", но проверенный, рабочий функционал, а не горы глючного кода, вполне можно организовать и обязательную проверку разработчиками своих собственных трудов. Я для этого написал небольшой список требований к такой проверке, который (не без помощи начальства (а лучше- активного участия)) внедряли в рабочий процесс.
Что получилось:
Вобщем я решил, что такой регламент должен быть коротким, чтобы разработчикам было не лень его читать и применять. Также чтобы он описывал только основные моменты.
Смысл его введения:
1. Разработчики дожны проверять, что то, что они сделали (написали\пофиксили), работает вообще.
2. Разработчики дожны проверять, что то, что они сделали, работает корректно.
3. Разработчики дожны проверять (хотя бы в минимальной степени), что то, что они сделали, не ломает существующий, корректно работающий функционал.
Можно переложить почти все эти проверки на тестировщиков при условии, что как максимум на 4 разработчиков будет 1 тестировщик. В нашем случае это без вариантов.
По опыту тестирования (конкретного софта) могу сказать, что очень много времени у меня уходило: на поиск существующих в системе баг трекинга баг репортов + их возвращение, комментирование; на запись похожих. При организации проверки фиксов разработчиками этого бы не понадобилось. А потраченное время я бы потратил на более серьезную проверку.
Проверка фикса (не только):
1. Время верификации каждого фикса не более 10-20 мин.
2. В первую очередь производится попытка воспроизведения бага (по описанным шагам).
3. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.).
4. Проверка этих областей.
5. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)).
6. Проверка этих методов.
Минимальное свободное тестирование (специфично для определенного софта):
7. Проверка работы с некорректными данными (например, сохранение, поиск по ним).
8. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт).
9. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными
обязательными полями).
10. Если, например, теструется установка дистрибутива или импорт данных, имеет смысл
использовать виртуальные машины для одновременной проверки разного функционала или
параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и быстрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).
Все это опять же- FYI.
Показаны сообщения с ярлыком баг. Показать все сообщения
Показаны сообщения с ярлыком баг. Показать все сообщения
вторник, 6 октября 2009 г.
пятница, 2 октября 2009 г.
Относительная плотность багов
Окунемся в теорию.
Рассмотрим такое теоретическое понятие как относительная плотность багов. количество багов на некоторую единицу, например, на единицу времени (неделя, итерация), на единицу разработки (фича, модуль), на рабочую единицу (тестировщик). Более всего интересно распределение количества по времени. Заметил, что с течением времени это количество не постоянно. Проанализировав, получил, что: значение плотности багов должно обычно изменяться с теченем времени, потому что:
1 низкая плотность в начале работы (обусловлено тем, что имеем новый продукт (софт\фича), вероятно, новые инструменты, новые люди);
2 выше в середине работы (процесс налажен, всё известно, все знают зачем, что и как делать, у всех есть желание и возможность сделать свою работу);
3 ниже к концу (известен предмет тестировани: проблема- примелькался продукт, к нему привыкли тестировщики; баги фиксятся+регрессионное тестирование дает свои плоды (позволяет разработчикам не повторять своих ошибок -это спорное утверждение, но именно с такой ситуацией я однажды столкнулся).
Обозначились проблемы. Попробуем сделать выводы и найти решения проблем.
выводы:
1. четко регламентировать и описать процесс работы. (Что даст нам ускоренное знакомство с софтом, инструментами, людьми путем четкого распределения обязанностей (кто что делает и почему), источников информации (кто как делает, зачем делает и какими средствами).
2. соблюдать инструкции и правила. (без этого предыдущий пункт можно вычеркнуть).
3. как можно раньше ввести людей в курс дела, обучить. (Здесь имеется ввиду больше знакомство тестировщиков на ранних стадиях с требованиеями, с первыми версиями спека и т.д. А также знакомство новичков.).
4. заранее продумывать пути совершенствования процесса, допустимые эксперименты. (Не лишним будет попробовать усовершенствовать тот или иной процесс (в пределах разумного) в рамках тестирования. Однако, такие эксперименты не всегда можно ставить- перед релизом, думаю, они чреваты:))
5. ревью тестов. (Изменяем\дополняем проверками, методами, которые раньше не проводились. Тут можно подумать, что первичный вариант тестов был не полным или неграмотным. Имеется ввиду- изменить проверки на аналогичные.).
6. ротация людей по областям (не обязательно всех), взаимозаменяемость.
7. смена типа, метода, подхода ручного тестирования (Прежде всего в области ad hoc, exploratory testing).
8. контроль предпринятых мер и мониторинг результатов. (Незачем продолжать неэффективные способы).
9. отслеживать % повторно открытых дефектов. (что позволит судить о таких вещах, влияющих на скорость разработки, как корректность баг репортов, корректность фиксов (ну должны же разработчики хоть немного смотреть на то, что они делают. В мое практике были случаи, когда баги фиксились методом лишь бы как-нибудь. Лечилось разговором с руководством и демонстрацией теряемого времени на возврат багов, заведение аналогичных, да и просто переводом с одного человека на другого)).
Отдельно стоит заострить внимание на пунктах 6 и 7. Возможности их осуществления должны быть заложены при планировании работы всей группы тестрования над тем или иным проектом. Если вы, например, решаете зафиксировать деятельность отдельных тестировщиков в проекте, то будет затруднительно менять направление деятельности каждого.
Рассмотрим сферического руководителя группы тетсирования в вакууме. В начале работы над некоторым проектом перед ним (и группой) стоят задачи: планирование тестов, дизайн тестов, разработка автотестов, выполнение тестов, предоставление результатов и оценка выполнения тестов. Вполне очевидно, что первые три задачи следует решить раньше других. Если учесть, что временные ограничения никто не отменял и делать это не собирается, то, чтобы добиться эффективной работы группы, необходимо на каждом этапе распределять работы так, чтобы максимально возможное количество сотрудников работало над теми задачами, которые необходимо решить в первую очередь. Например, на начальном этапе ставим задачу максимальному возможному большинству тестировщиков (здесь все-таки есть разумные ограничения- опыт в этой деятельности, другие задачи)- написание тест кейсов. Можно даже потерять немного времени на параллельное обучение тестировщиков, не имеющих опыта написания тест кейсов. Потери, конечно, должны быть разумными. А выигрыш в будущем за счет каждого нового обученного обеспечен (если он никуда не уйдет, но это уже совсем другая проблема). Далее. Когда большинство тест кейсов написано и готово к использованию- имеет смысл переключить часть сотрудников на непосредственно тестрование, а также на написание автотестов, если таковые предполагаются. Смысл в том, что появляется более приоритетная задача. Так как поддерживать тест кейсы в актуальном состоянии можно и не всем первоначальным составом. Как определить момент переключения на другую задачу? Делаем просто- переключаем постепенно. То есть сначала некое минимальное количество, а затем смотрим на успеваемость. И потом при необходимости добавляем людей на следующую задачу. Обращаем внимание, что в данном случае все участники рано или поздно сменят вид тестовой деятельности (по крайней мере между написанием и выполнением тестов). Как мне кажется, жесткая фиксация вида деятельности тестировщика имеет смысл лишь в том случае, когда проекты поставлены на поток, когда в любой момент времени нужно писать тест кейсы, вполнять их и так далее. В случае же, когда приоритет каждой задачи меняется с течением времени, выгодно иметь группу проффесионалов, которые смогут участвовать и в написании тестов, и в выполнении, и в работе по автоматизации... Таким образом мы сможем построить максимально эффективный процесс в каждый момент времени, имея возможность оптимально выстраивать\распределять работу над актуальными задачами, предотвращать задержки каких-то направлений из-за болезней, уходов сотрудников, а также имея возможность исправить несерьезные ошибки планирования перераспределяя ресурсы. Еще один выигрышный момент- когда низкая плотность багов обусловлена такой проблемой- примелькался продукт, к нему привыкли тестировщики,- при смене деятельности (не радикальной, хотя и такое может быть реализовано) получаем "незамыленные", свежие глаза и руки :) на каждом из направлений. Смена области приложения чередуется со сменой вида деятельности. Например, 6 тестировщиков, 2 модуля приложения, 3 задачи- написание ТС, их выполнение, написание автотестов. решаем проблему методом "каждый на каждой позиции". Тут нужно не забыть, что каждому понадобится различное время на знакомство, переключение на новый тип деятельности, различное время на выход на "максимальную скорость работы", и различное время на "замылевание", привыкание. При небольших по срокам проектах такая смена деятельности не оправдана. А также стоит учесть предпочтения самих тестировщиков.
А чтобы исключить взаимонепонимание, различные версии, интерпретации- необходимо воспользоваться первыми двумя пунктами выводов.
Это не фиксированная модель. Можно что-то добавить, что-то убрать, в каких-то моментах добавить ротации сотрудников, в других наоборот- иметь более постоянный состав. Общий смысл- варианты решения обозначенных выше проблем. Не исключено порождение новых, но тут уже нужно взвешивать все плюсы и минусы и решать что же выгоднее в каждом конкретном случае.
Рассмотрим такое теоретическое понятие как относительная плотность багов. количество багов на некоторую единицу, например, на единицу времени (неделя, итерация), на единицу разработки (фича, модуль), на рабочую единицу (тестировщик). Более всего интересно распределение количества по времени. Заметил, что с течением времени это количество не постоянно. Проанализировав, получил, что: значение плотности багов должно обычно изменяться с теченем времени, потому что:
1 низкая плотность в начале работы (обусловлено тем, что имеем новый продукт (софт\фича), вероятно, новые инструменты, новые люди);
2 выше в середине работы (процесс налажен, всё известно, все знают зачем, что и как делать, у всех есть желание и возможность сделать свою работу);
3 ниже к концу (известен предмет тестировани: проблема- примелькался продукт, к нему привыкли тестировщики; баги фиксятся+регрессионное тестирование дает свои плоды (позволяет разработчикам не повторять своих ошибок -это спорное утверждение, но именно с такой ситуацией я однажды столкнулся).
Обозначились проблемы. Попробуем сделать выводы и найти решения проблем.
выводы:
1. четко регламентировать и описать процесс работы. (Что даст нам ускоренное знакомство с софтом, инструментами, людьми путем четкого распределения обязанностей (кто что делает и почему), источников информации (кто как делает, зачем делает и какими средствами).
2. соблюдать инструкции и правила. (без этого предыдущий пункт можно вычеркнуть).
3. как можно раньше ввести людей в курс дела, обучить. (Здесь имеется ввиду больше знакомство тестировщиков на ранних стадиях с требованиеями, с первыми версиями спека и т.д. А также знакомство новичков.).
4. заранее продумывать пути совершенствования процесса, допустимые эксперименты. (Не лишним будет попробовать усовершенствовать тот или иной процесс (в пределах разумного) в рамках тестирования. Однако, такие эксперименты не всегда можно ставить- перед релизом, думаю, они чреваты:))
5. ревью тестов. (Изменяем\дополняем проверками, методами, которые раньше не проводились. Тут можно подумать, что первичный вариант тестов был не полным или неграмотным. Имеется ввиду- изменить проверки на аналогичные.).
6. ротация людей по областям (не обязательно всех), взаимозаменяемость.
7. смена типа, метода, подхода ручного тестирования (Прежде всего в области ad hoc, exploratory testing).
8. контроль предпринятых мер и мониторинг результатов. (Незачем продолжать неэффективные способы).
9. отслеживать % повторно открытых дефектов. (что позволит судить о таких вещах, влияющих на скорость разработки, как корректность баг репортов, корректность фиксов (ну должны же разработчики хоть немного смотреть на то, что они делают. В мое практике были случаи, когда баги фиксились методом лишь бы как-нибудь. Лечилось разговором с руководством и демонстрацией теряемого времени на возврат багов, заведение аналогичных, да и просто переводом с одного человека на другого)).
Отдельно стоит заострить внимание на пунктах 6 и 7. Возможности их осуществления должны быть заложены при планировании работы всей группы тестрования над тем или иным проектом. Если вы, например, решаете зафиксировать деятельность отдельных тестировщиков в проекте, то будет затруднительно менять направление деятельности каждого.
Рассмотрим сферического руководителя группы тетсирования в вакууме. В начале работы над некоторым проектом перед ним (и группой) стоят задачи: планирование тестов, дизайн тестов, разработка автотестов, выполнение тестов, предоставление результатов и оценка выполнения тестов. Вполне очевидно, что первые три задачи следует решить раньше других. Если учесть, что временные ограничения никто не отменял и делать это не собирается, то, чтобы добиться эффективной работы группы, необходимо на каждом этапе распределять работы так, чтобы максимально возможное количество сотрудников работало над теми задачами, которые необходимо решить в первую очередь. Например, на начальном этапе ставим задачу максимальному возможному большинству тестировщиков (здесь все-таки есть разумные ограничения- опыт в этой деятельности, другие задачи)- написание тест кейсов. Можно даже потерять немного времени на параллельное обучение тестировщиков, не имеющих опыта написания тест кейсов. Потери, конечно, должны быть разумными. А выигрыш в будущем за счет каждого нового обученного обеспечен (если он никуда не уйдет, но это уже совсем другая проблема). Далее. Когда большинство тест кейсов написано и готово к использованию- имеет смысл переключить часть сотрудников на непосредственно тестрование, а также на написание автотестов, если таковые предполагаются. Смысл в том, что появляется более приоритетная задача. Так как поддерживать тест кейсы в актуальном состоянии можно и не всем первоначальным составом. Как определить момент переключения на другую задачу? Делаем просто- переключаем постепенно. То есть сначала некое минимальное количество, а затем смотрим на успеваемость. И потом при необходимости добавляем людей на следующую задачу. Обращаем внимание, что в данном случае все участники рано или поздно сменят вид тестовой деятельности (по крайней мере между написанием и выполнением тестов). Как мне кажется, жесткая фиксация вида деятельности тестировщика имеет смысл лишь в том случае, когда проекты поставлены на поток, когда в любой момент времени нужно писать тест кейсы, вполнять их и так далее. В случае же, когда приоритет каждой задачи меняется с течением времени, выгодно иметь группу проффесионалов, которые смогут участвовать и в написании тестов, и в выполнении, и в работе по автоматизации... Таким образом мы сможем построить максимально эффективный процесс в каждый момент времени, имея возможность оптимально выстраивать\распределять работу над актуальными задачами, предотвращать задержки каких-то направлений из-за болезней, уходов сотрудников, а также имея возможность исправить несерьезные ошибки планирования перераспределяя ресурсы. Еще один выигрышный момент- когда низкая плотность багов обусловлена такой проблемой- примелькался продукт, к нему привыкли тестировщики,- при смене деятельности (не радикальной, хотя и такое может быть реализовано) получаем "незамыленные", свежие глаза и руки :) на каждом из направлений. Смена области приложения чередуется со сменой вида деятельности. Например, 6 тестировщиков, 2 модуля приложения, 3 задачи- написание ТС, их выполнение, написание автотестов. решаем проблему методом "каждый на каждой позиции". Тут нужно не забыть, что каждому понадобится различное время на знакомство, переключение на новый тип деятельности, различное время на выход на "максимальную скорость работы", и различное время на "замылевание", привыкание. При небольших по срокам проектах такая смена деятельности не оправдана. А также стоит учесть предпочтения самих тестировщиков.
А чтобы исключить взаимонепонимание, различные версии, интерпретации- необходимо воспользоваться первыми двумя пунктами выводов.
Это не фиксированная модель. Можно что-то добавить, что-то убрать, в каких-то моментах добавить ротации сотрудников, в других наоборот- иметь более постоянный состав. Общий смысл- варианты решения обозначенных выше проблем. Не исключено порождение новых, но тут уже нужно взвешивать все плюсы и минусы и решать что же выгоднее в каждом конкретном случае.
понедельник, 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
Вообще каждая багтрекинговая система содержит в себе достаточно всяких требований, условий и так далее. Но иногда, в чем я убедился, этого не совсем достаточно, особенно для новичков в тестировании.
Работа с дефектами:
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
Подписаться на:
Сообщения (Atom)
Сообщения
