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, а для вас - простых тестировщиков.
