Рамка-невидимка

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

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

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

Загнутые проволоки на заднике картины

Картины по номерам у меня получились все в двойных экземплярах за счёт вкладышей на бумаге. Раскрасив и приклеив дубликаты на картон, для них были сделаны рамки из деревянных реек и бумажной бересты. А оригиналы, которые фабрично уже были наклеены на ДВП, жалко было прятать под рамки и тем самым скрывать часть картины. Была попытка сконструировать рамку из деревянных реек по лицевой и изнаночной стороне, а в качестве защиты и удержания плоской формы взять стекло. Не смотря на то, что стекла было достаточно и его нарезку получилось быстро освоить, но такая конструкция становилась больно тяжёлой из-за стекла и требовала немалого вложения средств: двойные слои реек, болтики с гайками. Так что, этот вариант остался только в теории, но всё-таки поделюсь своими наработками.

Варианты картин по номерам после раскраски и покрытия акриловым лаком стали скручиваться по вертикали. Поэтому пришлось их до создания рамок положить под пресс (несколько стопок книг). Для деревянной рамки со стеклом были отмерены пять реек ширины картины (3 для задника и 2 для лицевой стороны рамки) и две рейки её длины с добавками в две ширины реек, также куплены 17 болтиков с гайками. Стекло нарезано с неменее чем сантиметровыми полями по периметру картины.

Деревянные рейки и стекло

Собираем рамку.

1. На двух лицевых вертикальных рейках просверлите шесть пар отверстий на концах и по центру.

2. Две горизонтальные лицевые рейки отпилите ровно по ширине картины. В верхней просверлите два отверстия, а в нижней - три.

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

4. Просверлите отверстия в изнаночных рейках. 

5. Теперь соберите картину в рамку (на три изнаночные рейки положите картину, сверху стекло и лицевые рейки), вставьте болтики в отверстия и закрепите их шайбами.

17 отверстий в 7 рейках

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

Возвращаюсь к рамкам-невидимкам. Для второго варианта возьмите пять-шесть скрепок.

Обычная скрепка

Цветные скрепки

Гигантская скрепка

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

Разогните пять скрепок по центральному сгибу. 

Разогнутая скрепка

Меньшие сгибы сверните в кольцо. 

Кольцо на одном конце

На кольцо первой скрепки нанижите вторую, третью и четвёртую.

Схема нанизывания скрепок

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

Узел скрепок на заднике картины

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

Кольца на концах

Вставьте картину в сгибы второй и третьей скрепок, опустите картину нижним ребром в сгиб пятой скрепки. Теперь можно на гвоздик в стене подвесить картину за сгиб первой скрепки. А если у вас несколько картин, то их можно друг за дружку на одном гвозде в стене уместить, цепляя первую скрепку следующей картины за нижнюю скрепку предыдущей.

Четыре картины на двух гвоздях

Когда картинная галерея объявила сбор произведений о глухарях к дню города, у меня родились два сюжета. Один был воплощён кофеграфией, а другой ошибаной на листах формата А3. Эти листы были в гигантской раскраске с ДВП-обложкой, поэтому вопрос с рамкой решился быстро. На лист ДВП была положена картина, сверху покрыта стрейч-плёнкой, которая на заднике скреплена скотчем. Пятью декоративными гвоздиками картина скреплена с ДВП и штапиком, приложенным сзади и тем самым усилившим жёсткость прямоугольника, а в просветы между штапиком и ДВП протянут шнур для подвешивания картины.

Вот такие почти бесплатные рамки продемонстрируют всем ваши шедевры во всей своей красе.

Пророчества

Иностранная литература о профессии тестировщика называет то, о чём хочу сегодня поговорить, - ShiftLeft. А по-русски такой метод работы можно назвать - пророчество.
В обязанности тестировщика входит оценка существующего программного обеспечения на предмет его совершенствования. При внедрении новшеств именно тестировщик должен просчитать положительные и отрицательные моменты для пользователя при реализации функционала. Тем самым, тестировщик становится прорицателем ситуации, если не доносит проектировщикам неопровержимые доказательства своих гипотез. Но поскольку большинство предположений тестировщика строятся на интуиции, то зачастую к нам относятся негативно и считают, что это мы "накаркали провал".
Генеря идею аналитики рассчитывают только на успешный исход, но тут вмешиваются тестировщики и, задавая самые неудобные вопросы, превращают "красивую картинку" проектировщика в прах. Группы разработчиков, прислушивающиеся к комментариям тестировщика, вовремя реагирующие на упаднические линии в производстве, умудряются действительно прийти к положительному результату при внедрении своего ПО. Ну а самовлюблённые руководители проекта, надеющиеся на авось, упрямо продвигают лишь собственное мнение. И, конечно же, при полной неудаче в конце концов всю вину скидывают на нас же, тестировщиков, как на "мальчиков для битья".
Из этих комментариев стажёры IT-индустрии могут сложить картину своего будущего. Никаких результатов своего труда вы не сможете "пощупать", если станете тестировщиком ПО. Хотя, здесь есть лазейка. На обсуждениях новшеств постарайтесь записать все слова, сказанные каждым членом группы разработки. А после успешного и провального внедрения переслушайте (или перечитайте) записи. Этим вы сможете проанализировать собственную интуицию: предугадали ли вы исход спринта, задали ли вы конкретные вопросы уточнения мелочей производства, заставили ли вы аналитиков продумать все возможные ситуации пользователя.
О фразе "я же говорил(а)" в монологе одного из начинающих артистов оригинального жанра есть мнение довольно неприемлемое в профессии тестировщика. Комик агитирует уходить от тех, кто выслушал ваше мнение на этапе идеи, но не последовал вашим рецептам в процессе реализации. Он аргументирует такой совет тем, что если эти люди забили на вас в начале пути, то по прошествии события в точности по вашим пророчествам во фразе "я же говорил(а)" смысла уже никакого нет. Но здесь никак не могу с ним согласиться. После спринта проходит ретроспектива, где вся группа разработки обсуждает успехи и неудачи прошедшего этапа. Именно на этом мероприятии тестировщик может в полной мере ощутить ценность своей работы, сравнив свои предсказания с полученным результатом.
Приведу несколько примеров из собственного опыта.
Долгие годы компания ConquestSS разрабатывала десктопный продукт SQLDetective для работы с базой данных Oracle в операционной системе Windows. По примеру ОС в приложении существовала панель с кнопками открытых в рабочей области модулей. Однажды владельцу продукта пришла мысль реализовать функционал таскбара в приложении наиболее приближенно к общеизвестному в операционной системе. Но шеф, выступавший иногда в роли аналитика, не собрал воедино весь известный функционал, а решил воплотить только то, чем пользовался он один. Кнопки одноимённых окон всегда автоматически объединялись, при наведении курсора на группу кнопок показывался лишь список кратких имён без отображения содержимого в минимизированном виде. Моё замечание о том, что новый функционал не имеет настроек пользователя и будет работать в неудобном формате, было письменно зафиксировано. Но упрямый владелец продукта категорично отверг моё предложение добавить настройку пользователя по выбору режима отображения кнопок в собранном по модулю режиме или самостоятельно для каждого окна. Как только новшество попало конечному пользователю, посыпалось юзерское негодование о потерянных из виду рабочих окнах. Только после этого моё первоначальное замечание было внедрено хотя бы частично. К тому же, на его реализацию потребовалось больше времени, нежели его было бы израсходовано сразу, поскольку произошла ротация ответственных программистов по продуктам и новичку пришлось изучать легаси (старый код предыдущего разработчика). Но, дабы не портить отношения с руководством, сокровенная фраза была произнесена лишь в уме, да и к тому времени у меня не было особой надобности выпячивать свой профессионализм: зарплата повышалась сама собой, авторитет у сотрудников давно заработан обильными подобными случаями.
Несмотря на то, что с момента описанных событий прошло более четырёх лет, явно действовавших лиц называть не буду, как меня приучили в ConquestSS. Да, полное совпадение поведения с героями Григоря Остера, которые не хотели предавать друга - Слонёнка. Поэтому вместо имён даю линки на их аккаунты в соцсетях.
Вторая история, которую хочу вам поведать, закончилась менее благополучно для пользователя, нежели предыдущая. Но обе ничего приятного мне, как добропорядочному тестировщику, не принесли. К сожалению, руководитель проекта всегда слишком ревностно относился к своему детищу, и это его погубило. После увеличения группы разработки неприятие чужих идей стало проявляться в нём более явно. Он игнорировал мнение разработчиков на обсуждениях замалчиванием или резкой фразой "я так решил, это не обсуждается". Удалял без предупреждения не свои задачи с предложениями из BTS и в этот же или на следующий день оформлял точно такую же, но от своего имени. То есть элементарным плагиатом пытался увеличить своё барско-собственническое отношение к продукту, реализуемому целой группой разработки. Поскольку мне, как тестировщику, была давно привычна роль "на отшибе команды", то моё недовольство за игнорирование своих идей направлялось приватно лишь самому руководителю группы. Но когда подобное негативное отношение к чужому стало распространяться на всех членов команды, то взыграло моё обострённое чувство справедливости, упроченное и развитое должностью ответственного за качество, и жалоба о безалаберности самовлюблённого руководителя группы легла на стол вышестоящего босса. К сожалению, тот, кто платит, не является сильным руководителем. Босс проявил себя слабым начальником и вместо того, чтобы отдать должное "серому кардиналу" и воспользоваться его заслугами по сплочению коллектива для достижения общей цели, оставил во главе группы разработки плагиатора. На тот момент босс утверждал, что даже такой нерадивый начальник будет делать именно то, что ему нужно, то есть сводить проект к полному уничтожению. Но, как показала практика, быстрого краха им добиться не удалось, потому что группа разработки была заряжена "серым кардиналом" на довольно длительную систематичную и добротно налаженную работу. На том объёме предложений, что были мной ранее оформлены, ConquestSS продержались год (до июля 2018) в полном составе и ещё пару лет в минимальном. Под шумок эпидемии закрыли два продукта (ClearDB в марте 2020, FADEX в июле 2020), а оставшиеся два (ClearSQL, SQLDetective) вместо того, чтобы стать лучшими в линейке подобных или уникальными через реформации и декомпозицию, скорее всего исчезнут с рынка, поскольку уже слишком долго (полгода-год) нет обновлений, да и сайт застрял в 2020 году (дата копирайта внизу главной страницы). Но это только мои предположения. А что же сбылось из ранее напророченного?
Когда в ConquestSS отказались от качества и на моё место взяли маркетолога, провалившего бум провайдера-новичка, то ему были даны несколько советов по построению работы. Все мои предложения (в области лицензирования, обучения пользователей, поднятия статуса продуктов у самих разработчиков, ученических версий для привыкания к продукту), не требующие глубокого погружения в предметную область, были реализованы специалистом по продвижению продукта на рынке и сыграли свою благоприятную роль. А вот к предупреждениям о возможных подлянках со стороны владельца продукта маркетолог вероятно не прислушался. Вся его годовая работа по привлечению пользователей была одномоментно выброшена в мусор. Статья "ПроЛОГОведение" частично об этом случае рассказывает. Лично мне было бы очень обидно, если бы группу в соц.сетях, набравшую моими усилиями большое количество подписчиков, вдруг кто-то удалил без возможности восстановления, да ещё и переименовал проект. То есть маркетологу оставалось только начать абсолютно всё с нуля - привлекать юзеров к новоимённому проекту, потеряв доброе имя поставщика стабильного продукта. Как уже было сказано, маркетолог не сильно разбирался в предметной области, поэтому не смог реализовать мои предложения по развитию самих продуктов. А ведь именно это могло спасти проект в тот момент, когда начался конец ConquestSS. Но он был неминуем. Во время моего разговора с боссом прозвучала его оговорка по-Фрейду, смысл которой был озвучен основной группе разработки: "Боссу мы не нужны и он мечтает о закрытии ConquestSS". Да, он давно жаловался, что мы - убыточный проект. Но эти верные работники много раз его выручали и соглашались на низкую оплату труда, либо бесплатную поддержку. Только ни CustDev, ни Agile в исполнении шефа не спасли проекты, а чуйка ответственного за качество никак не пробила упрямство самовлюблённого начальника. И, как итог такого эгоизма, крах неизбежно наступил. Даже предупреждённые программисты лишились работы. А тестировщик - не пророк, это просто его должностная обязанность читать между строк и слышать мысли, увязывая их с предшествующими событиями.
Надеюсь, что моё третье пророчество будет с хэппи-эндом. IT-сфера меня привлекла и тутже поглотила в 1986 году. Как понимаете, знания мне приходилось выуживать не из готовых учебников, а собственным опытом. В последнее время повышать квалификацию стало проще, ведь появились конференции наших специалистов, где в результате быстрого общения объём нового моментально распространяется. SQA Days явились первыми вестниками знаний широкого круга и даже выделили в отдельное течение аналитиков, охватили европейскую аудиторию тестировщиков. Когда конференции были в диковинку, тем и докладчиков было намного больше свободных мест. Но с годами наблюдаю, что в докладах исчезла новизна идей. Вероятно с приходом сертификации нашей работы, то есть сконцентрировав все правила в одном документе, у специалистов нашей профессии наступила остановка вливания новых идей. Мы вышли на плато. Все накопленные опытом знания уже озвучены, доклады на последних конференциях за пару лет повторяют себя в основном. Зачем же теперь стремиться поучаствовать в SQA Days? Разве что, ради бесплатной рекламы самого себя. Никаких прорывных новых идей, к сожалению, уловить на них не получается. А мусолить то, что уже известно всем - только трата времени попусту. Однажды выступив на конференции и получив положительный отзыв от куратора, меня активно зазывают стать докладчиком. Но за этими звонками я с точки слуха тестировщика предчувствую, что мной просто на просто пытаются закрыть дыры снизившейся популярности мероприятия. Но, уж если на то пошло и организаторы конференций не способны достичь кворума, может объединить все три конференции в одну? Тем более, что между тестировщиками и аналитиками к сегодняшнему дню уже почти стёрлась граница в должностных обязанностях. Ситуация закрытых границ между странами только положительно влияет на конференции, потому что для он-лайн режима появились, или вернее сказать улучшились, условия связи и проведения мероприятий. К тому же цена такого общения значительно дешевле, нежели очного. Так что, если организаторы конференций IT-Conf объединят все три мероприятия в одно, пригласят к участию больше иностранцев, переведут всё в он-лайн режим и максимально снизят плату за участие (в данном случае возможность быстрого общения с знаменитостью или получение ответа на жгучие вопросы от большой аудитории), то конференция останется в топе аналогичных. Появившиеся недавно конкуренты (Heisenbug, TechTrain и иные подобные) очень быстро наступают на пятки и даже в каком-то смысле обгоняют, привлекая к участию более глубоко практикующих специалистов.
В рамках профориентации эта статья скорее сослужит недобрую службу, поскольку показывает нашу профессию с самой неприятной стороны. Тестировщик одновременно должен и предугадать конец, и предложить несколько путей по минимизации провала. Но в любом случае вину за неудачи скинут на того, кто их "пророчил". Психологически быть тестировщиком - очень сложная задача. Постоянный риск комплекса "носителя плохих вестей", если вы добросовестный и ответственный работник, на мой взгляд минимизировать можно лишь двумя путями. Либо программисты перестанут плодить баги, тогда вы прекратите грустно отчитываться на стендапах об увеличенном потоке возвратов и регрессов. Либо вы станете пофигистом, тогда рост багов вас никак не будет задевать, но в этом случае вероятна потеря интереса к профессии. А если вы приучите свою психику радоваться чужим ошибкам, то никакой социум вас не подпустит к себе, поэтому сначала вы перейдёте в разряд интровертов, потом мизантропов и аутистов. Но к этому моменту вас лишат рабочего места в группе разработки, да и на аутсорсе одиночки-фрилансеры - явление редкостное. Так что, вовремя контролируйте свой внутренний конфликт отношения к чужим промахам. Не бойтесь обрисовать во всех чёрных красках плохой конец, но при этом подготовьте и "рояль в кустах", и "туза в рукаве" в виде альтернативных путей по достижению цели постановщика задачи и в качестве отходных манёвров при приближении к пропасти. Не скрывайте свои способности пророка, развивайте интуицию, если в ваших планах восхождение по карьерной лестнице. Нет, мы - тестировщики - не прорицатели, но картину будущего продукта можем обрисовать в сочных (чаще тёмных) красках.

Вижу = понимаю

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

Кино-режиссёры и театральные постановщики показывают своё видение пьесы или романа, зачастую очень далёкое от оригинала. Если бы мне, как читателю, какая-нибудь программа для компьютера, созданная МОИР-ом (Мастер Обучения Искусственного Разума), или электронной книги предоставила возможность нарисовать главного  героя по описанию писателя, а затем раскрасить фон в точности со словами из предисловия, то последующее наложение анимационных технологий автоматически сформирует мультик по всему сюжету книги. Вы ведь тоже у себя в голове прокручиваете такое кино?

Да, соглашусь, что чтение повышает грамотность и улучшает работу мозга в целом, а просмотр видеоряда тормозит мыслительные процессы: читая очередную главу вам обязательно надо держать в одном из уголков мозга ранее усвоенное, чтобы текущая информация получилась адекватной, понятной, логичной и уместной. Если же информацию получать из мультика, то наш мозг из творца и созидателя превратится только в тупого потребителя. Со временем обленится и перестанет требовать наполнения для обработки, станет только работать по поговорке "в одно ухо влетело - в другое вылетело".

Но для иностранных произведений видео-книга стала бы лучшим решением, как сегодняшние аудио-книги и экрано-озвучки для слабовидящих. Как вы думаете, почему у японцев так сильно развилось такое творчество, как комиксы? Им некогда вчитываться в текст книг, потому что много работают. А пролистав картинки, они успевают отвлечься от производственных мыслей за несколько минут, вместо нас, отдающих от получаса перед сном грамотному тексту.

Ещё одна мысль о мультфильмах. Почему этот продукт существует только для детей? Куда пропали взрослые мультики? Например, "Скамейка" о многом заставляет задуматься, что и является главной целью любого литературного произведения. У СоюзМультФильма есть множество путей монетизации контента не только в качестве обучалок для малышей, но и визуализируя русскую фантастику. 

Трёхмерность жизни

"Решение проблем - это движение вперёд и вверх" - девиз этого блога. Вся наша жизнь состоит из преодоления проблем для достижения целей и исполнения желаний. Все мы вынуждены жить в обществе, а значит зависимы от окружающих. Любая наша мечта или даже мелкая хотелка сама по себе никогда не произойдёт, жизнь - не сказка, то есть для её осуществления нужны хоть малые, но наши силы и возможности, а также сторонняя помощь или хотя бы одобрение. Поэтому окружающее общество придерживается введённых законов, дающих всем уверенность в равноправии достижения целей, не смотря на их разнородность.

Молодому поколению сложно справляться со своими проблемами, тяжело ступать по лестнице развития. Старшие же могут показать наглядно, как делать выбор на каждой стадии так, чтобы результат не перекосил последующую линию судьбы. Любое действие имеет свою причину. Но по закону физики любое действие имеет свою силу противодействия. Когда нам чего-то хочется, то оно не падает на нас манной небесной. 

Ось ХОЧУ

Определю желание или цель стрелкой вверх и влево, потому что всё сейчас недоступное обычно весит высоко, а более притягательное почему-то на дороге влево. Вспомнить хотя бы ходоков к чужим жёнам или сладкий плод в раю. Они тоже где-то слева вверху. Мечту чаще называют "розовой", потому и цвет оси "ХОЧУ" придам тёплый. Если же не в житейской терминологии её именовать, а юридической, то более подходит слово "ЦЕЛЬ". Или же можно назвать эту ось "птица счастья", у великого баснописца она, кстати, была Лебедем.

Двухмерность мечты и возможностей

Но любая хотелка, как уже ранее было сказано, не может материализоваться без вложений, то есть возможностей мечтателя. Поэтому определю наши силы для осуществления мечты синей стрелкой вправо и вверх.  Синий цвет оси "МОГУ" ассоциируется с работой и водой.  В той же басне за возможности отвечала Щука, ведь "без воды и ни туды, и ни сюды". Но не смотря на то, что вода обычно снизу, ось стремится тоже ввысь, потому что увеличивая свои возможности мы приобретаем опыта больше, чем в последствии тратим сил. Те, кто не разделяет сказочные объяснения, а желает придать моей теории научность, могут именовать эту ось юридическим термином "ПРАВА", по аналогии с документом, известном всем как "договор".

Трёхмерность желания

Ещё раз напомню, что мы всегда находимся в обществе, и все наши желания как-то влияют на окружающих, а значит и они нам противодействуют. То есть любую мечту НАДО соразмерять с ОБЯЗАННОСТЯМИ перед тем самым обществом. Это чаще всего самый сильный сдерживающий фактор и не только в качестве мнения света, но и последующей ответственности за нанесённые действия. Поэтому стрелка тёмно-серая и направлена вниз. И по ассоциации всё с той же басней - под ней можно подразумевать Рака.

Расценки мечты

Итак, у нас получилась трёхмерная система координат жизни, которой мы придадим условное исчисление: от 0 до 3 или 10, как вам больше нравится.

Выделим в текущий момент жизни одну проблему, например, финансовый кризис после пандемии. Попытаемся начертить кривую для решения этой конкретной проблемы в системе координат наших желаний, возможностей и обязанностей.  Первым шагом сформулируем мечту или цель, которая должна быть адекватной, достижимой и конкретизированной. Например, выиграть миллион в лотерею - это неадекватная, слабо-достижимая мечта, но конкретизирована суммой. А вот желание "летний трёхнедельный отпуск провести на морском побережье и потратить двухмесячный оклад" отвечает всем условиям, потому что если на Карибское море вашей зарплаты может и не хватит, но на Чёрное или Каспийское - вполне. Тем самым мы укладываем свою мечту в рамки адекватности и достижимости, точно сформулировав конкретизацию. Поскольку мечта удовлетворяет всем трём условиям, то отмечаем её на цифре 3 своей оси. И начинаем считать возможности, то есть проводим линии до осей МОГУ и НАДО сначала к точке 1 или даже к 0, поскольку все три оси находятся во взаимосвязи, что поясню позже на примере законов физики.

Связь ХОЧУ-НАДО

Связь ХОЧУ-МОГУ

Если у вас есть регулярный доход (работа с ежемесячным окладом или вклад с квартальным причислением процентов), то по оси МОГУ можем встать на 1. Если вы нашли тур, который по цене совпадает с вашей зарплатой, то сдвигаемся на пункт 2. Если же работодатель точно даст вам дни отпуска в июле-августе, то смело сдвигаемся на цифру 3.

Если на время вашего отпуска на предприятии рабочий процесс не остановится или не развалится без вас, то ставьте точку на 1 оси НАДО. Если перемещаясь в другой регион вы не нарушите санитарные нормы, например, привились от COVID-19, то сдвигаемся по оси НАДО до 2.  Если вы гарантируете, что не нарушите в чужом месте никакие законы и благополучно вернётесь домой, например, не будете вывозить дары моря из Египта, то смещаемся до 3 по оси НАДО. То есть подчёркиваем, что общество дома, на курорте и работе не понесёт потерь от вашего осчастливливания.

А  теперь посмотрим на получившийся треугольник взглядом физика. Представьте, что верхняя сторона ХОЧУ-МОГУ - это планка качелей (или поднос в руках официанта, или дощечка в пирамиде эквилибриста), а вершина оси НАДО - точка её переката (основание кисти официанта, касания цилиндра и цирковой арены). Таким образом, мы определили величины левого и правого плечей рычага, а также точку приложения силы. Когда всего достаточно (ХОЧУ, МОГУ и НАДО на равном удалении от центра), то равносторонний треугольник покажет устойчивость положения, а значит и проблема решится как-бы сама собой.

Равновеликая мечта

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

Большое желание при малых возможностях

Увеличение возможностей равняет качели мечты

Обязательства скатывают мечту с горки

Когда объём желаемого и возможного совпадает, но невелики при огромной задолженности перед обществом, например, должников по алиментам не пускают за границу, то острый равнобедренный треугольник на первый взгляд выглядит ровно, но его острота предупреждает о высокой неустойчивости положения. То есть внутри страны может вы и поездите, но недалеко и недолго. А значит и полного удовлетворения получить не сможете.

Обильный долг не ширит мечту и силы

Встречается и ещё один вариант равнобедренного треугольника, когда ХОЧУ и МОГУ достигают максимума, а НАДО не растягивает фигуру в правильную (равносторонний треугольник - самая жёсткая фигура геометрии). Физик вам сразу напомнит, что малейшее приложение силы к одному из длинных плеч рычага начнёт качание. То есть при минимальных обязательствах перед обществом расширение мечты на один шаг сократит возможности чуть ли не вдвое, например, девицы лёгкого поведения автостопом не всегда попадают к морю, а чаще в подпол лесной избушки.

Так живут безалаберные люди

Вот так, мы можем теперь рассмотреть любую проблему. Визуализировать её и проанализировать по прогнозам. Жизнь можно декомпозировать и запрограммировать простейшими алгоритмами, если знать элементарные законы естествознания. Попробуйте приложить к вашему уникальному случаю всем известные правила, и он разрешится как в вашу пользу, так и сохранит статус-кво окружающих. Живите счастливо сами, даря счастье близким. 

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

Взгляд назад

