DB IDE

26 апреля 2002 года на общем собрании Кольчугинского филиала компании "Real System for Corp." (RSC) было объявлено о самостоятельном направлении в развитии продукта "Table Magic", который начал своё существование ещё на базе отдела АСУП при заводе "Электрокабель" (ЭКЗ), а затем в 2000 году вместе с "родителем" исходники перекочевали в маленькую компанию разработчиков. В мае 2002 года на московской конференции продуктом, состоящим из "умного грида данных" и редактора хранимых подпрограмм, заинтересовался австрийский бизнесмен, поэтому в июле команду укрепили вторым программистом. Поскольку на тот момент мне приходилось тестировать смежный продукт этой же компании, то мои знания "Table Magic" сначала помогли "подчистить" презентацию и впоследствии привели на место тестировщика. Европейский аналитик порекомендовал множество идей, в том числе переименование в "DatabaseVoyager" (DV) и формирование американской компании "Conquest Software Solutions" (ConquestSS). К началу моей деятельности в августе 2003 года навигатор объектов насчитывал около полутора десятка типов объектов, которые и надо было мне тестировать. Каждый из объектов, добавляемый в список поддерживаемых, имел свой мастер по обработке и некоторые функции в отдельных модулях DV. Постоянно прибавляясь к 2017 году их накопилось более шести десятков. И только спустя пятнадцать лет у владельца продукта единожды возник вопрос о том, как проводится тестирование к тому времени уже давно переименованного продукта SQLDetective (SD).

Как вы понимаете, изначально никакого процесса тестирования в RSC не существовало, поэтому мне пришлось искать варианты самостоятельно. К тому же, руководитель проекта ставил программистов на несколько ступеней выше меня и не позволял вытягивать знания из них, а вместо этого отсылал все мои вопросы к самостоятельному изучению документации базы данных Oracle, собственно говоря для которой и создавался интерфейсный продукт, конкурирующий с TOAD от Quest Software. Итак, знания о новом объекте существенно отличались у программиста и тестировщика, а все задачи на разработку и тестирование были весьма краткие: "добавить поддержку объекта NN". В понимании программиста это зачастую ограничивалось созданием мастера объекта, поскольку он опирался лишь на статьи по его созданию (CREATE), редактированию (ALTER) и удалению (DROP). Но взгляд тестировщика на термин "поддержка объекта в продукте" более широк и рассматривает все операции (GRANT, REVOKE, ANALYZE, PURGE, ...) над объектом, доступные в базе данных. Эти мои обширные знания вынуждали формировать лишь на этапе тестирования, а не в процессе планирования, множество заданий на доработку.

Итак, первым шагом в тестировании нового поддерживаемого объекта было изучение документации. На это в моём плане по тестированию отводился целый день, поскольку в SD поддерживалось несколько версий базы. Сначала для последней версии базы распечатывались статьи по созданию (CREATE), редактированию (ALTER) и удалению (DROP) объекта. Затем тексты сравнивались с каждой предыдущей версией и в распечатке делались пометки о новшествах и утилизациях опций. Документация по объектам Oracle довольно хорошо структурирована, поэтому легко вычленялись необходимые статьи, в которых достаточно было сравнить лишь схемы DDL. Со временем в помощь разработчикам и тестировщикам в SD появился модуль "Oracle Documentation Browser", в котором можно было проиндексировать сразу все пять (на тот момент - 7.3, 8.0, 8.1, 9.0, 9.2, а позже к ним добавлялись 10.1, 10.2, 11.1, 11.2, 12) версий базы. Поиск в этом модуле позволил расширять тестирование статьями про иную (GRANT, REVOKE, ANALYZE, PURGE, ...) обработку объектов и связи, зависимости с другими объектами (точки восстановления с архивами, логи м/в и группы м/в, таблицы и их индексы, триггеры, констрейнты). Но некоторые (POLICY, MV GROUP, RESOURCE PLAN, ...) объекты БД Oracle регулируются не самостоятельными командами, а системными (DBMS_RLS, DBMS_REFRESH, DBMS_RESOURCE_MANAGER, ...) пакетами. Для их тестирования достаточно одной статьи, в которой пакетными процедурами и функциями описаны все действия над объектом, что немного упрощало дело. К концу первого дня у меня получался распечатанный план тестирования в разрезе версий БД и по операциям над объектом, по объёму которых можно было определить необходимое время на все последующие проверки. Так, на "большие" объекты (таблицы, шедулеры) минимально требовалось от пяти дней, а на самые "маленькие" (последовательности, операторы) - до двух дней.
Второй шаг - основное тестирование функциональности - проверяет корректность создания, редактирования и удаления объекта средствами нового интерфейса. Все эти операции в минимальном объёме выполняются на каждой из поддерживаемых версий БД. Следующим проходом по версиям базы тестируются различия схем DDL. И самое сложное, оставленное на закуску, заключается в детальной проверке всех опций DDL, которые в большинстве случаев достаточно посмотреть на последней версии базы.
На третьем шаге тестирования поддержки нового объекта в SD проверяется возможность выдачи и отъёма привилегий на объект через мастер привилегий, если таковые предусмотрены документацией Oracle. Здесь же рассматривается принадлежность объекта юзерской схеме или его системное положение. Не стоит забывать и про версионность базы данных.
Четвёртый шаг рассматривает взаимосвязи объектов через их мастера и панели выгрузки DDL. Например, мастер триггера вызывается из мастера таблицы, а индексный кластер можно создать в базе только после создания индекса. Тестирование SD расширяется модулями Schema Extractor, Compare DB и другими, где как-то фигурирует DDL нового объекта. Очень серьёзно здесь стоит приглядываться к различиям в версиях БД.

Заключительным пятым шагом проверяются всевозможные операции над новым объектом в различных утилитах SD. Например, релокацией партиций занимается "Storage Manager", перекомпиляция хранимой подпрограммы автоматически происходит при её открытии в "Stored Program Editor", для анализа вьювера существуют самостоятельные интерфейсы в рамках одного объекта или целой схемы. Как уже ранее говорилось, именно этот шаг даёт максимальный прирост задач программисту на доработку.

Тесты доступности, удобства, производительности и безопасности лучше проводить не самостоятельным шагом, а в рамках каждого из описанных. Набив руку на первом десятке объектов, у меня сформировалось устойчивое понимание, что только комплексное тестирование может сократить время на проверки, предусмотренные шагами со второго по пятый. К сожалению, владелец продукта никогда не жаловал процесс тестирования, поэтому ни при waterfall, ни при agile не был приверженцем декомпозиции задач и детального планирования, даже совмещая роль скрам-мастера. Менеджер продукта и первый программист откосили в своё время от армии, поэтому и не стремились к порядку, не умеют и до сих пор чётко следовать правилам и сдерживать данные обещания, как это принято у честных бизнесменов.  Очевидно поэтому вопрос РМ-а о вышеописанном стал чисто риторическим с его стороны, а ответ оформился в статью только спустя ровно семнадцать лет после оформления моего первого бага по SD, но уже не для команды ConquestSS, а для вас - простых тестировщиков.