О принципах тестирования любят говорить «коротко и по делу», из-за чего начинающие тестировщики теряются или упускают полезную информацию. Но авторам «Foundations of Software Testing: ISTQB Certification», Дороти Грэхем, Эрику ван Венендалу, Изабель Эванс и Рексу Блэку, удалось детально и нескучно написать о принципах тестирования. Именно их книгой мы вдохновились при написании этой статьи.
Принцип №1. Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.
Доказать, что чего-то нет, в принципе трудно. Сколько бы белых лебедей мы ни видели, мы не можем утверждать, что «все лебеди белые». Но если мы увидим хотя бы одного черного лебедя, то можем сказать, что «не все лебеди белые».
Точно также с тестированием: сколько бы успешных тестов не было, мы можем утверждать, что ошибок нет. Но если мы нашли хотя бы один дефект, можем быть уверены, что в ПО есть ошибки.
Но, это не означает, что тестирование бесполезно. Оно помогает повысить уровень качества проекта и уменьшает вероятность необнаруженных дефектов. Главное помните – даже если дефекты не найдены, это не значит, что их нет.
Принцип №2. Исчерпывающее тестирование невозможно
От начинающих тестировщиков можно услышать: «А сколько нужно тестировать?». Однозначного ответа на этот вопрос нет. Идеальным вариантом выглядит «протестировать полностью», но стоит разобраться можем ли мы вообще это сделать.
Количество тестов зависит от того, что мы понимаем под словом «полностью». Есть 10 возможных валидных значений, но, кроме того, надо еще убедиться, что невалидные значения правильно обрабатываются. 26 заглавных латинских букв, 26 строчных букв, не менее 6 знаков пунктуации и пробел. А это уже 68, а это мы еще не вспомнили о кириллице, спецсимволах и тому подобном.
На практике у систем больше одного поля ввода, и они имеют разный размер. Также существуют различные окружения, на которых нужно выполнить тесты. Если мы возьмем пример, где есть 15 полей ввода, каждое из которых принимает 5 значений, то чтобы протестировать все комбинации, нам понадобится 515 (30 517 578 125) тестов.
Но объем тестирования в реальной жизни ограничен временными рамками и бюджетом. Вместо попыток «протестировать всё» нужен особый подход к тестированию (стратегия), который обеспечит правильный объем тестирования для конкретного проекта и конкретных заказчиков (и других заинтересованных лиц). Что понять какой объем тестирования достаточен, нужно учитывать риски, время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте. Это позволяет варьировать трудозатраты на тестирование, основываясь на уровне риска в различных областях.
Кроме того, тестирование должно обеспечивать необходимую информацию, чтобы заинтересованные лица могли принимать информированные решения о релизе продукта или передаче заказчикам.
Принцип №3. Раннее тестирование
Этот принцип отсылает нас к термину «цена дефекта». Цена дефекта (или cost of defect) – это некий показатель, отражающий связь между жизненным циклом разработки и количеством ошибок. Не трудно догадаться, что этот показатель повышается на протяжении всего времени работы над проектом. Поэтому чем раньше начнется тестирование, тем раньше будут найдены и исправлены ошибки.
Если же дефект, внесенный еще на уровне требований, «дожил» до этапа системного или приемочного тестирования, исправить его будет дорого – ведь придется внести изменения не только в код, но, возможно, и в архитектуру, и в требования. Кроме того, один дефект в требованиях может проявиться во множественных дефектах на уровне архитектуры и кода, а после внесения исправлений нужно вновь проводить тестирование. Порой дефекты, обнаруженные на слишком поздней стадии, вообще не исправляются, потому что на это может уйти слишком много ресурсов.
Случается, и так, что ПО соответствует согласованным требованиям, но не соответствует потребностям пользователей. Это вызывает целый ряд проблем – нежелание пользователей переходить на новую систему, сложности с продажей и внедрением и так далее. Это значит, что требования изначально были неполны, но этот изъян не был обнаружен.
Вот почему важно начинать тестирование как можно раньше, со статических техник.
Еще один «плюс» раннего тестирования – это экономия времени. Если тестовые активности начнутся одновременно с разработкой, то тестировщики смогут раньше проверить ПО на соответствие требованиям и заняться ревью тест-кейсов.
Интересно продолжение? Подписывайтесь на нас в Яндекс.Дзен и следите за новостями!
Хотите стать тестировщиком? Присоединяйтесь к нашим курсам!
#технологии #программирование #тестирование #тестировщик