Ретроспективу тестировщики обычно проводят совместно со всей командой, но дата наших подведений итогов возможна намного позже выпуска, поскольку результат нашей работы виден лишь в долгосрочной перспективе. Отсутствие жалоб пользователей или благодарность за вовремя и в точности выполненные изменения - это положительный результат действий QA и его оценивают обычно на контрасте. Руководители проектов чаще не желают замечать тех ежедневных титанических усилий защитников качества, которые приводят к успеху продукта, а приписывают его только себе. Наши частые просьбы подправить мелкие баги в общей корзине изменений приводят к лоску всего продукта. Кто из ваших лидов отмечал эти капли на фоне моря бэклога во время ретроспективы? QA вполне могут приплюсовывать такие неприметные шажки к кампании по профилактике проблем.
Две-три недели изоляции достаточно для проведения первой ретроспективы. Но для полноценной оценки стоит учитывать не только предпринятые меры в учётный период. На примере современного общества можно увидеть, что государственное здравоохранение, организованное Н. Семашко, именно сейчас дало положительный эффект - спокойствие и государственную защищённость граждан. Страны, нацеленные на быстрый доход, не стремящиеся к долгосрочным перспективам (аналогия со стартаперами), только в текущей критичной ситуации заметили свою несостоятельность. Это яркий пример необходимости проводить регулярную профилактику вместо надежды на единственного супергероя, который в очередной раз вставит "костыль". Ещё одним положительным шагом, сыгравшим свою роль в условиях удалённой работы на дому, считаю проект Д. Медведева "Последняя миля". Как сто лет назад Ленин продвигал освещение по всей стране, так и в начале этого века нас покрыли RUNET-ом. Благодаря такому далеко-сведущему движению мы не только сейчас своевременно проинформированы обо всём, но можем продолжать обучение и трудовую деятельность. В рамках ретроспективы стоит сказать "спасибо" за столь важную предусмотрительность. А ваши тимлиды отмечают на подведении итогов роль примечаний и идей QA?
Наш соратник, бывший IT-шник, хотя врядли в наш инфо-век мы успеем стать "бывшими", М. Мишустин своевременно способствовал цифровизации налогообложения, а теперь, отменив в этом году перепись населения, надеюсь и её переведёт в режим фактов, не давая повода всяким фрикам хайпануть за государственный счёт. Хорошо помню свою волонтёрскую деятельность конца советского периода, когда летними вечерами приходилось обходить квартал за кварталом близлежащих к школе домов и переписывать всех детей, чтобы школа смогла вовремя составить расписание и подобрать пед.состав на одну или две-три смены. Тогда не было возможности обменяться базами данных ЗАГСу, паспортному столу и школам, даже тетрадку и ручку нам никто не выдавал. А сегодня тратятся немалые средства на оборудование (планшеты, канцелярия, удостоверения, реклама) и зарплату опрашивателей. Ведь эти все деньги и материалы вполне себе могли бы сослужить более выгодно: планшеты очень нужны школьникам для удалённого обучения, за меньшие деньги любое бюро разработки ПО быстро напишет связь всех нужных баз данных. Цифровизация переписи населения - это не только единоразовая экономия, это долгосрочное ПО, которым можно будет пользоваться хоть ежегодно, хоть ежедневно. Аналитики всех слоёв выгадают от этого, а у рядовых граждан не будет повода выдумывать всякую всячину взамен реальных имён, национальностей и прочих житейских параметров. Тут, как нельзя лучше, подходят обе поговорки "не было бы счастья, так несчастье помогло" и "всё, что не делается - к лучшему". Надеюсь, отменённая в этом году перепись населения перейдёт в разряд госзаказа на ПО, тем самым даст нам, тестировщикам-интеграторам, больше работы.
Ещё один правильный шаг делает правительство - повсеместно строит больничные комплексы. Это достаточно умно, если учесть, что сейчас семьи много времени проводят вместе, а государство объявило о поощрении роста демографии. Хочу натолкнуть вас на мысль, что эти больницы к концу года будут весьма востребованы в качестве перинатальных центров. QA, а вы умеете предложить такой костыль в критичных условиях, который лёгким движением превращается в солидное новшество? Помните, для плодотворной работы тестировщик обязан обладать многоходовым разумом шахматиста.
Ограничения на поездки переводят нас повсеместно в ранг пешеходов, многие из которых возможно спровоцируют очередной общегосударственный проект "Дорога к дому", в рамках которого главы поселений почувствуют на своих подошвах изношенность или отсутствие тротуаров, их затемнённость или узость. Надеюсь, местным властям, предпринимателям и жителям в рамках такой национальной программы удастся реставрировать устаревшие дорожки, проложить новые с полным соблюдением дистанции, обустроить зоны для велосипедистов, роллеров и иных мелко-колесящих участников движения. Хочется верить, что проект "Дорога к дому" на законодательном уровне закрепит героскутеры, скейтборды, самокаты и ролики, как средства передвижения по выделенным полосам тротуаров и пешеходных дорожек. Любое сужение рамок в творческом уме тестировщика порождает выгодные решения.
В рамках кризисного периода главы местного самоуправления получили больше полномочий, но почему-то не всюду торопятся ими воспользоваться на благо своих жителей. Например, каждый многоквартирный дом имеет придомовую территорию, но жители заперты в квартирах. А ведь старшие по дому и подъезду вполне могли бы составить плавающий график прогулок в пределах двора с предварительной санобработкой. Это же не так сложно - родителям части квартир за 10-15 минут пересменки до своей прогулки опрыскать детскую площадку антисептиками, а на последующие 45 минут вывести своих чад под присмотром и в соответствующем времени обмундировании (маска, перчатки).  Даже если в доме 100-200 квартир, то удлинившийся световой день вполне достаточен для того, чтоб на игровой площадке поочерёдно побывали хотя бы полчаса ежедневно все проживающие дети. Ребёнку нужен свежий воздух, физическая нагрузка, а не всякие жилые строения способны выдержать нагрузку прыгающих и бегающих непосед, да и стране более важны здоровые, а не хилые граждане. Если вам дали чуть больше воли, то используйте её на благо окружающих и тогда профит от неё подмигнёт звёздочкой на плече.
А. Рыжов хайпует постановками секс-шоу на старшеклассниках вместо воспитания в них культурного поколения. Запреты молодым актёрам на полное прочтение и просмотр оригинальных источников приводят к тому, что спектакли ТЮЗа из раза в раз отображают только комплексы режиссёра, а не истинные проблемы автора произведения и современного поколения. Театр - искусство массовое, несущее разум и воспитание. Также, как и при разработке ПО, постановка спектаклей вынуждена учитывать желания потребителей, изначально взятый курс стоит не только корректировать согласно современным течениям, но и забрасывать удочку на перспективу - развивать общество. А ваша команда на ретроспективе какие уроки пройденного периода усваивает и вырабатывает ли новые цели?
НТВ посылает московских репортёров в поля, не тронутые короновирусом, вместо расширения полномочий местных сотрудников и предотвращения распространения заразы, ведь привезти микробы они вполне могут на аппаратуре. Микрофоны как дезинфицируют? Концерт в Большом Театре показал отношение артистов к своему производственному предмету: клавиши рояля протирали перед каждым выступлением, О. Газманов держал микрофон в перчатках. Вещание круглосуточного новостного канала "Россия 24" перебазировалось в домашние условия, а НТВ по-прежнему собирает звёзд на тесных диванчиках, стратегически-важные каналы "Первый" и "Россия 1" в большинстве прямых эфиров и ток-шоу соблюдают социальную дистанцию, а НТВ зрителей и участников передач плотно набивает в зал без санитарных масок. Как представитель QA предупреждаю общественность, что телевещательный канал своим примером исключительности опасен в дни пандемии из-за несоблюдения санитарных правил. Не удивительно, что некоторые жители не соблюдают самоизоляцию, поскольку они берут пример со своих "любимых" телеканалов. История любых времён докажет вам, что в достижении успеха практика двойных стандартов никогда не являлась помощником, а только усугубляла процесс деградации.
За одну-две недели удалённой работы любой оценит важность соблюдения общепринятых правил и особенно распорядка дня, при чём не только средним звеном, но и высшим. Древняя наука - педагогика - практикует закон "пример заразителен", да и своё название взяла из фразы "веду за собой". Если руководитель желает сплотить коллектив и воспитать его в лучшем виде, то должен начать с себя, показать положительный пример на своём поведении и постоянно его придерживаться. Тайм-менеджмент нарушается начальником, считающим себя всегда исключением и не уважающим рабочее время своих сотрудников. В таких случаях я ратую за лозунг: "Чаты вместо звонков!" Профессионалы-тестировщики даже могут обучать искусству задавать краткие, конкретные, однозначные вопросы, которые способствуют эффективности в производстве и взаимоотношениях. Довольно многих раздражают голосовые сообщения из-за слов-паразитов, отнимающих драгоценное время. А при печатании текста ни их, ни мат уже не вставить. Боитесь, что затеряется ответ? Используйте напоминалки и цитирование в чатах. Любители поболтать, экономьте время ваших секретарш, которым всё-равно придётся переводить звук в печатный текст, ставьте задачи и вопросы сразу в письменном виде.

Полагаю, на этих нескольких примерах стали более очевидны принципы ретроспективы:
- выявить положительные и негативные действия как всей команды, так и отдельных её членов;
- дать оценку последствиям шагов обеих (+/-) сторон;
- выяснить причины успехов и провалов для выработки общих правил;
-  определить вектор развития.
Желаю, чтобы совещания в конце спринта стали более эффективными за счёт вышеизложенной памятки.

Балаболство

Прослушав очередные под-касты от QAGuild мне стало обидно за слушателей, которые впустую тратят время. Ребятки-миллениалы абсолютно не знакомы с правилами подачи информации. Кстати, этим же страдают не мало докладчиков IT конференций.
Друзья, вспомните всё то, чему вас учили в школе: сочинение должно иметь определённую структуру, а учитель при подаче новой темы всегда имел стандартный план. Мои познания в поурочных планах были оценены красным дипломом Пед.ВУЗа, поэтому стараюсь соблюдать общепринятое правило и ожидаю этого же от других.
Если предмет разговора (доклада, подкаста) имеет только наименование, но не поставлены чёткие цели, как результат стремления, то польза от действа - нулевая, как организатору, так и участникам. Если вы не договорились о методе подачи информации (лекция, семинар, МК, беседа, …), то не удивляйтесь обилию троллинга или позаботьтесь о наличии профессионального фасилитатора в числе организаторов. Если в начале разговора используемым терминам не даны однозначные определения, то общение не заинтересует участников диалога, либо понимание станет извращённым, а то и негативным. Ваши идеи не воспримут должным образом. Поскольку парни в основном из Украины, то даю им скидку на убогое использование русского языка с многочисленными вкраплениями новоявленных англоязычных слов для межнационального общения. Благодаря обилию узкоспециализированных терминов они стараются выделить себя в особую касту IT-шников. И не подмечают, что их речь доступна только ограниченному числу слушателей. Так зачем же распространять нечто непонятное всем и каждому, если оно так и остаётся абракадаброй? Если вы желаете поделиться своими знаниями и наработками с кем-то, то по законам педагогики сначала определяете уровень аудитории и постепенно поднимая его доводите до своей высоты.
В одном из моих постов предлагалось совмещать прослушивание под-кастов и докладов с основной работой. Так что, моё время не столь пострадало от трат на "ПиSDET - не мешки ворочать" и "Про тестирование контрактов". А вот полезных знаний так и не прибавилось. Кем стоит быть и что следует знать, чтобы стать SDET-ом? Что такое "контрактное" тестирование и чем оно отличается от unit-tests? Вопросы задавались, но ответов так никто и не дал.
Да, они правы сами про себя: "Нашему поколению миллениалов лишь бы хайпануть." Названием под-каста заинтересовали слушателей, но удовлетворить запрос не смогли. Значит сами делают некачественный продукт (Качество = запрошенные Требования исполнены + Вовремя доставлены + по сходной Цене), поскольку не дают то, что прорекламировали. Полагаю, им стоит полностью перейти на трансляцию только для тех, кто их спонсирует. Есть такие, которые ещё и вкладываются в подобное балаболство.  

ТО о SD 5.1.1.210

Отчёт о тестировании SQLDetective 5.1.1 (build 210), опубликованному 17 октября 2019 года. Все тесты основаны на пунктах Release Notes.
Три месяца прошло после публикации предыдущего фикс-билда #160, номер релиза или минора не изменился, а значит за этот период накопились фиксы багов без значительных улучшений. Попробуйте угадать "какого бага билд?", то есть какой критичный баг перевесил точку кипения юзеров и команда ConquestSS попыталась умаслить недовольство пользователей?

IMPROVEMENTS  0.5+0.8+0+0.5+0+0.5+1+0.3=3.6  из 1+1+1+1+1+1+1+1=8 возможных и багов на=-0.5-1.5=-2 балла
Core 0.5 из 1 возможного
⦁ Oracle Client is now automatically downloaded and installed if no installation is detected on the PC.
Клиент Oracle теперь автоматически загружается и инсталлируется, если на компе обнаружено полное отсутствие инсталляций.
Поскольку инсталлятор и функционал подключения к базе являются глобальными модулями, то описание тестов аналогично тем, что были проведены для CS 9.1. В рамках же SD лишь убедимся, что реализация и баги идентичны для обоих продуктов.

Нет детекции или забыто отображение результатов

Также стоит отметить, что инсталляция клиента базы Oracle не входит в рамки инсталлятора продукта, а окно подключения к базе автоматически появляется при запуске SD. Поскольку SD существует только в 32-битном исполнении, то и линк для загрузки клиента предлагается только 32-битный. Учтите, что в архивном файле предлагается не инсталлятор, а просто папка instant-client 19-й версии, которую всего лишь надо скопировать себе на диск (или любой доступный) и в переменных окружения в PATH добавить путь к этой папке. Об этом нигде (RNs или Online Help) не сказано. Реализация не совсем соответствует описанию (не блок опций коннекта к базе), расположение инсталлятора сомнительно (не на сайте вендора базы), отсутствие клиентов не проверяет остальные установки (никаких индикаторов о переменных окружения, пакете Microsoft, нет красных NO у лейбл клиентов), поэтому новшество также получает лишь полбалла.
SQL Editor 0.8 балла из 1 возможного
⦁ Added the ability to search for text occurrences in the DBMS Output tab.
Добавлена возможность поиска текста по результатам DBMS вывода.
Для теста подключаемся к любой базе и выполняем в SQL Editor простенький pl/sql блок с выводом dbms-пакета. Например, "begin  dbms_output.put_line('it is my test for search feature');  end;". Если на закладке DBMS Output в SQL Editor пусто после исполнения кода, то проверьте включенность вывода на этой же закладке или в "Preferences / Code Editors / DBMS Output". Далее проверим сам функционал поиска. В предыдущей версии SD не было ни пункта в контекстном меню, ни появления какого-либо диалога по стандартной горячей клавише "Ctrl+F" при активности курсора в окне результатов dbms-пакета. Стоит заметить, что поиск осуществляется интерфейсом, специально разработанным для SD, поэтому поддерживает все возможности, доступные в других текстовых редакторах приложения. К сожалению, хелп-топик закладки DBMS Output почти что не имеет содержимого, поэтому и новая фича не описана. Ещё одна странность этого новшества в том, что оно реализовано только в SQL Editor, а идентичная закладка в Stored Program Editor осталась не у дел. За что и получает новшество лишь 0.8 балла.
Compare Databases 0 из 1 возможного
⦁ Improved the comparison of system generated objects.
Усовершенствован механизм сравнения системных объектов.
Системными объектами в базе Oracle считаются не только те, что схемах SYS, SYSTEM, но и те, чьи имена автоматически генерятся, поэтому либо начинаются с "sys", либо заканчиваются "$$". В большинстве случаев это индексы, констрейнты, иногда таблицы и вьювера, а с 12-й версии базы - колонки таблиц. Так что очень сложно по вышеописанному определить, что конкретно изменилось в сравнении баз. Значит можно не заморачиваться с тестами и пометить этот пункт припиской, не дав балла.
Rename Object +0.5 из 1 возможного, -0.5 за нереализацию
⦁ Added the ability to
  ⦁ automatically rename tables indexes.
  ⦁ rename tables and indexes of another user.
Добавлены возможности автоматически переименовывать индексы таблиц и менять имена таблиц и индексов в чужих схемах.
Экшен переименования объекта доступен лишь в двух местах:  в главном меню Object или контекстном меню для ноды выбранного объекта в дереве Object Navigator. Описание новшества неточно описывает изменение. Радикально добавлено переименование индексов. Переименовывать можно не только табличный индекс, но и кластерный. Совместно с таблицей переименовываться по опции будут лишь индексы, совпадающие по имени с родительской таблицей. К тому же хелп-топик "Working with database objects – Renaming objects" не отредактировали согласно изменениям функционала.  Для проверки наличия новшества открываем вышеозначенные пункты меню для перечисленных типов объектов. Если достаточно прав у текущего пользователя, то выполняем команду RENAME. Для проверки переименования чужих объектов изучаем команду RENAME для используемой версии базы данных, выдаём тест-юзеру необходимые роли и объектные привилегии. Ещё одно неописанное новшество - возможность предварительно просмотреть полный текст исполняемой команды - внесло в SD интерфейсные баги. Текстовый редактор, являясь глобальным модулем, теперь с новыми огромными иконками для кнопок тулбара, заимствованных из CS 9. А на время его открытия исчезает окно, из которого текстовый редактор был вызван. Для текущего юзера оказывается, что переименовать индексы вместе с таблицей нельзя - нет опции, доступной при переименовании чужой таблицы. Единичное переименование своих и чужих индексов работает. Единичное переименование своих таблиц осталось неизменным. Чужие таблицы с массовым переименованием индексов терпит неудачу из-за неверно формируемого блока на исполнение, в котором индексам не присваивается новое имя. То есть для таблицы выполняется команда 'ALTER TABLE old_table_name RENAME TO new_table_name', а для индексов база ругается на существование одноимённого объекта для команд 'ALTER INDEX old_index_name RENAME TO old_index_name'. По результатам тестов могу дать только 0.5 балла и ещё 0.5 балла сниму за баг нереализации.
Dataset/Datagrid 0 из 1 возможного
⦁ Focused cells are now always highlighted in datagrids.
Фокусированные ячейки теперь всегда подсвечены в гридах данных.
Стоит упомянуть, что в SD компонент Datagrid используется повсеместно, но к нему не относятся таблицы без красного символа "?" в левом верхнем углу, например, на ContentSelector окна Object Navigator закладки Data и Columns относятся к числу гридов данных, а таблица на закладке Properties - нет. Больше всего меня в описании смущает слово "всегда", потому что оно откидывает пункт в блок исправленных багов и означает весьма обтекаемое свойство модуля. Дополнительный когнитивный диссонанс вызывает сочетание множественного числа с фокусом. В фокусе (визуально - с красными точками по бордюру) может быть только одна ячейка, даже если выделено несколько (по-умолчанию, цвет подложки - синий, цвет текста - белый). Если проверять фокусировку, то набор тестов будет для одной ячейки. Если проверять подсвечивание, то набор тестов будет касаться нескольких ячеек одновременно (строка, блок или вразброс выбранные ячейки). Если дизайнить тесты по слову always, то следует обращать внимание на интерфейс грида при открытии его самого, на прорисовку его элементов при работе с редактором ячейки (текстовый редактор для символьных полей, калькулятор для числовых, календарь для дат и прочее) или с вызываемыми утилитами (дублирование строк, экспорт/импорт данных и прочее). Все три типа тестов не показали разницы с предыдущим билдом, поэтому заключаю, что этот пункт RNs - приписка, не заслуживающая ни балла.
Taskbar 0.5 из 1 возможного
⦁ Applied the autofit to the taskbar buttons.
Применяется авто-подбор ширины для кнопок тулбара.
О каком тулбаре идёт речь? О главном или о всех в рабочих окнах? Или только о тех, где размер комбобокса со строкой подключения автоматически меняет ширину? Для тестирования будем открывать Icon Dictionary для главного тулбара, редактора и окон с результатами выполнения скрипта утилиты SQL Editor, какой-нибудь утилиты администратора (Session Navigator, Storage Manager, и т.д.) и простое окно без комбобокса сессий (Smart Dataset, Stored Program Editor). Тесты можно проводить параллельно в двух приложениях SD (прошлый и текущий билд), но каждое окно следует переоткрывать в своей рабочей сессии, чтобы применились настройки. Поскольку с предыдущим билдом разницы не выявлено, то считаю этот пункт исправленным багом, воспроизводимом в SD 5.0, но давно исправленном в SD 5.1, а не в текущем билде. Даю только полбалла за неконкретное описание, ошибочное место (не импрув), запоздалое включение в RNs. Запоздалые RNs получаются в команде без своевременного тестирования, когда задачи закрываются тестировщиком уже после выпуска, не поддерживается период заморозки кода.
Code Insight +1 за исполнение и -1.5 за баги
⦁ Added a horizontal splitter so that the height of the Details panel can be customized.
Добавлен горизонтальный сплитер для изменения высоты панели с деталями.
Модуль Code Insight является глобальным и все изменения идентичны, описанным для CS 9. Убедимся в наличии реализации, вызвав подсказчик кода в редакторе SQL Editor или Stored Program Editor. Аналогичность изменений подтвердила и идентичность багов, выявленным в CS 9. Поэтому за исполнение балл, а за баги -1.5 балла.
Query By Example 0.3 из 1 возможного
⦁ Renamed the “Query by Example Editor” command to “Query by Example (filter and sorting).”
Переименована команда вызова "редактора запроса по примеру" в установление "запроса по примеру с фильтром и сортировкой".
Вышеназванный экшен доступен в главном меню Dataset и в контекстном меню всех Datagrid. Стоит заметить, что переименование касается только пункта меню, но не окна редактора. В RNs новшество попало чисто для массовости, потому что изменение было сделано не в прошлом билде, а в прошлой версии продукта. И не только в интерфейсе, но и в хелпе. Так что получает не более 0.3 балла.

