Название тест-кейса — как оформлять

Главное правило хорошего названия:

 Причем это касается любого названия, будь то тест-кейс или баг.

Из названия тест-кейса я должна понять, какую проверку мне надо провести, не заглядывая в описание шагов. Вот, например, я вижу тест-кейс «Корректное имя»? Корректное — это какое? И какое действие я должна сделать? Куда это корректное имя вводить? При регистрации? Авторизации? В личном кабинете? При указании имени получателя? В загружаемом в систему файле? Где?

Допустим, при регистрации. Правильно ли будет переименовать тест-кейс в «Регистрация с корректным именем»? Или, скажем, сделать общую папку на тестирование регистрации и внутри уже писать «Корректное имя»?

На самом деле это название все равно не отвечает на вопрос «а что мне делать то?». Потому что что такое «корректное имя», я могу и не знать. Для одной системы «Оленька» будет корректно, а для регистрации в гос услагх → нет. Да и даже если обратить в проверкам, которые мы придумали ранее , то сколько там корректных имен? Много! Тогда как будет выглядеть наш набор тест-кейсов? Примерно вот так:

Корректное имя

Корректное имя

Корректное имя

Корректное имя

Корректное имя

....

Некорректное имя

Некорректное имя

Некорректное имя

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

Намного лучше будет смотреться такой список:

Регистрация 

Регистрация с длинным именем

Регистрация с составным именем

Регистрация с уменьшительно-ласкательной формой имени

...

Регистрация с пустым именем

Регистрация со спецсимволами вместо имени

…

 

Проницательный читатель заметит «Эй! А что значит тест «Регистрация»? Что я пойму из этого названия?», и будет прав. Вроде только что критиковала абстрактные названия и вот ведь, сама даю как пример! А я поясню.

Этот тест — основа тестирования функционала. Он показывает, как можно зарегистрироваться в системе. Ведь когда мы тестируем функционал, мы начинаем с самого-самого основного теста. Еще не пытаясь ничего сломать. Регистрация? Вводим везде корректные данные. А потом уже начинаем думать «Тааааак, а какие бывают имена? А что, если…?». И вот этот тест — он как раз на то, что регистрация в целом работает.

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

И тогда мы ссылаемся на другой тест: см тест-кейс «Регистрация». Такое короткое название помогает понять, о чем тот кейс и легко его найти. Но можно его так и назвать: «Регистрация (базовый тест)», будет понятнее!

Возможно, вы все еще задаетесь вопросом «Так а чем плохо название «Регистрация с корректным именем?». Разве я не могу проверить в одном тест-кейсе все вариации корректных имен?». И это отличный, правильный вопрос!

Да, вы можете проверить в одном кейсе все корректные имена. Существует и такой способ оформления теста, почему бы и нет? И вот тогда, и только тогда такое название будет оправдано. Проблема в том, что обычно начинающие любят давать «громкие» названия, которые реально проверяют пшик. 

Например, на моем интенсиве  студенты тестировали Дадату. Возьмем несколько примеров заголовков оттуда и разберем, что в них плохо.

Исправление опечаток в ФИО

Дадата умеет в том числе исправлять опечатки в ФИО. И вот, значит, студент сдает домашнее задание с тест-кейсом. Читаешь название и впечатляешься: «Исправление опечаток в ФИО». Ух ты, думаешь, сколько же он проверок придумал? 

Для понимания масштаба:

• справочник имен — примерно 50 тыс. строк;
• справочник фамилий — 500 тысяч. 

Допустим, средняя длина слова будет 5 символов. Опечатка может быть в любом месте, уже для одной строки получаем 25 вариаций опечатки. А тут даже не по именам или фамилиям отдельно, а для ФИО в целом написан тест-кейс! 

А потом открываешь сам тест, а там… Максимум 10 ФИО. И типа функционал проверен. Вот уж нет, если даете настолько громкое название — соответствуйте ему. Или выбирайте тест «попроще».

Конечно, ребята защищают свои тест-кейсы. «А я просто хочу проверить саму возможность». Но этот вариант в Дадате не прокатит 😊 Да, если бы опечатки исправлялись только через файл, проверить саму возможность, на 5-10 данных вместо тысяч, было бы вполне разумно. Например, для smoke-теста. 

Но в Дадате функционал очистки данных работает в двух режимах:

• По одному человеку
• Через файл

Проверка по одному человеку доступна без авторизации, открыл сайт, ввел ФИО, нажал «Проверить» → профит!

 

Проверка по одному человеку

А вот чтобы загрузить файл, нужно:

• Подготовить файл нужного формата;
• Зарегистрироваться в системе;
• Авторизоваться;
• Загрузить файл → вместо одной кнопки пройти несколько шагов (все нужны и важны, но ведь путь усложняют)

Как проще проверить, что «опечатки в целом исправляются»? Правильно, через форму по одному человеку. Но вот ведь засада, тренер то просит тест-кейсы на файл, «ну примите его так, мы же просто учимся оформлять». Не надо так думать.

Мы никогда не пишем бесполезные тесты, даже в рамках обучения. Это как когда я ходила на курсы по макияжу, там тренер говорила: «Как вы умудрились нанести тон за 5 минут? Профессионалы на это могут час тратить, чтобы все сделать идеально. У вас сейчас есть время, так учитесь. Это только кажется, что «Я щас на курсах быстренько и так себе сделаю, а уж потооооом, с реальными клиентами буду все зоны прорабатывать». Если не научитесь делать хорошо сейчас, то и потом халтурить будете».

