Скопление багов – это один из 7 базовых принципов тестирования, который не такой уж и теоретический термин, каковым его принято считать. Большинство тестировщиков с реальным опытом работы в проектах подтвердят данные слова.

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

Давайте подробно разберем термин «скопление дефектов» или, как говорят сотрудники ІТ-индустрии Зарубежья – «bug clustering».

[highlight dark=”no”]Скопление дефектов[/highlight] – основополагающий принцип, который гласит, что [highlight dark=”no”]80% всех дефектов продукта находится в 20% его модулей.[/highlight]

За основу данного принципа используется эмпирическая закономерность, названная именем известного экономиста и социолога Вильфредо Парето. В ней говорится: [highlight dark=”no”]«20% усиленного труда дают 80% результата, а оставшиеся 80% усилий – только 20% результата».[/highlight]

Это не значит, что нужно, следуя этому правилу, тестировать продукт хаотично, ища Грааль, содержащий все те заветные 80% проблем, которые позволяют Вам стать крутым тестировщиком и помогут сделать основополагающий вклад в развитие проекта. Велосипед придумывать не стоит.

Как вы поняли, принцип Парето имеет свои недостатки. Ознакомимся с ними:

1. В первоначальной формулировке (не учитывая соотношения значений 80 и 20 процентов), данное правило – это только наблюдение, при котором результат мы получаем из выполнения большого количества разнообразных факторов; значение каждого из этих факторов часто разнится;
2. С математической точки зрения, количественная формулировка принципа не совсем корректно изложена:

• в процессе работы над проектом, в реальной жизни, распределение вклада факторов может быть любым, и совсем нет гарантии, что он будет равняться 20 и 80%;
• легко можно убедится в том, что конкретные данные распределения могут поддаваться изменениям даже во время анализа одинаковых значений. Для этого потребуется всего лишь сменить правила группировки данных, выбранных хаотично.

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

Тут возникает вопрос: «Зачем тогда вообще знать об этом законе?». Все просто: «время  – деньги»: так, как основные ресурсы ПО имеют ограничения и лимит. Суметь покрыть все составляющие тестами – что-то из мира фантастики. Именно поэтому важно уметь эффективно и быстро находить баги и проблемы за предоставленное время.

Смоделируем ситуацию: времени на создание качественных тестовых кейсов просто нет и команда работает над простеньким чек-листом. Тут начинает работать закон Парето.

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

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

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

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

К примеру, если выяснится, что одна из составляющих на всех спринтах создает огромное количество дефектов или их там немного, но они постоянно появляются, тут стоит задуматься над тем, нужно ли продолжать воплощать ее именно таким образом? Такое возможно вследствие конфликтности между уже существующими и новыми модулями, вступления в проект новых программистов, и, таким образом, несовпадения старого кода с новым.

Принцип Парето говорит нам о том, что, возможно, следует попробовать решить проблему другим путем: может, нужно изучить и видоизменить ТЗ? Может, легче написать новый модуль, который будет гармонировать с настоящим, чем пользоваться старым?

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

Как показывает статистика, данные которой полученные независимой консультативной компанией по исследованиям в сфере ІТ, 45% функций программы посетители никогда не применяют, 19% – используют редко, 16% – время от времени и всего лишь 20% – очень часто или всегда. Основываясь на этих цифрах, напрашивается предположение, что, уделив большинство внимания именно этим 20%, используемых чаще всего, можно добиться большего результата, нежели если действовать иначе.

Фундаментальные законы тестирования изначально могут показаться неприменимыми в практике. Только в процессе анализа каждого этапа рабочего процесса, всё это собирается в единое целое, из чего можно сделать вывод, что законы тестирования прячутся в простых вещах, которые, казалось бы, не связаны ничем, но, по факту, дополняют общую картину.

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