🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Перевод статьи «A complete philosophy of software testing in under 50 words».
Философия, которую можно изложить в двух словах, там и должна оставаться.
- Надпись на вывеске отеля в Лос-Анджелесе
(конец 1970-х – начало 1980-х)«Наш главный приоритет — удовлетворять потребности клиента за счёт ранней и непрерывной поставки ценного программного обеспечения.»
— Двенадцать принципов гибкой разработки ПО
Базовая философия
Мой заголовок, конечно, провокационный. Всё можно уложить в 40 слов. Вот 34 (без учёта нумерации)
- Тестирование — это процесс, а не разовая акция.
- Главная цель — находить риски, снижать их и держать под контролем.
- Риски — вещь индивидуальная, нет универсальных рецептов.
- Лучший баг — тот, которого нет (предотвратить дешевле, чем чинить).
- Чем раньше найдешь проблему — тем проще и дешевле её исправить
Всё, базовая философия изложена. Дальше — только практика.
И ещё несколько слов…
Заголовок статьи — это не только провокация, но и лукавство. У меня нет чёткого критерия, чтобы измерить «полноту» философии тестирования. Тем не менее, эта философия рабочая и плодотворная (по крайней мере, для рыночно-ориентированного ПО в условиях мягкого регулирования). Так что её я и буду придерживаться.
Впрочем, полнота — не главное. Лично я скорее сторонник решения локальных проблем, чем грандиозных теорий, которые «пытаются разом объяснить всё» (как и в разработке ПО, я предпочитаю подход Unix инструментов — простых и специализированных). Но надеюсь, что пункты 1-5 и дальнейшие примеры помогут прояснить хотя бы некоторые аспекты тестирования. По сути, эти пункты — моя лучшая попытка сформулировать основные принципы, которыми я руководствовался в работе почти 30 лет. Но, как показывает опыт, многие компании их упускают.
Я предлагаю их не как незыблемые истины, а как инструменты, ориентиры или эвристики — всё ради качества продукта.
Но сначала немного менее афористичные пояснения к базовой философии.
Тестирование — это процесс
Как и разработка ПО, тестирование — это процесс, интеллектуальное упражнение в решении практических задач (или, если следовать Джеймсу Баху, прикладная эпистемология). Это не единый, чётко очерченный процесс, а комплекс активностей и практик, мастерство в которых превращает его в ремесло.
Среди этих активностей (но не только):
- Анализ бизнес- и продуктовых требований на ясность, полноту и тестируемость
- Оценка предлагаемых UI/UX решений
- Подготовка тестовых данных
- Анализ архитектуры на уязвимости и узкие места
- Разработка стратегии и тактики тестирования
- Создание тест кейсов
- Исследование поведения системы (исследовательское тестирование)
- Воспроизведение багов, найденных пользователями или командой
- Поиск первопричин дефектов
- Анализ логов на аномалии и подсказки о поведении системы
- Проверка зон риска и поиск новых
- Разработка и поддержка автотестов
- Внедрение возможностей для тестируемости системы
- Запуск тестов (ручных и автоматизированных)
- Интерпретация и передача результатов тестирования
- Разбор проблем интеграции в сложных системах
- Оценка входящих баг репортов
- Управление сторонними тестировщиками
- Обучение команды тест навыкам
- Подготовка нагрузочных сценариев
- Оценка готовности к релизу
- Анализ обратной связи: поддержка и передача проблем нужным командам
Важно не путать саму деятельность с её результатами (тест планами, кейсами, баг репортами, отчётами и т. д.).
Как и другие сложные навыки — разработка ПО, танцы, баскетбол или философия — тестирование осваивается на практике: через ошибки, обратную связь и бесконечные попытки. (Подробнее о тестировании как петле обратной связи — ниже.) Именно поэтому важно фокусироваться на процессе, а не только на итогах.
Джей Розенберг в своей книге The Practice of Philosophy сравнивал становление философа с обучением танцам — со всеми шишками и выбитыми пальцами. А Элвин Плантинга говорил, что философское размышление — это «просто усердное мышление», акцент на действии. То же самое и с тестированием: это ремесло, которое оттачивается в работе.
Тестирование и риски
Тестирование направлено на выявление, снижение и контроль рисков, которые угрожают продукту, клиентам или бизнес ценности в конкретном контексте разработки. Поскольку ценность продукта меняется от проекта к проекту, меняются и связанные с ним риски. (Подробнее о зависимости от контекста — ниже.)
Один и тот же риск может относиться сразу к нескольким категориям. Например, серьёзная уязвимость в безопасности:
- ставит под удар клиентов
- наносит ущерб бизнесу
Яркий пример — масштабный сбой CrowdStrike в июле 2024 года, вызванный ошибкой в логике обработки именованных каналов (named pipes) в Windows. Эта ошибка прошла мимо тестов компании, но в продакшене привела к глобальным последствиям:
- сбои в работе Microsoft сервисов
- отменённые и задержанные авиарейсы
- неработающие платёжные системы
- перебои в работе госучреждений, экстренных и медицинских служб
Общий ущерб для бизнесов по всему миру превысил $10 млрд, а сама CrowdStrike столкнулась с исками (например, от Delta Air Lines) и финансовыми потерями
Риски могут конкурировать между собой, вынуждая искать баланс. Например:
- Улучшение производительности для пользователей может замедлить выход продукта, снизив его бизнес ценность
- Решение: отложить оптимизацию на следующий релиз, чтобы минимизировать риски для бизнеса
Тестирование помогает взвешивать риски и преимущества.
Контекстная зависимость
Риски глубоко зависят от контекста. Универсальных решений для оценки рисков не существует. Они определяются не только тем, что мы создаём, но и для кого и зачем.
Предположим, мы добавляем семантический поиск на страницу результатов Zillow (это отвечает на вопрос «Что?»). Мы можем делать это:
- Чтобы улучшить опыт покупателей с четкими намерениями, показывая им более релевантные результаты напрямую (без необходимости ручной фильтрации)
- Чтобы принести пользу бизнесу, улучшая ключевые метрики вовлеченности, удерживая этих клиентов на сайте дольше (возможно, стимулируя запись на просмотры или контакты с агентами)
Предотвращение риска лучше, чем его обнаружение.
Раннее обнаружение лучше, чем позднее — и зачастую дешевле.
Ответы на вопросы «Почему?» (быстрее получать релевантные результаты, повысить вовлеченность пользователей) и «Для кого?» (покупатели, бизнес) могут быть весьма сложными. Однако связанная с качеством деятельность, включая планирование тестирования, должна учитывать эти детали и адаптироваться по мере их изменения или появления новых рисков для достижения желаемой ценности.
Разумеется, детали того, как мы создаем ценность, также важны для оценки рисков. Слишком сложная техническая реализация может ухудшить производительность и надежность, что повлечет последствия для клиентов и бизнеса. То, как работа над проектом распределяется и выстраивается между командами, доступность и состояние тестовых сред (интеграционных и других), доступ к релевантным и репрезентативным тестовым данным — все это (наряду с другими факторами) также влияет на контекст.
Тестирование должно быть чувствительным к этим аспектам реализации. Например:
- Проблемы с интеграционными тестовыми средами могут скрыть дефекты взаимодействия между компонентами
- Отсутствие репрезентативных тестовых данных может привести к тому, что проблемы проявятся только у реальных пользователей
Таким образом, эффективное тестирование требует:
- Понимания конкретного контекста продукта (что, для кого, зачем)
- Гибкости для адаптации к изменениям этого контекста
- Учета технических и организационных ограничений реализации
Это не абстрактные принципы, а практические ориентиры для принятия обоснованных решений в тестировании.
Предотвращение и раннее выявление
На первый взгляд эти утверждения могут казаться схожими:
- Предотвращенный риск лучше обнаруженного
- Раннее обнаружение лучше позднего — и зачастую дешевле
Однако они не эквивалентны, если под «предотвращением» понимать недопущение реализации риска.
Конкретную ошибку в UI дизайне можно выявить:
- Во время дизайн ревью
- Или непосредственно перед реализацией, когда разработчик только планирует работу
В обоих случаях ошибка не попадает в реализацию и не будет обнаружена на более позднем (возможно, значительно более позднем) этапе. Тем не менее, оптимально находить проблемы:
- Пока изменения, их вызвавшие, еще свежи в памяти
- До наслоения других изменений или зависимостей
- До попадания в продакшен и воздействия на клиентов или других потребителей
То же самое относится к:
- Неоднозначностям или пробелам в требованиях продукта
- Потребностям в аналитике или данных
Ранние усилия в этих направлениях помогают:
- Предотвратить целые категории проблем
- Остановить волну поздних обнаружений
- Избежать дополнительных затрат
Две главные ловушки, которых стоит избегать:
- Плохие идеи на старте. Если идея изначально слабая, не стоит тратить на неё силы. Лучше отбросить сразу, чем ждать, пока она съест кучу ресурсов.
- Узкая техническая фокус. Можно сделать идеальный с точки зрения кода продукт, который никому не нужен — просто потому что забыли спросить: «А зачем это клиенту?»
Оба случая повод начать тестировать раньше (об этом ниже).
Практическое применение базовой философии
Данный подход раскрывает свою ценность, когда основные принципы 1-5 применяются в конкретных ситуациях. Приведённые ниже примеры носят иллюстративный характер и могут быть расширены в следующих материалах.
Качество
Термин «качество» не фигурирует в 1-5, однако тестирование неразрывно с ним связано. Первый принцип Agile манифеста гласит: «Наивысшим приоритетом является удовлетворение потребностей клиента… через раннюю и непрерывную поставку ценного ПО». Мы согласны: разработка ПО — это в первую очередь доставка ценности, которую мы понимаем как обеспечение качества.
Качество определяется ценностью. Споры о качестве часто становятся бессмысленными дискуссиями — путаными, если не откровенно противоречивыми, и обычно без чёткого предмета обсуждения.
В нашем подходе качество лучше рассматривать через призму ценности, которую мы стремимся обеспечить, и практик, помогающих эту ценность доставить. Такой акцент на ценности создаёт общий язык для Product, Design и Engineering команд, а также всего бизнеса. Вместо конфронтации мы движемся в одном направлении на протяжении всего жизненного цикла продукта.
Качество, безусловно, не сводится к тестированию. Однако тестирование — это деятельность по обеспечению качества, даже если не вся такая деятельность является тестированием.
Качество проявляется в процессе. Качество не является чем-то овеществленным или абстрактным; его нельзя «внедрить» в работу или «влить» в систему, как через капельницу. Не существует «прививки» от бесполезной работы. Фраза «встраивание качества» — это в лучшем случае сокращение, обозначающее соответствие практик обеспечения качества конкретным обстоятельствам разработки. Качество — это это результат, а не атрибут — свойство сложной системы деятельности множества команд, скоординированных в рамках жизненного цикла проекта.
Качество — это общая ответственность. Следовательно, качество не принадлежит какой-то одной команде или человеку, а является общей ответственностью всех участников разработки — от замысла до реализации и далее. Например, в Zillow Group когда-то использовали модель разработки «PEMD» (Product, Engineering, Marketing, Design), где инженеры по качеству относились к Engineering. Однако качество и тестирование явно касаются не только разработки (E), но и продукта (P), маркетинга (M) и дизайна (D). Ограничивать их инженерией — рискованно.
Тестирование
Управляйте рисками — и баги последуют. Тестирование — это функция управления рисками, а не поиск багов как таковых. Однако они связаны. Физик Дж. А. Уилер писал: «Вся наша задача — совершать ошибки как можно быстрее». Перефразируя, можно сказать, что тестирование — это поиск наиболее важных багов как можно быстрее: «наиболее важных» — согласно выявленным (или новым) рискам для продукта, клиентов или бизнеса; «как можно быстрее» — за счет раннего вовлечения тестирования на всех этапах жизненного цикла. Таким образом, тестирование обеспечивает итеративную обратную связь о текущем состоянии качества.
Определяйте объем тестирования на основе рисков. Понимая конкретные риски, связанные с разработкой, основная техническая задача тестирования — определить, что тестировать и почему (т.е. как тест связан с выявленными рисками). Затем можно решать, где (на каких уровнях), когда (например, с какой частотой или на каком этапе CI/CD) и как тестировать. Строго говоря, основная задача тестирования — это задача планирования, включающая как оценку рисков, так и определение стратегии и объема тестирования в ответ на них.
Тестирование — это не второстепенная задача, а важнейшая часть процесса. Многие виды тестирования (см. список выше) требуют сосредоточенности; они так же подвержены когнитивным затратам из-за прерываний и переключений контекста, как и разработка. Поэтому тестирование может «утонуть» в ограниченных ресурсах или объеме параллельных задач. Качество может пострадать из-за того, как команды управляют проектами. Более того, передача задач тестирования другим командам (например, разработчикам) почти наверняка повлияет на их нагрузку — при условии, что работа вообще будет выполнена или выполнена хорошо.
Начинайте тестировать раньше. Тестирование следует начинать как можно раньше («сдвиг влево») в жизненном цикле продукта, чтобы обеспечить раннюю обратную связь. Термин «shift-left testing» ввел Ларри Смит в 2001 году. «Влево» означает не только этап разработки, но и любые предыдущие шаги цепочки создания продукта. Некоторые возможности для такого сдвига были упомянуты выше в контексте предотвращения и обнаружения. Дополнительные примеры приведены ниже в разделе об автоматизации тестирования.
Внедряйте циклы обратной связи на основе рисков. Если нет веских причин для «большого взрыва» (одновременного выпуска всей разработки), тестирование должно (при прочих равных) идти параллельно с разработкой, обеспечивая раннюю обратную связь по выявленным рискам. Эта обратная связь затем влияет на дальнейшую разработку. Иными словами, тестирование — это серия циклов обратной связи, основанных на рисках. Частота циклов зависит от того, как организована разработка. Даже в случае «большого взрыва» планирование тестирования (включая автоматизацию) может идти параллельно.
Регулярно переоценивайте риски. По мере изменения рисков или появления новых в течение цикла, обратная связь может влиять на то, что и как мы тестируем. Это еще один пример зависимости от контекста, дающий возможность адаптировать стратегию и тактику тестирования по мере необходимости.
Форматы вовлечения команд важны. Качество страдает, когда тестирование откладывается на потом, особенно при множестве параллельных проектов, ведущих к переключению контекста и невозможности сосредоточиться. Это может быть следствием модели взаимодействия: например, когда тестировщики работают в нескольких командах одновременно. Ситуация усугубляется, если удаленные тестировщики (в других часовых поясах) работают с общей очередью задач от множества команд или проектов.
Универсальных решений не существует. Стратегия тестирования иногда обсуждается в отрыве от конкретного контекста разработки, как если бы существовала некая «идеальная стратегия». Из-за зависимости рисков от контекста такой стратегии нет. Хотя в планировании тестирования могут быть общие элементы, в реальности мы создаем индивидуальные планы, учитывающие специфику каждого проекта. «Универсальная стратегия» — если это не заблуждение — может быть лишь крайне абстрактным набором принципов, подобным философии тестирования из 1-5, или частью описания жизненного цикла продукта.
Автоматизированное тестирование
Ещё один метод тестирования. Наш подход принципиально не разделяет ручное и автоматизированное тестирование. Вместо этого мы рассматриваем разные методы тестирования.
Как, например:
- Некоторые истины случайны (например, «Тэрик Скубал лидировал по страйкаутам среди питчеров MLB в 2024 году» — это верно для 2024, но не для 2023)
- Другие истины необходимы («Ничто не может быть одновременно круглым и квадратным»)
- Заведомо ложное утверждение («7+5 < 12»)
…так и некоторые тесты выполняются вручную, другие — автоматически, а некоторые могут выполняться обоими способами.
Сначала «что», потом «как»
Как и ранее, ключевой принцип: сначала определить, что тестировать (для проекта) и почему. Затем уже решать вопрос «как» и выбирать между ручным и автоматизированным выполнением.
Сдвигайте автоматизацию ко времени сборки
Для обеспечения ранней обратной связи по качеству автоматизированные тесты следует по возможности выполнять на этапе сборки. Это позволяет:
- Использовать падение тестов как критерий остановки в CI/CD пайплайне
- Предотвращать попадание проблемных сборок в пре-продакшен или продакшен
- Оптимально выстраивать последовательность и слои тестирования
Повторяем: универсальных решений нет
Хотя существуют общие рекомендации по автоматизации, конкретная стратегия автоматизации — это часть стратегии тестирования, которая зависит от контекста разработки продукта. Здесь действует та же контекстная зависимость, что и в других аспектах тестирования.
Автоматизации недостаточно
Повторяю:
- Качество — это ценность
- Тестирование — это выявление и снижение рисков для этой ценности
Мы можем не достичь желаемой ценности по нескольким причинам:
- Реализованная функциональность (соответствуя спецификации) не приносит ожидаемой ценности
- В наших ожиданиях ценности есть пробелы
Выявление этих проблем, особенно второго типа, требует рационального решения задач в условиях неполных данных. Это включает анализ:
- Категорий пользователей
- Потребностей и сценариев использования
- Конкурентной среды
Опытные тестировщики и специалисты успешно справляются с подобными задачами даже при отсутствии четких требований.
Эта способность человеческого интеллекта заставила таких исследователей, как лингвист и философ Джерри Фодор, заявить, что настоящий ИИ потребует расшифровки механизмов человеческого мышления. Как выразился Фодор, необходимо решить «проблему Гамлета» — определить, «когда прекратить размышления» и принять рациональное решение. Пока этого не произошло. Возможно ли это вообще — отдельный вопрос. Но до тех пор автоматизированное тестирование не сможет заменить человека.»
Философия тестирования: от теории к практике
Истоки моего подхода
Мой взгляд на тестирование сформировался под влиянием философии и работ Джеймса Баха, который называл тестирование «прикладной теорией познания». Как и в философских исследованиях, здесь важно критическое мышление и способность адаптироваться к новым вызовам.
Автоматизация: инструмент, а не панацея
Автоматизированные тесты — как запись любимой песни: они полезны, но не заменят живого исполнения. Как метко заметил Бах: «Настоящий ручной тест невозможно автоматизировать». Суть не в технологии, а в понимании: сначала определяем, что тестировать, затем решаем, как.
Shift-left: не тренд, а необходимость
Идея раннего тестирования (термин Ларри Смита, 2001) — это логичный подход, а не дань моде. Оптимальная последовательность:
- Модульные тесты
- Контрактные тесты
- Интеграционные проверки
Философия в действии
- По Уилеру: «Наша задача — совершать ошибки как можно быстрее»
- Тестирование — это управление рисками, а не охота за багами
- Качество рождается во всей цепочке разработки, а не только в QA
Главный принцип
Хорошее тестирование сочетает техническую грамотность с глубоким пониманием продукта и критическим мышлением. Автоматизация — мощный инструмент, но именно человеческий интеллект превращает тестирование в искусство.
P.S. Все удачные идеи в этом тексте, вероятно, принадлежат моим учителям и коллегам. Все спорные утверждения — исключительно на моей совести.