БЛОК 3. Основы тестирования — 10. Boundary Value и Edge cases
🧭 Введение: почему баги часто живут на границах
Многие фичи «в середине» работают нормально, но падают на минимуме, максимуме и рядом с ними. Именно поэтому junior QA важно не только проверять обычные значения, но и целенаправленно идти в границы.
Boundary Value Analysis (BVA) помогает проверить лимиты системно, а edge cases расширяют картину редкими, но реалистичными ситуациями.
💡 Совет:
Если в требовании есть диапазон, длина, лимит или счётчик, сразу помечайте это как зону boundary-тестов.
✅ Вывод:
Границы и edge-кейсы — это быстрый способ находить «тихие» дефекты до релиза.
⚠️ Проблема -> решение
Без boundary-подхода QA часто проверяет «типичные» значения и пропускает баги на 0, 1, min, max, max+1. В результате критичные дефекты проявляются у реальных пользователей под нагрузкой или на редких данных.
Решение — строить проверку в двух слоях:
- boundary values (границы и рядом с границами);
- edge cases (редкие/нестандартные условия использования).
🟢 Если совсем просто:
BVA отвечает на вопрос «что на лимитах», edge cases — «что в необычных, но возможных ситуациях».
🎯 Как понять, что этап прошёл успешно:
Для каждого ограничения в требованиях есть набор boundary-проверок и минимум 1–2 edge-сценария.
🛠️ Чем помогает и как работает
BVA и edge-подход делают тест-дизайн предсказуемым. Вы не гадаете «что бы ещё проверить», а идёте по понятному алгоритму от требований к проверкам.
Как это работает:
- Шаг 1: находите все ограничения (диапазоны, длины, лимиты, квоты, счётчики).
- Шаг 2: выделяете значения: min-1, min, min+1, max-1, max, max+1.
- Шаг 3: задаёте expected result для каждого значения.
- Шаг 4: добавляете edge-ситуации (редкие комбинации, тайминги, параллельные действия).
- Шаг 5: приоритизируете проверки по риску.
- Шаг 6: переводите это в тест-кейсы/чек-лист.
✅ Вывод:
Системный подход к границам резко сокращает вероятность пропуска критичных дефектов.
📚 Ключевые термины (простыми словами)
- Boundary Value Analysis (анализ граничных значений) — техника проверки минимумов, максимумов и соседних значений.
- Edge case (граничный/редкий кейс) — нестандартная ситуация, где поведение системы может отличаться от обычного.
- Range (диапазон) — допустимый интервал значений.
- Limit (лимит) — верхняя или нижняя граница.
- Valid (валидное значение) — допустимое значение по требованиям.
- Invalid (невалидное значение) — значение вне допустимых правил.
- Expected result (ожидаемый результат) — что система должна вернуть для конкретной проверки.
- Test data set (набор тестовых данных) — подготовленный список значений для выполнения сценариев.
1. Boundary Value Analysis: что проверяем и зачем
BVA применяют там, где есть количественные ограничения: возраст, длина поля, сумма, количество попыток, размер файла, дата в диапазоне.
🟢 Если совсем просто:
Нас интересует не «любое число из середины», а точки возле границ.
🎯 Как понять, что этап прошёл успешно:
Для каждого ограничения подготовлены минимум 6 точек: min-1, min, min+1, max-1, max, max+1.
Назначение:
Найти дефекты в валидации и логике обработки лимитов.
Простыми словами:
Проверяем дверь не только «открывается», но и «что происходит прямо на пороге».
Для новичка:
Если в задаче есть «от ... до ...», это почти всегда сигнал делать boundary-набор.
Аналогия:
Как проверка лифта: важны не только этажи «в середине», но и первый/последний этаж и попытка выйти за предел.
Пример:
Требование: возраст 18–65Проверки:17 (invalid), 18 (valid), 19 (valid), 64 (valid), 65 (valid), 66 (invalid)Мини-шаблон BVA (быстрое правило):
Если есть диапазон min..max, проверь:- min - 1- min- min + 1- значение из середины- max - 1- max- max + 1🔎 Как это происходит на практике:
- QA выписывает диапазон из AC.
- Строит таблицу граничных значений.
- Для каждой строки фиксирует expected result.
Характеристики:
- ✅ Высокая вероятность найти баги за короткое время.
- ✅ Чётко привязывается к требованиям.
- ✅ Легко объясняется команде.
Когда использовать:
Всегда, когда есть числовые, символьные или временные ограничения.
✅ Вывод:
BVA — базовая must-have техника для любого junior QA.
2. Edge cases: редкие, но реальные ситуации
Edge cases дополняют BVA. Они не всегда про «число +1/-1», а про нестандартный контекст: повторный submit, редкая комбинация полей, timing, параллельные действия.
🟢 Если совсем просто:
Edge — это «необычная, но возможная» ситуация.
🎯 Как понять, что этап прошёл успешно:
Вы добавили edge-сценарии, которые отражают реальные пользовательские и системные риски.
Назначение:
Проверить устойчивость функции вне обычного потока.
Простыми словами:
Смотрим, как система ведёт себя, когда пользователь делает что-то не так или среда нестабильна.
Для новичка:
Если сценарий редкий, но может случиться в проде, это кандидат в edge-case.
Аналогия:
Как проверка авто не только в городе, но и на льду, в ливень и при резком торможении.
Пример:
Форма регистрации:- двойной клик по кнопке "Создать аккаунт"- refresh страницы в момент отправки- очень длинное имя + невалидный телефон одновременноМини-шаблон для поиска edge cases:
Спроси себя:- Что если сделать действие дважды?- Что если обновить страницу в критический момент?- Что если данные придут в необычном формате?- Что если внешний сервис не ответит?- Что если ввести спецсимволы/emoji/пробелы?- Что если пользователь делает действие слишком быстро?- Что если ограничение уже почти достигнуто?🔎 Как это происходит на практике:
- QA смотрит на историю инцидентов и поддержку.
- Выбирает 3–5 редких, но рискованных условий.
- Проверяет корректность поведения и отсутствие дублей/потерь данных.
Характеристики:
- ✅ Находит дефекты, которые пропускают обычные проверки.
- ✅ Хорошо выявляет проблемы с устойчивостью.
- ✅ Повышает надёжность релиза.
Когда использовать:
После базового happy/negative и boundary-покрытия.
✅ Вывод:
Edge cases закрывают «слепые зоны», которые часто выходят в прод.
3. Boundary vs Edge: как не путать
Новички часто смешивают эти термины. Это нормально на старте, но для качественного тест-дизайна важно разделять их.
🟢 Если совсем просто:
Boundary — про границы диапазона, edge — про нестандартный контекст.
🎯 Как понять, что этап прошёл успешно:
В сценарной карте отдельно видны boundary-набор и edge-сценарии.
Назначение:
Сделать покрытие точным и избежать дублирования проверок.
Простыми словами:
Boundary — «какие числа/длины брать», edge — «в каких необычных условиях проверять».
Для новичка:
Если проверяете min/max — это boundary. Если проверяете редкое поведение пользователя/системы — это edge.
Пример:
Пароль 8–20 символов Boundary:- 7, 8, 9, 19, 20, 21 Edge:- 8 символов + эмодзи- вставка из буфера с пробелом в конце- повторный submit при медленном ответе API✅ Вывод:
Разделение boundary и edge делает тест-покрытие глубже и понятнее для ревью.
4. Пошаговый алгоритм для junior QA
Чтобы не «придумывать проверки в воздухе», используйте простой рабочий алгоритм.
🟢 Если совсем просто:
Ограничение -> граничные значения -> expected result -> edge-риски.
🎯 Как понять, что этап прошёл успешно:
По требованию собрана таблица boundary + список edge-сценариев с приоритетом.
Алгоритм:
- Выписать все ограничения из требований.
- Построить boundary-набор значений.
- Зафиксировать expected result по каждому значению.
- Добавить 2–5 edge-сценариев по реальным рискам.
- Проставить priority для релизного прогона.
- Перенести в тест-кейсы/чек-лист.
✅ Вывод:
Алгоритм снижает хаос и повышает воспроизводимость качества.
📊 Сравнение: Boundary Value vs Edge Case
| Критерий | Boundary Value | Edge Case |
|---|---|---|
| Что проверяет | Границы и соседние значения | Редкие/нестандартные условия |
| Главный источник | Ограничения из требований | Риски использования и среды |
| Тип данных | Числа, длины, даты, лимиты | Комбинации, тайминги, повторные действия |
| Цель | Проверить корректность валидации | Проверить устойчивость поведения |
| Пример | 7/8/20/21 символ | Double submit, refresh на отправке |
✅ Must-Know для junior QA
- Если есть диапазон — делайте boundary-набор обязательно.
- Проверка только min и max недостаточна: нужны соседние значения.
- Edge cases не заменяют BVA, а дополняют его.
- Expected result должен быть у каждого boundary/edge теста.
- Приоритет проверок задаётся риском, а не удобством выполнения.
- Границы часто ломаются после изменений в backend-валидации.
- История инцидентов — хороший источник edge-сценариев.
❌ Частые мифы
❌ Миф:
Boundary Value нужен только для чисел. ✅ Как правильно:
Он применим и к длине строк, и к датам, и к лимитам попыток. 📎 Почему это важно:
Иначе легко пропустить баги в полях ввода и ограничениях API.
Boundary Value нужен только для чисел. ✅ Как правильно:
Он применим и к длине строк, и к датам, и к лимитам попыток. 📎 Почему это важно:
Иначе легко пропустить баги в полях ввода и ограничениях API.
❌ Миф:
Достаточно проверить только min и max. ✅ Как правильно:
Нужны ещё значения рядом с границами: min-1/min+1/max-1/max+1. 📎 Почему это важно:
Ошибки часто живут именно в соседних точках.
Достаточно проверить только min и max. ✅ Как правильно:
Нужны ещё значения рядом с границами: min-1/min+1/max-1/max+1. 📎 Почему это важно:
Ошибки часто живут именно в соседних точках.
❌ Миф:
Edge cases — это лишнее для junior. ✅ Как правильно:
Даже 2–3 edge-сценария могут поймать критичный баг до релиза. 📎 Почему это важно:
Редкие условия часто становятся прод-инцидентами.
Edge cases — это лишнее для junior. ✅ Как правильно:
Даже 2–3 edge-сценария могут поймать критичный баг до релиза. 📎 Почему это важно:
Редкие условия часто становятся прод-инцидентами.
❌ Миф:
Boundary и negative — одно и то же. ✅ Как правильно:
Boundary — техника выбора данных на границах, negative — класс сценариев с ошибочным/невалидным поведением. 📎 Почему это важно:
Точное разделение повышает качество тест-дизайна.
Boundary и negative — одно и то же. ✅ Как правильно:
Boundary — техника выбора данных на границах, negative — класс сценариев с ошибочным/невалидным поведением. 📎 Почему это важно:
Точное разделение повышает качество тест-дизайна.
❓ Часто спрашивают на собеседованиях
❓ Вопрос:
Что такое Boundary Value Analysis? ✅ Ответ:
Это техника тест-дизайна, где проверяют значения на границах допустимого диапазона и рядом с ними.
Что такое Boundary Value Analysis? ✅ Ответ:
Это техника тест-дизайна, где проверяют значения на границах допустимого диапазона и рядом с ними.
❓ Вопрос:
Почему нужно проверять min+1 и max-1? ✅ Ответ:
Потому что дефекты часто проявляются не только на самой границе, но и в соседних значениях.
Почему нужно проверять min+1 и max-1? ✅ Ответ:
Потому что дефекты часто проявляются не только на самой границе, но и в соседних значениях.
❓ Вопрос:
Чем edge case отличается от boundary test? ✅ Ответ:
Boundary test проверяет граничные значения, а edge case — нестандартные условия использования или состояния системы.
Чем edge case отличается от boundary test? ✅ Ответ:
Boundary test проверяет граничные значения, а edge case — нестандартные условия использования или состояния системы.
❓ Вопрос:
Как выбрать edge-кейсы, если времени мало? ✅ Ответ:
Берут сценарии с максимальным риском: дубли, таймауты, лимиты попыток, параллельные действия.
Как выбрать edge-кейсы, если времени мало? ✅ Ответ:
Берут сценарии с максимальным риском: дубли, таймауты, лимиты попыток, параллельные действия.
❓ Вопрос:
Как понять, что boundary-покрытие достаточное? ✅ Ответ:
Когда по каждому ограничению есть набор значений до/на/после границы и ожидаемый результат на каждую проверку.
Как понять, что boundary-покрытие достаточное? ✅ Ответ:
Когда по каждому ограничению есть набор значений до/на/после границы и ожидаемый результат на каждую проверку.
🚫 Типичные ошибки
Ошибка 1: Проверяют только «середину»
❌ Неправильно:
Тестировать только удобные валидные значения.
✅ Правильно:
Сначала закрывать граничные точки и значения рядом.
Почему:
Именно там чаще всего находятся дефекты валидации.
Ошибка 2: Не фиксируют expected result
❌ Неправильно:
«Проверить 21 символ» без описания ожидаемого поведения.
✅ Правильно:
Явно фиксировать, что должно произойти на каждом значении.
Почему:
Без expected result pass/fail становится субъективным.
Ошибка 3: Путают edge и случайные проверки
❌ Неправильно:
Добавлять «что пришло в голову» без связи с риском.
✅ Правильно:
Выбирать edge-кейсы по реальным сценариям и инцидентам.
Почему:
Так проверки дают практическую пользу, а не шум.
Ошибка 4: Нет приоритета перед релизом
❌ Неправильно:
Запускать boundary и edge проверки в случайном порядке.
✅ Правильно:
Сначала critical ограничения и высокорисковые edge-кейсы.
Почему:
Это снижает релизный риск при ограниченном времени.
🧩 Best Practices
- Для каждого ограничения делайте мини-таблицу boundary-значений.
- Храните набор типовых edge-кейсов для повторного использования.
- Привязывайте boundary/edge проверки к AC и рискам.
- Проверяйте одинаковые ограничения на UI и API уровнях.
- Обновляйте edge-набор после каждого прод-инцидента.
- На ревью объясняйте, почему именно эти границы и edge выбраны.
🏁 Заключение
Boundary Value и Edge cases — ключевые навыки, которые быстро отличают системного QA от «кликера».
Они помогают проверять не только «что работает», но и «насколько это надёжно на границах и в нестандартных условиях».
Они помогают проверять не только «что работает», но и «насколько это надёжно на границах и в нестандартных условиях».
Если вы стабильно применяете BVA + edge-подход, качество ваших проверок растёт очень заметно уже на уровне junior.