Одной из основных частей работы QA является локализация дефектов. 

Техники тест дизайна помогают нам выбрать сценарии тестирования делая его эффективнее. Но что такое локализация дефекта и что может с этим помочь? 

Начнем с начала. 

Локализация это поиск ответа на вопрос «в какой момент и где что‑то пошло не так?». Без правильной локализации дефект может передаваться как между фронтендом и бэкендом, так и между командами разработки. При этом теряется время на исправление и, возможно, контекст. 

Процесс локализации дефекта можно сравнить с прохождением лабиринта, а запросы и логи приложения с клубком нитей. Но намного удобнее было бы бродить по лабиринту имея в руках, не только клубок нитей, но и карту лабиринта, хотя бы примерную. Роль такой карты может сыграть архитектура приложения. 

Что же такое архитектура приложения? 

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

Для себя я выделяю 2 архитектуры: клиент-серверная и архитектура бэкенда.

• Клиент-серверная архитектура говорит нам о том, как взаимодействуют друг с другом клиент и сервер.

• Архитектура бэкенда определяет то, как бэкенд будет обрабатывать запросы клиента.

Немного о клиент-серверной архитектуре.

Часто выделяют 2 типа клиент серверной архитектуры: 

• тонкий клиент

• толстый клиент

От типа зависит то, как много информации клиент хранит и обрабатывает сам. Есть и другие подходы к реализации архитектуры, но мне бы хотелось говорить только о том, с чем я знакома на собственном опыте. 

Большая часть мобильных и веб приложений это тонкие клиенты. Вся информация хранится на сервере и клиент-приложение запрашивает данные или просит их обработать. При регистрации, авторизации, подписки на уведомления - клиент отправляет запрос на сервер. При этом весь процесс обработки на сервере скрыт от клиента. В ответ на запрос клиент получит собранную и обработанную информацию из базы данных или сообщение о том, что запрос успешно выполнен. 

Приложение толстого клиента большую часть обработки клиент делает сам: добавляет данные в БД, составляет отчеты, рассчитывает суммы и формирует документы. Часто они устанавливаются локально, но не всегда. Примеры толстого клиента: оффлайн игры, autoCad и некоторые варианты 1С.

Немного об архитектуре бекенда

Два самых распространенных подхода к архитектуре бекенда: 

• монолит

• микросервисы

Когда обработка почти всего происходит в почти одном месте - это монолит. 

Если для обработки запроса отправляются запросы в другие сервисы нашей системы - скорее всего перед вами микросервисная архитектура. 

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

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

Структура организации и зоны ответственности.

Название страшное, но за ним скрывается ответ на вопрос: кто,  что делает и за что отвечает. Представим у нас большая компания: банк, маркетплейс, доставка еды или еще что-то. Чем больше наше приложение, тем больше людей над ним работает. А чем больше людей, тем чаще их делят на команды, а каждой команде дают свою зону для разработки. 

Например, одна команда может заниматься акциями в нашем приложении, другая будет отвечать за оплаты. Если у нашего приложения есть разные услуги, то команды могут отвечать за отдельные услуги, например за ЭДО, бухгалтерию или госзакупки.

Знать всё и всех не обязательно, но если есть документация с тем, какая команда чем занимается - ее лучше иметь в закладках. 

Как это использовать

Вооружившись картой и имея в руках клубок начнем исследовать наш лабиринт в поисках причины дефекта. Для этого представим несколько ситуаций. 

Ситуация первая. 

Закроем глаза и представим, что мы тестируем сайт с занятиями в разговорном клубе. 

Мы открываем расписание и читаем про каждое занятие, но в какой-то момент наш глаз цепляется за опечатку. 

Что мы делаем, чтобы понять на какой стороне она появилась? Начнем наше путешествие! 

Открываем devTools, обновляем страницу и смотрим запросы и ответы на них. Так как у нас тонкий клиент, то в одном из ответов мы находим нашу опечатку — она пришла с бека.

Мы открываем логи и ищем обработку по запросу или ответу от бека — это наша ниточка из волшебного клубка. Искать логи можно по любой информации из запроса и ответа, но лучше использовать уникальные значения: xiid запроса, ID из запроса, номер телефона и тому подобное. 

Находим запись и проверяем: информацию о занятиях мы получаем из БД или от другого сервиса? 

Если информацию получили из БД, то можно передать вопрос в техподдержку для исправления опечатки в БД.  

Если информацию получили из другого сервиса, то дефект можно передать им. 

Поздравляю, мы прошли первый лабиринт: локализовали дефект и передали его на исправление. 

Ситуация вторая

Снова закроем глаза и представим, что тестируем форму регистрации. 

Мы вводим почту, какие-то данные и придуманный пароль. Нажимаем на кнопку регистрации и неожиданно получаем ошибку.

Берем нашу клубок и идем исследовать: открываем горячо любимую вкладку network в devTools и смотрим, что пошло не так: повторяем все действия и проверяем ответ от сервера.

В ответ на запрос нам пришел код 400 с пустым телом ответа. Можно бежать заводить дефект на фронтенд? Но разве мы знаем, что именно пошло не так и что нужно исправить? Часто 400 ошибка приходит, когда есть отличие между тем, что пришло от клиента и то, что ожидал сервер. Причин у этого может быть много, некоторые из них: 

• неактуальная документация в задаче,

• внесение изменений без документирования,

• опечатки. 

Проверим запрос клиента. 

Если у нас есть документация: написанная вручную или сгенерированная в swagger или openApi, то используем ее и проверим, что: 

• передаем все обязательные параметры

• значения в параметрах такие как ожидаем: для int параметров передаем число

Как еще можно проверить запрос?

Даже если нет документации, то можно проверить следующее: 

• соответствует синтаксис: если запрос передается в формате JSON, то он должен следовать синтаксису JSON

• опечатки в названиях параметров: mony вместо money, doby вместо body

• кириллица среди латиницы: например namе написано с русской “е”, вместо “e”

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

Берем нашукарту и «спускаемся» в логи

Проверяем логи

Здесь нас может ждать 2 ситуации: 

• мы увидим явную ошибку при обработке нашего запроса 

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

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

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

• запрос к беку

• лог с ошибкой

• вывод о том, что и где нужно исправить

Итог

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

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