В тестировании, да и в любой другой области, все то же самое. Обучение для того и нужно, чтобы учиться делать сразу хорошо. Какой толк от того, что вы научились оформлять бесполезные тесты, которые никогда в реальной работе не будете применять? Все основные темы этой книги завязаны между собой. Нет смысла сразу учиться красиво описывать тест-кейс, если вы не можете придумать идею теста. 

Поэтому сначала мы учимся генерировать идеи, потом описывать, а дальше мы будем расширять количество наших проверок, а потом, наоборот, выкидывать лишнее. Так как в реальной жизни задач всегда полно, а времени мало.

Но вернемся к разбору неправильных названий.

Проверка обработки данных на транслите

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

Дадата умеет обрабатывать:

— ФИО;

— Дату рождения;

— Телефон;

— Почтовый адрес;

— Электронную почту;

— Паспорт;

— Автомобиль.

Это можно увидеть на первом экране обработки файлов, в структуре документа:

 

Структура файла

Сколько из этих данных можно записать как на русском, так и на английском или транслите? Да почти все, за исключением разве что даты рождения, если писать ее исключительно в формате ДД.ММ.ГГГГ. Хотя… Если попробовать написать «19 мар 2010», то вот уже и символы, можно попробовать транслит. Хотя его система разбирать и не должна. Ну и в телефоны обычно пишут без текста, только цифры.

А самое интересное и полезное — это ФИО и адреса. Которые вполне могут заполнять на транслите. Например, в аэропорту. И такие данные круто разбирать. Но как тестировать? Допустим, мы выделили пока только одну область — разбор транслита в ФИО. Заметьте, это уже сильно меньше, чем обещает название «Проверка обработки данных на транслите». При этом обычно студенты пишут такое громкое название, а внутри — только ФИО, да и тех штук 5.

Но это мы уже обсуждали чуть выше. Саму возможность обработки транслита можно проверить в форме по одному человеку. Через файл же можно загрузить сразу много данных, проверив все одним махом.

Идем гуглить, исследуем. Нам надо проверить:

— Каждую букву алфавита;

— Хитрые комбинации (когда буква сама по себе читается так, а в паре с другой эдак, как O и ОО).

Уже получается неплохой набор различных данных! Но тут вспоминаем, что мы тестируем не какого-то абстрактного коня в вакууме, а конкретную систему. Это значит, что мы не можем просто додумать, по какому именно ГОСТ работает система, нам надо пойти и уточнить у аналитиков.

И вот тут то мы узнаем, что все еще сложнее, чем казалось! Потому что Дадата умеет распознавать 12 стандартов:

Июнь 2017: умная транслитерация ФИО

Раньше Дадата часто пасовала, если имя и фамилия набраны латиницей не по стандарту. Например, не догадывалась, что это всё Юлия Юрьева:

• Ulia Ur'eva
• Iuliia Iureva
• Yulia Yureva

Теперь алгоритм поумнел и понимает 12 стандартов транслитерации. И даже распознаёт привычные для людей способы записывать ФИО латиницей, которые не соответствуют никаким стандартам.

Тут на один то стандарт можно 30+ тестов написать, а уж на двенадцать… А насколько больше становится «хитрых» кейсов, которые в разных стандартах работают по разному. Ух! Сотни, тысячи!

Так что студентам я этот кейс брать не рекомендую. Проверить сразу все они все равно не осилят, да это и не нужно. В конце концов, их задача — научиться писать кейсы, а не протестировать нашу систему вдоль и поперек. Поэтому их основная задача — придумать тест-кейс на обработку, который будет полезным, но не на 100500 строк.

Домашнее задание 

Зная информацию с картинок: какие файлы умеет обрабатывать система и какие типы данных она в состоянии обработать, придумайте тест-кейсы на обработку данных.

Помните, что тесты должны быть полезными. Нет смысла пытаться проверить через файл саму возможность чего-то (исправление опечаток, определение пола, транслитерация). Но и не надо придумывать сложные тесты, которые вы будете составлять целую неделю.

 

Обработка файла

Вы уже догадываетесь, чем плохо это название? Оно ни о чем не говорит. Вот у меня разные кейсы есть - в файле только ФИО, ФИО + адрес, в файле 1 строка, 10 строк, миллион строк, это эксель, csv с одним разделителем, csv с другим разделителем итд. С таким названием кейсов у меня будет 100 штук "обработка файла", как мне среди них ориентироваться? 

Определитесь, что вы хотите проверить. Об этом и пишите. Кратко, но емко.

Если наполнение файла важно, так и пишите — "Обработка файла с тремя телефонами в одной строке". Или "Обработка опечаток в фамилии". Если это не важно, пишите то, что важно — "Обработка CSV файла" или "Обработка файла весом более 20Мб".

Тестирование функционала загрузки файла-образца

Выкидывайте лишнее, текст ради текста не нужен. "Загрузка файла-образца", все.

"Тестирование функционала загрузки..." -- лишние слова, которые можно выкинуть. Туда же можно выкинуть и слово "проверка", это тест-кейс, мы в нем всегда что-нибудь проверяем!

Всегда думайте, можно ли будет понять фразу / название / описание, если выкинуть какое-то слово. Если да → то зачем оно нужно?

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков