В обязанности 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 ПО, невозможность инсталляции ПО, некорректная конфигурация систем и тд. Что делать в таком случае?

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

  1. Установить точные шаги воспроизведения (воспроизвести повторно)

  2. Прояснить/вспомнить архитектуру системы

  3. Посмотреть документацию по данному функционалу (если необходимо!) Да, при локализации таких проблем документация может быть бесполезной, но в некоторых случаях, тот же 500 код можно частично локализовать, посмотрев документацию. Например, посмотреть какой метод вызывается после наших действий.

  4. Собрать логи, скриншоты, посмотреть конфигурацию, в зависимости от ситуации

  5. Провести возможный анализ

  6. Написать разработчику/аналитику/сис. админу/ РП с информацией, которую удалось собрать

  7. Завести дефект, или инициировать процесс, направленный на исправление причины ошибки

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

Рассмотрим несколько примеров.

Пример 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 [...]
    at org.hsqldb.jdbc.Util.throwError(Unknown Source)
    at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)...

По коду java.sql.SQLException можно сделать вывод, что ошибка произошла при записи данных в таблицу.

6 шаг:

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

7 шаг:

Заводим дефект "Система_1. POST SysReview - ошибка записи данных в таблицу"

Так же возможные причины, из-за которых вы не можете самостоятельно локализовать проблему

  • Некоторые требования обсуждались устно или в переписке - в документации не закрепили;

  • Некачественная документация (противоречия, неоднозначность);

  • Кейс не продуман аналитикой;

  • Вынос доработок без предупреждения команды тестирования;

  • У тестирования и разработки разные версии требований.

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

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