Подтвердите, что исправление реально: простые проверки до и после

Как выглядит настоящее исправление простыми словами

Настоящее исправление легко описать: проблема исчезает в той же самой ситуации, где раньше возникала, и остаётся исчезнувшей, когда вы повторяете те же действия.

Если вы не можете объяснить, что значит «исправлено» в одном предложении, легко принять изменение, которое выглядит хорошо только в быстрой демонстрации. Демонстрации обычно проходят на одном устройстве, под одной учётной записью и по идеальному сценарию. Реальные пользователи ведут себя не так аккуратно.

Чтобы подтвердить, что исправление реальное, сфокусируйтесь на доказательствах, которые можно повторить, а не на мнениях вроде «кажется работает» или «на моей машине работает». Вы не оцениваете код. Вы проверяете результат.

Простое определение, которое можно повторять:

Исправление реально, когда те же шаги, которые раньше падали, теперь проходят, и они продолжают проходить при небольших вариациях условий.

Почему быстрые демонстрации вводят в заблуждение

Многие баги прячутся за «особенными» условиями: вы уже вошли в систему, браузер сохранил данные или у вас есть доступ, о котором вы не знали.

Прототипы, сгенерированные ИИ, добавляют ещё одну ловушку: они иногда ведут себя по‑разному в зависимости от того, кто создал первые записи. Учётная запись сборщика выглядит нормально, тогда как у совершенно новых пользователей возникают ошибки.

Что считается надёжным доказательством (без чтения кода)

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

Надёжное доказательство обычно имеет такие черты:

• Чёткие, повторяемые шаги
• Зафиксированный «до» результат (ошибка, неправильный экран, нерабочая кнопка)
• Зафиксированный «после» результат (правильный экран, верные данные, отсутствие ошибки)
• Один и тот же результат два раза подряд
• Одна быстрая «обычная» вариация, которую вы не использовали в демонстрации (другая учётная запись, обновление страницы, другой браузер)

Если вы можете сделать это, у вас есть доказательство, а не предположение.

Зафиксируйте чёткий «до» результат

Начните с того, чтобы зафиксировать чистый «до» результат: одна конкретная вещь, которая ломается, записанная так, чтобы кто‑то другой мог повторить. Без этого легко принять счастливый клик за реальное исправление.

Выберите одну задачу, которая раньше ломалась, и держите её узкой.

• Слишком широкое: «Оформление заказа не работает.»
• Чётко: «При вводе данных карты и нажатии Pay висит спиннер навсегда.»

Запишите точные шаги в том порядке, в котором вы их делали, как если бы объясняли другу, который никогда не видел приложение. Укажите страницу, кнопки, по которым вы кликали, и то, что вводили (скрывайте приватные данные). Мелочи важны, потому что многие баги проявляются только после конкретного пути.

Сохраните то, что видели. Скриншота достаточно, если на нём видна ошибка. Если проблема связана с таймингом (вечная загрузка, редирект‑луп, кнопка, которая иногда не срабатывает), лучше 10–20 секунд записи экрана. Добавьте одно предложение о том, чего вы ожидали и что случилось на деле.

Также отметьте окружение, потому что одно и то же приложение может вести себя по‑разному на разных устройствах и в разных браузерах:

• Устройство (телефон или ноутбук)
• Браузер (Chrome, Safari и т. п.)
• Состояние аккаунта (вышли, тестовый аккаунт, основной аккаунт)
• Дата/время (помогает при сверке логов)
• Точный видимый результат (текст ошибки, пустая страница, бесконечная загрузка)

Пример заметки: «На iPhone Safari, вышел из аккаунта, нажал Sign up, ввёл email, нажал Create account, страница обновилась и вернулась к той же форме без сообщения.»

Пошагово: выполните простой тест до‑и‑после

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

1) Повторяйте те же шаги, а не «похожее»

Используйте ваше доказательство «до» (скриншот, запись или заметки) и следуйте ему как рецепту. Маленькие тесты лучше «кликайте вокруг и посмотрите», потому что они делают очевидным, что именно улучшилось.

Держите всё одинаковым:

• Начинайте с того же места (та же страница и состояние приложения)
• Выполняйте те же действия в том же порядке
• Используйте те же вводимые данные
• Ищите ту же точку отказа, которую вы зафиксировали ранее
• Повторите один раз сразу, чтобы подтвердить стабильность

2) Сравнивайте результаты, а не усилия

