О принципах тестирования любят говорить «коротко и по делу», из-за чего начинающие тестировщики теряются или упускают полезную информацию. Но авторам «Foundations of Software Testing: ISTQB Certification», Дороти Грэхем, Эрику ван Венендалу, Изабель Эванс и Рексу Блэку, удалось детально и нескучно написать о принципах тестирования. Именно их книгой мы вдохновились при написании статей. Первую часть читайте тут.
Принцип 4. Скопление дефектов
Мы давно обратили внимание на то, что дефекты как-бы «кучкуются» в одном месте. Это связано с тем, что всегда есть самая сложна и запутанная часть кода. А когда в нее вносятся изменения, весь проект начинает «сыпаться» как домино. Именно поэтому, опытные тестировщики сразу фокусируются на таких «проблемных» областях.
О том, где «кучкуются» дефекты, можно узнать еще на ранних этапах, когда проводится статическое тестирование (например, code review и анализ кода при помощи специальных инструментах). Когда дойдет дело до динамического тестирования, можно сфокусироваться на тех областях, где было обнаружено больше дефектов статическими методами.
Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
Принцип 5. Парадокс пестицидов
Интригующее название, не правда ли? Суть этого принципа заключается в том, что, если каждый раз применять одни и те же тесты, они перестанут находить новые ошибки. И дело не в том, что нам удалось их исправить. Скопление дефектов, о котором мы писали ранее, может «перемещаться». Точно также как вредители, чье место обитания было обработано пестицидами. Часть из них погибнет, а часть выживет. В такой ситуации повторная обработка уже не спасет – у насекомых выработался иммунитет к яду.
Чтобы преодолеть «парадокс пестицидов», необходимо регулярно пересматривать существующие тест-кейсы и создавать новые, разнообразные тесты, которые будут выполняться на различных частях системы. Это позволит обнаружить больше дефектов.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта Интернет-магазина.
Что значит «риски тестирования»? Во-первых – это потенциальная проблема, во-вторых – это негативные последствия, возникающие из-за дефектов ПО. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся.
Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние. Например, когда мы переходим дорогу, есть некоторая вероятность, что нас собьет машина. Вероятность этого зависит от ряда факторов: насколько интенсивное движение на дороге, есть ли безопасный пешеходный переход, насколько хорошо мы видим, насколько быстро мы можем перейти дорогу. Воздействие зависит от скорости движения машины, от того, есть ли на нас какая-то защитная одежда, от нашего возраста и состояния здоровья и так далее. Исходя из этих факторов, человек выбирает оптимальную в данном случае стратегию перехода через дорогу.
То же можно сказать и о ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьирует. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени и деловой репутации.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО – это люди и компании, которые не интересуются ошибками ПО, ведь они пришли за готовым продуктом. Им не важно, насколько разработанный проект подходит под наши внутренние требования. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Поэтому, даже если мы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.
Иначе говоря, верификация ≠ валидация. Другими словами, проверка на соответствие требованиям ≠ проверке на соответствие ожиданиям заказчика. Поэтому, часть тестовых активностей должна быть направлена на верификацию, часть – на валидацию.
Теоретически, если требования были собраны и проанализированы правильно и на этапе разработки архитектуры и кода не вкрались искажения, противоречия быть не должно. Но жизнь, увы, не идеальна.
Хотите стать тестировщиком? Присоединяйтесь к нашим курсам!
#технологии #программирование #тестирование #тестировщик
