😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеСемь главных принципов тестирования

Семь главных принципов тестирования

Автор

Дата

Категория

Собрали 7 базовых принципов тестирования, которые должен знать каждый QA.


Простое объяснение

Как определить, что вы применяете правильную стратегию тестирования? Нужно не отклоняться от базовых принципов тестирования.

Мы собрали 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-системы в ритейле отличается от тестирования АТМ-банкомата.

Миф: принципы — только для справки. На практике они не применяются.

Это неправда. Знание этих принципов тестирования помогает создавать правильную стратегию тестирования, и писать правильные тест-кейсы для отлавливания ошибок.

Научиться применять эти принципы — как научиться водить автомобиль.

Сначала, пока учишься водить, обращаешь внимание на переключение передач, на скорость, сцепление и т.п. С опытом, просто фокусируешься на вождении, все остальное делается на автомате.

Так же с принципами тестирования. Опытные тестировщики знают эти принципы в совершенстве и применяют их не задумываясь.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

5 КОММЕНТАРИИ

Подписаться
Уведомить о
guest

5 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
andy
andy
1 год назад

Принципы очевидные и из разряда «мы за все хорошее и против всего плохого».

aviator
aviator
1 год назад

Спасибо, КЭП 🙂

Evgeny
Evgeny
1 год назад

Второй принцип, очевидно, не «классификация», а «кластеризация» дефектов?

testengineer.ru
1 год назад
Ответить на  Evgeny

да, все верно — допустили ляп в терминологии. Исправили в статье.

Huane_G
Huane_G
7 месяцев назад

В последней строке («…к следующему принципу: классификация дефектов») принципа № 1 забыли заменить классификацию на кластеризацию 🙂

$1100*
медианная зарплата в QA в ноябре 2021

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать

Последние комментарии