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

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

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 — сохранила в сборник историй!