Error guessing и опытные техники

Все техники, разобранные с начала темы — классы эквивалентности, границы, таблицы решений, диаграммы состояний, pairwise — работают от структуры требования: сначала есть текст, описывающий поведение, и уже из него техника извлекает тестовые значения. А что делать, если требование вообще ничего не говорит про целую категорию ситуаций? Требование на запись в группу описывает, как один пользователь занимает свободное место. Оно ничего не говорит о том, что произойдёт, если два администратора одновременно нажмут «подтвердить» на последнее свободное место — потому что автор требования об этом просто не подумал. Систематической технике здесь не от чего оттолкнуться: структуры, из которой выводить тесты, попросту нет.

Чему научишься за этот урок:
— применять error guessing как систематизированный опыт, а не гадание наугад;
— назвать типичные источники багов, которые проверяют независимо от того, что написано в требовании;
— отличить error guessing от бессистемного «а вдруг сломается».

Когда систематика бессильна

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

Error guessing — это не гадание

Error guessing (предугадывание ошибок) — техника, основанная на опыте: тестировщик держит в голове список типичных мест, где разработчики обычно ошибаются — не по конкретному требованию, а вообще, в любых системах, — и целенаправленно проверяет их, даже когда требование ничего об этом не говорит.

Ключевое отличие от бессистемного «а вдруг сломается»: error guessing опирается на конкретный, выучиваемый список источников багов, накопленный отраслью за десятилетия практики, а не на случайную догадку в моменте. Тестировщик, который открывает форму и ждёт вдохновения, что бы такое странное туда ввести, занимается не error guessing, а случайным перебором — результат может быть похожим внешне, но метод принципиально другой: у одного есть система, у другого нет.

Типичный список источников багов

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

+-----------------------------------------------------------+
| ТИПИЧНЫЕ ИСТОЧНИКИ БАГОВ (стартовый список error guessing) |
+-----------------------------------------------------------+
| [ ] деление на ноль / пустая коллекция там, где ждали      |
|     хотя бы один элемент                                    |
| [ ] одновременная работа двух пользователей с одной и той  |
|     же записью                                               |
| [ ] часовые пояса и даты на стыке суток, месяца, года       |
| [ ] повторная отправка одной и той же формы                |
+-----------------------------------------------------------+
  • Деление на ноль / пустая коллекция. Формула среднего балла делит сумму на количество учеников — что если учеников в группе стало 0? Отчёт ждёт хотя бы одну запись — что если записей нет вообще?
  • Одновременная работа двух пользователей с одной записью. Два преподавателя одновременно открывают карточку одного ученика и меняют разные поля — чьё изменение сохранится, не потеряются ли данные?
  • Часовые пояса и даты на стыке суток, месяца, года. Действие происходит в 23:59 по часам пользователя, но уже в следующих сутках по серверному времени — какая дата запишется?
  • Повторная отправка одной и той же формы. Пользователь нажимает кнопку дважды подряд, пока первый запрос ещё не обработан — получится одна запись или две?

Пример на полигоне: два администратора и одно место

В группе на нашем полигоне осталось одно свободное место. Два администратора одновременно открывают заявки разных учеников и почти в один момент нажимают «Подтвердить». Требование про запись в группу описывает только обычный случай — один администратор, одно свободное действие. Про одновременное нажатие двух администраторов требование молчит полностью. Именно здесь и работает error guessing: тестировщик проверяет эту ситуацию не потому, что она описана, а потому что «одновременная работа двух пользователей с одной записью» — известная категория из списка, актуальная для любой формы с ограниченным ресурсом.

Правильное поведение системы в этом случае: место должен получить ровно один администратор (тот, чей запрос обработался первым), а второй должен увидеть понятное сообщение о том, что место уже занято — без создания второй записи сверх лимита группы и без падения системы.

Как применять список на практике

Работает список так: перед завершением тестирования любой фичи тестировщик проходит по каждому пункту и спрашивает «применимо ли это здесь?» — независимо от того, упоминает требование такую ситуацию или нет. Список растёт с опытом: со временем в него добавляются категории, характерные именно для проектов, с которыми работает тестировщик, но стартовый набор из этого урока применим почти везде с первого дня.

Итог:
— error guessing дополняет систематические техники там, где требование молчит совсем, а не заменяет их;
— в основе техники — систематизированный опыт отрасли, а не случайная догадка;
— насмотренность растёт с годами практики, но стартовый список типичных мест можно выучить сразу, не дожидаясь личных шишек.

Контрольный вопрос. Error guessing (предугадывание ошибок) — это техника тестирования, которая…

АОснована на систематизированном опыте: тестировщик держит список типичных мест, где разработчики обычно ошибаются, и целенаправленно их проверяет
БОснована на случайном переборе действий без всякой системы
ВРаботает только тогда, когда есть чёткое требование с описанием всех сценариев

Подсказка: Ключевое слово — систематизированный список, а не случайность.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. В чём главное отличие error guessing от бессистемного «а вдруг сломается»?

АError guessing опирается на конкретный, выучиваемый список типичных источников багов из практики отрасли, а не на случайный тык
БError guessing выполняется быстрее, чем любой другой вид тестирования
ВError guessing вообще не требует запускать систему

Подсказка: Разница не в скорости и не в результате, а в источнике идей для проверки.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Тестировщик проверяет: что произойдёт, если открыть список заявок группы, в которой сейчас нет ни одной заявки — список пуст, хотя интерфейс обычно ожидает хотя бы одну запись. К какой категории типичных источников багов из урока это относится? Ответь коротко, 2-3 слова.

Подсказка: Категория прямо называет ситуацию, когда коллекция оказывается пустой там, где ожидали хотя бы один элемент.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Какие из перечисленных проверок относятся к типичным источникам багов error guessing из урока (выбери все подходящие)?

