Содержание |
Тест-дизайн
Тест-дизайн предусматривает процесс создания тест-кейсов, необходимых для обеспечения оптимального тестового покрытия. Все кейсы разрабатываются с учетом заранее определенных критериев и целей самого тестирования.
Для высокой эффективности результатов необходимо провести ряд мероприятий:
- Используя проектную документацию, определяем требования, разрабатываем план и стратегию, определяем приоритетность задач и анализируем риски;
- Проведение самого тестирования осуществляется после анализа собранных данных на этапе подготовки. Главное выбрать технику, методику, которая сможет сократить количество тестов, но найдет наибольшее число высокоприоритетных дефектов.
- По завершении тестов нам необходимо собрать все результаты в единый отчет и провести полноценный анализ. Отличительным фактом для QA-специалистов является возможность принимать итоговое решение, основываясь не только на итоговой документации, но и на устных комментариях коллег.
На текущий момент присутствует большой выбор техник, методик для проведения тестирования. Все они используются для повышения эффективности, а также помогают сократить затрачиваемые на проведение тестирования ресурсы – финансовые, человеческие.
Базовые техники QA
Сегодня мы рассмотрим базовые техники QA, их применение на примерах из повседневной жизни большинства людей.
Классы эквивалентности
Первым стоит рассмотреть классы эквивалентности. Нам необходимо разбить первичные данные на группы по схожим, либо идентичным характеристикам так, чтобы тесты одного элемента из этой группы были равнозначны тесту любого другого элемента из этого же класса/группы. Таким образом не нужно создавать сценарии для каждого значения, что существенно сокращает количество проводимых тестов.
Рассмотрим на примере. Скоро в городе будет выступать музыкальная группа, но организаторами введены возрастные ограничения: от 18 до 60 лет. Следовательно, здесь мы выделяем 3 группы:
- от 0-17 включительно – при вводе любого значения из данного диапазона программа должна выдавать ошибку;
- от 18-60 включительно – при вводе любого значения из данного диапазона программа должна давать положительный отклик и запускать дальнейшие шаги;
- от 61 и выше – при вводе любого значения из данного диапазона программа должна выдавать ошибку.
Метод граничных значений
Следующая техника метод граничных значений живет совместно с предыдущим методом. Почему же так? Здесь мы предполагаем, что большая часть ошибок возникает, как раз, на границах равнозначных классов. При использовании данной методики необходимо проверить, насколько корректно система реагирует на введенные значения.
Для примера, мы рассмотрим ту же ситуацию, что и в прошлом методе. Учитывая наши вводные данные, граничными значениями будут возрасты от 17 и ниже, от 61 и выше. Задача тестировщика – проверить, как система реагирует на ввод данных возрастов.
Таблица принятия решений
Метод таблица принятия решений может быть вам известен еще и как матрица принятия решений. Она используется в более сложных системах, нежели прошлые методы, но её формат предоставления результатов будет понятен обычному пользователю. Ведь данный инструмент визуализирует нам таблицу, где столбцы – это введенные нами условия, а строки будут отображать результат на основе этих условий. При проведении тестирования система на различных этапах может выдавать разные сообщения – в зависимости от того, на каком этапе была допущена ошибка.
Попарное тестирование
Четвертым методом мы рассмотрим попарное тестирование. Нам необходимо из первичных вариантов выделить только уникальные, то есть исключить элементы, которые мы можем объединить в одну группу. Такой отбор помогает нам не только существенно сократить таблицу, но и обнаружить максимальное покрытие требований тестами. В этом методе есть технические возможности, обеспечивающие автоматизацию процесса.
Например, у нас есть набор исходных данных:
При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех:
Причина и следствие
Причина и следствие. Метод простой проверки действий и результатов, полученных в результате этих действий. Работает он также, как и в обычной жизни. Если проецировать уже на процесс тестирования, то здесь мы вводим комбинации, они же условия-причины, для получения ответа от системы, который является следствием.
Алгоритм этого метода очень прост и везде единый:
- Выделяем причины и следствия в спецификациях.
- Связываем причины и следствия.
- Учитываем «невозможные» сочетания причин и следствий.
- Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
- Расставляем приоритеты.
Например, QA-специалист тестирует приложение типа `записная книжка`. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита.
Предугадывание ошибок
Предугадывание ошибок. Этот метод основывается уже на опыте самого специалиста, а в большей степени – на интуиции. Отсюда идет название методики. Специалист на базе своих знаний пытается «предугадать», при каком варианте развития событий произойдет ошибка.
В заключение можно сказать, что мы рассмотрели лишь небольшую, но основополагающую часть методов и техник тестирования в формате «просто о сложном». Это поможет тем, кто только начинает свой путь, выбрать подходящие варианты для него, а также понять, что тестирование, на самом деле, кропотливая, но не столь страшная работа. Но и опытные специалисты смогут рассмотреть для себя классические методы в новом ключе.Как защищать «поумневшие» промышленные сети: «Синоникс» на страже безопасного объединения изолированных сетей 
Этап тестирования является очень важным в процессе реализации любого проекта. Он помогает своевременно исправить баги/ошибки системы. Что, в свою очередь, обеспечивает сохранение ресурсов и получение большей выгоды от реализации проекта или позволяет сократить издержки, связанные с некорректным поведением ПО.
Автор: Артем Маренков
