вторник, 12 марта 2019 г.

Рисуем алгоритм сложной процедуры из ТЗ

На одном из проектов сделали довольно хитрую схему импорта данных из буферной таблицы. Для пользователя написан вариант использования и там все просто:
  1. Исходная система выгрузила данные в буферные таблицы
  2. В таблице increment добавила номер выгруженного инкремента — это будет флаг для нашей системы начинать забор данных.

См также:
Как составлять вариант использования

А на нашей стороне надо проверить таблицу инкрементов, попробовать выбрать этот инкремент, проверить, создавать новые карточки или обновлять старые, и другие подробности. Если смотреть через админку, триггер запускал три задачи:
  1. Подготовка данных
  2. Загрузка
  3. Очистка буфера
Каждая задача выполняет внутри кода выполняет несколько действий. А мне надо подготовить набор автотестов на каждый этап. Значит, надо разобраться, что там происходит. Я сначала долго тупила над «пользовательской» докой, пытаясь понять, как оно устроено внутри, а потом пошла к разработчику и попросила объяснить «для блондинок».

Это было продуктивное общение! Пока он объяснял, я рисовала на бумажке схему и задавала по ней вопросы. После нескольких вопросов раработчик признал, что я молодец, он про «вот это и то» не думал. Не зря рисовала!! Без рисунка я бы просто не удержала все в голове и не обнаружила проблемные зоны.

По итогам обсуждения я создала в конфлюенсе раздел «Техническая сторона сценариев, алгоритмы» и переписала туда все со своего листочка, полученный алгоритм и рисунок (в visio накидала):
  1. null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1.
  2. Удаляем неактуальные записи из буферных таблиц (физ лица и телефонов).
  3. Грузим физиков по условию in (id_increment, для которого import_status in 1).
  4. Грузим телефоны по условию in (import_status in 1).
  5. Создаем связи телефон - физик или телефон - юрик (тип контрагента смотрим по staging).
  6. Удаляем физиков из буфера, если не было ошибок на этапе загрузки.
  7. Удаляем те телефоны, у которых есть связи (проверяем наличие record_id физика/юрика в staging).
  8. 1 => 2. Выбираем все записи из таблицы INCREMENTS, где import_status = 1 и устанавливаем им значение import_status = 2.



Согласитесь, при наличии такой картинки тесты на каждый раздел писать намного проще! Я четко вижу, что задача подготовки выполняет три действия. Значит, тестируем каждое!

null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1. 
↓ 
Добавляем запись с пустым import_status — проверяем, что статус изменился на 1.
А если исходно был статус 1?
А если исходно другой статус? 
Так, дальше идет вызов oracle-процедуры. На схеме записано, как она называется — ищем по названию в коде, изучаем, что она делает. И готовим тестовые данные, как позитивные, так и негативные. 
Что у нас дальше? ... 

И так по каждому пункту. Потом, когда к проекту подключались другие люди и тоже не могли понять, как тестировать задачу, я давала ссылку на эту страничку в конфлюенсе. И все сразу вставало на свои места!

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

А вы зарисовываете ТЗ?

См также:
Пример карты сценариев для визуализации ТЗ
PowerPoint как инструмент тестировщика — визуализация тестов!
Примеры диаграммы State Transition Testing


PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

PPS — сохранила в сборник историй!

Комментариев нет:

Отправить комментарий