Выберите все верные варианты.

АДва администратора одновременно нажимают «подтвердить» на последнее свободное место в группе
БПользователь вводит email без символа «@»
ВЗаявка создаётся ровно 31 декабря в 23:59, и её дата попадает уже в следующий год
ГПользователь дважды подряд отправляет одну и ту же форму записи на курс, пока первая отправка ещё обрабатывается

Подсказка: Проверка формата email — это негативная проверка из более раннего урока про позитивные и негативные проверки, а не пункт списка error guessing из этого урока.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Когда error guessing особенно полезен по сравнению с систематическими техниками (классы эквивалентности, границы, таблицы решений, диаграммы состояний)?

АКогда требование вообще ничего не говорит про целый класс ситуаций, и оттолкнуться от структуры требования невозможно
БКогда в требовании подробно расписаны все допустимые значения поля
ВКогда нужно проверить ровно одно поле формы

Подсказка: Вспомни рассуждение из начала урока про то, чего систематическим техникам не хватает.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. На чём в первую очередь строится список типичных источников багов в error guessing?

АНа накопленном опыте отрасли о местах, где разработчики обычно ошибаются
БНа личной интуиции конкретного тестировщика без всякой опоры на чужой опыт
ВНа формальном математическом расчёте вероятностей

Подсказка: Список можно выучить заранее — значит, он не завязан на личную интуицию одного человека.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Функция начисления баллов ученику срабатывает по расписанию раз в сутки в полночь по серверному времени. Тестировщик проверяет, что произойдёт, если ученик из другого часового пояса завершит задание за минуту до полуночи по своим часам, но уже после полуночи по серверным. К какой категории типичных источников багов из урока это относится? Ответь коротко, 2-4 слова.

Подсказка: Категория связана с расхождением дат и времени на стыке суток из-за часовых поясов.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. Отчёт по группе показывает средний балл учеников. Тестировщик проверяет отчёт для группы, из которой всех учеников удалили — учеников в группе стало 0. Формула среднего балла делит сумму баллов на количество учеников. Какая типичная ошибка программирования здесь напрашивается для проверки? Ответь коротко, 2-3 слова.

Подсказка: Что происходит при делении на количество, которое стало равно нулю?

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

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

Подсказка: Речь про запись, с которой одновременно работают два пользователя.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. На полигоне запускают новую фичу — форму записи на бесплатный вебинар с ограниченным числом мест (50 мест). Требование описывает только счастливый путь: «пользователь вводит имя и email, нажимает «Записаться», получает подтверждение». Составь 3 проверки в стиле error guessing для этой формы, каждая — из своей категории типичного списка урока (не повторяй одну категорию дважды). Для каждой укажи: что проверяем и какой реакции системы ожидаем.

Принято, если указаны три проверки из трёх разных категорий чеклиста, например: (1) одновременная работа: два пользователя одновременно занимают последнее 50-е место — ожидаем, что запишется только один, второй получит понятный отказ «мест не осталось»; (2) повторная отправка: пользователь дважды быстро нажимает «Записаться», пока первый запрос ещё обрабатывается — ожидаем ровно одну запись, а не две; (3) пустая коллекция/деление на ноль: организатор смотрит статистику заполненности вебинара, когда на него ещё никто не записался (0 из 50) — ожидаем корректное отображение «0 из 50», а не ошибку расчёта процента.

Подсказка: Возьми три разные категории из чеклиста урока, подходящие именно записи с ограниченным числом мест: например про одновременность, про повторную отправку и про пустую коллекцию/деление на ноль.

✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.

Онлайн-проверка ответа появится позже

Задание. Два администратора одновременно нажимают «Подтвердить» на последнее свободное место в группе (пример из урока). Опиши одним предложением, какое поведение системы будет ПРАВИЛЬНЫМ в этой ситуации.

Критерий приёмки: Правильное поведение: место должен получить ровно один из администраторов (тот, чей запрос обработался первым), а второй должен увидеть понятное сообщение о том, что место уже занято, без создания второй записи сверх лимита и без падения системы.

Подсказка: Правильное поведение — не «оба успеха» и не «крах системы», а корректный результат с понятным сообщением для того, кто не успел.

✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.

Онлайн-проверка ответа появится позже

Задание. Стажёр-тестировщик говорит: «Я тоже применяю error guessing — просто открываю форму и жду вдохновения, что бы такое странное туда ввести». Объясни одним-двумя предложениями, почему это НЕ error guessing в том смысле, в котором техника описана в уроке, и что стажёру нужно сделать, чтобы это стало настоящим error guessing.

Критерий приёмки: Это не error guessing, а бессистемный случайный перебор («а вдруг сломается»): у стажёра нет опоры на список типичных источников багов из практики отрасли, идеи берутся из момента вдохновения, а не из систематизированного опыта. Чтобы это стало настоящим error guessing, стажёру нужно выучить и осознанно применять конкретный список категорий (деление на ноль, пустые коллекции, одновременная работа нескольких пользователей, часовые пояса, повторная отправка и т.п.), а не полагаться на случайную догадку.

Подсказка: Вспомни, в чём разница error guessing и бессистемного «а вдруг сломается» — дело не в результате, а в источнике идей для проверки.

✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.

Онлайн-проверка ответа появится позже

Что дальше

Теперь в арсенале есть весь набор техник тест-дизайна: от систематических (классы, границы, таблицы решений, состояния, pairwise) до опытных (error guessing). Следующий вопрос — как понять, что тестов достаточно, и как измерить, какую часть системы они реально покрывают. В следующем уроке разберём метрики покрытия тестами.

Назад  ·  ↑ В начало урока  ·  ⌂ В начало курса  ·  Вперёд →

Школа Виктора Комлева