BUGS FIXED  4.6+1+0+1+0.5+1.5+1+1+1.8+0.8+0=13.2 из  7+2+2+1+1+2+2+1+2+1+1=22 возможных и багов на=-4.5-1.2-2-0.3=-8 баллов
Core 0+1+0.8+1+0+1+0.8=4.6  из 7 возможных, -1-2-0.5-1=-4.5  за баги
⦁ Fixed highlighting of search results in lines that include the TAB character.
Исправлена подсветка результатов поиска в строках с символом табуляции.
Поскольку пункт RNs не в блоке "Редактор", то придётся тестировать и недавнее новшество поиска по гриду вместе с поиском по текстовому редактору. В качестве данных для теста возьмём текст, содержащий символ табуляции в начале строки, в конце строки, в строке без иных символов, в строке между символами, несколько знаков табуляции в одной строке до искомого значения. Все эти варианты проверяем в текстовом редакторе, в гриде, в текстовом редакторе с предварительным выделением поисковой части. Отдельно проверяем поиск по регулярному выражению (\t  - табуляция (HT/TAB), можно также \x09), поскольку описание можно двояко понять. Поскольку в редакторах текста невозможно включить режим отображения символов табуляции, чтобы убедиться в их наличии после копирования и вставки, и буфер памяти не всегда (или не везде) вставляет все символы в точности, то перед вызовом диалога поиска набивайте вручную табуляторы. После исполнения тестов выяснено, что на самом деле сделан анти-фикс: раньше все подряд находились значения, а теперь через раз, раньше рядом с подсветкой курсор позиционировался, а теперь через несколько символов от найденной позиции. Вдобавок до сих пор проявляется интерфейсный баг диалога поиска в гридах, когда курсор мигает не в окошке ввода поискового значения, а где-то в районе радио-кнопок, имеющих подписи регионального языка операционной системы.

Пугающее юзера положение мигающего курсора

Не могу дать ни балла за изменение, да ещё сниму балл за общее число сопутствующих проблем.
⦁ The words “left”, “right”, “outer”, “inner”, and “cross” are now treated and highlighted as reserved words.
Служебные слова left, right, outer, inner, cross теперь интерпретируются и подсвечиваются как зарезервированные.
Перечисленные слова используются в DML и DDL, код которых отображается в SynEdit (не простые текстовые редакторы, а редакторы кода с раскраской символов). А именно, мастер объекта, просмотр DDL или скрипта в некоторых утилитах, SQL Editor и Stored Program Editor. Настройка шрифта и расцветки зарезервированных слов доступна в "Preferences / Code Editors / Color / Elements / Keywords" (комбобоксы блока Color и чек-боксы блока Text Attributes). Устанавливаем особенные значения шрифта и вводим в доступных редакторах перечисленные слова без кавычек, а для подтверждения работоспособности просмоторщиков кода без права модификации придётся создать объекты с использованием перечисленных слов. Для создания необходимых объектов обращаемся к документации базы Oracle. Это довольно удобно осуществить в Oracle Documentation Browser, встроенном в SD. Поиск по документации предложит статьи из цикла SQL Language Reference, а поскольку большинство слов употребляется в рамках DML, то можно создать вьювер, пусть и инвалидный, по примерам из документации. Странно, что пункт RNs не в группе редактора кода и в багах вместо новшеств, а в остальном заслуживает балл за исполнение.
⦁ Alternative quoted literals are now highlighted correctly.
Теперь корректно подсвечиваются символы в альтернативных кавычках.
Опять странное расположение пункта RNs не в блоке редактора кода, который поддерживает расцветку текста. Никакие иные графические элементы не раскрашивают символы, вводимые через альтернативные нотации. Не рекомендую искать термин альтернативной нотификации в документации Oracle, а просто ознакомтесь с термином Literals, либо воспользуйтесь примерами от разработчиков базы. Если вставите тексты в прошлой версии Stored Program Editor и текущей, то заметите, что последующий текст не раскрашивается в стринговые значения (по-умолчанию, красный цвет шрифта до следующего одинарного апострофа). Но о корректности подсветки говорить нельзя, поскольку нет отсылки к общепринятым или узаконенным стандартам (кстати, даже страница с примерами вендора имеет смущающую расцветку текстов). За введение пользователя в заблуждение дам только 0.8 балла.
⦁ The error “FROM clause not found in SQL” no longer occurs on trying to execute a statement that includes alternative quoting.
Ошибка о ненайденном FROM слове в SQL теперь больше не случается при попытке выполнить выражение с альтернативными нотациями.
В качестве примера выполним запрос "select q'[It's test]' from dual" в предыдущем билде, получим оракловую ошибку с выводом лога Eureka. То есть была двойная ошибка: парсер кода падал при обработке апострофов и оракловая ошибка излишне вызывала отладчик Eureka. В текущем билде запрос выполняется без багов парсера и DOA, но, к сожалению, до сих пор исполнение запроса может быть заблокировано окном подвисшего процесса, закрытие которого вызывает не обработанную ошибку с логом Eureka. И уже в OSD Messenger выясняется баг комплексного тестирования: глобальная osd.dll скомпилирована из CS 9 с новыми огромными иконками, но без возможности быстрого просмотра писем в дереве osd сообщений (нижнее окно всегда пустое). За фикс балл дам, но пару сниму за старый недоправленый и новый баг сборки.
⦁ Ampersand is no longer duplicated in the tab’s caption in the SQL Editor.
Символ амперсанда больше не дублируется в заголовке закладки SQL Редактора.
Пункт RNs по ошибке не в блоке редактора, подозреваю потому, что это интерфейсный баг, а модуль GUI в ConquestSS считается глобальным. Касательно окна SQL Editor, только одна закладка с переменными имеет амперсанд в своём заголовке изначально. Заголовки же закладок с кодом или данными после выполнения запроса никогда не отображали и до сих пор пропускают один амперсанд, то есть никак не дублируют, а наоборот пропускают. Так что из-за описания, абсолютно не соответствующего исполнению и вводящего пользователя в заблуждения с пониманием, не дам ни балла и сниму -0.5.
⦁ The error “SQL command not properly ended” no longer occurs on trying to execute a statement with the nested procedures in the WITH clause.
Ошибка о неверном завершении команды больше не случается при попытке выполнить выражение с сылочной процедурой в WITH выражении.
Пункт RNs ошибочно попал в группу Core, поскольку выполнением выражений заведует глобальный модуль DOA. А на самом деле скрипт со структурой WITH можно выполнить только в SQL Editor.  К тому же термин nested стоило заменить на inline, как это описано в документации БД версии 12c. Для теста найдите в примерах оракловых форумов запрос с inline procedure in with clause. Выполнив его в предыдущем билде и текущем, убеждаемся в реальности фикса бага. Балл заслужен.
⦁ The CLOB field now has an inplace combo box with the IS [NOT] NULL, [NOT] LIKE operators.
CLOB поля теперь имеют встроенный комбобокс с операторами IS [NOT] NULL, [NOT] LIKE.
Пункт RNs однозначно потерялся и попал вместо блока "Improvements / QBE" в блок "Fixed Bugs / Core". Для теста создаём таблицу с CLOB полем и данными, в редакторе фильтров и сортировок пытаемся выставить ограничения на поле CLOB. Новшество реализовано в редакторе фильтров для грида данных, причём термин field стоило заменить на column, а список условий не стоило перечислять, так как раньше вообще никакие не были доступны. За недостатки описания вынужденно даю только 0.8 балла.
В рамках комплексного тестирования выяснилось, что появилась регрессия в Table Wizard: создание любой таблицы, даже самой простенькой, завершается неожиданной ошибкой. За что с билда снимаю балл.

