Прошлая часть: Составление проверок или первые шаги к тест-дизайну
Всем привет. Мы продолжаем.
После прочтения предыдущей главы у вас могло возникнуть много вопросов. Например, «Какие конкретно тестовые данные надо брать для конкретной проверки? Ведь если поле пароль длиной от 10 до 256 символов – какую длину брать правильнее – 11 символов или 243?». Или, например, вот такой вопрос - «Есть ли какой-то универсальный подход/подходы для составления проверок?». Ответы на эти вопросы дает «тест-дизайн»
Тест-дизайн – этап тестирования ПО, на котором проектируются и создаются тест-кейсы, в соответствии с определенными ранее критериями качества и целями тестирования. Это по определению. По-рабочекрестьянски – это часть работы тестировщика, когда он составляет список проверок, которые будет проводить по конкретному функционалу.
Для того, чтобы этот этап тестирования проходил более продуктивно применяют «техники тест-дизайна». Если по-простому – это подходы к составлению проверок, которые упрощают их составление и сокращают их количество, что немаловажно. Наиболее популярными техниками являются «Классы эквивалентности», «Граничные значения». На деле их больше, но лично я не вижу смысла вдаваться в такие подробности для инженера уровня Junior. Эти две техники покроют 99% ваших потребностей во время реальной работы.
Рассматривать применение этих подходов мы будем на куске кода, который якобы проверяет поле «логин» на валидность. Да, вроде как тут мы говорим про «тестирование для чайников», но в этом куске кода нет ничего страшного, да и на плюс-минус реальных примерах материал мы закрепим лучше. Вот сам код (в который, кстати, заведомо добавлена ошибка, чтобы продемонстрировать как сработают данные подходы):
Классы эквивалентности
Классы эквивалентности – это техника тестирования, когда вы разделяете входные данные на классы, которые с точки зрения проверок являются одинаковыми и выбираете из каждого класса по одному представителю.
На примере поля «Логин» из предыдущей главы мы видим, что на него наложены следующие ограничения: «Поле ввода принимает для ввода английские буквы, арабские цифры, а также символы «_», «-», «.»».
Допустимые значения нам понятны. Недопустимые значения тоже. Но представьте количество комбинаций, которые мы можем тут составить. Давайте рассмотрим примеры возможных входных данных, заранее договорившись, что все перечисленные логины будут уникальны на момент проведения проверки.:
- «login» - допустимые данные, покрывает часть требований только про английские буквы
- «login1» - допустимые данные, покрывает часть требований только про английские буквы и цифры
- «login_1» - допустимые данные, покрывает часть требований только про английские буквы, цифры и символ «_»
- «log-in.New_1» - допустимые данные, покрывает всю часть требований про возможные данные для ввода
Возникает резонный вопрос – «Зачем проводить много проверок, если можно провести всего лишь одну?». И ответ на него – незачем. Мы из всех вариантов для входных данных берем тот, которые максимально покрывает описанные требования т.е. «log-in.New_1», так как значения с точки зрения программного кода должны быть эквивалентны между собой и по приведенному выше коду вы это можете увидеть. Какое бы из валидных значений вы не выбрали – оно пройдет один и тот же путь проверок – блоки №1, №2, №3 и №4. При этом всём надо учитывать, что в процессе тестирования вам приходилось бы каждый раз заполнять поля «Пароль» и «Повторите пароль», а также придумывать новый уникальный логин, что увеличивало бы время тестирования.
Что по поводу недопустимых значений? В первую очередь – у нас есть преимущество, т.к. нам не придется заполнять поля «Пароль» и «Повторите пароль», т.к. при вводе недопустимых значений в поле «Логин» у нас не завершается регистрация. Давайте взглянем на код, который проверяет текст из поля «Логин» на валидность по указанной выше части требований.
В теории вы тут можете обойтись значением «login!@#$%^&*()+=?:;№Ы», но, к сожалению, разработчик может в процессе написания кода сделать опечатку в регулярном выражении «[a-z0-9_.-]» и сделать его вида «[a-z0-9_.-!]» (добавлен восклицательный знак), что приведет к распознаванию строки «login!» как валидной, а следовательно к багу. По поводу символов «!@#$%^&*()+=?:;№» - я бы, будь я начинающим и не умеющим читать код тестировщиком, провел проверки вида «login!» / «login@» / «login#» и так далее (сколько людей, столько и мнений). Они будут не такие уж и трудозатратные, т.к. при получении ошибки валидации мы сможем просто стирать последний символ в поле «Логин» и менять его на новый, без повторного заполнения полей «Пароль» и «Повторите пароль». Но даже здесь мы можем сократить список проверок при помощи классов эквивалентности. Например «LoginЫ» и «loginЯ» для нас будут эквивалентные, так как если мы на одной из этих проверок получим ошибку – это будет значить, что все буквы русского алфавита не валидны.
На более абстрактном примере – у вас есть 100 тысяч объектов с одинаковым набором свойств. Требования гласят, что если у объекта свойство X равное 1, то с объектом можно выполнить операцию №1. При этом 25 тысяч объектов имеют свойство Х равное 1, а 75 тысяч объектов имеют свойство Х не равное 1.
Используя технику «Классы эквивалентности» вам достаточно взять 1 любой объект из тех 25 тысяч, где свойство Х равно 1 и проверить возможность выполнения операции №1. Если операция выполняется с ним, то выполнится и с оставшимися 24999 объектами. И аналогично со второй частью объектов – берем любой объект из 75 тысяч, где свойство Х не равно 1 и проверяем отсутствие возможности выполнения операции №1. Если эта возможность отсутствует, то она будет отсутствовать и на оставшихся 74999 объектах.
Граничные значения
Пожалуй, самая простая для понимания техника тест-дизайна – это «Граничные значения». Ее используют прямо так, как она слышится – определяют границы поля ввода и проверяют что за пределы этих границ нельзя выйти. На примере требований к полю ввода «Логин»: «Минимальная длина логина – 5 символов. Максимальная длина логина – 40 символов.». Что это значит – что у нас есть вариантов проверок, когда логин длиной:
- 4 символа - первое меньшее значение, чем минимальная допустимая длины
- 5 символов – левая граница, минимально допустимая длина
- Любая длина от 6 до 39 – значение внутри допустимого интервала значений, чтобы убедиться, что логин может быть длиной не только 5 или 40. Длина может быть любой из интервала т.к. мы уже знаем про классы эквивалентности
- 40 символов – правая граница, максимально допустимая длина
- 41 символ – первое большее значение, чем максимальная допустимая длина
Вот так всё просто, а главное эффективно. Аналогично это будет работать со всякими «скидка должна начисляться при заказе от 150 тысяч рублей» - тогда вы будете проверять значения 149999 / 150000 / 150001. Или «Допустимые значения для ввода [-100;100]» - тогда вы будете проверять значения -101;-100; 100; 101 и любое значение от -99 до 99. Как-то так.
Я упомянул выше, что в куске кода заложена ошибка и сейчас я продемонстрирую, как техника граничных значений ее найдет. Разработчика в процессе написания кода отвлекли звонком (ну или интересным тик-током), и он в блоке №3 при проверке «верхней» границы написал неправильно условие сравнения. Написал «больше или равно» вместо «строго больше» и таким образом при длине поля «логин» в 40 символов программа будет выдавать ошибку, хотя не должна это делать по требованиям.
Путь проверок в реальности будет примерно такой:
- Проверили логин длиной 4 символа – получили ошибку – проверка прошла успешно.
- Проверили логин длиной 5 символов – успешно зарегистрировались – проверка прошла успешно.
- Проверили логин длиной 13 символов – успешно зарегистрировались – проверка прошла успешно.
- Проверили логин длиной 40 символов – получили ошибку – проверка прошла неудачно.
- Проверили логин длиной 39 символов для локализации проблемы из проверки №4 – успешно зарегистрировались – проверка прошла удачно.
- Сделали вывод из шагов №4 и №5, что разработчик сделал ошибку в проверке верхней границы, оформили баг-репорт.
- При перепроверке баг-репорта снова проверили все граничные значения.
Следующая часть: Чек-листы и тест-кейсы
Поддержать или поблагодарить можете:
Лайком;
Комментарием;
Подпиской на канал;
#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля
