Цели и задачи тестирования

1. Цели и задачи тестирования: почему мы не ищем все ошибки? (Верификация vs Валидация, принцип «Парето» в багах).

2. Миф об «абсолютном качестве» (Почему невозможно найти все ошибки)

«Абсолютное качество» (Zero Defects) — это гипотетическое состояние продукта, в
котором отсутствуют любые, даже самые незначительные, отклонения от требований.
Тестирование не может гарантировать отсутствие всех ошибок из-за комбинаторного
взрыва входных данных, ограничений по времени и конечности ресурсов.
Невозможность найти все ошибки объясняется тремя фундаментальными причинами.
• Математическая невозможность полного перебора. Даже для простой формы
входа, например поля «Имя» длиной от 1 до 50 символов со 100 возможными
вариантами символов, количество тестов равно 100 в пятидесятой степени. Это число
больше, чем атомов в наблюдаемой Вселенной. Полное тестирование одного такого
поля заняло бы миллиарды лет.
• Парадокс «невидимого бага». Ошибка может проявляться только при строго
определенной последовательности действий пользователя. Например: нажать
кнопку «Назад», подождать ровно три секунды, развернуть окно на весь экран, затем
нажать F5. Такую комбинацию невозможно предусмотреть ни в одном тест-плане.
Представьте, что вы тестируете тостер. Чтобы найти все ошибки, вам пришлось бы:
• проверить каждый миллиметр нагревательного элемента под микроскопом;
• испытать прибор при всех уровнях напряжения в сети от 100 до 250 Вольт;
• попробовать поджарить все виды хлеба, включая испорченный, мокрый и
замороженный;
• проверить работу при минус 30 и плюс 50 градусах Цельсия.

3. Цель тестирования ≠ найти все баги (Истинная роль тестировщика)

Цель тестирования — не исчерпывающий поиск дефектов, а предоставление
заинтересованным сторонам (менеджерам, разработчикам, владельцам продукта)
объективной и измеримой информации о текущем уровне качества, существующих
рисках и готовности продукта к выпуску. Тестирование — это инструмент принятия
решений, а не «сачок для ловли багов».
Начнём с распространённого заблуждения. Начинающие тестировщики гордятся сотнями
найденных ошибок и думают: «чем больше багов, тем лучше я работаю». Профессионал
знает иначе: сто косметических багов (опечатки, сдвинутые на пиксель кнопки) могут
быть менее ценны, чем один критический баг с потерей данных пользователя.
Правильная метрика успеха — не количество найденных багов, а количество
предотвращенных инцидентов в работающем продукте.
Тестирование решает три реальные задачи.
• Первая — оценка рисков. Тестировщик должен сказать менеджменту: «Если мы
выпустим продукт прямо сейчас, с вероятностью 80 процентов упадет платежный
шлюз». Например, обнаружено, что база данных не выдерживает тысячу
одновременных запросов, значит, каждый десятый пользователь получит ошибку
таймаута.
• Вторая — верификация критического пути. Нужно проверить, что сценарии, за которые
пользователи реально платят деньги, работают без сбоев. Если это интернет-магазин,
критический путь включает регистрацию, добавление товара в корзину, оплату и
получение чека. Всё остальное вторично.
• Третья — сбор данных для принятия решений. Тестирование даёт цифры: какой
процент тестов пройден, сколько открыто багов каждой критичности, сколько времени
потребуется на их исправление. С этими цифрами менеджер решает: выпускать релиз
или задерживать.

4. Верификация и Валидация — два разных смысла проверки