DDL новой таблицы - минимально стандартный скрипт. 

А что приложение предлагает базе - секрет программиста.

SQL Editor 0+1=1 из 2 возможных, -1-0.2=-1.2 за баги
⦁ Timestamps with time zones are now shown correctly in the Data and Output tabs.
Время с зоной теперь отображается корректно на закладках Data и Output.
В SQL Editor окне существует закладка Data Output, а не Data, и ещё три закладки имеют постфикс Output. Поэтому записываем минус в карму тех.писательницы и проверяем все четыре вывода.  Для проверки фикса на Data Output создаём таблицу с полем TIMESTAMP WITH TIME ZONE, но данные придётся добавить в неё вручную, так как SmartDataset всё ещё не позволяет редактировать данные такого типа. Либо берём из документации Oracle пример "SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00', 'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York') AT TIME ZONE 'America/Los_Angeles' "West Coast Time" FROM DUAL;" и на его основе выполняем запрос в закладки Data Output и SQL Output, pl/sql блок с обращением к dbms-пакету, а через html-редактор создаём процедуру с выводом в HTML Output закладку. Результаты тестов показали идентичность отображения в предыдущем и текущем билдах. Из чего заключаю, что либо этот пункт RNs - приписка, либо тех.писательнице стоило более полно и понятно описать фикс. Полагаю, второй вариант побудил её использовать термин correctly без аппеляции к каким-либо правилам. Фикс ничего не получает. А билд теряет балл за проблему с полем в SmartDataset.
⦁ The application no longer hangs after the replacement of multiple text occurrences.
Приложение больше не виснет после замены множественных текстовых вхождений.
Стоит пояснить, что речь идёт о поиске и замене в тексте, а значит пункт RNs по ошибке попал не в блок любого текстового редактора или поиска по тексту. Для теста открываем текстовый файл побольше размеров в SQL Editor или в Stored Program Editor. Содержимое файла может не быть SQL, поскольку выполнение или компиляция нас не интересует. Предварительно в редакторах подправьте настройки так, чтобы содержимое файла не перезаписалось при закрытии окна или закладки. Вполне удобно в таком случае взять скрипт на вставку нескольких тысяч строк в таблицу и запустить переименование всех названий схемы на другую. В предыдущем билде диалог процесса замены всех найденных сочетаний не позволял параллельно работать в остальных окнах приложения, но в текущем билде изменение таково, что окошко процесса совсем исчезает, позволяя полноценно работать в других окнах. Это явно не исправление бага, а улучшение интерфейса, но слегка не доработанное из-за невозможности следить или прервать процесс массовой замены. Даю балл полезному новшеству, но снимаю -0.2 за недостатки.  
Object Navigator +0+0=0 из 2 возможных и -2 за баг
⦁ Parent nodes are now automatically refreshed once a new object is created.
Родительские ноды теперь автоматически обновляются при создании нового объекта.
У нод верхнего уровня существует два индикатора, меняющихся при добавлении объектов внутрь: количество и наличие символа "+". Их изменением управляет опция "Preferences / General / Object Navigator / Refresh tree on object change". Изменять или создавать объект можно через мастер объекта или в редакторах кода (SQL Editor, Stored Program Editor). К большому сожалению, тех.писательница не уточнила для какого уровня и типа данных сделан фикс. В число верхнеуровневых нод входит не только нода коннекта, моей схемы, всех схем, несхемных объектов и прочие. Также верхнеуровневыми считаются подпапки с подобъектами параметров редактируемого объекта, например, папка колонок или триггеров для таблицы. Также нет уточнения по поводу типа объекта и статуса папки (пустая или есть хоть один подобъект, свёрнутая или развёрнутая). Так что придётся проверять всё, да ещё в множестве сочетаний. Минимально таблица может выглядеть так:

	создан объект в мастере	создан объект в SQL Editor	создан объект в Stored Program Editor
включена опция Preferences / General / Object Navigator / Refresh tree on object change
выключена опция Preferences / General / Object Navigator / Refresh tree on object change
создаётся первый объект (нода пустая)
создаётся последующий объект (нода не пустая)
нода не разворачивалась
нода раскрыта
моя схема
все схемы
системный объект
папка схемных объектов
подпапка схемного объекта

