Одна идея этого урока: продукт определяется не счастливым сценарием, а тем, что происходит на краях.
Знакомая ситуация
Агент построил бота записи на консультации. На демо всё идеально: выбрал слот, оплатил, получил подтверждение. Запускаешь на учениках – и за первый день: одна ученица нажала «оплатить» дважды и получила два списания; у другого оборвался интернет посреди оплаты – деньги ушли, запись не создалась; третья зашла, когда свободных слотов не осталось, и увидела пустой экран без единого слова.
Счастливый сценарий работал безупречно. Продукт – нет. Всё, что сломалось, не было багами в построенном – это были требования, которые никто не сформулировал.
Счастливый сценарий (happy path) – это витрина. Настоящий продукт – это поведение на краях: пусто, слишком много, оборвалось, нажали дважды. Краевые случаи (edge cases) – не «потом отполируем», а часть постановки задачи.
Классика краёв: пять вопросов к любой фиче
Края не нужно каждый раз выдумывать заново – они одни и те же почти в любой фиче. Держи короткий список:
1
Ноль – один – много zero – one – manyЧто увидит пользователь, когда данных нет совсем? Когда элемент один? Когда их тысяча? Пустой экран без объяснения – самый частый провал.
2
Повторное нажатие double submitКнопка нажата дважды подряд – из нетерпения или потому что «ничего не произошло». Два платежа, две записи, два письма?
3
Обрыв на середине interrupted operationСеть пропала между «деньги списаны» и «запись создана». В каком состоянии останется система и что увидит человек?
4
Невалидный ввод invalid inputТелефон с буквами, дата из прошлого, эмодзи вместо имени, пустое поле. Система должна вежливо объяснить, а не молча сломаться.
5
Одновременные действия concurrencyДва человека берут последний слот в одну секунду. Два администратора правят одну карточку ученика. Кто победит и узнает ли об этом второй?
Правило «ноль – один – много» (zero – one – many) из первого пункта – самый дешёвый инструмент списка: три вопроса, которые ловят целый класс проблем ещё на бумаге, до всякой стройки.
Края диктуются до постройки, а не находятся после
Ключевое отличие сеньора – момент, когда края попадают в задачу. Если агент получил только счастливый сценарий, он сам решит, что делать на краях – тихо и как попало: где-то молча проглотит ошибку, где-то покажет пустой экран. Потом эти решения найдут твои пользователи – самый дорогой вид тестирования.
Поэтому сеньор проходит по пяти вопросам выше до постройки и записывает ожидаемое поведение для каждого края прямо в постановку: «слотов нет – показать текст и кнопку „написать мне, когда появятся"». Одна минута на край в постановке против часа разборов с недовольной ученицей.
Как думают три уровня
Джун · строит happy path«Работает же!» Демо проходит, задача закрыта. Края обнаруживаются в бою, чинятся в панике, и каждая заплатка добавляет сложности.
Мидл · ловит края на тестированииПосле постройки садится и «прощёлкивает» продукт: находит пустые экраны и двойные нажатия. Уже хорошо – но найденное после стройки чинится дороже, чем учтённое до неё.
Сеньор · перечисляет края в постановке задачиКрая для него – требования наравне с фичами. В задаче агенту сразу написано: ноль, один, много, повтор, обрыв, невалидный ввод, одновременность – и ожидаемое поведение для каждого.
Проверь себя
1. Агент показал демо бота записи – счастливый сценарий работает идеально. Что делает сеньор перед запуском на учеников?
Демо показывает витрину – тот единственный путь, который строили специально. Повторный прогон того же пути ничего не добавляет. Ломается продукт всегда на краях, поэтому именно их сеньор проверяет до пользователей, а в идеале – диктует ещё в постановке.
2. Фича «список участников вебинара». Какие случаи проверить по правилу «ноль – один – много»?
Типичный случай и так проверяется демо, а «выдержал много» не означает «осмысленно показал ноль»: у пустого списка своя проблема – не нагрузка, а «что сказать человеку». Ноль, один и много ломаются по-разному, поэтому правило требует все три.
3. Два администратора школы одновременно редактируют карточку одного ученика. Кто должен решить, что при этом произойдёт?
«Чья правка выживет и узнает ли второй, что его изменения пропали» – это вопрос о том, как работает твоя школа, то есть продуктовое решение. Отдать его агенту – значит получить случайный ответ. А «слишком редкая» – иллюзия: редкие ситуации на реальных пользователях случаются регулярно, просто с каждым по отдельности.
Что говорить агенту уже сегодня
До постройки: перечисли краевые случаи этой фичи: пусто, один, много, повтор, обрыв сети, невалидный ввод, одновременные действия
Пустые экраны: что увидит пользователь, когда данных ноль? покажи все «пустые» состояния
Опасные места: что произойдёт при двойном нажатии «оплатить» и при обрыве сети посреди операции?
В постановке: вот список краёв – для каждого напиши ожидаемое поведение и согласуй со мной, прежде чем строить
Источники
Edge case (Wikipedia) – что такое краевой случай и почему работу с краями регулярно недооценивают.
Bill Wake, Zero-One-Many – правило «ноль – один – много» как способ проектировать от простого к общему.