Относительная плотность багов

Окунемся в теорию.
Рассмотрим такое теоретическое понятие как относительная плотность багов. количество багов на некоторую единицу, например, на единицу времени (неделя, итерация), на единицу разработки (фича, модуль), на рабочую единицу (тестировщик). Более всего интересно распределение количества по времени. Заметил, что с течением времени это количество не постоянно. Проанализировав, получил, что: значение плотности багов должно обычно изменяться с теченем времени, потому что:

1 низкая плотность в начале работы (обусловлено тем, что имеем новый продукт (софт\фича), вероятно, новые инструменты, новые люди);

2 выше в середине работы (процесс налажен, всё известно, все знают зачем, что и как делать, у всех есть желание и возможность сделать свою работу);

3 ниже к концу (известен предмет тестировани: проблема- примелькался продукт, к нему привыкли тестировщики; баги фиксятся+регрессионное тестирование дает свои плоды (позволяет разработчикам не повторять своих ошибок -это спорное утверждение, но именно с такой ситуацией я однажды столкнулся).

Обозначились проблемы. Попробуем сделать выводы и найти решения проблем.
выводы:
1. четко регламентировать и описать процесс работы. (Что даст нам ускоренное знакомство с софтом, инструментами, людьми путем четкого распределения обязанностей (кто что делает и почему), источников информации (кто как делает, зачем делает и какими средствами).

2. соблюдать инструкции и правила. (без этого предыдущий пункт можно вычеркнуть).

3. как можно раньше ввести людей в курс дела, обучить. (Здесь имеется ввиду больше знакомство тестировщиков на ранних стадиях с требованиеями, с первыми версиями спека и т.д. А также знакомство новичков.).

4. заранее продумывать пути совершенствования процесса, допустимые эксперименты. (Не лишним будет попробовать усовершенствовать тот или иной процесс (в пределах разумного) в рамках тестирования. Однако, такие эксперименты не всегда можно ставить- перед релизом, думаю, они чреваты:))

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

6. ротация людей по областям (не обязательно всех), взаимозаменяемость.

7. смена типа, метода, подхода ручного тестирования (Прежде всего в области ad hoc, exploratory testing).

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

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

Отдельно стоит заострить внимание на пунктах 6 и 7. Возможности их осуществления должны быть заложены при планировании работы всей группы тестрования над тем или иным проектом. Если вы, например, решаете зафиксировать деятельность отдельных тестировщиков в проекте, то будет затруднительно менять направление деятельности каждого.

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

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