Использование техник тест-дизайна

Использование техник тест-дизайна

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

О некоторых техниках тест-дизайна поговорили тут:

Еще немного предисловия, о том, как к сожалению тестируют в большинстве своем многие, кто ударяя себя пяткой в грудь именуют 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

По большому счету мы сейчас использовали аналитический подход, изучая нашу документацию с требованиями и выделили “эквивалентные классы” наших параметров, ошибки по которым будут отвечать за одну и ту же область. И наш метод не такой явный: как градация на цифры, буквы или только по формату файла ( например загруженный .doc будет открываться в гугл доках приложением  — документы, а excel в таблицах). Мы выделили далеко не все, но многие вещи. Возьмем за основу, что все остальное будет эквивалентный класс негативных тестов и будет приводить к одной и той же ошибке, иначе мы в нашем с вами сферическом тесте закопаемся. А еще у нас был случай, когда вот так вот закапывались в тестах

Следующим шагом, стоит остановится и подумать, а какие вещи/параметры я еще упустил. Поискать возможные варианты сбоев для не стандартных вещей, обдумать что или где могло быть пропущено в спешке. Список выше не должен составляться за один подход. Это не работает по принципу сел и написал. Лучше накидывать постоянно корректируя и доводя до готовности. Почитайте еще раз требования, обсудите с коллегами, пните разработчика и БА. 

Совершенствуем тесты с помощью техники тест-дизайна

Далее, попробуем избавится от параметров, которые или не могут быть применены либо являются не граничными, либо уже эквивалентные относительно одного параметра. Что не исключает возможности их тестирования при наличии времени или проверки интеграционными тестами. 

Из форматов изображений сложно что-то убрать, уж слишком специфический у нас набор получился и любое исключение может привести к багу. А вот разрешение вполне подходит под один эквивалентный класс и взять можно граничные значения 320*240 и 1920*1080. В соотношении сторон тоже все понятно, а файл если отработает самый маленький и самый большой то будет все окей. Цветность фотографий в условиях переборки большинства форматов, тоже не волнует ( хоть и вряд ли повлияет на работу загрузки и отображения). Стандартные размеры фотографии для печати не так важны, но могут не верно отображаться, а значит стоит протестировать. Пожалуй стоит рискнуть и все же убрать несколько форматов в целях уменьшения тестов (при минимальном наборе можно было бы оставить — но в дальнейшем точно нужно будет избавится), предположим что мы это выяснили у БА — избавимся от jpg ( есть jpeg), pnm/bmp ( не столь популярен) и ico ( формат хранения файлов значков ).

Test-case
IIIIIIIVVVIVII
Форматjpegpngpdftiffgifrawheic
Разрешение фотографии320*240any1920*1080800×600anyany1280×720
Соотношение сторон2:35:316:95:48:5256:135 any
Размер файла1kb1bany1mb10mb100mb4,7mb
Цветность фотографиblack and whitetransparentanytransparentmultispecificany
Стандарты размера фотографии10×15,15×3020×3015×2030×40any9×13
ИСПОЛЬЗОВАНИЕ ТЕХНИК ТЕСТ-ДИЗАЙНА

Немного поработав во всех направлениях, как с техниками тест-дизайна так и БА/DEV, мы получаем минимальный набор тестов. Который с какой то высокой ) долей вероятности покроет большой процент возможных кейсов. Привыкайте думать в таких масштабах — фраза мы все протестировали — тянет в бездну. И наш клиент будет рад — а что еще нужно ? ) Там где мы добавили any — это возможность для большей фантазии и использования параметров не включенных в требования. Таким образом потратив совсем немного времени наш маленький большой QA сможет проведя около 7 тестов — спать спокойно сегодня вечером.

Вместо выводов о техниках

Как можно было заметить мы использовали еще одну интересную технику тест дизайна — очень большую и достаточно сложную. Мы непросто тестировали каждое значение в отдельности, мы применили комбинации значений и соединили их, чтобы снизить количество тестов до минимально достаточного набора. В конечном случае, если один из тестов даст ошибку, хорошему тестировщику нужно не просто зарепортить баг, нужно еще и отыскать какой именно из параметров дал сбой. 

Для того чтобы провести более полноценное тестирование, не исчерпывающее, необходимо сделать “немного” больше тестов с использованием комбинации различных параметров друг с другом. Подробнее об этом, и используя комбинаторику парных значений обсудим в следующей статье этого цикла.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.