На сегодняшний день тестирование – это один из базовых элементов при создании любого программного продукта. Неважно, какую именно методологию вы используете, тестирование ПО так или иначе всегда присутствует в процессе создания веб-продукта.
За последние несколько лет тестирование достаточно очевидно сформировалось в отдельную область, которая постоянно терпит изменения и улучшения.
Далее речь пойдет о деятельности именно ручного тестировщика и о том, как он должен справляться с основами тест-дизайна.
Понятие тест-дизайна и проблемы его использования
Многие специалисты данной сферы слышали о таком понятии как тест-дизайн. Но мало кто по настоящему использует данные методологии проверки программного обеспечения в своей повседневной рабочей деятельности.
Можно задаться вопросом, а почему так происходит? Ведь техники тест-дизайна – базовая составляющая при разработке сценариев тестирования (это как правила дорожного движения при обучении в автошколе). Так почему тестировщики крайне редко применяют эти знания в своей работе?
Все просто! Когда учат будущего тестировщика на специализированных курсах, ему детально рассказывают на простых примерах, как на практике использовать техники тест-дизайна. И главный минус подобного обучения состоит в том, что тестировщики не могут правильно перенести все полученные познания на свои реальные проекты. Другими словами, у них нет возможности использовать техники тест-дизайна на повседневной основе.
Также можно отметить то, что данный процесс максимально формализуется и выглядит так, будто тестировщику нужно абсолютно все в своей работе формализовать. А обычно подобные вещи никому не нужны, да и времени на них попросту нет.
Теперь от проблем можно перейти к базовым понятиям, а именно, что же из себя представляет тест-дизайн. Итак, тест-дизайн – это определенная совокупность правил и стратегий, которые позволяют правильно использовать предоставленный список требований при тестировании ПО.
Но самое важное – это возможность правильно на интуитивном уровне имплементировать данные правила и порядки. Именно умение правильно анализировать отличает хорошего тестировщика от рядового!
Базовыми задачами любого тест-дизайна являются:
- Процесс анализа требований и рисков;
- Возможность определения базовых проверок для тестирования;
- Основы формализации проверок в типе тестовых сценариев;
- Возможность приоритезации тестовых проверок;
- Аналитика подходов к процессу тестирования.
Реализация техник тест-дизайна на практике
Начнем с двух наиболее распространенных техник, про которые слышали, наверное, все тестировщики и которые иногда используются ими на интуитивном уровне. Речь идет о классах эквивалентности и граничных требованиях.
Наибольший интерес в нашем случае представляют классы эквивалентности, о которых далее как раз и поговорим.
Класс эквивалентности
Класс эквивалентности – это специальный набор входных параметров ПО, которые проходят процесс обработки программой по 1 алгоритму или приводят к одному желаемому итогу.
Простыми словами, это некоторое множество специальных значений, которые можно предоставить в обработку программе и получать один и тот же итог. Таким итогом могут быть не просто конкретные обозначения или параметры программы, но и сфера использования.
Это значит, что наиболее простые классы эквивалентности, на которые можно разделить проверки, это положительные и негативные сценарии. Они присутствуют всегда и на любом проекте. Каждый тестировщик делит все свои проверки на эти классы, но, увы, не каждый знает, зачем он это делает.
Ответ прост – классы эквивалентности. Любой класс эквивалентности можно поделить на вспомогательные классы до той стадии, пока проверки не станут приводить к точным и конкретным итогам тестирования.
Ознакомимся с примером
Нам поручено протестировать работу системы скоринга процентной ставки по кредиту исходя из возраста клиента.
Есть такие данные от пользователей:
- От 18 до 25 лет – 18%;
- От 25 до 45 лет – 16 %;
- Старше 45 лет – 20%.
Наша задача – определить 2 базовых класса эквивалентности – негативные и позитивные сценарии проверки.
Положительными сценариями будут абсолютно все значения, которые приводят к получению указанного результата. Негативными сценариями будут значения, итоги которых не описаны как ожидаемый результат.
Далее можно поделить класс позитивных сценариев на 3 класса вводными значениями от 18 до 24, от 25 до 44 и свыше 45.
В классе негативных итогов мы можем сформировать значение, исходя в первую очередь из надобности проверки отказов ПО. Следовательно, имеем 0,1-17 – отрицательные значения и ввод некорректных символов.
Итогом данного разбиения станет значение или диапазон некоторых значений, в котором необходимо выполнить всего одну проверку со случайным значением из диапазона данных. Бывают ситуации, когда есть всего одно значение в диапазоне. Это тоже отдельный класс эквивалентности и он тоже нуждается в тестировании.
В итоге у нас получаются такие группы проверок:
- Позитивные проверки – ввод значений 19, 30, 48 (цифры могут быть любые с данного диапазона класса);
- Негативные сценарии – 0, 3, значение с минусом.
Крайне важно, что все техники тест-дизайна не применяются независимо от остальных! Более того, есть сразу три уровня использования техник тест-дизайна при подготовке к тестированию:
- Базовый уровень – тестирование элементов системы;
- Второй уровень – проверка работоспособности логики системы;
- Третий уровень – тестирование бизнес-процессов системы и логики функционирования ПО.
Визуально это можно отобразить следующим образом.
Уровни использования техник тест-дизайна
В заключение
В завершение необходимо сказать, что техники тест-дизайна могут покрыть только часть проверок программного обеспечения. А именно отобразить корректность или некорректность работы частей системы и итоги их комбинаций в процессе функционирования.
Тест-дизайн – это очень важная составляющая любого ручного тестирования, ведь именно ее зачастую проверяют QA-специалисты в своей повседневной деятельности.
Оставить комментарий