После изменения не судите по тому, насколько плавно всё прошло. Сравните случившееся с тем, что вы записали ранее.

Если «до» было «кнопка Login крутится вечно», то «после» должно быть явно другим: вы попадаете на дэшборд или получаете понятную ошибку, с которой можно что‑то сделать (например, «пароль слишком короткий»).

Также проверьте, что изменение действительно сохраняется. Если приложение показывает «Сохранено!», но обновление исчезает после перезагрузки — это не настоящее исправление. Это более красивый вид ошибки.

3) Если всё ещё падает, зафиксируйте, что изменилось

Если после теста всё ещё ошибка, зафиксируйте, что отличается: точный текст ошибки, на каком шаге вы были и что вводили. Одна маленькая разница (аккаунт, браузер, данные) часто объясняет, почему исправление выглядит правильным, но на самом деле нет.

Проверьте вторую учётную запись, чтобы избежать ложной уверенности

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

Создайте чистого тестового пользователя, который ведёт себя как новый клиент:

• Полностью выйдите из учётной записи (не просто закройте вкладку)
• Откройте приватное/инкогнито окно, чтобы не было куки
• Зарегистрируйтесь или войдите под второй учётной записью (другой email)
• Повторите тот же поток, который считали «исправленным»
• Подтвердите, что результат соответствует ожиданию

Если баг связан с онбордингом, правами, биллингом или настройкой профиля, часто правда проявится на второй учётной записи.

Также следите за ролями. Если в приложении есть роли вроде admin и member, протестируйте обе. Исправление, которое работает только для администратора, ещё не готово.

Пример: «Invite teammate» работает для админа, но новый участник при принятии приглашения получает пустой экран. Это часто указывает на сломанную сессию или пропущенные проверки прав.

Обновите и повторите: докажите, что оно выдерживает сброс

Исправление может выглядеть идеально один раз, а затем сломаться сразу после перезагрузки страницы или перезапуска приложения. Обычно это значит, что «успех» опирался на что‑то временное: кеш, застрявшую сессию или состояние, которое есть только в текущей вкладке.

Цель проста: верните приложение в нормальное состояние и повторите тест, чтобы убедиться, что результат остаётся прежним.

Быстрая процедура сброса (2–3 минуты)

Проведите подтверждённый «после» тест, но добавляйте по одному сбросу:

• Жёстко обновите страницу и повторите тест
• Выйдите и войдите снова, затем повторите тест
• Полностью закройте браузер/приложение и откройте снова, затем повторите тест
• Попробуйте в приватном/инкогнито окне

Не меняйте шаги теста во время этого. Если вы «помогаете» приложению, кликая вокруг, перезагружая на полпути или меняя путь, вы не поймёте, что реально сработало.

Как выглядит «последовательно»

Настоящее исправление — это скучно. Вы делаете то же самое после перезагрузки, и всё всегда работает одинаково.

Красные флажки, которые часто проявляются после сброса:

• Работает сразу после входа, ломается после обновления
• Работает до выхода, не работает после повторного входа
• Первый раз проходит, второй раз появляется пустой экран или другая ошибка

Пример: вы сбросили пароль, приложение говорит «Успешно». После жёсткого обновления новый пароль не работает. Значит сообщение изменилось, а обновление не применилось.

Пара быстрых вариаций, которые ловят большинство проблем

Не нужно тестировать сто вещей. Сначала проверьте один обычный сценарий, затем добавьте один небольшой поворот, который часто ломает приложения.

Хорошие вариации:

• Пустой ввод: оставьте одно обязательное поле пустым и отправьте форму
• Длинный ввод: вставьте очень длинное имя/адрес/запись
• Типичная опечатка: добавьте пробел в конце, неправильный регистр или один неверный символ
• Другой браузер или устройство: попробуйте один раз в другом браузере или на телефоне
• Повторите сразу: выполните то же действие два раза подряд

Пример: после исправления регистрации создайте аккаунт с нормальным имейлом. Затем попробуйте снова с тем же имейлом, но с пробелом в конце. Если приложение считает их разными пользователями, что‑то ещё не в порядке.

Когда остановиться (чтобы тестирование оставалось быстрым)

Остановитесь, как только тест даст вам новое знание.

• Если вариация провалилась — остановитесь и зафиксируйте точно, что вы сделали и что произошло
• Если две вариации ведут себя одинаково, переходите дальше
• Если работает в ещё одном браузере/устройстве, обычно этого достаточно на данном этапе

Быстрый чеклист, который можно повторять каждый раз

