Локализация дефектов на интеграционном уровне
В обязанности QA инженера входит локализация дефекта — процесс, направленный на анализ проблемы, с целью максимально‑возможной детализации причины ее возникновения. Чем больше информации о проблеме — тем быстрее ее решит команда. Ни в коем случае не стоит перекладывать эту работу на разработчика или аналитика. Обращение к команде идет только после анализа проблемы со стороны тестировщика.
Ситуация — Тестируя функционал, вы столкнулись со странным/ неправильным, с вашей точки зрения, поведением.
Что делать?
Завести дефект — Нет;
Написать разработчику — Нет;
Написать аналитику — Нет;
Написать другому тестировщику (Приучайте себя к самостоятельности! У Коллеги свои задачи!) — Нет;
Установить точные шаги воспроизведения (воспроизвести еще раз) — Да;
Прояснить/вспомнить архитектуру системы — Да;
Посмотреть документацию по данному функционалу — Да.
Первым шагом в локализации является сбор информации по функционалу, в котором обнаружена проблема/ошибка, а так же четкое понимание архитектуры системы. Отвечаем на вопрос «Что я знаю по этому функционалу?»
Дальше задаем вопрос «Поведение соответствует документации?». Скорее всего информации для ответа хватать не будет. Как ответить на этот вопрос?
Раздобыть недостающую информацию: сбор логов, настроек окружения, условий воспроизведения и т.д.
Провести анализ. Сопоставить информацию ожидаемую (документация), с информацией фактической (логи, настройки и тд).
Сделать вывод. Завести баг/таск и др.
В случае, когда архитектура сложная, интеграционная, необходимо проверять каждый уровень последовательно.
Если по какому‑то из пунктов находится расхождение — заводим баг. Теперь мы уже точно знаем в каком месте ошибка и можем конкретизировать проблему и поставить задачу правильно и на нужную систему.
Пример 1 |
Ситуация: После перехода на форму вы не увидели кнопку, которая по вашему мнению должна отображаться. 1 шаг: Восстанавливаем шаги воспроизведения — Открыли приложение — Авторизовались первый раз — Перешли на Главную страницу 2 шаг: Идем искать архитектурную схему проекта. Уяснили для себя, что в тестируемом продукте следующая схема «FE → BE → Система_1». 3 шаг: Открываем документацию по текущему функционалу. Смотрим условия отображения кнопки на FE. Узнали, что «кнопка отображается, если значение параметра «param» в ответе метода GET Example = 1, тип данных параметра — int, параметр обязательный. При значении 2 — кнопка не отображается.» Т.к отображение зависит от значения параметра, необходимо также посмотреть требования на BE метод GET Example. Узнали, что »… значение «param» передается из Системы_1 в методе GET SysExample параметре «sparam»…». Смотрим документацию Системы_1 метод GET SysExample. Узнали, что «sparam = 1, если вход в приложение первый, sparam = 2, если вход в приложение повторный. Значение параметра по умолчанию 1, в Системе_1 параметр изменяется на значение 2, после первой деавторизации пользователя». Итак, мы узнали изначально важное условие отображения кнопки: вошли первый раз — отображается, вошли повторно — не отображается. Выяснив это, уже можно точно быть уверенным, должна быть кнопка или нет. Если вы действительно вошли в приложение повторно, то дальнейший анализ не понадобится — дефекта нет. Если же ваши действия в приложении корректны и кнопка действительно должна отображаться, переходим к следующему шагу. 4 шаг: Т.к условие отображения кнопки зависит от значений параметра в методе, нужно обязательно посмотреть в логи. Находим логи вызовов GET Example, GET SysExample после которых кнопка не отобразилась. 5 шаг: Проводим анализ. 1 случай: В логе вызова GET Example нашли параметр «param», значение параметра 1. Значение передано с типом int, структура ответа соответствует описанию. Условия для отображения кнопки выполняются, но кнопка не отображается — дефект фронта. Данного уровня локализации достаточно. 2 случай: В логе вызова GET Example нашли параметр «param», значение параметра »1». Значение передано с типом string, структура ответа соответствуют описанию. Условия для отображения не выполняются, т.к нарушен тип возвращаемого параметра — дефект BE. Заводим баг «BE — GET Example. Тип возвращаемого параметра «param» sring вместо int». Разработчик метода уже точно будет знать в каком месте проблема и быстро поправит. 3 случай: В логе вызова GET Example нашли параметр «param», значение — null. В логе вызова GET SysExample параметр «sparam» так же null. Условия для отображения не выполняются, т.к не передано нужное значение — дефект Системы_1. Заводим дефект «Система_1 — GET SysExample. Не передается значение в параметре sparam». 4 случай: В логе вызова GET Example нашли параметр «param», значение параметра 2. Значение передано с типом int, структура ответа соответствует описанию. Условия для отображения (а точнее скрытия) кнопки выполняются, кнопка так же не отображается. Но не спешим с выводами. Ранее мы выяснили, что кнопка точно должна отображаться, т.к вход в приложение первый. Получается что на Системе_1 некорректное дефолтное значение параметра sparam. Заводим баг «Система_1 — некорректное значение по умолчанию параметра sparam» |
Как мы видим из примера, у одной ситуации может быть несколько исходов. Если бы мы завели дефект сразу, могли бы ошибиться с системой, и еще хуже — дефекта вообще могло не быть, что влечет за собой потраченное время разработчика (и не только).
Не всегда локализация опирается только на документацию. Бывают проблемы, не связные напрямую с ошибками в логике систем. Пример таких проблем: 500 ошибка от сервера, сетевые ошибки, недоступность систем, окончание сроков доступов между системами, crash ПО, невозможность инсталляции ПО, некорректная конфигурация систем и тд. Что делать в таком случае?
Действия не сильно отличаются от шагов выше, но есть несколько особенностей, связанные с тем, что каждая из проблем может решаться по-разному.
Установить точные шаги воспроизведения (воспроизвести повторно)
Прояснить/вспомнить архитектуру системы
Посмотреть документацию по данному функционалу (если необходимо!) Да, при локализации таких проблем документация может быть бесполезной, но в некоторых случаях, тот же 500 код можно частично локализовать, посмотрев документацию. Например, посмотреть какой метод вызывается после наших действий.
Собрать логи, скриншоты, посмотреть конфигурацию, в зависимости от ситуации
Провести возможный анализ
Написать разработчику/аналитику/сис. админу/ РП с информацией, которую удалось собрать
Завести дефект, или инициировать процесс, направленный на исправление причины ошибки
После проведения анализа скорее всего будет понятно какая система и метод не работают некорректно. С этой информацией уже можно будет понять к кому идти. Например, с крашем ситуация может быть разная, и ее без разработчика фронта скорее всего не выяснить, краш может быть как из-за отсутствующего параметра, так и по причине неуспешной отрисовки форм на определенном устройстве (и др. причины). Разработчик сможет сказать более конкретно о возможных причинах краша, затем можно заводить дефект с корректным описанием. Если проект не предполагает возможности общения с разработчиками, придется заводить дефект с поверхностным описанием и с приложенными логами (обязательно). После анализа дефекта разработчиком, может оказаться, что причина ошибки заключается в другом, тогда придется переназначить дефект на другую систему и другого исполнителя.
Рассмотрим несколько примеров.
Пример 2 |
Ситуация: На форме отображается ошибка «Недостаточно прав». 1 шаг: Восстанавливаем действия, выполненные до ошибки. 1. Открыли приложение 2. Авторизовались 3. Перешли на вкладку со списком объектов 2 шаг: Идем искать архитектурную схему проекта. Уяснили для себя, что в тестируемом продукте следующая схема «FE → BE → Система_1». 3 шаг: Смотрим документацию на FE и BE.»При переходе на вкладку Объекты вызывается метод GET Objects для отображения списка всех объектов. Значения параметров берутся из ответа метода GET SysObjects (Система_1)» Смотрим документацию на Систему_1 метод GET SysObjects. «Значения для списка объектов заполняются из БД таблицы all_objects.» 4 шаг: Собираем логи метода GET Objects и GET SysObjects. Обнаруживаем, что вызова GET SysObjects вообще не было. 5 шаг: Анализируем лог по вызову GET Objects. Смотрим в первую очередь на ответ. В ответе ошибка «Недостаточно прав», http код 403. Согласно http протоколу, 403 код означает отсутствие доступа. В документации нет ни слова о том, что список объектов доступен только определенным пользователям/ролям. Соответственно, исключаем вариант блокировки функционала по бизнес логике. Также может быть ситуация когда у систем нет доступов друг к другу (возможно в логе будет более развернутый текст ошибки. Например, «Доступ между IP_х и IP_y закрыт»). 6 шаг: Пишем тому, кто отвечает за инфраструктуру стендов (разработчику/РП/сис. админу). Сообщаем, что отсутствует доступ между BE и Системой_1. 7 шаг: Выполняем рекомендации ответственного на предыдущем шаге. Например, необходимо завести заявку в HD на восстановления доступа между системами. |
Аналогичным образом будет производиться локализация проблема, где по http статусу можно понять проблему. Например, 500 — ошибка сервера, данная ошибка будет на той системе (самой нижней относительно FE по архитектурной цепочке), в логах которой она обнаружена. Если в логах BE есть 500 и в логах Системы_1 тоже есть 500, значит ошибка на Системе_1. (Если статус вам не известен, не спешите идти за помощью, погуглите — повод для развития).
Рассмотрим еще один пример, когда текст ошибки ни о чем нам не говорит.
Пример 3 |
Ситуация: Написали отзыв и нажимаем кнопку «Оставить отзыв». На форме отображается необработанная ошибка, по которой невозможно сразу определить в чем проблема. Например, «Violation of unique constraint MY_ENTITY_1: duplicate value (s) for column (s) MY_COLUMN in statement […]» 1 шаг: Восстанавливаем действия, выполненные до ошибки. 1. Открыли приложение 2. Авторизовались 3. Перешли на Главную страницу 4. Написали отзыв 5. Нажали кнопку «Оставить отзыв» 2 шаг: Идем искать архитектурную схему проекта. Выяснили, что в тестируемом продукте следующая схема «FE → BE → Система_1». 3 шаг: Смотрим документацию на FE и BE.»При нажатии кнопки «Оставить отзыв» вызывается метод BE POST Review. BE вызывает метод POST SysReview (Система_1) значения параметров проксируются из запроса Review.» Смотрим документацию на Систему_1 метод POST SysReview. «Метод POST SysReview создает в таблице [Dev].[review] строку, заполняя поля значениями параметров запроса по маппингу…» 4 шаг: Не всегда по тексту ошибки можно понять — это ошибка фронта или сервера. Исключить фронт в этом случае можно, посмотрев логи сервера. Если в логах сервера есть ошибка, отображаемая на фронте, то ошибка точно не на FE. Собираем логи метода Review и SysReview. 5 шаг: Анализируем логи. Ошибка проксируется из ответа метода SysReview. В зависимости от детализации логов, в логах Системы_1 может быть указан SQL запрос в БД и его результат. Так же в логах скорее всего будет полный текст ошибки, например: Caused by: java.sql.SQLException: Violation of unique constraint MY_ENTITY_1: duplicate value (s) for column (s) MY_COLUMN in statement […] По коду java.sql.SQLException можно сделать вывод, что ошибка произошла при записи данных в таблицу. 6 шаг: В данном случае писать разработчику не обязательно, т.к. вам удалось выяснить в каком месте происходит ошибка. Но если бы по логам невозможно понять причину, тогда необходимо писать разработчику, описать кейс и скинуть лог. Разработчик сможет по ошибке сказать в чем именно дело. 7 шаг: Заводим дефект »Система_1. POST SysReview — ошибка записи данных в таблицу» |
Так же возможные причины, из-за которых вы не можете самостоятельно локализовать проблему
Некоторые требования обсуждались устно или в переписке — в документации не закрепили;
Некачественная документация (противоречия, неоднозначность);
Кейс не продуман аналитикой;
Вынос доработок без предупреждения команды тестирования;
У тестирования и разработки разные версии требований.
В случае, когда собранная только вашими силами информация не отвечает на все ваши вопросы — обращаемся за помощь к аналитикам, разработчикам, дизайнерам, в зависимости от ситуации.
С каждой локализацией дефекта, с каждой проверенной задачей увеличивается опыт и профессионализм специалиста по тестированию. По достижению определенного уровня навыка вы сможете заранее предугадывать и определять причины ошибок, скорость локализации дефекта возрастает, как и умение чтения и анализа логов.
