Всем привет! Меня зовут Сергей, я – Senior Manual QA Engineer в "Петрович-Тех", и в этой статье я предлагаю разобрать граничные значения на практических кейсах.
Думаю, почти любой тестировщик вспоминает граничные значения первыми из всех техник тест-дизайна. Особенно на собеседовании. Граничные значения звучат просто и понятно, про них легко рассказать, потому что даже из названия ясно, где и как они применяются.
Несмотря на то, что техника простая – она решает много проблем. Это не попарное тестирование, о котором я писал здесь, где есть куча инструментов на выбор, надо правильно составить входные данные, потом анализировать их и выдавать результат. Тут всё проще: мы руководствуемся чистой логикой.
Разберем в статье конкретные примеры использования этой техники. Поехали!
Граничные значения – это техника тест-дизайна, которая направлена на проверку границ в исследуемом функционале. А по теории тестирования – это проверка допустимых минимальных и максимальных значений в рамках функционального тестирования программного обеспечения.
Можно согласиться и остановиться на этом. Но при обдумывании кейсов на проверку границ я бы всё-таки залез чуть-чуть дальше, за пределы классических определений: в предугадывание ошибок. Давайте посмотрим детальнее на примерах с сайта СТД «Петрович».
Карты
Обратимся к картам. Новички в тестировании могут сказать «Сергей, ну какие границы у карт, кроме очевидных пунктирных линий между странами. Земля же круглая, что тут еще смотреть».
Отвечаю. Карты — это очень полезный и хитрый инструмент. Он регулярно используется не только для того, чтобы пользователь указал себе удобную точку получения товара, но также для расчетов доставки. Тот, кто хоть раз тестировал карты, проклинает их знает, что они таят в себе много секретов.
У логистов есть много собственных границ: зоны доставки, зоны ограничений, правильность определения адреса в зависимости от местоположения человека, определение нужного адреса пользователю среди двух одинаковых на равноудаленном расстоянии (например, улица Ленина есть в каждом городе РФ), правильность координат и формат их передачи. Продолжать можно бесконечно.
Давайте придём на сайт «Петровича» и потестируем границы на картах. Возьмём один кейс про акционную доставку, так как если мы будем тестировать все границы, придется посвятить этому отдельную статью.
Открываем страницу «Доставка и подъем». Видим, что у нас по Петербургу она действует в 3 зонах (от центра города). Значит, нам нужно сделать очевидные следующие проверки:
1. Проверка доступности акционной доставки в зоне 3. Здесь мы проверяем границу с крайней доступной зоной для доставки.
2. Проверка недоступности акционной доставки в зоне 4. В это кейсе мы уже смотрим на границу, связанную с крайней недоступной для акционной доставки областью.
Из менее очевидного можно проверить:
3. Здание, которое стоит одновременно и зоне 3, и в зоне 4. Здесь мы анализируем поведение системы в спорной ситуации. В каждой компании по разному решают такие кейсы и их надо подмечать. Кстати говоря, такие кейсы могут ломать логику работы сайта.
4. Улицу, которая пересекает и зону 3 и зону 4. Здесь тоже самое, что и в 3-ем кейсе. Спорная ситуация, которая может возникнуть, если пользователь ввел адрес в адресную строку, без дома.
5. Здание в зоне 1–3 с ограничениями на доставку. Здесь мы просто проверяем недоступность доставки в принципе. В любом городе, есть места с ограничениями: здания администрации, здания за закрытой территорией, здания спец служб и другие.
6. Если у вас есть поиск по координатам, то есть и ограничение по количеству вводимых символов. Здесь можно создать много кейсов, проверяющие вводимое значение. Границы есть не только на картах, но и в числе координат. Одни системы могут обрабатывать одно количество после запятой, другие — другое. А возможно, есть какое‑то округление. В общем, всё зависит от Вашей системы.
И всё это будет относиться к граничным проверкам. Я уверен, что коллеги, часто работающие с картами, могут придумать еще много кейсов — буду рад комментариям по теме.
Деньги
Разберем границы в бонусной системе в корзине.
Условия: у Петровича есть система баллов Клуба Друзей (далее — КД). 1 балл = 4 рубля. Использовать можно от 70 баллов, т. е. при корзине от 280 рублей. Если заказ на сумму ровно 280 рублей, то при использовании баллов оплата за такой заказ будет от 0,01 до 1 рубля (здесь работает сложная внутренняя логика), потому что по закону и для банкинга важно, чтобы был какой‑то номинальный остаток. Верхней границы использования баллов нет.
Оговорюсь, примеры — упрощенные, так как система лояльности сложная штука и зависит не только от суммы, но и от товаров, их количества и других факторов.
Теперь выделим границы:
Наша граница 70 баллов, или 280 рублей. Наши кейсы:
Проверяем эту самую границу: создаем заказ на 280 рублей и тестируем возможность использования баллов КД. Ожидаемый результат: сумма в корзине от 0,01 до 1 ₽ Так мы проверяем ближайшую допустимую для использования баллов границу.
Проверяем небольшое отклонение от границы в большую сторону, используем заказ на сумму от 280,01 до 283,99, и также проверяем возможность использования баллов КД. Результат, который мы ждем: сумма в корзине от 0,01 до 1 ₽ Здесь мы также проверяем допустимость использования баллов.
Еще одно отклонение от границы в большую сторону, используем сумму 283,99 ₽ В этом кейсе нам важно увидеть, что нет возможности использовать еще один балл КД. Ожидаемый результат: применяется только 70 баллов. Сумма заказа 3,99 ₽ Здесь мы смотрим на количество используемых баллов на ближайшей допустимой границе.
Немного зайдем в тест‑дизайн «Предугадывание ошибок». Берем сумму заказа 279,99 руб и смотрим, чтобы не было возможности использовать баллы КД. Это базовая проверка недоступности использования наших баллов при покупке на самой крайней границе наших условий.
6, 7, 8 и далее. Таким же образом нужно проверить возможности использования 71 балла, то есть сделать заказ на 284 рубля. И для собственного спокойствия взять еще один кейс за 100 баллов (вдруг трехзначные числа использовать нельзя) — этого хватит. Для чего? Просто для того, чтобы проверить доступность использования баллов больше семидесяти.
Казалось бы — всё, граница на замке. Но давайте залезем поглубже. В любой системе есть округления. Где бы вы ни работали, они найдутся. Сумма из корзины идет в БД, из БД она идет в CRM, из CRM может пойти в эластик или обратно в БД. Как это можно отразить в контексте примера выше? Представим следующую ситуацию.
Я создал заказ на сумму 279,99 или 283,99 и решил не использовать сразу баллы КД в корзине. Мой заказ должен обработать оператор. Оператор делает это в CRM системе, как и в любом сайте. И вот он звонит мне, для того чтобы подтвердить заказ. И тут я говорю оператору: «Знаете, я подумал, давайте мы всё баллами оплатим». Оператор говорит «Окей» и инициирует оплату баллами со своей стороны. Внимание! Допустит ли система оплату баллами для заказа на 279,99 руб или допустит ли система покрыть полностью баллами заказ на 283,99 — 71 баллом? т. е. важно, имея доступ к проверкам из нескольких мест, использовать и их, потому что в одной системе сумма может не округляться, а в другой — наоборот, такая возможность имеется.
По такому же примеру можно проверить скидки, воздействия акций и тд. Вообще, по оплатам можно сделать большое количество проверок границ. Что важно — эти проверки легко придумать и осуществить.
Каталог
Напоследок возьмём каталог.
Каталог — непростая система. В зависимости от сайта у вас могут быть разные типы товаров. Есть товары с бесконечными остатками, например, подписки или какие‑то электронные сертификаты, но также такие товары могут иметь ограничения на покупку на один аккаунт. Есть товары, которые идут с производства напрямую. Их тоже можно считать условно бесконечными: понятно, что есть какие‑то ограничения по количественной нагрузке на предприятие, но давайте не будем совсем мудрить. И, разумеется, есть товары с остатками.
Здесь можем выстроить границы по:
1. Наличию товара на складе. Здесь, по аналогии с кейсами выше:
1.1 Кейс по покупке максимального количества товара. Для того, чтобы проверить возможность покупки всего того, что указано в наличии в «выпадашке», т. е. по самой верхней границе допустимости.
1.2 Кейс по покупке превышающее максимальное количество товара. Здесь уже мы смотрим на обратную сторону, проверяем поведение системы, тогда, когда мы превысили границу допустимости.
2. Политике стоимости товара в зависимости от покупаемого количества. Например акции «1+1=3» и им подобным. т. е. тут у кейсов будет задача проверять изменяемость цен в зависимости от количества товаров. Например:
2.1 Кейс про «1+1=3». Здесь мы проверяем работу акции в пределах ее обозначенных границ. На деле бывают самые разные кейсы. У нас в Петровиче есть акции «6+1», «7+1» и важно будет проверить работу их доступных границ.
2.2 Еще один такой же кейс, но с удвоенным количеством товара, т. е. 2+2=6. А если у вас кейс про какой‑то отдельный товар, например, если у Вас: «дрель Сергей + дрель Сергей = 3 дрели Сергей», то прикольно будет найти такой товар, наличие которого не делится на 3 и посмотреть как поведет себя система.
2.3 Кейс про покупку одного товара. Посмотреть, что скидка не применяется, т.к. границы для активизации акций не соблюдены.
2.4 Кейс на покупку 4-х товаров. Посмотреть, что скидка применяется только на один товар и этот товар, должен быть самый меньший по стоимости. Например, когда Вы приходите в магазин одежды, у которого такая акция, Вы понимаете, что бесплатным будет тот товар, который будет меньший по стоимости. Условно говоря: взяли джинсы и футболку = носки будут в подарок, так как они дешевле.
3. Кейсы на покупку товара с бесконечным остатком. Здесь можно сделать несколько кейсов про доступность покупки, а также кейсы с большими цифрами 1 млн единиц товара, 1 млрд и тд. Разные системы на такие кейсы реагируют по‑разному.
По каталогу есть много приколов. Например, если есть какая‑то бонусная система или промокоды, можно придумывать тесты с ней. Здесь в качестве примера могу привести случай в декабре 2023, на известном всем МегаМаркете, где при определенной комбинации использования промокодов и бонусов «Спасибо» можно было остаться в плюсе при покупке товара. А ведь такие моменты можно было выявить как раз проверками границ! Хотя, возможно, это был просто пиар‑ход для привлечения внимания пользователей.
Бонус от автора
Граничные значения — удобная техника тест‑дизайна, позволяющая выявлять специфические кейсы практически в любом ПО. Пишите свои комментарии, что думаете по поводу этой техники, как часто используете сейчас, и если есть, что дополнить по статье, а я тем временем добавлю анонс.
С 19 по 21 июля в Ульяновске пройдет ULCamp 2024, где я буду выступать с темой о тестировании оплат. Если хотите прикольно провести время и пообщаться в компании коллег по цеху — велкам, по промокоду скидка на билет 10%: SPEAKERSULCAMP