Вам не нужен идеальный QA-процесс. Нужен один и тот же небольшой набор проверок каждый раз, чтобы «исправлено» имело чёткий смысл.

Перед тестом запишите ожидаемый результат простыми словами.

• Хорошо: «После ввода правильного email и пароля я попадаю на дэшборд.»
• Ещё лучше: добавьте одну видимую деталь, которая доказывает, что всё сработало, например заголовок дэшборда.

Шаблон, который можно вставить в заметку:

• Название исправления + ожидаемый результат (простыми словами): ______________________________
• До результат (что происходило): Pass / Fail | Дата: ____ | Примечания: _______
• После результат (те же шаги): Pass / Fail | Дата: ____ | Примечания: __________
• Проверка второй учётной записи: Pass / Fail | Дата: ____ | Примечания: _____________
• Проверка обновления/сброса: Pass / Fail | Дата: ____ | Примечания: _____________

Держите заметки конкретными. Замените «кажется работает» на «Получена ошибка: ‘Invalid token’ после обновления» или «Дэшборд загрузился, но страница настроек пуста.»

Распространённые ошибки, которые заставляют считать исправление реальным, когда это не так

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

Типичные ловушки:

• Тестирование только под учётной записью сборщика/админа (дополнительные права и сохранённое состояние скрывают баги)
• Изменение сразу трёх вещей (нельзя понять, что помогло или что сломало)
• Доверие к единственному успешному прогону (тайминги и данные часто ломают второй раз)
• Неповторение тех же шагов, что вызвали баг (те же страница, порядок, ввод)
• Забвение о кешировании (старые скрипты, сохранённые сессии или устаревшие ответы могут маскировать проблемы)

Если исправление постоянно флипует между работой и сбоем, это обычно признак глубинной причины: сессии, права, грязные данные, хрупкая логика или шаблон, сгенерированный ИИ, который работает только на счастливом пути.

Пример: у вас работает вход, но у новых пользователей — нет

Вы (основатель) можете войти всегда, кажется, что всё исправлено. Но новый пользователь регистрируется и застревает на пустом экране или получает «invalid session».

Типичная «до» история: вы открываете приложение, кликаете Log in и попадаете на дэшборд. Коллега создаёт новый аккаунт, подтверждает email, а приложение перенаправляет его обратно на экран логина в цикле. Это может происходить только на мобильных или только сразу после регистрации, поэтому легко пропустить, если тестировать только своей учёткой.

Сразу после того, как кто‑то скажет «готово», выполните три проверки:

• До‑и‑после: повторите точные шаги, которые приводили к сбою (новая регистрация, подтверждение email, первый вход)
• Вторая учётная запись: сделайте это с аккаунтом, который никогда не заходил
• Тест обновления: когда попадёте на дэшборд, обновите страницу и перейдите на вторую страницу (например, Settings)

Если проходит один раз, но ломается позже, считайте, что это всё ещё нестабильно. Для багов с логином причина часто в временном токене, куки, который не устанавливается, или сессии, которая ломается после обновления. Ещё одна полезная проверка: подождите 5–10 минут и попробуйте тот же новый аккаунт снова.

Когда вы сообщаете результаты, держите это коротко и конкретно, чтобы никто не спорил о «работает»:

"До: Новая регистрация → подтверждение email → первый вход — цикл возврата на экран логина. После: Создал аккаунт B, завершил регистрацию, вошёл, попал на дэшборд, обновил страницу дважды, сессия осталась. Проверил снова через 10 минут — всё работает."

Следующие шаги, если вы всё ещё не доверяете исправлению

Если вы не можете уверенно подтвердить исправление, считайте это полезным сигналом. Это обычно значит, что тесты нечетки, исправление хрупкое или проблема шире, чем один патч.

Напишите короткую тестовую заметку, которой сможет воспользоваться любой:

• Шаги, которые вы сделали (клик за кликом)
• Что вы ожидали
• Что произошло
• Устройство и браузер
• Окружение (production vs staging) и время

Попросите повторяемое доказательство, а не обещание. Хорошее исправление включает простой способ показать, что оно остаётся исправленным.

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

Если ваш продукт создан ИИ и исправления всё время кажутся ненадёжными, фокусированный аудит часто быстрее, чем слепое исправление багов. FixMyMess (fixmymess.ai) специализируется на диагностике и ремонте кодовых баз, созданных ИИ, чтобы один и тот же баг не возвращался после выхода, обновления или регистрации нового аккаунта.