О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 3. Раннее тестирование
Тестовые активности должны начинаться как можно раньше в цикле разработки и быть сфокусированы на определенных целях.
Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить.
Дефект, найденный в требованиях, обходится дешевле всего. Если дефект обнаружен на этапе разработки архитектурного решения, исправить его тоже не составляет большого труда. Если же дефект, внесенный еще на уровне требований, «дожил» до этапа системного или приемочного тестирования, исправление его будет очень дорогим – ведь придется внести изменения не только в код, но, возможно, и в архитектуру, и в требования. Кроме того, один дефект в требованиях может проявиться во множественных дефектах на уровне архитектуры и кода, а после внесения исправлений нужно вновь проводить тестирование.
Порой дефекты, обнаруженные на слишком поздней стадии, вообще не исправляются, потому что это обошлось бы слишком дорого.
Случается, и так, что ПО поставляется и формально соответствует согласованным требованиям, но не соответствует нуждам и потребностям пользователей. Это также вызывает целый ряд проблем – нежелание пользователей переходить на новую систему, сложности с продажей и внедрением и так далее. Это значит, что требования изначально были неполны, но этот изъян не был обнаружен.
Вот почему важно начинать тестирование как можно раньше, со статических техник.
Еще одно важное преимущество раннего тестирования – экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
Принцип 4. Скопление дефектов
Небольшое количество модулей содержит большинство дефектов, обнаруженных на этапе предрелизного тестирования, или же демонстрируют наибольшее количество отказов на этапе эксплуатации.
Многие тестировщики наблюдали такой эффект – дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов – тестировщики фокусируются на известных «проблемных зонах».
О том, где «кучкуются» дефекты, можно узнать еще на ранних этапах, когда проводится статическое тестирование (например, code review и анализ кода при помощи специальных инструментах). Когда дойдет дело до динамического тестирования, можно сфокусироваться на тех областях, где было обнаружено больше дефектов статическими методами.
Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
Предыдущая статья: 7 принципов тестирования. Часть 1.
Продолжение: 7 принципов тестирования. Часть 3.
Курсы по тестированию ПО.