Всем привет. А помните, я не так давно рассказывал, как пользователь всегда сам покажет, как может сломаться программа? Так вот, я тут подумал, а не замутить ли мне серию постов на эту тему. Сегодня - первый пост про то, а что может вообще пойти не так.
Спойлер: не так пойти может почти всё :)))
Знаете, самый обманчивый момент в разработке - это когда код сделал то, что от него хотели. Кнопка нажалась, виджет появился, данные загрузились. Но один успешный запуск доказывает только одно:
Код оправдал гипотезу, что при этих данных, в таком порядке действий и с исправно работающим сервером мы получили ожидаемый результат.
А потом начинается самое интересное, когда один удачный запуск можно переставать считать доказательством удачного кода.
1. На примере формы обратной связи - могут прийти неожиданные данные от пользователя (как получилось у меня с виджетом)
И когда проектируешь такие системы, надо задать себе вопросы:
- а что, если пользователь введёт не те данные?
- а что, если пользователь попытается отправить пустоту?
- а что, если название в поле ввода слишком большое?
- а что, если....
Основной сценарий мы строим на удобных нам данных, но никто не гарантирует, что всё пойдёт так, как задумано.
2. На примере "ой, я вам сайт сломал"
Всегда есть вероятность, что пользователь на вашем проекте:
- нажмёт кнопку два раза
- обновит страницу во время загрузки карточки товаров
- накосячит еще в четырех местах одновременно.
Мы представляем аккуратный маршрут: действие → результат → следующее действие. Реальный человек может прервать, повторить или поменять порядок почти в любой момент.
3. Проблемы с сетью и их обработка
Да, это круто, когда localhost работает с 50мс на обработку запроса. В реальности запрос может вообще оборваться. Или идти пять секунд. Что будет делать пользователь в это время? Нажимать кнопку повторно десяток раз? Или как он поймет, что данные вообще сохранились? Не покажет ли ему интерфейс результат, что всё хорошо, а на самом деле всё будет плохо?
4. Внешние данные решили измениться
Сегодня API отдаёт все нужные поля, а завтра одно поле отсутствует, приходит в другом формате. содержит зхначения, о которых никто не знал и которых никто не ожидал. Что будем делать? И еще прикол в том, что даже собственный backend может поменяться раньше, чем сторонний API, благодаря лишь одной просьбе к ИИ о переделке.
5. Конфликт старого и нового состояния
Допустим первый запрос выполняется долго. А пользователь, пока его ждал, выполнил второй. Второй ответ пришёл быстро, интерфейс обновился, а потом пришёл ответ от первого раза и перезаписал данные устаревшей версией. И в итоге - баг.
И это лишь малая часть примеров, которые следует учитывать при разработке. Про остальное - в дальнейшей серии постов, которую мы создадим совместно с Алёной, автором канала "Тестирую жизнь". Она замечательный человек и классный QA специалист, нам есть, что вам рассказать 😀
🧠 Вместо морали
"Я создал/а код и он работает" - это слишком широкое утверждение. Полезнее спрашивать:
При каких условиях система перестанет работать правильно?
И либо учесть это самому, либо попросить об этом ИИ. Пример промта:
Найди возможные поломки кода в четырёх категориях: граничные значения, неожиданные действия пользователя, проблемы сети и некорректные внешние данные. Пока не пиши тесты. Для каждого сценария опиши риск и ожидаемое поведение интерфейса. Не придумывай требования, отдельно отметь места, где их не хватает.
Так ИИ не просто подтверждает уже написанный happy path, а помогает искать предположения, которые мы забыли проверить.
#папашапрогер #полезное