Одной из основных частей работы QA является локализация дефектов.
Техники тест дизайна помогают нам выбрать сценарии тестирования делая его эффективнее. Но что такое локализация дефекта и что может с этим помочь?
Начнем с начала.
Локализация это поиск ответа на вопрос «в какой момент и где что‑то пошло не так?». Без правильной локализации дефект может передаваться как между фронтендом и бэкендом, так и между командами разработки. При этом теряется время на исправление и, возможно, контекст.
Процесс локализации дефекта можно сравнить с прохождением лабиринта, а запросы и логи приложения с клубком нитей. Но намного удобнее было бы бродить по лабиринту имея в руках, не только клубок нитей, но и карту лабиринта, хотя бы примерную. Роль такой карты может сыграть архитектура приложения.
Что же такое архитектура приложения?
Архитектура это то, как компоненты системы взаимодействуют между собой. Если вернутся к примеру с лабиринтом: то, как один сегмент лабиринта переходит в другой и по каким коридорам.
Для себя я выделяю 2 архитектуры: клиент-серверная и архитектура бэкенда.
Клиент-серверная архитектура говорит нам о том, как взаимодействуют друг с другом клиент и сервер.
Архитектура бэкенда определяет то, как бэкенд будет обрабатывать запросы клиента.
Немного о клиент-серверной архитектуре.
Часто выделяют 2 типа клиент серверной архитектуры:
тонкий клиент
толстый клиент
От типа зависит то, как много информации клиент хранит и обрабатывает сам. Есть и другие подходы к реализации архитектуры, но мне бы хотелось говорить только о том, с чем я знакома на собственном опыте.
Большая часть мобильных и веб приложений это тонкие клиенты. Вся информация хранится на сервере и клиент-приложение запрашивает данные или просит их обработать. При регистрации, авторизации, подписки на уведомления - клиент отправляет запрос на сервер. При этом весь процесс обработки на сервере скрыт от клиента. В ответ на запрос клиент получит собранную и обработанную информацию из базы данных или сообщение о том, что запрос успешно выполнен.
Приложение толстого клиента большую часть обработки клиент делает сам: добавляет данные в БД, составляет отчеты, рассчитывает суммы и формирует документы. Часто они устанавливаются локально, но не всегда. Примеры толстого клиента: оффлайн игры, autoCad и некоторые варианты 1С.
Немного об архитектуре бекенда
Два самых распространенных подхода к архитектуре бекенда:
монолит
микросервисы
Когда обработка почти всего происходит в почти одном месте - это монолит.
Если для обработки запроса отправляются запросы в другие сервисы нашей системы - скорее всего перед вами микросервисная архитектура.
В первом случае определить из-за чего именно возник дефект может быть сложно, так как кодовая база у разных команд и разных сервисов обычно одна, а это значит изменения могут возникнуть там, где этого не ожидаешь.
Во втором случае сервисы поделены и у каждого своя кодовая база, а значит изменения в одном сервисе мало влияют на другие.
Структура организации и зоны ответственности.
Название страшное, но за ним скрывается ответ на вопрос: кто, что делает и за что отвечает. Представим у нас большая компания: банк, маркетплейс, доставка еды или еще что-то. Чем больше наше приложение, тем больше людей над ним работает. А чем больше людей, тем чаще их делят на команды, а каждой команде дают свою зону для разработки.
Например, одна команда может заниматься акциями в нашем приложении, другая будет отвечать за оплаты. Если у нашего приложения есть разные услуги, то команды могут отвечать за отдельные услуги, например за ЭДО, бухгалтерию или госзакупки.
Знать всё и всех не обязательно, но если есть документация с тем, какая команда чем занимается - ее лучше иметь в закладках.
Как это использовать
Вооружившись картой и имея в руках клубок начнем исследовать наш лабиринт в поисках причины дефекта. Для этого представим несколько ситуаций.
Ситуация первая.
Закроем глаза и представим, что мы тестируем сайт с занятиями в разговорном клубе.
Мы открываем расписание и читаем про каждое занятие, но в какой-то момент наш глаз цепляется за опечатку.
Что мы делаем, чтобы понять на какой стороне она появилась? Начнем наше путешествие!
Открываем devTools, обновляем страницу и смотрим запросы и ответы на них. Так как у нас тонкий клиент, то в одном из ответов мы находим нашу опечатку — она пришла с бека.
Мы открываем логи и ищем обработку по запросу или ответу от бека — это наша ниточка из волшебного клубка. Искать логи можно по любой информации из запроса и ответа, но лучше использовать уникальные значения: xiid запроса, ID из запроса, номер телефона и тому подобное.
Находим запись и проверяем: информацию о занятиях мы получаем из БД или от другого сервиса?
Если информацию получили из БД, то можно передать вопрос в техподдержку для исправления опечатки в БД.
Если информацию получили из другого сервиса, то дефект можно передать им.
Поздравляю, мы прошли первый лабиринт: локализовали дефект и передали его на исправление.
Ситуация вторая
Снова закроем глаза и представим, что тестируем форму регистрации.
Мы вводим почту, какие-то данные и придуманный пароль. Нажимаем на кнопку регистрации и неожиданно получаем ошибку.
Берем нашу клубок и идем исследовать: открываем горячо любимую вкладку network в devTools и смотрим, что пошло не так: повторяем все действия и проверяем ответ от сервера.
В ответ на запрос нам пришел код 400 с пустым телом ответа. Можно бежать заводить дефект на фронтенд? Но разве мы знаем, что именно пошло не так и что нужно исправить? Часто 400 ошибка приходит, когда есть отличие между тем, что пришло от клиента и то, что ожидал сервер. Причин у этого может быть много, некоторые из них:
неактуальная документация в задаче,
внесение изменений без документирования,
опечатки.
Проверим запрос клиента.
Если у нас есть документация: написанная вручную или сгенерированная в swagger или openApi, то используем ее и проверим, что:
передаем все обязательные параметры
значения в параметрах такие как ожидаем: для int параметров передаем число
Как еще можно проверить запрос?
Даже если нет документации, то можно проверить следующее:
соответствует синтаксис: если запрос передается в формате JSON, то он должен следовать синтаксису JSON
опечатки в названиях параметров: mony вместо money, doby вместо body
кириллица среди латиницы: например namе написано с русской “е”, вместо “e”
Осмотрев запрос мы не видим в нем ошибки, а это значит, что, чтобы найти ответ нам нужно продолжить путешествие по лабиринту.
Берем нашукарту и «спускаемся» в логи
Проверяем логи
Здесь нас может ждать 2 ситуации:
мы увидим явную ошибку при обработке нашего запроса
мы увидим логи без ошибки, но с отправкой запросов
Во втором случае нам придется продолжить хождение по микро сервисному лабиринту и искать место, где обрабатывался наш запрос.
Найдя лог с ошибкой мы узнаем, что именно пошло не так, а значит закончим нашу локализацию и наше путешествие. Останется только собрать артефакты и приложить их к задаче:
запрос к беку
лог с ошибкой
вывод о том, что и где нужно исправить
Итог
Иногда вы будете упираться в стены: лог, за которым вы следовали не вывел вас к ошибке или сильнее запутал. В такой ситуации я, обычно, делаю пару «шагов назад» или начинаю с самого начала.
Путешествия по лабиринтам могут быть долгими, тяжелыми и таить много опасностей: обработки некоторых запросов могут быть запутанными и отправлять запросы в несколько разных сервисов. И иногда имеет смысл упростить себе задачу и обратиться к архитекторам лабиринта — разработчикам.
