
Виктория Слинявчук
7 принципов тестирования. Часть 2
19.05.2020 30078
Другие статьи автора
Пирамида автоматизации
Распространенные ошибки начинающих тестировщиков
Как научиться учиться. Часть 2
Как научиться учиться. Часть 1
7 принципов тестирования. Часть 1
7 принципов тестирования. Часть 3
Манифест Agile-тестировщика. Часть 1
Оружие математического поражения
Манифест Agile-тестировщика. Часть 2
Шерстяная Фуфайка на карте мира
Последние статьи в блоге
Как сдать сертификацию с первого раза: лучшие методы подготовки и обучения
Учебный центр IBS принял участие в конференции Analyst Days
Счастливого Хелл... Тыквеного Спаса!
Сертификация для системных аналитиков: “за” и “против”
Никакой ИИ пока вас не заменит. Все гораздо прозаичней и обидней: вас заменит человек, использующий ИИ… Часть 2
В «Сколково» предложили разработать национальную систему ИТ-сертификации
Никакой ИИ пока вас не заменит. Все гораздо прозаичней и обидней: вас заменит человек, использующий ИИ… Часть 1
Популярные курсы по направлению Архитектура ПО
Вопрос на сертификационном экзамене: применение Threads и Executors
Включи лето на максимум
О 7 принципах тестирования пишут часто, но обычно довольно сжато. Дороти Грэхем и соавторы в своей замечательной книге объясняют эти основополагающие принципы весьма детально.
Принцип 3. Раннее тестирование
Тестовые активности должны начинаться как можно раньше в цикле разработки и быть сфокусированы на определенных целях.
Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить.
Дефект, найденный в требованиях, обходится дешевле всего. Если дефект обнаружен на этапе разработки архитектурного решения, исправить его тоже не составляет большого труда. Если же дефект, внесенный еще на уровне требований, «дожил» до этапа системного или приемочного тестирования, исправление его будет очень дорогим – ведь придется внести изменения не только в код, но, возможно, и в архитектуру, и в требования. Кроме того, один дефект в требованиях может проявиться во множественных дефектах на уровне архитектуры и кода, а после внесения исправлений нужно вновь проводить тестирование.
Порой дефекты, обнаруженные на слишком поздней стадии, вообще не исправляются, потому что это обошлось бы слишком дорого.
Случается, и так, что ПО поставляется и формально соответствует согласованным требованиям, но не соответствует нуждам и потребностям пользователей. Это также вызывает целый ряд проблем – нежелание пользователей переходить на новую систему, сложности с продажей и внедрением и так далее. Это значит, что требования изначально были неполны, но этот изъян не был обнаружен.
Вот почему важно начинать тестирование как можно раньше, со статических техник.

Еще одно важное преимущество раннего тестирования – экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
Принцип 4. Скопление дефектов

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

О том, где «кучкуются» дефекты, можно узнать еще на ранних этапах, когда проводится статическое тестирование (например, code review и анализ кода при помощи специальных инструментах). Когда дойдет дело до динамического тестирования, можно сфокусироваться на тех областях, где было обнаружено больше дефектов статическими методами.
Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
Предыдущая статья: 7 принципов тестирования. Часть 1.
Продолжение: 7 принципов тестирования. Часть 3.
Курсы по тестированию ПО.
Расскажи друзьям:
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!