Что такое исчерпывающее тестирование?

• Кратко
• Подробнее
• Пример
• О (не)возможности на практике
• Ситуации когда все же пытаются
• Исчерпывающее vs Эффективное
• Сложности
• Выгоды

Кратко 

Исчерпывающее тестирование (exhaustive testing) — специфический вид тестирования, применяемый в редких ситуациях, когда нужно протестировать все возможные тестовые вводы в приложение, покрывая все возможные тестовые сценарии. Методика крайне затратная по времени, однако ее результатом является приложение с полным отсутствием дефектов.

Подробно

Альтернативные названия: «полное тестирование», также «brute force тестирование», то есть «полный перебор всех вариантов».

Итак, одна из методик тестирования, при которой проверяются все возможные входные комбинации. Это значит, что проверяется тестируется всё «сверху донизу и вглубь», покрывая каждый возможный вариант, с целью сделать приложение идеально надёжным, гарантировать на 100%, что приложение не упадёт ни при каких обстоятельствах.

В большинстве случаев, однако, полное исчерпывающее тестирование на практике невозможно, поскольку нереально покрыть абсолютно все тестовые ситуации (сценарии). 

Несмотря на это, тестировщики в некоторых ситуациях пытаются покрыть как можно больше тестовых сценариев (особое внимание уделяя негативным). 

При этом исключаются заведомо маловероятные сценарии, которые допустимо игнорировать, поскольку они с 99,999% не повлияют на функциональность, если смотреть в целом.

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

Быстрый пример

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

• Например, что пользователь может ввести пароль длиной в 12 символов, в шести различных комбинациях.
• Итого, сразу получаем 6¹² (шесть в двенадцатой степени) возможных комбинаций, то есть 2176782336, больше 2 миллионов вариантов
• Разумеется, уйдёт нереально много времени на тестирование всех этих входных значений, и на практике невозможно проверить их все
• Поэтому в абсолютном большинстве случаев исчерпывающее тестирование остаётся лишь теоретической концепцией

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

Почему нереально

В целом уже должно быть понятно, а есть и другие ограничения:

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

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

• Тестирование восстановления после сбоев: проверка восстановления приложения путем анализа возможных причин. Приоритизация функциональности с низким показателем восстановления, и уточнение, какая функциональность требует особо тщательного тестирования
• Регрессионное: всякий раз после устранения бага тестировщик должен валидировать приложение, проверяя, что после выполненных действий функциональность осталась не затронутой. 
• Бизнес-импакт: этот параметр помогает упростить процесс и сделать более эффективным. Команда обращается к бизнес-аналитику, чтобы оценить влияние (импакт) сбоя какой-то функции на другие модули, для оценки рисков с точки зрения бизнеса. 
• Тестирование на отказ, какие функции приложения наиболее вероятно потеряют функциональность. Таким образом, тестировщики смогут уделить больше внимания самым проблемным модулям, и присвоить им приоритет 
• Ad-hoc—тестирование: поиск дефектов во всех возможных модулях интуитивно
• Ревью: к процессу подключаются бизнес-аналитики, менеджеры, или другие сотрудники, имеющие отношение к созданию приложения, внутри или вне компании, для лучшего понимания требований 
• Фокус-тестирование: тестирование сосредоточено только на приоритетных частях приложения, в ситуации когда важна скорость и простота
• Обновление тест-кейсов: при проверке и обновлении некоторых тест-кейсов

Исчерпывающее vs Эффективное

Челленджи

• Как уже говорилось выше, на практике невозможно провести исчерпывающие тестирование более-менее реального приложения. Как гласит один из главных принципов тестирования (в большинстве источников это вообще Первое правило тестирования), исчерпывающее тестирование невозможно; но в некоторых, исключительных, ситуациях тестировщики могут пытаться покрыть как можно больше возможных ситуаций (сценариев), хоть это бывает трудно и утомительно
• Ручное тестирование: ручные тестовые сценарии реального приложения в «исчерпывающем» объеме вряд ли возможны, и вероятно это самый большой челлендж QA-команды
• Из перечисленного выше должно быть понятно, что полное исчерпывающее тестирование потребовало бы колоссального времени. Протестировать реальное приложение полностью, со всеми зависимостями, во всех возможных ситуациях, и при любом поведении пользователей — это сотни лет
• Утомительно: даже тестирование какой-то части, например мобильного приложения, exhaustive-путем утомляет и демотивирует команду
• Грамотно подобрать входные значения бывает сложно, — математика и логика не всем легко дается

Преимущества

• В приложении нет ни одного заметного бага: в идеале протестированный продукт полностью, целиком свободен от любых багов, работает идеально с точки зрения пользователя
• Надежное приложение, устойчивое в любым ситуациях
• Разумеется, таким идеальным приложением доволен любой клиент
• Оценка рисков: даже «приближение к исчерпывающему тестированию» позволяет более-менее достоверно оценить вероятность багов в отдельных частях/модулях

***