7 Принципов тестирования
Основы тестирования,  Тестирование

7 принципов тестирования

7 принципов, на которых базируется тестирование, 7 золотых правил, которым нужно следовать. Все мы про них слышали, но не все задумывались над их практическим применением. В этой статье мы немного подробнее разберём все 7 принципов и посмотрим на то, как они могут улучшить процесс тестирования.

1. Исчерпывающее тестирование невозможно

Я думаю, сейчас всем должно быть понятно, что для современных приложений исчерпывающее тестирование невозможно.

Если непонятно, то давайте объясню.

Представим форму, где нужно будет собрать себе обед. На форме будет 3 списка, в которых нужно выбрать по одному значению. В каждом списке есть по 3 опции.

Для того чтобы протестировать и перебрать все-все значения и комбинации нам потребуется 27 тестов (3 в 3-ей степени).
Ну, звучит пока реально. А что будет если мы расширим наше меню напитками и салатами тоже по 3 варианта?
Количество тестов превратится в 243 (3 в 5-ей степени). А что если добавить больше вариантов блюд? А что если выбор блюд из какой-то категории сделать необязательным? Количество тестов начнём расти в геометрической прогрессии.

Кстати, на форме были только позитивные значения. Если на форме можно будет вводить негативные значения, то количество тестов будет расти ещё сильнее.

Я думаю вы поняли к чему я клоню. Невозможно, либо нецелесообразно тестировать все возможные варианты и комбинации значений. Ведь это займёт крайне много времени. А хотим ли мы тратить годы работы для тестирования одной жалкой формы? А что если в ней что-то поменяется?

Мне страшно представить тестировщика, который перебрал все возможные варианты на этой форме и ему сказали сделать это ещё раз 🙂

Поэтому в тестировании мы используем анализ рисков и приоритетов, для того чтобы проверить наиболее показательные варианты значений. Для этого существуют техники тестирования (Test techniques), либо их ещё называют техники тест-дизайна (Test design techniques). О них поговори как-нибудь в другой раз.

2. Принцип скопления дефектов

Этот принцип говорит о том, что в наименьшем количестве мест, находится наибольшее количество дефектов. Это чем-то похоже на правило Парето 80/20, где 80% дефектов находятся в 20% функций.

Почему дефекты любят скапливаться в одном месте?
Очень часто какая-то область кода может быть сложной или плохо написанной. Поэтому в ней и может скапливаться бесчисленное количество дефектов.

Может сработать и «эффект бабочки». Мы исправляем меняем что-то в коде и тем самым создаём много неожиданных последствий в местах, где что-то поменяли.

В связи с этим, мы должны учитывать это в своей стратегии и делать упор на те места, где больше всего дефектов.

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

3. Эффективность раннего тестирования

Активности по тестированию должны начинаться как можно раньше в жизненном цикле нашего продукта.
Ведь чем позже мы нашли проблему, тем дороже её будет исправить.

Ниже мы можем увидеть, как меняется цена дефекта в зависимости от фазы на которой он был найден.

7 Principles of Testing - Part 2

Поэтому мы должны делать сильный упор на статическое тестирование и верификацию, чтобы найти проблемы на ранних этапах и исправить их как можно раньше. Такой подход называется “Shift-Left”.

Наглядно принцип раннего тестирования

Да, в этом подходе тестирование будет стоить немного дороже, чем если бы мы совсем не тестировали требования.
Но как говорится «Скупой платит дважды».

Ведь если у нас хорошие и качественные требования, то с большей долей вероятности мы сделаем качественный продукт, который будет нужен пользователям.

4. Парадокс пестицида

Если одни и те же тесты проходить снова и снова, то рано или поздно они перестанут находить дефекты.

QA] Hiệu ứng thuốc trừ sâu (Pesticide paradox)

То есть, наш продукт со временем адаптируется к нашим тестам.

Но это не будет означать, что в нем не будет дефектов.

Для того, чтобы избежать таких ситуаций рекомендуется следующее:

  • Использовать разные данные при тестировании
  • Постоянно пересматривать и улучшать свои тесты
  • Добавлять новые тесты
  • Использовать разные техники тестирования
  • Проводить ротацию кадров

Неформальные техники тестирования основанные на опыте (например, исследовательское (Exploratory testing) и свободное тестирование (Ad-hoc)) очень хорошо помогают бороться с парадоксом пестицида.

5. Заблуждение об отсутствии ошибок

Сколько бы мы не находили ошибок, это не даст нам гарантию того, что мы нашли их все или что продукт будет качественным.

Продуктов без багов (Bug free) не существует!

Поэтому задача тестирования состоит не в нахождении всех дефектов, а нахождении наиболее важных дефектов до того, как их найдут пользователи. Да, при этом ещё и не забывая про верификацию и валидацию.

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

К тому же, уверены ли вы, что в вашем продукте нет нефункциональных багов?

Например, удобства использования, производительности, совместимости, безопасности и так далее.

6. Тестирование показывает наличие дефектов

Тестирование может показать, что в нашем продукте есть дефекты, но не может доказать, что ошибок нет.

Ведь они есть всегда 🙂 см. принцип 5.

Этот принцип как раз и говорит, что тестирование напрямую не улучшает качество, а лишь показывает, что в продукте есть дефекты. Это помогает сделать качество лучше тем, что мы знаем о проблемах и можем их исправить. А вот уже улучшением качества может заниматься Quality Assurance.

7. Тестирование зависит от контекста

Не существует единственного верного способа тестировать программное обеспечение. Вряд ли систему контроля жизнеобеспечения мы будем тестировать как интернет-магазин. Даже 2 очень похожих интернет-магазина могут тестироваться совсем по-разному.

Ведь контекст может быть разный.

Что может входить в контекст тестирования:

  • Тип продукта — веб, десктоп, мобайл, сервис и тд
  • Цель продукта — продажа товаров, игра, обеспечение безопасности
  • Проектная команда — количество человек, специализация, опыт и тд
  • Сроки — как много времени у нас есть до релиза
  • Ожидаемый уровень качества — чем выше показатель, тем тщательнее нужно тестировать
  • Риски — существует огромное число рисков, которые нужно учитывать. Например, из-за того, что команда неопытная в разработке продукта с заявленными целями и типом, есть риск, что в продукте может быть много багов. Тем самым, достижение ожидаемого уровня качества может затянуться.
  • Доступные инструменты — есть ли у нас возможность пользоваться какими-то инструментами для тестирования или необходимо изобретать самим.
  • И другие моменты

Исходя из данных нашего контекста, мы и будем строить эффективный процесс тестирования.