Какие техники Вы используете при тестровании продукта? Как часто Вы меняете приоритетность задач? Вам важнее полное тестирование по тест-кейсам или исследовательское тестирование? Вы измеряете качество продукта по количеству багов или по их отсутствию?
На практике для разных проектов требуется свой индивидуальный подход к тестированию ПО. Как для нарезки продуктов используются разные ножи, так и для проекта нужны свои подходы и инструменты, способствующие быстрому результату от команды тестировщиков.
Я выделяю следующие техники тестирования:
1. Последовательность (шаг за шагом, по заранее согласованному сценарию). Актуально для web проектов с использованием функционального и тестирования верстки, а также для mobile проектов. Выполнять такое тестирование может начинающий тестировщик, выполняя тест-кейсы, а также ТОП-менеджмент, проверяя повторно одну и ту же интересующую функцию.
2. Распределение. Техника для больших команд, когда за минимальные сроки необходимо покрыть полное тестирование. Актуально для mobile & game проектов. К примеру, mobile функциональное тестирование конкретного блока/функции на большом количестве устройств (один тестировщик отвечает за одну функцию, а другой – за следующую). В даном случае могут появиться дополнительные баги только по причине несоответствия ПО/ОС мобильного устройства, несовместимости версий или отсутствия поддержки ПО для конкретного вида устройства (планшет/телефон/аксессуары/консоли и т.д.). Пример для game проекта: тестирование локализации, когда необходимо покрыть тестами более чем 10 языков. Можно распределить задачу по тестированию следующими подходами- 1 уровень – 1 тестер – все языки- 1 локация/страница меню – 1 тестер – все языкиВ обеих случаях иногда потребуется помощь коллег :), которые могут сделать скриншоты конкретной локации при прохождении игры и предоставить их ответственному (в случае, если тестируется игра на нескольких платформах/большом количестве устройств).
3. Синхронизация. Техника, которая используется при тестировании нового функционала/модуля/блока, и требуется протестировать только часть ПО. Техника схожая с регрессионным тестированием и отвечает на вопрос: “Не поломалось ли что-то после последнего обновления?”. Актуально для hot fixes, доработок, модульного тестирования, внедрения поддержки новой версии ПО мобильного устройства ( например, iOS 9 -> iOS 10).
4. Ad-hoc (мы не знаем, что найдем при тестировании). Актуальна для нового ПО, стартапов, замены команды разработчиков и/или QA команды. Тестируется зачастую опытными тестировщиками, которые используют свой опыт и аналитические способности, чтобы найти что-то новое, используя доступные средства (зачастую такие тестировщики могут нечаянно взломать базу данных или поломать ПО).
5. Валидация. Незаменимая техника для web проектов. Проверяются все возможные и невозможные случаи, используются знания системного администрирования, баз данных, структуры, конкретного используемого ПО (например, конструкторов Joomla, Drupal, WordPress, которые сами по себе имеют ошибки).
6. Интеграция. Актуальна для проектов социальных сетей, когда необходимо внедрить/распространить игру/сайт (например, используя API) и получать статистику посещений с разных ресурсов.
7. Дубль. Отличная техника для проектов, которые тестированы-перетестированы, а заказчик хочет идеальный продукт. Пример с ножами: Вы режете сыр специальным ножом для плавленого сыра, но решили попробовать его разрезать ножом для хлеба. Такой же подход можно использовать и в тестировании: Вы можете тестировать одну и ту же функцию разными способами, используя разное ПО (FireBug, LogCat, network settings, Android SDK…).
Дорогие читатели! Если у Вас есть дополнения или критика по теме – буду рада ознакомиться с ними в комментариях или в письменном виде.