Для пары наугад выбранных типов объектов все тесты не показали никакой разницы, поэтому пункт RNs выкидывается в ранг приписок, а билд недополучает балл.
⦁ The reset action is no longer available for collections.
Операция восстановления больше не доступна для коллекций.
В дереве объектов коллекция - это объектный тип (в документации Oracle он называется Standalone varying array (varray) type). Они расположены в отдельной подпапке у Types. Операция восстановления - это возврат к версии объекта эдишена. Для лучшего понимания изучите Editions, как объект базы данных и команду Alter Type с параметром Reset. А по-минимуму для теста достаточно иметь хоть один объект коллекцию и раскрыть контекстное меню для него в навигаторе объектов. К сожалению, до сих пор невозможно создать объект-коллекцию ни через мастер (в 5-й версии SD он исчез), ни через Stored Program Editor (в нём открываются существующие коллекции, вместо мастера). Так что создайте коллекции через SQL Editor по скриптам из документации базы. И вы убедитесь, что восстановление разрешено для коллекций. Кстати, в документации Oracle нет ограничений на коллекции, поэтому этот пункт - глупая и ненужная приписка. Балл не могу добавить, а вот снять пару за долговечную проблему с мастером коллекций и введение в заблуждение об объектах базы стоит.
Dataset/Datagrid +1 за фикс, -0.3 за недоделки
⦁ The “ORA-01480: trailing null missing from STR bind value” no longer occurs on trying to commit a table  with over 500 characters in the field.
Ошибка предшествующих пробелов у символьных переменных больше не случается при попытке сохранить данные таблицы с более 500 символами в одном поле.
К сожалению, не упомянут тип поля, поэтому проверять придётся таблицу со всевозможными символьными полями, длина которых может быть более 500 символов. Создавая таблицы для тестов не забудьте ограничение на сочетание полей разных типов в одной таблице. Сохранять будем значения с пробелами в начале, конце и середине текста, текст из пробелов и пустой. Типы полей для проверки: varchar2 byte, varchar2 char, char byte, char char, long, clob, nclob, nvarchar2, nchar. Можно также расширить список типов за счёт ANSI и User Defined. Но фактически достаточно иметь таблицу с полем varchar2(4000). Описанная ошибка больше не случается, но текстовый редактор не обрезает слишком большие значения, а база ругается "ora-01461: can bind a LONG value only for insert into a LONG column", не смотря на то, что текст в редакторе обрезается. Встаёт вопрос: на каком этапе (закрытие редактора, вставка из буфера, ручной ввод, post in visible grid или commit  в базу) и кто (приложение или база) должен мониторить и подправлять предлагаемый объём данных к имеющимся возможностям для хранения? За исполнение, соответствующее описанию, балл дам, но за неполноценность разработки сниму -0.3 балла.
Database Connection Window 0.5 из 1 возможного
⦁ Oracle homes changed for the database connection are now saved and restored correctly after restarting the application.
Оракловый хоум, изменённый при очередном коннекте к базе, сохраняется и восстанавливается при следующем запуске приложения.
Для теста нужно иметь проинсталированными хотя бы два клиента разных версий (не забудьте про дозволенное сочетание версий клиента и базы) или типов (полный или облегчённый). Одна сессия приложения разрешает только одного клиента для всех баз, поэтому термин changed имеет двоякий смысл: либо вы вручную выбирали клиента, либо приложение автоматически сменило клиента для второго и последующих подключений. Стоит ещё вспомнить функционал окна подключения: строки считаются разными, если отличаются имена пользователей или баз, тип подключения (нормальный или администратор). Минимальный приёмочный тест: открываем предыдущий билд, подключаемся к одной схеме с клиентом_1, отключаем коннект, подключаемся к одной схеме с клиентом_2, закрываем приложение, открываем приложение и убеждаемся, что в списке запомнен коннект с клиентом_1. Теже самые шаги в текущем билде дают запомненный коннект с клиентом_2. Если проводить расширенное тестирование для автосмены клиента приложением, то результат будет отрицательным, то есть описанный фикс касается только ручной смены клиента. Поэтому слово correctly, использованное в описании фикса, не приемлемо. Когда появился баг - не знаю, но в ранних версиях всем последующим коннектам клиент менялся автоматически. Поэтому за фикс могу дать лишь полбалла.
Table Wizard +0.5+1=1.5 из 2 возможных
⦁ An access violation error no longer occurs on trying to truncate a selected partition.
AV-ошибка больше не случается при попытке очистить выбранную партицию.
Перед тестом стоит изучить команду Alter Table, в частности её параметр truncate partition. Но поскольку тех.писательница проявила неуважение к пользователям и не пояснила, что именно было багом, и что конкретно изменено, почему пункт в группе мастера таблицы, а не навигатора объектов или главного меню (там тоже доступна команда очистки), то сниму несколько долей балла. Говоря, что исправлена av-ошибка, тестировщик или программист ленится актуализировать баг для выяснения его причины и возможных улучшений продукта. В процессе моего тестирования выяснилось, что баг появился в SD 5, а исправление в текущем билде внесло регрессию: если вы подключились к базе с подтверждением DDL команд, то диалог предупреждения появляется при очистке партиции только из главного меню или контекстного меню навигатора объектов, а мастер таблицы лишился подтверждения на выполнение DDL команд. По совокупности оплошностей фикс получает лишь полбалла.
⦁ On creating a new table, the table name is now immediately shown in the window title once the “Object Name” filed is filled in.
При создании новой таблицы её имя сразу показывается в заголовке окна при вводе символов в поле имени объекта.
Сомнительно, что пункт RNs в блоке исправленных багов, так как его описание более похоже на улучшение интерфейса. При воспроизведении не забудьте режим максимизации окна, когда заголовок мастера таблицы и заголовок главного окна приложения являются одним и тем же элементом интерфейса. Изменение сделано и получает балл. За регрессию о сопутствующем баге при создании таблицы уже был снят балл ранее.
Code Folding +1+0=1  из 2 возможных
⦁ Fixed code folding for the lines with parentheses.
Исправлено вложение кода для строк со скобками.
Напомню, что в некоторых редакторах кода на левом поле имеются интерактивные линии, отображающие вложенность кода по служебным словам и скобкам. Не знаю, для каких конкретно случаев скобки не учитывались в структуре, да и тех.писательница не удосужилась это пояснить. Поэтому берём первый попавшийся код (мне подвернулся объектный тип с телом) и смотрим его в Stored Program Editor, как наиболее часто используемом редакторе кода. Да, линии стали прорисовываться для большего числа случаев. В моём случае, если скрипт состоит из спецификации и тела, то линии структуры имеются и в прошлом, и в текущем билдах. А если скрипт состоит только из спецификации типа, то линии структуры прорисовываются для круглых скобок только в текущем билде. С большой натяжкой даю балл исправлению, которое вполне можно было разместить в группе улучшений.
⦁ Fixed the highlighting when statements are collapsed.
Исправлена подсветка для свёрнутых выражений.
Скорее всего термин подсветки относится к линиям структуры кода при нахождении активного курсора в пределах блока. Но речь может быть и о подсветке служебных слов либо выбранность курсором или поиском нескольких символов (строк). Посмотрим изменения и позже решим, о чём конкретно хотела уведомить пользователей тех.писательница. Для теста открываем одинаковый текст в прошлом и текущем билдах, сворачиваем одни и теже ноды и пытаемся найти отличия при перемещении курсора. Мне абсолютно не удалось приметить хоть каких-то отличий. Поэтому не дам ни балла.
Code Insight +1 из 1 возможного
⦁ Ctrl+click now works correctly for all object names.
Горячая клавиша для открытия объекта теперь работает корректно для всех имён объектов.
Не могу согласиться, что функционал открытия мастера объекта или локализации курсора в коде по спец.клику на его имени является частью подсказчика кода, а не фичей редактора или навигатора объектов. К тому же, описание фикса содержит ещё пару промахов. Что имелось ввиду под определением всех имён объектов? Мне известны следующие случаи: имя латиницей в нижнем/верхнем/смешанном регистре, имя латиницей в двойных кавычках, латиницей в нижнем/верхнем/смешанном регистре в двойных кавычках, на региональном языке в двойных кавычках и без кавычек (только utf-базы поддерживают), имена объектов с префиксом схемы через точку, имя подпрограммы с префиксом родительского объекта. Поэтому проверять пришлось все случаи, из которых исправленными оказались имена в двойных кавычках и на региональном языке. Фикс получает балл, а тех.писательница моё и обще-пользовательское "фи" в карму из-за лишних проверок.
Find and Replace +0.8+1=1.8  из 2 возможных
⦁ Fixed the look-and-feel of the dialog box that appears during the text replacement process.
Исправлен внешний вид диалога о процессе замены в тексте.
Поскольку нет уточнения о какой замене речь (единичная или множественная, прерывания для подтверждения или градусник без остановки), топроверяем все четыре варианта. При чём один уже сделан в рамках одного из предыдущих тестов про зависание. И он же единственный дал мелкое отличие в позиционировании окна с прогрессом замены: в текущем билде окошко центрируется относительно редактора, а было в прошлом билде прилеплено к левому верхнему углу главного окна приложения. Иных внешних отличий нет. Поэтому из-за неверного использования термина "внешний вид" вместо "позиционирование", а также из-за размещения улучшения интерфейса в группе исправленных багов даю 0.8 балла.
⦁ Clicking “Cancel” now breaks the text replacement process.
Нажатие кнопки Cancel теперь прерывает процесс замены в тексте.
По-моему, стоило объединить все четыре изменения заменителя текста в один пункт по совершенствованию диалога о процессе массовой замены. Потому что этот пункт RNs лишь дублирует проведённый тест и работоспособность кнопки при огромных объёмах замены. Уж не буду и здесь снимать балл за невозможность прервать процесс замены после временной активации иных рабочих окон, а просто пожалею группу разработки и дам балл за фикс.
Find Text / Find in Files 0.8 из 1 возможного
⦁ The progress dialog box that appears once the text replacement takes more than 5 seconds is now shown at the top of the main window, not in the SQL Editor workspace.
Окно процесса, появляющееся спустя 5 секунд с начала замены в текстах и файлах, теперь показывается в верхнем углу главного окна, а не в рабочей области редактора.
Фикс сделан, но совершенно наоборот описанному: процессинговое окно теперь легче обнаружить в рамках редактора, нежели оно западало за верхний край монитора. К тому же, исправление касается не только окна SQL Editor, но и всех других, поддерживающих массовую замену текста. Ещё одно заблуждение - помещение фикса в рамках модуля по поиску в файлах, поскольку он работает со своим текстовым редактором, а результат и процесс отображаются не в диалоге, а в приклеенной к низу главного окна специальной панельке. Так что из-за промашек тех.писательницы даю лишь 0.8 балла.
System Information 0 из 1 возможного
⦁ TNS_ADMIN registry values are now included in the system information.
Значения реестра TNS_ADMIN теперь включены в системную информацию.
Этот пункт RNs никак не соответствует терминологии багов, ему явное место в новшествах. При чём эти добавления (переменная окружения TNS_ADMIN, список имён баз из файла tnsnames.ora) были сделаны очень давно, но втихоря (тогда срочно нужна была инфа от юзера, а GDPR ещё не поддерживали). Полагаю, поскольку переменные окружения могут быть уровня системы и пользователя, то о значениях сказано в множественном числе. Либо тех.писательница перепутала термины "значение переменной окружения", "содержимое файла tnsnames.ora" и настройка пути к базам через "строковый параметр реестра". Или же последние версии Oracle кроме ветки "Software / Oracle" работают с иными параметрами реестра? Тогда стоило уточнить баг номером версии базы. Для инфы из реестра в файле с системной информацией продуктов выделен блок "OCI Information / Oracle Registry Data", куда попадает всё содержимое упомянутой ветки, а значит и параметр TNS_ADMIN. У меня так и не получилось выяснить, что же конкретно изменилось в содержимом этого файла, который собирается из множества источников и показывается через главное меню "Help / System Information". Также эти все данные передаются в техподдержку ConquestSS без архивации и шифровки вместе с OSD-сообщением. Видимо у разработчиков проявилась совесть или того требует GDPR, поэтому пункт RNs заявил об изменениях спустя несколько лет. Балл за исполнение дать никак не могу, при чём не столько из-за его невоспроизведения, сколько из-за запутанного описания.

Ещё пара багов, до сих пор мозолящие глаза при инсталяции. За каждый из них снимаю по баллу из-за их долговечности и введении пользователя в заблуждение.
Инсталлятор продукта испортился давно, с одного из билдов версии SD 5.0 тем, что список инсталлированных предыдущих версий опустел и определяет наличие только версии 4.7.2.
Файл ReadMe.HTML имеет одну недоправленную ссылку "top..", взятую из аналогичного файла для CDB.

Линк на внутреннюю папку разработчика

Итоги по билду: набрано 3.6+13.2=16.8 баллов из 8+22=30 возможных, значит билд готов на 56%, выявленные баги снимают -2-8-2=-12 баллов.