Home

В своей новой статье Наталья Руколь, автор и ведущая Школы Тест-Аналитика, рассказывает о самой сложной части тест-анализа: отказа от тестов по причине нехватки времени. Как, когда, какие?

Тяжкая миссия тестировщика

Какая самая главная задача тестировщика? Какой навык является наиболее ценным для хорошего тестирования?

Начинающие тестировщики обычно считают, что их главная задача - придумать как можно больше тестов:

• Что может влиять на выполнение той или иной операции?

• При каких значениях всё может сломаться?

• Как “положить” систему?

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

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

• чёткое разбиение на классы эквивалентности и доменный анализ,

• комбинаторику значений параметров действия,

• pairwise и triplewise

• и т..д.

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

И именно здесь - ступень для перехода на следующий уровень экспертизы и мастерства. В дело вступает реальность: в большинстве случаев провести достаточное количество тестов невозможно. “Спасибо, что вы столько тестов придумали, но продукт мы отдаём в тестирование сегодня вечером, а релиз должен состояться завтра”.

У некоторых тестировщиков такая ситуация вызывает постепенную демотивацию: мы не можем протестировать всё! Но просветлённые тестировщики смотрят на ту же проблему под другим углом: “отлично! вот это challenge! мне надо придумать, как протестировать это всё действительно быстро!”. А чтобы протестировать в сжатые сроки, от каких-то тестов придётся отказаться. Каждый из них может найти потенциальный дефект, и получается, что, отказываясь от проведения того или иного теста, мы повышаем вероятность пропуска дефекта. Насколько критичного? Зависит от теста, которому мы говорим “прости и прощай, но не в этот раз”. И получается, что главная задача тестировщика в этом случае - выбрать, какие тесты мы не будем проводить. Не будем тестировать, Карл!

Последовательность выбора тестов

Раз от каких-то тестов всё равно придётся отказаться, и всё мы протестировать не сможем - может, и не надо сразу придумывать кучу тестов? Может, раз ресурсы ограничены, потестим, что успеем?

Давайте отвлечёмся ненадолго от тестирования и рассмотрим другой пример. Вы упаковали чемодан перед поездкой в отпуск и проверяете, проходит ли он по весовым нормативам. Увы! Перевес 3 килограмма, надо что-то выложить. Как вы это сделаете? Откроете чемодан и посмотрите, что в нём, принимая решение - или вслепую вытащите первые подряд вещи, пока вес не уменьшится? Во втором случае есть серьёзные риски. Например, вы нечаянно достанете оттуда САМЫЕ важные вещи: зарядки, кошелёк, паспорт, телефон…

Конечно, вам даже в голову не придёт идея так делать! Вы посмотрите на содержимое чемодана и, оценив общий масштаб (что в нём есть), сможете выбрать наименее ценное (что вы можете оттуда достать). Чтобы принимать решения, нам нужна достаточная входная информация!

Итого, пирамида наших действий строится примерно следующим образом:

Как обуздать свой аппетит?

Как бы ни хотелось всё протестировать, пора смириться с данностью: не получится! Но как выбрать самое важное? Тут нам поможет целый набор инструментов, про 3 основных из которых написано ниже:

1. Классы эквивалентности и доменный анализ

Это самые базовые техники тест-аналитика. Благодаря разбиению продукта на классы эквивалентности, мы можем ограничить количество значений тестируемых параметров на 1-м этапе анализа. Например, форматы загружаемого изображения. Каждый поддерживаемый формат (PNG, JPG, TIFF и т.д.) обрабатывается по-разному и, несмотря на то, что они все входят в класс “поддерживаемые типы файлов”, нам нужна каждая из этих проверок. Но что делать с неподдерживаемыми? Их значительно больше, и проверить каждый займёт слишком много времени, но обработка неподходящих форматов должна вестись одинаково. В этом случае мы целый класс эквивалентности “неподдерживаемые форматы” можем рассматривать как значение, и нам достаточно протестировать загрузку только одного файла, не являющегося картинкой.

2. Риски качества

В предыдущем пункте мы очень смело отказались от проверки большого набора входных данных просто потому, что они эквивалентны, и их много. Всегда ли мы можем так сделать? Конечно, нет!

Отказываясь от того или иного теста, мы решаем: а что будет, если мы пропустим тут ошибку? Какова вероятность этого происшествия и какова критичность потенциально пропущенного дефекта?

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

Риск невелик, критичность потенциальной ошибки тоже. Adios, куча тестов, hasta la vista!

Но в случае с классом “поддерживаемые файлы” мы не можем себе позволить отказ: критичность ошибки (не загружается поддерживаемый тип файла) высока,  вероятность (все обрабатываются по-разному, могут быть специализированные ошибки) тоже. Будем проверять!

3. Комбинаторика несвязанного

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

При таком совмещении важно учитывать несколько правил:

1. Не перемудрить. Когда вы в тесте проверяете десяток разных влияющих факторов, локализовать обнаруженную ошибку очень сложно. В моей практике приемлемое число параметров для последующей локализации - 3-4.

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

Конечно, эти 3 инструмента - неполный список. На Школе Тест-Аналитика мы разбираем более детально и тестирование наших имеющихся тестов “на профпригодность”, и техники сокращения количества тестов (самая популярная из которых - pairwise). Но даже если вы просто перейдёте на рассмотренный в статье алгоритм, меньше станет и тестов, и пропущенных ошибок. Win-win!

Подведём итоги

Адаптированный под жёсткие сроки, и при этом не жертвующий качеством тестирования тест-анализ, обычно строится по следующему алгоритму:

1. Декомпозиция продукта на объекты, состояния и действия системы

2. Поиск классов эквивалентности и выявление возможности “сэкономить” на них (подключая разработчиков и понимание архитектуры ПО!)

3. Комбинаторика тестов используя ДПЗ (действия-параметры-значения), попарное тестирование (pairwise), таблицы решений (decision tables).

4. Оценка тестов на “профпригодность” по 3-м ключевым критериям: вероятность ошибок, критичность потенциальных ошибок, комбинирование разных проверок в одном тесте (желательно - с продуманной заранее подготовкой тестовых данных).

Всем удачи в нелёгкой борьбе с багами, и да прибудет с вами сила!