Техники тест-дизайна — это правила и подходы, которые помогают создавать грамотные тест-кейсы. Они помогают нам тестировать, не просто переходя со страницы на страницу, а объясняют, почему мы вводим определенные значения и какие конкретно значения нужно вводить.
И в этой статье мы поговорим про такие техники тест-дизайна:
Теперь — детально и с примерами про каждую из этих техник.
Если вы хотите быстро получить необходимые знания для работы тестировщиком, то наши партнеры из Robot Dreams и Mate Academy с радостью вам помогут. Лучшие практикующие специалисты ждут вас.
Помогать использовать первую технику будет сайт Instagram, а начнем с техники «Эквивалентное разделение». В чем ее суть? Мы берем все возможные варианты ввода текста и разделяем их на валидные и невалидные. Давайте протестируем поле «мобильный телефон» или «электронный адрес» — валидные и невалидные варианты ввода.
Введем +380999999999 — номер засчитан, как правильный, потому мы можем считать его валидным:
Теперь я хочу попробовать невалидный номер телефона и потому допишу сюда еще две цифры, и посмотрим, что скажет валидация (+38099999999999). Instagram показал нам крестик, то есть этот номер телефона уже не считается валидным, поскольку в нем много символов:
Пробуем дальше. Давайте я удалю два лишних символа и введу вместо одной цифры букву. Результат отрицательный, этот номер телефона тоже считается невалидным:
Теперь попробуем электронный адрес. Ввожу abc@gmail.com
Пробуем такой — abcdfgty1234@gmail.com — он кажется уникальным, и после ввода видим, что Instagram посчитал его валидным. Делаем вывод, что невалидными считают те адреса, на которых люди уже зарегистрировались:
Попробуем еще один пример — natasha@gmail.com. По этому электронному адресу уже кто-то зарегистрирован, потому Instagram отнес его к невалидным:
Пробуем natash76554a@gmail.com — он валидный:
А что, если мы введем электронный адрес без символа «@»? Он считается неправильным:
А если вернуть символ собачки, но удалить точку? Он также считается невалидным:
Давайте попробуем поменять домен на другой. Например, natash76554a@ukr.net — он абсолютно правильный, и такая почта вряд ли существует:
Instagram тоже посчитал его верным. Итак, мы разделили все возможные вводы мобильного телефона или электронного адреса на валидные и невалидные группы. Вот результат:
Валидные | Невалидные |
+380999999999 | +38099999999999 |
abcdfgty1234@gmail.com | +38099999999л |
natash76554a@gmail.com | abc@gmail.com |
natash76554a@ukr.net | natasha@gmail.com |
natash76554agmail.com | |
natash76554a@gmailcom |
Теперь можно составлять тест-кейсы. Первым будет: зарегистрироваться с валидным номером телефона, и конкретно этот номер телефона можно использовать как тестовые данные. Второй — зарегистрироваться с валидным электронным ящиком и использовать какой-то из примеров или же сразу все ящики
К невалидным будут относиться:
Теперь я покажу, как использовать технику «Граничных значений». В этой технике мы работаем только с цифрами. Допустим, у нас есть требование, что пароль должен быть от 6 до 16 символов. То есть на границе от 6 до 16 это должны быть четыре числа:
Давайте тестировать. Сначала я хочу ради эксперимента ввести пароль с одним символом. Кнопка регистрации серая — то есть с одним символом невозможно:
Вводим пароль из пять символов — кнопка регистрации все еще серая:
Вводим пароль из 6 символов — кнопка регистрации засветилась, то есть регистрация позволена:
И пароль из 16 символов — кнопка все еще голубая:
Ну и поскольку в Instagram нет ограничений по количеству символов в пароле (или мне лень вводить 256 символов :)), то сделаем вид, что 17 — это максимум. Ввожу 17 символов и мы делаем вид, что кнопка «Зарегистрироваться» стала серой:
Давайте разделим эти варианты ввода на валидные и невалидные значения:
Валидные | Невалидные |
123456 | 12345 |
1234567890123456 | 12345678901234567 |
В валидные пойдут: пароль из 6-ти символов и пароль из 16-ти символов. В невалидные — пароль из 5-ти символов и пароль из 17-ти символов. То есть, чтобы использовать в тест-кейсе граничные значения, нам нужно использовать четыре шага: два из них — это граничные валидные значения (6 и 16) и вторые два — это граничные невалидные значения, то есть 5 и 17.
Где еще можно использовать эту технику тест-дизайна? Везде, где фигурируют цифры: например, возраст. Давайте представим, что есть сайт, на котором регистрация позволена людям от 18 до 60 лет. И посчитаем, какие значения можно и нельзя вводить. Итак, валидные значения — это 18 и 60. Тогда невалидным значением будет 17, потому что в 17 лет нас не должно зарегистрировать, и 61, потому что после 60-ти тоже не должно регистрировать по правилам выдуманного нами сайта:
Валидные | Невалидные |
18 | 17 |
60 | 61 |
Где еще может использоваться эта техника? Например, в номере телефона. Все мы знаем, что валидный номер телефона состоит из 10 цифр, которые не относятся к коду страны ((+38)099 999 99 99). Это будет валидный номер телефона. Но что, если я хочу создать номер телефона из 11 цифр без кода страны (или из 9)? Номер телефона считается невалидным в таких случаях:
Валидные | Невалидные |
+38 099 999 99 99 | +38 099 999 99 99 9 |
+38 099 999 99 9 |
1. Создать пароль из 6-ти символов.
2. Создать пароль из 16-ти символов.
3. Создать пароль из 5-ти символов и ожидать, что регистрация не пройдет.
4. Создать пароль из 17-ти символов и ожидать, что регистрация не пройдет.
5. Зарегистрироваться с возрастом 18 лет.
6. Зарегистрироваться с возрастом 60 лет.
7. Зарегистрироваться с возрастом 17 лет.
8. Зарегистрироваться с возрастом 61 год.
9. Зарегистрироваться, указав правильный номер телефона из 10 символов без кода страны.
10. Зарегистрироваться, указав неправильный номер телефона из 9 символов без кода страны.
11. Зарегистрироваться, указав неправильный номер телефона из 11 символов без кода страны.
Для того, чтобы люди не тестировали 10 символов в пароле, которые никому не нужны, потому что они находятся на границе между 6 и 16. Для того, чтобы не тестировать возраст 20, 30, 40, потому что все эти значения находятся между 18 и 60. Также для того, чтобы люди не тестировали возраст 100 лет или -100 лет. Для того, чтоб не проверять номер телефона из 1, 2, 100 цифр. Потому что все эти проверки будут бессмысленными, ведь мы уже протестировали граничные значения.
Следующая техника тест-дизайна — «Таблица принятия решений» или ТПР.
Нужно нарисовать таблицу, в которой мы будем использовать разные условия и ситуации.
На примере Instagram мы должны заполнить четыре поля:
И мы будем решать, валидные или невалидные ситуации мы ввели, и показывать ожидаемый результат. Но сначала давайте условимся, как мы будем обозначать валидные и невалидные способы ввода:
Почему цифры 1 и 0? Так пишут программисты. В бинарном
Теперь нам нужно создать таблицу. Это делается с помощью дискретной математики.
Рисуем таблицу на 16 колонок. 16 — это если возвести 2 в 4 (а столько у нас полей) степень, то выйдет 16.
Нам нужно сделать так, чтобы все варианты ввода отличались друг от друга, то есть чтобы не было двух одинаковых, как я сделала в этом примере:
Поскольку у нас 16 колонок, то делим 16 на 2 и получаем 8. В первой строке этой таблицы первые 8 цифр заполняем нолями, вторые 8 цифр — единицами.
Чтоб заполнить следующую строку, делим уже 8 на 2 и получаем 4. Заполняем так: 4 ноля, 4 единицы, 4 ноля, 4 единицы.
Для следующей строки делим 4 на 2. Получается 2 ноля, 2 единицы, 2 ноля, 2 единицы, 2 ноля, 2 единицы, 2 ноля, 2 единицы.
И в последней строке проставляем 0 и 1 через 1: 0, 1, 0, 1, 0 , 1…
С помощью этой тактики мы получили уникальные колонки, то есть нет ни одной одинаковой пары.
Теперь давайте использовать эту таблицу:
В первой ситуации (столбце), мы вводим невалидный электронный ящик, имя пользователя, имя и фамилию, пароль. Если попробовать ввести все эти данные невалидно, то увидим, что регистрироваться нам не дадут, поэтому в строку с результатом вносим букву F — fail, и для наглядности можем сделать эту клеточку красной.
Так я буду проходиться по каждой колонке этой таблицы, пока не заполню все 16 результатов.
Во второй строке я должна ввести все невалидные данные, кроме пароля. Пробую на практике ввести нормальный пароль и нажать «Регистрация» и получаю два сообщения об ошибке:
В результат в таблице тоже пишу F, а в идеале в ту клеточку нужно вставить оба ожидаемых сообщения об ошибке.
Продолжаем пробовать все ситуации до конца таблицы. Конкретно в этом примере все результаты, кроме последней колонки, имеют статус Failed, а последняя — Pass, поскольку там мы ввели правильный мобильный телефон, официальное имя, никнейм и пароль.
Давайте создадим еще одну таблицу, но попроще, для примера.
Допустим, нам нужно загрузить аватарку, и есть требования: она должна весить меньше 1 Гб и быть в формате фото (jpg, png или gif). В таблице я делаю две строки:
Два во второй степени равно четырем, так что у нас будет всего четыре колонки:
1 | 2 | 3 | 4 | |
Формат фото? | 0 | 0 | 1 | 1 |
Размер меньше 1 Гб? | 0 | 1 | 0 | 1 |
Результат | Fail | Fail | Fail | Pass |
Пройдемся по каждой колонке:
А теперь я покажу еще один пример, только он будет интересней. Тут результат будет не Fail и Pass, а цифры. Но в клеточках таблицы также будут ноли и единицы.
Представьте себе, что вы пошли в супермаркет и для привлечения покупателей владелец придумал систему скидок:
Теперь давайте рассмотрим все эти ситуации и их результат:
С помощью этой таблицы мы увидели интересные вещи, которые точно пропустили бы без нее.
Например, что делать, если у нас есть две скидки (20% и 50%) одновременно: прибавлять их или использовать большую из них? Или такая ситуация: если клиент новенький, но пришел со скидочной картой, значит он ее у кого-то взял и пытается обмануть магазин. Что мы делаем в такой ситуации: прощаем и используем карточную скидку или выгоняем?
Соответственно, можно создать целых 16 интересных и уникальных тест-кейсов для 16 разных ситуаций. Помочь разобраться во всех аспектах помогут специалисты Robot Dreams со своим курсом QA Manual.
Для техники «Парное тестирование» нужно открыть любой интернет-магазин и каталог товаров. Пусть это будут «Cмартфоны, ТВ и электроника».
Давайте посмотрим на левую панель. Здесь есть обширный фильтр: по продавцу, отправке, бренду, алфавиту, цене, беспроцентному кредиту и т.д. В чем суть парного тестирования? Мы имеем много разных характеристик, по которым нужно сортировать, но мы будем тестировать не по одной характеристике, а сразу по двум. Для чего? Чтобы проверить, какая будет реакция у системы, какой будет результат. Переходим к практике. Сначала мы должны протестировать продавца и готовность к отправке. Ставим две галочки:
И проверяем, что есть товары, отфильтрованные по продавцу и по готовности к отправке. Теперь убираем галочку с «Готов к отправке» и ставим следующий фильтр, например, бренд:
То есть фильтруем по продавцу и по бренду, и проверяем, есть ли результаты. Результат есть — значит эта пара прошла. Идем дальше, бренд анчекаем, фильтруем по продавцу и по цене: выставляем цену от 359 до 500 грн. И этот фильтр тоже работает — тест прошел.
Идем дальше, убираем фильтр цены и ставим на «страну производителя», допустим, Индонезия. Видим, что отфильтровано два товара — тест пройден:
Убираем страну-производителя и ставим фильтр на страну регистрации бренда — Австралию. И так проходимся по комбинациям из двух разных фильтров, пока не протестируем все со всеми (первый и второй, первый и третий, второй и третий).
Следующая техника тест-дизайна — работа с диаграммой. И перед тем, как начинать, было бы логично показать, на каких сайтах и с помощью каких программ их удобно рисовать:
Первая диаграмма, которую мы рассмотрим — «Диаграмма перехода состояний» (State Transition Diagram). Всегда нужно учить английские термины, потому что спрашивают именно их. Итак, из чего состоит диаграмма перехода состояний? Из кружочков и стрелочек 🙂
Что у нас получилось? Это самый элементарный пример диаграммы перехода состояний, а именно — пример выключателя света: если мы выключим — то свет не горит, если включим— свет горит. Над стрелочками принято писать действия, которые мы делаем, например, «выключить свет» и «включить свет». А внутри кружочка пишутся состояния, которые в этот момент происходят. Например, если мы выключим свет, то состояние будет «темнота», а если включим, то состояние «светло».
Теперь давайте рассмотрим более сложную систему, например систему входа в социальную сеть.
Говорят, что каждая диаграмма перехода состояний должна иметь начало и конец, по этому мы рисуем кружочки и для этих состояний:
Сначала пользователь просто заходит на сайт и вводит логин и неправильный пароль (ведь мы его забыли :)). Результат — пароль неправильный.
Дальше вводим пароль со второй попытки (и опять неправильный). Результат — пароль снова неверный.
Третья попытка — снова вводим неверный пароль. Результат — пароль снова неверный и пользователя забанят на час.
Следующее действие — ждем, пока пройдет час. Результат — аккаунт разбанен.
Что дальше? Давайте снова введем неверный пароль. Поскольку система помнит, что у нас было три неудачных попытки, то она забанит нас на неделю.
Ждем неделю. Результат — аккаунт разбанен.
Давайте мы наконец-то поумнеем и нажмем на кнопку «Забыли пароль». Результат — на электронную почту приходит письмо для восстановления. Дальше пользователь проверяет почту, и как результат — в письме пришла ссылка для восстановления пароля.
Пользователь нажимает на ссылку для восстановления пароля, и видит сообщение «Введите новый пароль». Пользователь вводит пароль и аккаунт обновляется.
Зачем нужны эти диаграммы? Если у нас есть море вариантов, то мы легко можем запутаться или не покрыть все возможные варианты тест-кейсами.
Следующая техника будет называться «Диаграмма пользовательских ролей» (Use Case Diagram).
Представим себе обычный интернет-магазин. Какие там есть роли? Например:
У каждой роли есть свои права и доступы, и каждый из них умеет что-то делать. Поэтому рисуем четырех человечков, подписываем их роли и переходим к их действиям. Все действия будем указывать в небольших прямоугольниках. Проведем стрелочку от роли к доступному действию.
Давайте начнем с незарегистрированного пользователя. Он умеет:
Рисуем от незарегистрированного пользователя стрелочки к первым двум действиям. Чтоб добавить товар в корзину, его нужно открыть, то есть мы не можем кинуть товар в корзину, не посмотрев на него. Поэтому к действию «Добавлять товар в корзину» рисуем стрелочку от «Смотреть товар», а не от роли. То же самое с оформлением покупки, мы не можем оформить ее, не добавив товар в корзину, потому ведем стрелочку от «Добавить товар в корзину». У нас получилась небольшая цепочка с правами.
Теперь давайте посмотрим, что может покупатель:
Что может делать продавец:
Что может администратор:
Кроме очевидных тест-кейсов, которые приходят всем на ум, глядя на эту диаграмму, можно протестировать такие вещи:
1. Незарегистрированный пользователь не может изменять информацию о товаре
2. Незарегистрированный пользователь не может банить людей
3. Продавец не может банить людей
4. Администратор не может регистрироваться
Все предыдущие техники назывались техниками «черного ящика». Есть еще техники «белого ящика», но для них надо знать языки программирования и работать с кодом. Потому мы поговорим про следующие техники тест-дизайна, которые относятся к отдельной категории: тестирование, связанное с опытом.
Начнем с угадывания ошибок (Error Guessing). В этой технике нужны опытные ребята, которые могут придумать и вспомнить ситуации, в которых ПО «ломается». Обычно эти ситуации встречались им с предыдущим опытом. Именно эта техника сильно зависит от мастерства, ведь только опытные специалисты знают, где искать баг.
Какие типичные условия следует попробовать, чтоб пройти угадывание ошибок:
Это самые часто встречающиеся ошибки.
Переходим к последней технике. Это исследовательское тестирование.
Его нужно применять в ситуациях:
Окей, мы изучили, что это тестирование без подготовки и без документации, тогда назревает вопрос: а в чем разница между исследовательским и свободным тестированием
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…