Верификация — это проверка того, правильно ли мы строим продукт, то есть соответствует ли
он формальным требованиям, спецификациям и стандартам. Валидация — это проверка того,
то ли мы строим, то есть удовлетворяет ли продукт реальным потребностям пользователей и
бизнеса. Первое отвечает на вопрос «сделали по инструкции?», второе — на вопрос «а ту ли
дверь мы открываем?».
Проще всего различить эти понятия на жизненном аналоге. Вы купили шкаф из ИКЕА и собрали
его строго по инструкции: все винты на месте, все полки закреплены правильно, дверцы
открываются и закрываются. Это верификация пройдена — вы сделали всё по правилам. Но
когда вы попытались поставить шкаф на кухню, оказалось, что он не влезает в угол, потому что
вы ошиблись при замерах ещё в магазине. Валидация не пройдена — продукт не решает вашу
реальную задачу.
Что включает в себя верификация:
• проверка соответствия кода техническому заданию;
• проверка, что все требуемые функции реализованы;
• проверка, что API возвращает данные в оговоренном формате;
• проверка, что интерфейс соответствует макетам по цветам и расположению элементов.
Что включает в себя валидация:
• проверка, что пользователь действительно может выполнить свою задачу без путаницы;
• проверка, что функция, прописанная в задании, вообще нужна людям;
• проверка, что продукт удобен в реальных сценариях использования, а не в идеальных
лабораторных условиях.

5. Принцип Парето в багах

Принцип Парето, также известный как закон 80/20, в контексте тестирования гласит: 80 процентов всех серьёзных ошибок и
сбоев содержится в 20 процентах модулей или компонентов системы. Это означает, что дефекты распределены
неравномерно: есть небольшая часть кода, которая «болит» постоянно, и большая часть кода, которая работает стабильно.
Этот принцип был подмечен экономистом Вильфредо Парето, который обнаружил, что 80 процентов итальянских земель
принадлежит 20 процентам населения. Позже закон проявил себя повсюду: 80 процентов выручки приносят 20 процентов
клиентов, 80 процентов опозданий случаются на 20 процентах маршрутов. Тестирование не стало исключением.
В программном коде это работает по нескольким причинам.
Некоторые модули объективно сложнее других. Модуль расчёта налогов или платёжный шлюз содержит в десять раз
больше логических ветвлений, чем форма обратной связи. Чем сложнее код, тем больше в нём потенциальных ошибок.
Некоторые модули меняются чаще других. Команда разработки постоянно дорабатывает ядро продукта, добавляет
функции, переписывает старые участки. Каждое изменение — это риск внести новый баг. А есть модули, которые не
трогали годами, и они работают как часы.
Некоторые модули пишутся разными людьми с разным уровнем квалификации. Опытный разработчик напишет
надёжный код с хорошей обработкой ошибок. Стажёр может не учесть краевые случаи. И эти 20 процентов «опасного»
кода будут давать 80 процентов проблем на продакшене.
Что это означает для стратегии тестирования. Если вы попытаетесь тестировать все модули с одинаковой
интенсивностью, вы потратите 50 процентов времени на проверку стабильных, редко меняющихся компонентов,
которые почти никогда не ломаются. И у вас не останется времени на глубокую проверку тех самых 20 процентов
сложного и часто меняющегося кода.
Правильная стратегия выглядит так:
проанализировать историю багов за последние месяцы;
выделить модули, в которых было найдено больше всего критических дефектов;
именно эти 20 процентов кода тестировать в первую очередь, наиболее тщательно, разными методами;
на стабильные 80 процентов кода тратить минимум времени, ограничиваясь дымовым тестированием.

6. Качество — это не отсутствие багов, а ценность для пользователя

Качество программного продукта — это не синоним «ноль дефектов», а степень удовлетворения
реальных потребностей пользователя при допустимых для него ограничениях по надёжности, скорости и
удобству. Идеальный с точки зрения отсутствия багов продукт, который никто не хочет использовать,
обладает нулевым качеством. Продукт с заметными, но терпимыми недостатками, который решает важную
проблему, обладает высоким качеством.
Рассмотрим конкретные примеры. YouTube иногда тормозит, видео может подвисать на пару секунд,
иногда случаются ошибки при загрузке. Пользователи знают об этих недостатках, но продолжают
пользоваться сервисом каждый день. Почему? Потому что YouTube решает фундаментальную задачу: даёт
доступ к огромному количеству видео бесплатно и удобно. Ценность от решения этой задачи многократно
перевешивает мелкие неудобства.
А теперь представим идеально работающий корпоративный портал для подачи заявок на отпуск. Он
никогда не падает, не теряет данные, все кнопки на своих местах, опечаток нет. Но интерфейс выглядит так,
будто его сделали в 1998 году, для заполнения заявки нужно пройти пять экранов, а подтверждение
приходит через три дня. Такой продукт будет ненавидеть вся компания. Он обладает нулевой ценностью
при идеальной верификации.
Почему пользователи прощают одни баги и не прощают другие? Есть несколько правил.
• Пользователь прощает баги, которые не мешают выполнить его основную задачу. Если в приложении
для заказа такси сдвинута иконка настроек, но машина приезжает быстро и дёшево, никто не уйдёт к
конкуренту.
• Пользователь прощает редкие баги, особенно если они не приводят к потере данных. Вылет
приложения раз в месяц — это раздражение. Вылет приложения раз в час — это бегство к конкуренту.
• Пользователь не прощает баги, которые заставляют его делать двойную работу или терять деньги. Если
интернет-магазин дважды списал деньги за один заказ, пользователь уйдёт и расскажет об этом десяти
друзьям.
• Пользователь не прощает баги, которые заставляют его чувствовать себя глупо. Если приложение
постоянно выдаёт непонятные ошибки с кодом вместо человеческого текста, пользователь решит, что
«это приложение для айтишников, а не для меня».

7. Риск-ориентированный подход

Риск-ориентированный подход в тестировании — это стратегия распределения ограниченных ресурсов
(времени, людей, инфраструктуры) таким образом, чтобы в первую очередь проверялись те функции и
сценарии, отказ которых приводит к наиболее тяжёлым последствиям: потере денег, утечке данных, полной
недоступности сервиса или массовому уходу пользователей. Всё остальное проверяется по остаточному
принципу.
Этот подход прямо отвечает на вопрос «почему мы не ищем все ошибки?». Потому что у нас нет
бесконечных ресурсов, но у нас есть понимание, какие ошибки критичны, а какие — нет. Мы сознательно
жертвуем проверкой неважного ради глубокой проверки важного.
Как работает риск-ориентированное тестирование на практике. Команда садится и отвечает на три вопроса
для каждой функции продукта.
• Первый вопрос: какова вероятность отказа этого компонента? Она зависит от сложности кода, частоты
изменений, квалификации разработчиков, истории багов в этом модуле.
• Второй вопрос: каковы последствия отказа? Здесь оценивается ущерб. Отказ кнопки «Поделиться в
соцсетях» — это небольшая потеря трафика. Отказ платёжного шлюза — это ноль выручки за всё время
простоя.
• Третий вопрос: насколько мы уверены в наших оценках? Если данных мало, риск считается повышенным.
После этого все функции раскладываются по матрице приоритетов. Высокий риск и высокие последствия —
тестируем максимально глубоко, разными методами, несколькими тестировщиками. Низкий риск и низкие
последствия — проверяем бегло один раз или вообще пропускаем.
Лучший жизненный аналог — медицина и диагностика. Врач скорой помощи не назначает полное МРТ
каждому пациенту с насморком. Он действует по принципу триажа: сначала определяет, кто умирает прямо
сейчас (инфаркт, инсульт, тяжёлая травма), и спасает их. Потом смотрит тех, кто может умереть через
несколько часов (аппендицит, внутреннее кровотечение). Потом тех, кто не умирает вообще (насморк,
лёгкая температура). Насморк получает минимальное внимание или отправляется домой с рекомендацией
«попить чай».
В тестировании то же самое. Критический риск — потеря денег, утечка персональных данных, полный отказ
сервиса. Проверяем жёстко, автоматизируем, прогоняем регресс перед каждым релизом. Высокий риск —
падение производительности при большой нагрузке, некорректная работа ключевого алгоритма.
Проверяем серьёзно, но с меньшей частотой. Средний риск — неправильная работа второстепенных
функций. Проверяем выборочно. Низкий риск — косметические баги, опечатки, редкие краевые случаи. Не
проверяем вовсе или чиним по факту жалобы.

8. Практическое задание № 1

Допфайл (ФЛЕШКА)

9. Домашнее задание

Выполнить на занятии.