Собрали 7 базовых принципов тестирования, которые должен знать каждый QA.
- 1. Все протестировать невозможно
- 2. Кластеризация дефектов
- 3. Парадокс пестицида
- 4. Тестирование показывает наличие дефектов
- 5. Отсутствие ошибок может быть обманчивым
- 6. Раннее тестирование
- 7. Тестирование зависит от контекста
Простое объяснение
Как определить, что вы применяете правильную стратегию тестирования? Нужно не отклоняться от базовых принципов тестирования.
Мы собрали 7 принципов тестирования, широко практикуемых в индустрии.
Чтобы понять это нагляднее, представьте сценарий, при котором вы перемещаете файл из папки А в папку В.
Кроме стандартных, неошибочных сценариев поведения, какие тест-кейсы тут можно набросать?
- Перемещать файл, когда он открыт в каком-то приложении
- Нет прав на перемещение файла в папку В
- Папка В находится на общем диске, и весь его объем уже забит
- Папка В уже имеет файл с таким же именем (ну и так далее)
Или представьте, что есть 15 полей ввода, каждое имеет по 5 возможных значений, таким образом количество возможных комбинаций равно 5 в 15-й степени.
Протестировать все комбинации — невозможно, это будет огромное превышение времени и затраты на тестирование вырастут экспоненциально. Нам нужны принципы и стратегии оптимизации усилий тестирования.
Вот 7 принципов правильного тестирования
1. Все протестировать невозможно
Да, это невозможно. Вместо этого, требуется оптимальное тестирование, на основании оценки рисков.
Важнейший вопрос — как оценить эти риски?
Для этого нужно сделать мысленное упражнение: представьте, что вы тестируете операционную систему. Задайте себе вопрос: по своему опыту, какая операция, скорее всего, «положит» операционку? Уверен, ответ будет приблизительно такой: «открыть 10 приложений одновременно».
Итак, если вы тестируете операционную систему, то ошибки, скорее всего, будут сосредоточены «где-то в области многозадачности». И они должны быть протестированы тщательно. Что приводит к следующему принципу: классификация дефектов
2. Кластеризация дефектов
Кластеризация дефектов — принцип, который предполагает, что небольшое количество модулей содержат в себе большинство багов. Это яркий пример применения в тестировании принципа Парето: 80% проблем таятся в 20% модулей.
Имея опыт, можно легко определить эти проблемные модули. Но в этом подходе свои проблемы.
Если те же тесты повторяются снова и снова, то «почти одинаковые» тест-кейсы не смогут помочь найти больше ошибок.
3. Парадокс пестицида
Повторное применение одного и того же пестицида для истребления насекомых со временем приведет к выработке у насекомых устойчивости к этому пестициду. То же касается и тестирования софта. Если есть некий набор повторяемых тестов, он будет бесполезен в определении новых дефектов.
Чтобы решить эту проблему, тест-кейсы должны регулярно просматриваться и обновляться, должны добавляться новые тест-кейсы, ориентированные на другую функциональность или тестирующие уже существующую под другим углом.
Тестировщики не могут всегда зависеть от уже существующих тест-кейсов. Они должны постоянно развиваться, улучшая существующие тест-кейсы. Но даже так, делая все добросовестно, никогда нельзя дать гарантий, что багов в продукте нет. На презентации Windows 98, которую, между прочим, проводил сам Билл Гейтс, система «упала».
Казалось бы, такая корпорация как Microsoft, уж точно протестировала свою операционку вдоль и поперек, и не могла рисковать своей репутацией, но нет, операционка упала, презентация была почти что сорвана.
4. Тестирование показывает наличие дефектов
Принцип: тестирование говорит нам о наличии багов, но ничего не говорит об отсутствии багов. То есть, тестирование снижает вероятность существования необнаруженных дефектов остающихся в софте, но даже если ни один дефект не найден, это не есть доказательство полной корректности кода.
Но что, если вы делаете работу добросовестно, соблюдаете все требования и делаете свой продукт на 99,99% свободным от багов и он все равно не соответствует требованиям клиента?
Это подводит нас к следующему принципу: отсутствие ошибок может лишь казаться.
5. Отсутствие ошибок может быть обманчивым
Бывает, что софт, на 99% свободен от ошибок — тем не менее он не удовлетворяет требованиям. Это может быть в случае, если система тестировалась тщательно, но прописанные требования были некорректными. Тестирование софта — это не только поиск багов. Это еще и проверка, отвечает ли софт бизнес-требованиям. Этот принцип говорит о том, что поиск и устранение багов не поможет, если построенная система изначально неправильно построена и не соответствует требованиям клиента.
Для решения этой проблемы, следующий принцип: раннее тестирование.
6. Раннее тестирование
Тестирование должно начинаться как можно раньше в жизненном цикле разработки. И любые баги, еще на этапе сбора требований, или на этапе дизайна, будут отловлены заблаговременно. И да, намного дешевле исправить дефект на ранних стадиях разработки. Но как рано должно начинаться тестирование? Рекомендуется начинать поиск с момента, когда описаны требования.
7. Тестирование зависит от контекста
Тестирование зависит от контекста; это значит, что способ, которым вы тестируете сайт для e-commerce, будет отличаться от способа тестирования мобильного приложения. Софт бывает самый разный и подход к его тестированию тоже бывает самый разный. Необходимо применять разные подходы, методологии, техники и типы тестирования в зависимости от приложения. Тестирование POS-системы в ритейле отличается от тестирования АТМ-банкомата.
Миф: принципы — только для справки. На практике они не применяются.
Это неправда. Знание этих принципов тестирования помогает создавать правильную стратегию тестирования, и писать правильные тест-кейсы для отлавливания ошибок.
Научиться применять эти принципы — как научиться водить автомобиль.
Сначала, пока учишься водить, обращаешь внимание на переключение передач, на скорость, сцепление и т.п. С опытом, просто фокусируешься на вождении, все остальное делается на автомате.
Так же с принципами тестирования. Опытные тестировщики знают эти принципы в совершенстве и применяют их не задумываясь.