основные практики тест дизайна
Техники тест-дизайна
Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли в тест дизайне:
Попросту говоря, задача тест-аналитиков и дизайнеров сводится к тому, чтобы, используя различные стратегии и техники тест-дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. На большинстве проектов эти роли выполняет QA инженер.
Тестовое покрытие — это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Существуют следущее подходы к оценке и измерению тестового покрытия:
Техники тест дизайна:
Пример использования техники анализа классов эквивалентности:
Эквивалентное разделение, алгоритм использования техники:
Можно разбивать тесты на классы эквивалентности по разным принципам. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем выбрать разные принципы разбиения на классы эквивалентности:
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
Рис. 5.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Определим классы эквивалентности:
(для каждого теста из этих классов мы ожидаем получить одинаковый результат):
Пример использования техники анализа граничных значений
Примерный алгоритм использования техники анализа граничных значений:
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
Рис. 5.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Выделим классы эквивалентности:
Тест-дизайн. Когда и для чего
Предположим простую ситуацию. Вам дали тестировать сайт с описанием фильмов. Там около 1000 страниц. Простой вопрос, что тестировать?
Всегда существует вариант — тестировать “в лоб”. Открываем каждую страницу, проверяем на месте ли текст и картинки, смотрим, что расположение элементов не поехало и все стоит на своих местах. Звучит как-то не очень весело, не правда ли? Я уже не говорю о потраченном времени.
Или, например, у нас есть интернет-магазин, в котором около 5000 товаров. Получается, для того, чтобы проверить покупку товаров, нам необходимо зайти в каждый и купить?
Но это еще ерунда по сравнению с мыслью о том, что мы что-то забыли проверить, не подумали о важности именно этого теста и пропустили баг в релиз.Можно сказать, что без тест-дизайна мы словно стреляем в цель с закрытии глазами.
Что такое тест-дизайн?
Мы, тестировщики, люди ленивые и не хотим много работать. Даже придумали автоматизированное тестирование, которые выполняет за нас всю нашу работу, а мы в это время лежим на берегу моря ничего не делая и зарабатывая от 100 000 рублей в месяц…. немного отвлекся:) Так вот. Умные люди задумались: а вдруг есть способ не тестировать все страницы? Может быть, есть возможность протестировать сайт быстрее, но так же качественно?
Оказывается есть. Работу тестировщика можно оптимизировать и вместо 1000 тестов провести, например, 15 или 20 тестов. Но для этого необходимо использовать определенные подходы к построению тестов. Такие подходы называют техниками тест-дизайна.
Когда и для чего нужен тест-дизайн:
— когда тестирование включает в себя множество однотипных действий,
— когда необходим вдумчивый подход к тестированию для избежания лишних трат времени и финансов,
— чтобы разработать тесты, которые обнаружат наиболее серьезные ошибки,
— чтобы минимизировать количество необходимых тестов для проверки продукта.
Если брать шире, то тест-дизайн — это процесс который позволяет, используя определенные техники, создать оптимальное тестовое покрытие тестируемого объекта.
Раз речь зашла о процессе, то необходимо проговорить об этапах этого процесса.
Этапы тест-дизайна
Во-первых, необходимо проанализировать тестируемый объект. Изучить его документацию, пообщаться с разработкой, узнать как он работает и как спроектирован. Этап важный, так вы поймете какие техники тест-дизайна использовать. А самое главное — КАК.
Во-вторых, зная информацию о продукте, необходимо определить какие техники необходимо использовать для определенного вида тестирования.
И, в-третьих, используя полученные знания, необходимо составить набор тестов (чек-листов/тест-кейсов)
Изучить продукт. Определить техники. Написать тест-кейсы.
Еще один вопрос: должны ли они идти в таком порядке? Желательно, но не обязательно. Иногда, когда начинаешь писать кейсы, понимаешь, что необходимо еще изучить продукт и снова возвращаешься к первому этапу. Особенно если нет документации. Это нормально.
Техники тест-дизайна
Самый большой интерес в тест-дизайне представляют его техники.
В нашем цикле мы разберем следующие техники на конкретных примерах:
1. Граничные значения и классы эквивалентности.
2. Pairwise.
3. Таблицы переходов.
Кроме знания техник необходимо уметь:
— разделять целый продукт на составные части (декомпозиция),
— находить и анализировать требования к продукту,
— расставлять приоритеты,
— логично излагать свои мысли.
Техники тест-дизайна
Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли в тест дизайне:
Попросту говоря, задача тест-аналитиков и дизайнеров сводится к тому, чтобы, используя различные стратегии и техники тест-дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. На большинстве проектов эти роли выполняет QA инженер.
Существуют следущее подходы к оценке и измерению тестового покрытия:
Техники тест дизайна:
Пример использования техники анализа классов эквивалентности:
Эквивалентное разделение, алгоритм использования техники:
Можно разбивать тесты на классы эквивалентности по разным принципам. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем выбрать разные принципы разбиения на классы эквивалентности:
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
Рис. 5.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Определим классы эквивалентности:
(для каждого теста из этих классов мы ожидаем получить одинаковый результат):
Пример использования техники анализа граничных значений
Примерный алгоритм использования техники анализа граничных значений:
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
Рис. 5.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Выделим классы эквивалентности:
QA evolution
Использование техник тест-дизайна
Использование техник тест-дизайна и их сложность, как обычно, заключается не столько в том, чтобы разобраться в них по отдельности. Сколько, во-первых в понимании зачем они вообще нужны, как их полноценно комбинировать, и в принципе в применении на практике с пользой.
Еще немного предисловия, о том, как к сожалению тестируют в большинстве своем многие, кто ударяя себя пяткой в грудь именуют QA. И не сказать что ребята плохие или знаний мало, но вот не хотят думать, анализировать. Получил задачу и сразу в бой, сразу баги искать, а еще лучше сразу в негативные тесты. И вот ты уже тысячу раз проговорил все, обсудили как надо подходить, договорились о стандартах и правилах. А вместо обдуманного тестирования все равно тестиим дальше…
Ну что обновляем тестовый сервер, и приступаем…
Фича, вполне себе обычная и скорее к грусти своей практически нереальная, ибо ну не поставляют такими маленькими кусками, сколько бы не пытались детализировать и скрамить. Давай-те возьмем для примера, всего лишь сферическую загрузку фото, без учета как будет загружаться, без окружений и требований бизнеса, иначе утонем, а для понимания надо хотя бы немного поплавать.
К чему приводит неправильное использование техник тест-дизайна
Подзаголовок правильнее было бы назвать даже не неправильное использование тест-дизайна. И в принципе не использование его. Как же это происходит на практике.
Получает тестировщик задачу, о том, что надо протестировать новый функционал в виде загрузки изображений. И начинается рандомное засовывание рандомных файлов в окно загрузки. Бессистемное изменение форматов, размеров, подстановка неправильных или несуществующих файлов, очень больших или абсолютно пустых, исполняемых и так далее. Буквальное через несколько минут начинают в мессенджерах лететь нотификации о том что драг-н-дроп в поле не работает, сервер выдает “500” если “тестер” ( уж извините) грузит фильм в формате 4К, а исполняемый скрипт выдает ошибку в поле имени.
Сейчас мы конечно не рассматривали ситуацию когда и задачу поставили не верно и запилено было не правильно. Исходим из того что все стадии до QA были верно “реализованы. Хотя такое редкость, к сожалению.
Использование техник тест-дизайна
Как и предполагается каждая из техник тест-дизайна практически не живет своей отдельной жизнью и необходимо работать с ними в связке. Рассмотрим для начала, что же от нас хотят и как нам подойти к этому вопросу. И мы сейчас не будем исходить из адекватного подхода для смок теста, когда было необходимо всего лишь убедится в простой загрузке обычного фото ( хотя это очень грубое предположение).
Казалось бы какие тут могут быть конфигурации, поле то всего одно, что здесь думать и анализировать. Поехали…
Выберем параметры для проверки
Какие параметры файла необходимо проверить исходя из требований к тестированию новой функциональности:
Форматы: jpeg, png, ico, tiff, jpg, pdf, pnm, bmp, gif, raw, heic
Разрешение фотографии (количество точек): 320*240, 320*480, 640×480, 800×600, 1024×768, 1280×720, 1600×900, 1920*1080
Соотношение сторон: 4:3, 5:3, 2:3, 5:4, 16:9, 8:5, 256:135
Размер файла: 1 b, 1kb, 1mb, 10mb, 100 mb,
Цветность фотографии: black and white, multi, specific, transparent ( казалось бы причем здесь цвета )
Стандарты размера фотографии ( при печати, пожалуй очень спорный пункт но оставим для массовки): 9×13, 10×15, 15×20, 15×30, 20×30, 30×40
Следующим шагом, стоит остановится и подумать, а какие вещи/параметры я еще упустил. Поискать возможные варианты сбоев для не стандартных вещей, обдумать что или где могло быть пропущено в спешке. Список выше не должен составляться за один подход. Это не работает по принципу сел и написал. Лучше накидывать постоянно корректируя и доводя до готовности. Почитайте еще раз требования, обсудите с коллегами, пните разработчика и БА.
Совершенствуем тесты с помощью техники тест-дизайна
Далее, попробуем избавится от параметров, которые или не могут быть применены либо являются не граничными, либо уже эквивалентные относительно одного параметра. Что не исключает возможности их тестирования при наличии времени или проверки интеграционными тестами.
Из форматов изображений сложно что-то убрать, уж слишком специфический у нас набор получился и любое исключение может привести к багу. А вот разрешение вполне подходит под один эквивалентный класс и взять можно граничные значения 320*240 и 1920*1080. В соотношении сторон тоже все понятно, а файл если отработает самый маленький и самый большой то будет все окей. Цветность фотографий в условиях переборки большинства форматов, тоже не волнует ( хоть и вряд ли повлияет на работу загрузки и отображения). Стандартные размеры фотографии для печати не так важны, но могут не верно отображаться, а значит стоит протестировать. Пожалуй стоит рискнуть и все же убрать несколько форматов в целях уменьшения тестов (при минимальном наборе можно было бы оставить — но в дальнейшем точно нужно будет избавится), предположим что мы это выяснили у БА — избавимся от jpg ( есть jpeg), pnm/bmp ( не столь популярен) и ico ( формат хранения файлов значков ).
| Test-case | I | II | III | IV | V | VI | VII |
| Формат | jpeg | png | tiff | gif | raw | heic | |
| Разрешение фотографии | 320*240 | any | 1920*1080 | 800×600 | any | any | 1280×720 |
| Соотношение сторон | 2:3 | 5:3 | 16:9 | 5:4 | 8:5 | 256:135 | any |
| Размер файла | 1kb | 1b | any | 1mb | 10mb | 100mb | 4,7mb |
| Цветность фотографи | black and white | transparent | any | transparent | multi | specific | any |
| Стандарты размера фотографии | 10×15, | 15×30 | 20×30 | 15×20 | 30×40 | any | 9×13 |
ИСПОЛЬЗОВАНИЕ ТЕХНИК ТЕСТ-ДИЗАЙНА
Вместо выводов о техниках
Как можно было заметить мы использовали еще одну интересную технику тест дизайна — очень большую и достаточно сложную. Мы непросто тестировали каждое значение в отдельности, мы применили комбинации значений и соединили их, чтобы снизить количество тестов до минимально достаточного набора. В конечном случае, если один из тестов даст ошибку, хорошему тестировщику нужно не просто зарепортить баг, нужно еще и отыскать какой именно из параметров дал сбой.
Для того чтобы провести более полноценное тестирование, не исчерпывающее, необходимо сделать “немного” больше тестов с использованием комбинации различных параметров друг с другом. Подробнее об этом, и используя комбинаторику парных значений обсудим в следующей статье этого цикла.
QA evolution
Тест дизайн — один из первоначальных этапов тестирования программного обеспечения, этап планирования и проектирования тестов. Тест дизайн представляет собой продумывание и написание тестовых случаев (test case), в соответствии с требованиями проекта, критериями качества будущего продукта и финальными целями тестирования.
Тест дизайн
Цели тест дизайна
Тест дизайн задачи
Какие скиллы необходимо прокачивать тест дизайнеру для того чтобы разрабатывать тесты оптимальными, быстро и с минимальными ошибками. В большинстве небольших компаний разработка таких тестов доверяется непосредственно тестировщику, для этого нужно иметь знания и быть готовым к такой задаче.
Тест дизайн скиллы профессионала:
Техники тест дизайна
Техники тест дизайна это рекомендации, советы и правила по которым стоит разрабатывать тест для проведения тестирования приложения. Это не образцы тестов, а только рекомендации к применению. В частности различные инженеры могут работая под одним и тем же проектом создать различный набор тестов. Правильным будет считаться тот набор тестов, который за меньшее количество проверок обеспечит более полное покрытие тестами.
Например если поле для возраста принимает значения от 18 до 110 лет. Пограничными целыми значениями будут значения выходящие за интервал и находящиеся непосредственно на границах. Для нижнего это будет 17,18 — для верхнего 110,111 лет.
Например одинаковыми значениями одного класса эквивалентности при применение техники тест дизайна будет. Одно значение сегмента букв, одно из цифр. Таким же образом может быть для примера возраста из граничных классов — для проверки всего класса эквивалентности будет достаточного любого числа из 18 — 110.
Для пары логин пасс можно предположить такую простую матрицу: Правильный пасс логин, неправильный пасс логин, правильный пасс неверный логин, неправильный пасс правильный логин. Итого имеем 4 теста. Рассмотрев варианты как должно реагировать приложение для каждого из тестов, оставляем только те которые выдают различный результат. В идеальном случае у нас остаётся только два теста.
Ключевую роль здесь как нигде играет опыт инженера по качеству. На основе своего опыта, представлении как должно работать приложение, и предположения где может быть ошибка, строятся и проводятся тесты.
Вид тестирования обычно подвергающийся автоматизации. Из настроек и подготовки можно выделить необходимые знания js, и не большой опыт работы с back-end проекта.
Здесь как и в тестировании предугадывания ошибок, важнейшей составляющей является опыт инженера. Хорошая подготовка по документации проекта, плюсом будет знание похожих проектов.