Многие web-баги связаны не с кнопкой на экране, а с тем, что приложение неправильно хранит или читает данные в браузере. Пользователь "вроде уже вышел, но всё ещё залогинен", новая вкладка ведёт себя иначе, старая ошибка повторяется после refresh, фильтр помнит старое состояние, а токен живёт дольше, чем ожидалось. Очень часто корень таких историй сидит в cookies, sessionStorage или localStorage.
Для QA это важная тема, потому что browser storage напрямую влияет на сессии, авторизацию, поведение вкладок, восстановление состояния и воспроизводимость тестов. Если не понимать, где именно живут данные, легко принять закономерное поведение за баг или наоборот пропустить реальную проблему.
В чём между ними разница
На базовом уровне разница такая:
- →Cookies часто используются для сессий, авторизации и серверного взаимодействия. Они могут отправляться на сервер автоматически.
- →sessionStorage живёт в рамках конкретной вкладки и конкретной сессии страницы.
- →localStorage живёт дольше и сохраняется между перезагрузками и даже между сессиями браузера.
Но для QA важно не просто выучить эти три определения. Важнее понимать практические последствия.
Cookies чаще всего влияют на login flow, logout, remember me, серверные сессии, CSRF-защиту и поведение между вкладками. sessionStorage часто участвует во временном клиентском состоянии: черновики, промежуточные шаги, локальный UI state внутри текущей вкладки. localStorage обычно используют для более "долгоживущих" вещей: токенов, настроек интерфейса, выбранного языка, feature flags, локальных кэшей и клиентских предпочтений.
И именно здесь начинаются реальные риски.
Cookies: не просто маленькие данные в браузере
Cookies важны для QA прежде всего потому, что они часто связаны с серверной сессией. Это значит, что поведение продукта может зависеть не только от UI и JavaScript, но и от того, какие cookies выставлены, с какими флагами, когда они истекают и при каких условиях отправляются обратно на сервер.
Что полезно понимать QA:
- →cookie может быть session-based или persistent
- →cookie может быть недоступна JavaScript, если выставлен HttpOnly
- →cookie может отправляться только по HTTPS, если выставлен Secure
- →политика SameSite может сильно влиять на login, redirect, embedded flows и интеграции
- →сервер может ожидать cookie автоматически, даже если UI нигде явно этого не показывает
Очень частая ловушка - думать, что если пользователь "вышел", то система точно разлогинена. На практике logout может визуально сработать, но cookie может не очиститься как надо, или клиент может оказаться в странном промежуточном состоянии.
sessionStorage: состояние одной вкладки
sessionStorage часто недооценивают. Он полезен именно тем, что живёт в рамках конкретной вкладки. Это значит, что одно и то же приложение в двух вкладках может иметь разное sessionStorage-состояние.
Для QA это важно в сценариях вроде:
- →многошаговые формы
- →черновики
- →временные фильтры
- →состояние мастера или onboarding flow
- →данные, которые не должны переживать закрытие вкладки
Если приложение хранит важное состояние в sessionStorage, полезно проверять:
- →что происходит после refresh
- →что происходит при открытии новой вкладки
- →переносится ли состояние туда, куда не должно
- →не ломается ли сценарий после back/forward navigation
- →корректно ли очищается временное состояние после завершения или отмены сценария
Очень частый баг здесь выглядит так: в одной вкладке пользователь уже в новом состоянии, а в другой всё ещё живёт старый промежуточный клиентский контекст.
localStorage: удобно, но коварно
localStorage удобен тем, что переживает reload и новые сессии браузера. Именно поэтому команды любят складывать туда "что-нибудь полезное". Но как раз из-за этой долговечности он часто становится источником хитрых багов.
Типичные проблемы:
- →старое состояние влияет на новый сценарий
- →пользователь получает устаревшие данные после релиза
- →logout визуально сработал, но чувствительные данные остались в storage
- →в новом аккаунте подхватываются артефакты от предыдущего пользователя
- →локальный feature flag или кэш ломает воспроизводимость бага
- →поведение на "чистой" машине и у реального пользователя отличается именно из-за localStorage
Для QA это означает простую вещь: localStorage нужно проверять не только как "техническую деталь", а как часть состояния продукта.
Что чаще всего ломается на практике
Самые типичные storage-баги обычно такие:
- →после logout в браузере остаются токены или user data
- →новая вкладка получает не то состояние, которое ожидалось
- →refresh неожиданно сохраняет то, что должно было исчезнуть
- →после логина под другим пользователем остаются данные предыдущего
- →приложение зависит от localStorage, но плохо переживает очистку storage
- →cookies не выставляются из-за Secure, SameSite, CORS или окружения
- →sessionStorage ведёт себя по-разному в popup, redirect или при работе с opener
- →UI и backend расходятся в понимании, активна ли сессия
Для пользователя это часто выглядит как "странный нестабильный веб". Для QA это вполне конкретный класс дефектов.
Что важно проверять QA
Если в продукте важна авторизация, пользовательское состояние или сложная навигация, полезно регулярно проверять такие вещи:
- →что остаётся в cookies и storage после login
- →что очищается после logout
- →что происходит после refresh
- →как ведут себя две вкладки одного и того же сценария
- →что увидит другой пользователь в том же браузере после предыдущего
- →есть ли чувствительные данные в localStorage, если им там не место
- →не зависит ли функциональность от "грязного" storage сильнее, чем должна
- →одинаково ли приложение ведёт себя на чистой сессии и после долгой истории использования
Это особенно полезно при тестировании логина, корзины, фильтров, onboarding, checkout, feature flags и offline-like поведения.
Практический пример
Представь сценарий logout.
Пользователь нажимает "Выйти", его перекидывает на страницу входа, и внешне всё выглядит нормально. Но QA стоит проверить больше:
- →удалена ли сессионная cookie
- →не остался ли access token в localStorage
- →не хранится ли user profile или role в client storage
- →что произойдёт после refresh
- →что будет, если нажать Back
- →можно ли открыть старую вкладку и всё ещё увидеть приватные данные
- →если войти под другим пользователем, не подтянутся ли данные предыдущего
Очень часто именно здесь и видно, насколько корректно продукт работает с клиентским состоянием.
Что должен вынести QA из этой темы
- →Cookies, sessionStorage и localStorage решают разные задачи и ломают разные классы сценариев.
- →Cookies часто связаны с серверной сессией и auth flow.
- →sessionStorage живёт в рамках вкладки и полезен для временного состояния.
- →localStorage удобен для долговременного состояния, но легко создаёт скрытые баги и утечки клиентского контекста.
- →Хороший QA проверяет не только UI, но и то, какое состояние реально осталось в браузере после сценария.
Что ещё почитать
- →Внутри базы: DevTools для тестировщика
- →Внутри базы: Аутентификация и авторизация
- →Внешний материал: MDN Set-Cookie
- →Внешний материал: MDN localStorage
- →Внешний материал: MDN sessionStorage
- →Внешний материал: MDN Using the Web Storage API