«У меня в Postman все зеленое!» «В базе данные правильные, бэкенд ни при чем!»

Знакомо? 😅

Бывает, проверяешь БД - все идеально. Смотришь API - тоже все хорошо. А пользователь открывает приложение и видит совсем не то.

И начинается перепинывание мяча между фронтом, бэком и аналитикой. Это как испорченный телефон, только в IT. И задача QA - разобраться, на каком этапе данные исказились.

Кейс №1. Перепутанные координаты

Однажды в мобильном приложении обнаружили, что координаты отображаются неправильно. Начала разбираться и пошла по цепочке от пользователя к источнику данных: - БД мобильного приложения - широта и долгота перепутаны местами. - API - то же самое. - Сервер UI - координаты перепутаны. - БД сервера - аналогичная картина. - Смотрю логи - и нахожу источник: именно в таком виде данные приходят от интеграционной системы 🕵️‍♀️

Причина найдена. Но что делать с релизом?

Интеграционная система исправляла ошибки небыстро, а блокировать наш релиз не хотелось.

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

Временное решение, зато позволяло продолжить работу и корректно отображать координаты.

Когда интеграция исправила ошибку у себя, я завела еще одну задачу - убрать наше преобразование. Иначе временное решение могло бы остаться навсегда.

Кейс №2. Часовые пояса

Тоже интересная история.

Пользователь из UTC+3 создает запись. Пользователь из UTC+7 открывает ее и видит неправильное время: часовые пояса фактически складывались.

А система была связана с записью к врачу. Ошибка во времени - уже не просто некрасивое отображение, а вполне реальный риск пропустить прием 😱

В итоге договорились: в БД храним время в UTC+0, а на интерфейсе отображаем его с учетом часового пояса пользователя.

Как я локализую такие проблемы?

Иду от места, где обнаружена ошибка, к источнику данных: UI - что именно видит пользователь? БД - какие данные фактически хранятся? API - что возвращается клиенту? Логи - что система получила, обработала и передала дальше? Источник данных / интеграция - откуда пришли исходные значения?

В ход идут консоль разработчика, логи, БД, Postman или Swagger. Инструменты разные, задача одна - проследить путь данных и найти точку, где возникло расхождение.

И еще один важный момент - как донести результаты расследования.

В баг-репорте описываю не просто «не работает», а что именно проверила и какие данные получила на каждом этапе.

Когда разработчик говорит: «У меня все проходит», предлагаю повторить проверку вместе. И иногда выясняется, что он просто отступил от шагов в баг-репорте 😄

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

Тестирование - это не просто тыканье в экран. Это понимание всей цепочки движения данных: от источника до того, что в итоге видит пользователь.