За кем пойдёшь?

При прослушивании доклада "Все, что тимлид должен знать о найме и увольнении" Степана Овчинникова меня затронуло нижеследующее.
"Тимлидами не рождаются, тимлидами становятся". В CSS техническим директором стал первый программист направления, а продуктовые лиды были им назначены после полугода работы некоторых набранных разработчиков, при этом команду тестировщиков оставил обезглавленной. Полагаю, причина была чисто этническая: шеф - привыкший к домашнему "гарему" татарин, а все тестировщицы женского пола. Якобы не желал насаждать иерархию, в команде все должны быть равны. Противоречие на противоречии. В итоге, и сам не знал, как правильно управлять тестированием, и никому другому не давал проявить мастерство.
Становление руководителем из программиста может быть благоприятным процессом, если он в силу своих возможностей дообучиться всё же их использует. Но если это закоренелый "царедворец" или того хуже азиат среди европейцев, то ничего, кроме построения покорной свиты, от него ждать не приходится, особенно демократии.
Особенного внимания заслуживают составляющие управленца: люди + процессы + производство. В этой триаде связующим звеном является "процессы". триггером для которых и является руководитель. При этом объём информированности самого лида и его подопечных регулируется теми самыми процессами. И если команда организована по принципам, описанным в докладе "Полная прозрачность в компании" Михаила Самарина, то шеф сам себе может облегчить заботы.
На собеседования кандидатов шеф CSS звал тимлидов только для того, чтоб они давали техническую оценку тестовой работы. Запрещая задавать вопросы о личностных качествах, PM сам себя обкрадывал и не давал выяснить "у порога" потайные стороны личности. А позже сваливал вину на сторожил за то, что на приёме не разглядели нежелательных элементов. Если же мне удавалось прорвать этот барьер, то мои рекомендации полностью были окуплены.
Ни на одном из собеседований, которые мне довелось подслушать, программистов не спрашивали о мотивах прихода в CSS, поскольку у руководства единый ярлык на всех - желание денег. Но через месяц общения мне раскрывались иные причины: кому-то не хватало коллектива или опыта, другим важно было применить знания на практике. И поскольку это не было в приоритете у начальника, то спрос с программистов постепенно становился не адекватен ожиданиям. В таких случаях мои конкретизирующие задачу разъяснения обеим сторонам рассматривались как "подсиживание руководства". Хотя, по факту - мной выполнялась работа фасилитатора и, в силу неравнодушия к судьбе проекта, приходилось забирать на свои плечи (читай "пятую точку") функции лида. Да, со временем это переросло в "серого кардинала", и я этот факт не скрываю. Но это был вынужденный шаг.
Последующее мотивирование на рабочую волну никак не было замечено в руководстве CSS. Инструменты брались только бесплатные и то, надо было предоставить существенные причины, чтобы их развернули на компах. А уж о покупке единственного (никакие иные не могли работать с самописным интерфейсом) в мире средства автоматизации для тестировщиков разговоры заканчивались отказом более 10 лет. Так тайком и роль завхоза-devops-а лежала на мне: кому дебаггер, кому скринсейвер подкинешь, а с первой тестировщицей на триальной версии урывками писали и запускали автотесты.
Результаты работы не могли мотивировать, потому что ограничивались лишь еженедельными "пузомерками" по количеству закрытых и запланированных задач. Даже на демках никто из разработчиков не мог толково пояснить, за что им можно гордиться, потому что главным было не личное достижение каждого, а только общепродуктовый рост. Очень сильно меня удивила приписка в резюме шефа о его применении мотиваторов. Если это и было, то только к одному его любимчику, с которым он ездил на всякие конференции, а на нас "смертных" всегда не было денег у фин-директора. На развитие членов команды PM-у всегда было наплевать, поэтому самостоятельно приходилось проходить курсы и слёты профессионалов за собственные средства в отгульные дни-часы.
К сожалению, Степан пропустил пункт построения команды или сплочения коллектива и сразу перешёл к сохранению людей. Но наблюдение и своевременная корректировка процессов вполне могла бы помочь вам, если вы начинающий тимлид. А вот конкретный пример про короткое тесное общение весьма показателен. Шеф CSS подменял его ежедневным стендапом, где вся команда была на виду. Но это иной уровень, хоть и регулярный, и результат такого официоза играл не в его пользу. Многие вещи мне приходилось допояснять в приватных чатах. Опять же, выполнять роль руководителя для сдерживания коллективности.
Вторым шагом по сохранению людей Степан считает повышение планки.  Он прав. Но мои вопросы к расслабившейся тестировщице были восприняты в штыки, а шеф усугубил конфликт вместо поиска причин. Он сам никак не наблюдал за нами, поэтому ему было наплевать на наши темпы. В итоге, долг задач стал копиться и дошло до того, что РМ в один день сам без разбора убрал (то закрывал скопом, то удалял без разбору) из работы значительное количество задач. Правда потом их пришлось восстанавливать (опять же) мне, поскольку это "не царское дело". А, казалось бы, обрати он внимание, что скорость снизилась, дай ей передышку или новое что, скорее всего и не было бы последующих проблем (конфликт отношений, долг багов, дополнительная занятость по восстановлению невыполненного).
Ещё одним мотиватором заявлен профессиональный рост. Среди тестировщиков это никак не поощрялось, а наоборот пресекалось. Мои цитаты и ссылки на статьи, доклады были запрещены шефом, который посчитал это отвлечением от работы. Его слова: "Не надо здесь устраивать избу-читальню. Мы занимаемся работой.". Поэтому пришлось сделать закрытый канал в чате, только для узкого круга тестировщиков, где давались своевременные подсказки. А в среде разработчиков образование сначала пытались нарастить через индивидуальное code review (тимлиды и шеф заслушивали по отдельности каждого программиста, отчитывающегося за месячный код). Мне приходилось быть невольным слушателем таких "бесед". И когда лиды стали повторяться с советами для каждого, то наконец-то прислушались к моей идее объединять всех программистов в один час, где не только "чистили" код, но и обменивались глубиной познаний кодирования. Из пугающего "вызова на ковёр" проверка кода превратилась в познавательный диалог.
Поскольку, как уже упоминалось, шеф никогда не вёл беседы тет-а-тет, то мало о каких личных делах он был в курсе. В итоге, увольнял некоторых по причине "не оправдал ожидания". А матрицу компетенций попросил составить лишь однажды (без общекомандных оценок), когда CEO надумал расширять линейку продуктов. Тяга к знаниям никак не поощрялась, может поэтому все сборы команды ограничивались лишь распитием спиртного и разговорами на общие темы (табу было на рабочие и политические темы). Да, команду удалёнщиков сложно собрать, но раз в полгода это случалось. Два раза в месяц бывали ретроспективы, но и они ограничивались демагогией "как жить дальше".
Очень правильно Степан затронул проблему "неадекват". Подпишусь под всеми его шагами по выявлению и устранению подобного.
Отличное высказывание: "Принимая человека на работу сразу знай, за что его уволишь." Так и мы за любой товар платим - он стоит этой цены на рассчитываемый мной срок службы. Но вот слова шефа CSS, вернувшегося после временного кризиса компании, меня ошарашили: "Я научился увольнять. Мне это не сложно теперь." Он полгода поруководил проектом на стороне, новыми ему людьми, хвастал, что успел обновить почти всю команду. И этот ужас от высказанного продолжал наращивать негатив при каждом последующем увольнении у нас. Текучка в CSS после кризиса подпрыгнула в несколько раз (за первые десять лет выросли до 8 членов, но перед кризисом уволили шестерых; а за три года после кризиса состав обновлялся 4 раза, и после меня через год команду разогнали до исходных двух с половиной проггеров). А по поводу рассуждений Степана о правиле "на работе мы работаем" у меня когнитивный диссонанс с поведением шефа CSS и его любимчиком. Дело в том, что шефа по непонятной мне причине раздражало, что я постоянно остаюсь в офисе и доделываю ежедневку свою (оформить найденные баги всегда мешают неожиданные обсуждения). А вот многочасовые словоблудства любимчика о гаджетах, никоим образом не относящихся к предмету нашей разработки, он никогда не прерывал, а наоборот всецело поддерживал. Аналогичное непонимание всей команды вызывали увольнения трёх разработчиков, когда даже на наш вопрос: "Что такое они сделали не так, чтоб нам не повторить чужие ошибки" шеф отнекивался, и лишь твердил, как попугай: "Он не справился с возложенными на него надеждами. Я так решил. Вопрос закрыт.". От подобного "избавления от слабых" команда не становилась сильнее. Естественно, процесс расставания с этими выгнанными был мгновенным, и вопреки советам Степана логины аннулировались вечером перед утренним объявлением. В случае же со мной офисным пришлось терпеть мою жажду приносить пользу ещё пару недель - КЗоТ про сокращение обошли доп.соглашением. Местных бездельников, судачащих о домашних делах, коробила моя усидчивость при изучении проф.литературы и они выпроводили меня досиживать срок по сокращению штата дома. Полагаю, что истинной причиной стала моя докладная фин.директору о тех бесчинствах шефа, которыми он не давал команде работать в спокойной обстановке, о необходимости повышения его знаний и умений в области управления людьми. Как бы ни было прискорбно, но по всем видам руководителя из доклада "Buzzword Driven Management" Сергея Атрощенко у меня до сих пор перед глазами факты (чайка, хамелеон, кукушка и так далее) поведения вышеописанного шефа CSS.
А за каким лидом движетесь вы? Куда он вас приведёт?

Токсичный тестер

Кислотность, как качество тестировщика
Эпитет "токсичный" применяется к человеку не так давно, поэтому не всем ещё понятно его значение. И зачастую им подменяют ранее известные "упорный", "пристрастный", а то и утрируют смысл "заботливости". На сколько мне известно, применять определение кислотности начали молодые люди применительно к своим родителям или знакомым, которые постоянно пытались оградить неразумных от ошибочных шагов. Детям казалось, что им навязывают поведение скромных, ограничивают бесшабашность. Конечно же постоянная опека им надоела и взрослых стали называть "кислотными", отравляющими подросткам жизнь. Также, не желая разбираться в истоках проблемы, которая на самом деле крылась в самих "якобы не-кислотных", более сообразительных приятелей относили к изгоям. А ведь эти, названные "кислотными", на самом деле идут более верным путём.
В качестве примера могу предложить отрывок из шоу "Уральских пельменей", когда в баре собрались друзья вечером пятницы. А герой Мясникова им уже заказал и столик, и питьё с закуской. Благодаря тому же wi-fi-ю в момент разрешил споры, на что приятели и обиделись. Соглашусь, друзья собираются вечером в пятницу пообщаться. Но ведь Мясников предупредил ссоры своими зачитываниями неопровержимых фактов. Почему же его относят к "кислотным"? Да потому, что у них изначально не было тяги к спокойствию. Как же пятница может закончиться без мордобоя?! Более привычный финал для пахавших всю неделю умом мужиков. Мясников не дал случиться проблеме, уберёг от разногласий, а его отвергают. В ком корень зла? Угу, в тех, кто не желает думать, кто "а-ля на стиле" с нацепленной улыбкой.
Это довольно показательная миниатюра для понимания "войны" между командой разработки и тестировщиками. Мы тоже, как Мясников, знаем и предупреждаем от неверных шагов. А нас в конце концов обзывают "кислотными". Так что не расстраивайтесь, а гордитесь таким званием. По моему мнению, это более красочно описывает наши профессиональные качества. Если в вас недостаточно кислотности, то важные баги могут просочиться в публикуемый билд. Хотите добиться чистоты продукта, наращивайте в себе упорство и уверенность в знаниях. Пусть наших вопросов жуть, но в этом и состоит наша круть!  

Перегрузки

После прочтения статьи "Как спроектировать нагрузочный тест" Кристины Джеквони (Kristin Jackvony) в переводе Ольги Алифановой возникли нижеследующие дополнения.
* Для тестирования нагрузки базы в первую очередь обращаюсь к Explain Plan.
* Далее смотрим на наличие полезных индексов. Очень познавательный рассказ про индексирование есть в "Вся правда об индексах в PostgreSQL" от Олега Бартунова и Александра Короткова.
* Не менее важно использование кэширования. А в области данных вам в помощь станут CRUD матрицы.
* Если можете проверять белый ящик, то обращайте внимание на отсутствие излишних перерисовок интерфейса (Flowchart и Call Tree диаграммы покажут зацикленность и бесполезные повторы).

Foreign or local

Прочтение статьи "Тестирование локализации" Кристины Джеквони (Kristin Jackvony) в переводе Ольги Алифановой всколыхнуло во мне нижеследующие мысли.
* Благодарность автору за список, по которому можно автоматически строить тестирование приложения перед передачей пользователям из разных стран.
* Из личного опыта и по рекомендации программиста: если размер формы не критичен, то самое удобное расположение элементов - в один столбец, а не колоноками. Это позволяет не заморачиваться о длине подписей, что может быть критично на разных языках при масштабировании элементов интерфейса (например, ширина кнопки) по длине текста языка локализации.
** Особого внимания заслуживает свойство wrapped (перенос на следующую строку) у каждой подписи.
* Иметь все переменные в одном юните со всеми используемыми переводами - удобство для техписателя при проверке грамматики. Или же для всех подписей в продукте использовать внутреннюю базу (xml, sqlite), где хранить как основной язык приложения, так и все переводы. Такая структура приложения упрощает программирование и поддержку.
*Для лёгкого включения в тестирование локализации путешествуйте по разным странам, узнавайте их уклад и пристрастия напрямую, воспитывайте в себе толерантность. Понимание жизни других помогает в тест-дизайне локализации.

ТО о SD 5.1.1.160

Очередной build#160 продукта SQLDetective (SD) 5.1.1 выложен 18 июля 2019г. Пройдёмся по Release Notes (RNs).

IMPROVEMENTS  (85+0+80)/3=55%   минус (2,6+1+0,2)=3,8 баллов

Code Explorer (0,9+0,8+0,9+0,8)/4 = 85% готовности, минус (1+0,3+0,3+0,5+0,5)/5=2,6 пунктов за баги
• By default, the Code Explorer panel is now always open in the SQL Editor and Stored Program Editor.
По-умолчанию панель Code Explorer теперь всегда открыта в редакторах SQL Editor и Stored Program Editor.
В надежде на лучшее будем полагать, что наличие раскрытой панели Code Explorer является дефолтным только для первого открытия редакторов, так как в SQL Editor она не всегда нужна, например, DML запросы в этом дереве показаны лишь одной нодой, поэтому ничем не упрощают работу программисту. Постараемся в тестах не путать понятия "открыт" и "развёрнут", поскольку первое управляется кнопкой на тулбаре или опцией в контекстном меню, а второе - сплиттером открытого дерева.
По результатам общего теста (смотри ниже) для всех новшеств блока Code Explorer текущий пункт получает 0,9 балла, потому что кнопка тулбара показывает верно состояние дерева только в SQL Editor.
• It is now possible to toggle the visibility of the Code Explorer panel for each module separately.
Теперь возможно переключать видимость панели Code Explorer  для каждого модуля раздельно.
Напомню, что панель Code Explorer предназначена для визуализации PL/SQL кода, поэтому её наличие ожидаемо в следующих модулях и окнах: Stored Program Editor / main editor, SQL Editor / code editor, Trigger Wizard / Trigger Body / code editor, Job Wizard / General / What Execute, Sched.Job Wizard / Program / Inline Program / PL/SQL Block / code editor, Sched.Program Wizard / General / PL/SQL Block. Причём в Stored Program Editor и Trigger Wizard дерево существовало давно, а в SQL Editor добавили в SD 5.0, но из Trigger Wizard дерево как бы пропало в SD 5.1, поскольку апдейт не включает новую настройку (чуть позже опишу баг).
В целом новшество реализовано, но описание не конкретизировало модули, поэтому даю 0,8 балла.
• The “Code Explorer” page was removed from Preferences.
Страница "Code Explorer" удалена из настроек приложения.
Странно, что этот пункт не в отдельном блоке Removes и не в блоке компонента Preferences.
Проверка этого новшества заключается в трёх тестах: 1) функциональный - визуально проверить отсутствие страницы в окне Preferences; 2) недоделки (функционально-регрессионный) - в окне поиска Preferences не должны появляться убранные элементы; 3) регрессионный - восстановление (загрузка из файла) настроек приложения из предыдущей версии не меняет функционал. Функционально-юзабилити тест на замещение необходимо было бы проводить при отсутствии следующего пункта RNs.
Тест новшества положителен, но за неточности техписателя даю 0,9 балла.
• Added the “Toggle Code Explorer” command to the SQL Editor, Stored Program Editor, and Trigger Wizard pop-up menus.
Контекстное меню редакторов в окнах SQL Editor, Stored Program Editor и Trigger Wizard дополнено пунктом "Toggle Code Explorer".
Техписателю стоило уточнить, что пункт добавлен в блок Tools, а также функционал продублирован в IDic.
Тест новшества положителен, но за неточности техписателя даю 0,8 балла.

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

Для просмотра кликните по элементу

Если вы заметили, то этой матрицей мы одновременно проверяем все вышеописанные новшества. Проверки состояния пункта Tools/Togle Code Explorer в контекстном меню, состояния кнопки переключения дерева на тулбаре, состояния дерева expanded-split также можно сделать параллельно, но для полной детализации стоит расширить матрицу соответствующими строками.
Примечания. Первое открытие приложения "на чистую" всегда сопровождается автоматическим открытием SQL Editor, поэтому влияние модулей друг на друга проверяем полностью, а не опираемся на первый кейс. Поскольку SD позволительно запустить множество раз на одной машине, а некоторые настройки приложения временно работают из оперативки, то не лишним будет тест в трёх параллельных сессиях приложения (не подключение к базе, а отдельные инстансы интерфейса).
Тесты дали в большинстве положительные результаты. Выявленные баги:
1. Опцию переключения дерева кода в Trigger Wizard перенесли в иное место хранения (внутрипрограммные заморочки), но не выполнили перенос значения опции при апдейте приложения. В результате - регрессионный баг функционала - старые пользователи "потеряли" дерево кода в Trigger Wizard. Почему не включили для новых пользователей? Первая гипотеза - забыли, вторая - посчитали излишним, третья - посчитали интерфейс и без того перегруженным. Минус 1 балл.
2. В редакторах PL/SQL кода таких окон как Job Wizard, Sched.Job Wizard, Sched.Program Wizard нет дерева кода. Если бы описание новшества было конкретизировано по модулям, то это не считалось бы багом, а предложением. Минус 0,3 балла.
3. Не упомянуты в RNs изменения экшена и его кнопки в рамках IDic. Баг малой критичности из области документирования. Минус 0,3 балла.
4. Состояние открытости дерева в Stored Program Editor и Trigger Wizard не совпадает с состоянием кнопки переключения на тулбаре. Примечание: этот же экшен корректно отображается в контекстном меню. Интерфейсный баг не высокой критичности. Минус 0,5 балла.
5. В мастере триггера выявлен баг, связанный с размерами окна. При переоткрытии окна не восстанавливается высота. К тому же, предлагаемая высота чуть больше рабочего пространства, что вынуждает приложение добавлять вертикальный скроллер. Минус 0,5 балла.

Text Editor -100% антивыполненности
• When there is no text occurrence of the searched text in the code, the user is no longer prompted to start searching from the top.
Юзеру больше не предлагают начать поиск с начала, если в тексте закончились места с искомым.
Во-первых, в SD существует два типа редакторов текста: SynEdit, встроенный в модули для редактирования кода, и стандартный редактор текста, используемый самостоятельным окном для показа, например, значений символьных полей. Во-вторых, в обоих поиск запускается по стандартному экшену (Ctrl+F, кнопка на тулбаре, пункт в контекстном меню) и должен итерационно продолжаться по тоже стандартному экшену (F3, кнопка на тулбаре, пункт в контекстном меню).
Тест на продолжение и окончание поиска показал, что в SynEdit функционал поиска остался неизменно удобным: продолжение поиска работает и, при достижении конца/начала текста, предлагает новую итерацию. А вот в простом редакторе текста (окно с результатами Schema Extractor или дополнительное окно для просмотра/редактирования varchar-поля) не то что выполнение следующей итерации с начала/конца текста перестало быть возможным, а даже обычное продолжение по F3 (нет кнопки Find Next на тулбаре и пункта в контекстном меню).
Мало того, что описание новшества не соответствует реализации, так ещё это можно назвать анти-юзабилити. Поэтому минус 1 балл.
В рамках комплексного тестирования выявлено западание окна с результатами множественных замен в тексте.

Для просмотра кликните по элементу

Online Support Desk (=OSD) 80% готовности
• Added the ability to reply to OSD messages from the “OSD Preview” window.
Добавлена возможность отвечать на OSD сообщение из режима предварительного просмотра.
Вспомним, что экшен Reply давно появился в списках сообщений. Но почему-то хотя бы в рамках новшества не убрали лишние пункты из меню для отправленных и удалённых, поскольку для черновиков пункта Reply нет в контекстном меню.
В режиме просмотра кнопка Reply активна для сообщений типа Received, но странно, что она не гаснет и для просматриваемого нового ответа. Да, для обычных новых сообщений кнопка в неактивном режиме, но ведь ответ - это тоже новое сообщение. Значит программист на каком-то этапе не допереключил флаг с Received на New, поскольку ещё раз ответ уже не генерится.
С учётом недоделок даю 0,8 балла.
В рамках комплексного тестирования вылезли следующие юзабилити-баги:
1. Минимальная высота окна такова, что все кнопки управления спрятаны. Для их нажатия приходится скроллить основной экран, что прячет информацию из заголовка сообщения. Моё предложение про необходимость сворачивать блоки существует (если шеф его не удалил) в базе багов очень давно, года с 2015-2016.
2. В форме нового сообщения-ответа (Reply) поле Text имеет два окна: не редактируемая пустая строка и основное окно. Эта пустая строка - лишний элемент, обычно показываемый для авто-формируемых сообщений из EurekaLog. Если её скрыть, то кнопки управления будут хотя бы наполовину видны.

Для просмотра кликните по элементу

BUGS FIXED  (100+0+75+90+50+100)/6=69,16%  минус (1+0,3+1+0,3)=2,6 балла

Code Explorer два бага исправлены на 100%, но за регрессию минус 1 балл
• Toggling the visibility of the Code Explorer panel in the Stored Program Editor no longer affects the SQL Editor and Trigger Wizard.
Переключение видимости панели дерева кода в Stored Program Editor больше не влияет на SQL Editor и Trigger Wizard.
Поясню. Раньше (до SD#5) Code Explorer был только в Stored Program Editor и Trigger Wizard, его видимость определялась по своим настройкам в каждом окне, но для Stored Program Editor был дубликат опции в настройках приложения. Когда в предыдущей версии Code Explorer добавили в SQL Editor, то его видимостью (а заодно и фильтрацией) заведовала общая опция с Stored Program Editor. Теперь, поскольку у каждого модуля есть самостоятельная опция переключения видимости, изменение её значения для одного окна не влияет на остальные два. Тест уже был проведён в рамках вышеописанных новшеств для Code Explorer - это тоже принцип комплексного тестирования, когда одним тестом закрываются и новшества, и баги по одному модулю. Ставлю 1 балл.
• The Code Explorer tree is no longer empty on first opening of the script.
Дерево Code Explorer больше не пустое при первом открытии скрипта.
Этот баг был актуален только для SQL Editor, поскольку для чистой закладки редактора дерево кода даже не подписывалось и воспринималось как лишнее окно. Баг исправлен и заслуживает 1 балл.
Но тест был бы не полным, если бы мы ограничились лишь одним модулем и не проверили пустые окна Stored Program Editor и Trigger Wizard. Открытие пустого окна и новой закладки в Stored Program Editor никакой регрессии не привнесло. А вот открыть новый Trigger Wizard с пустым редактором кода не было возможным в предыдущей версии (шаблон тела триггера вставляется автоматически). Попытки же создать новый триггер без предварительного выбора таблицы/вьювера оказались невозможными. То есть внесён баг регрессии: невозможно открыть мастер триггера для создания нового объекта из главного меню приложения и контекстного меню навигатора объектов без заведомо выбранного родительского объекта. Минус 1 балл.

Schema Compiler не более 0,5 балла
• An access violation error no longer occurs after compilation is completed.
Ошибка доступа больше не случается по окончании компиляции.
В качестве теста выполняем компиляцию схемы в предыдущем билде и текущем. Поскольку у меня не получилось отловить AV ни на особой схеме, ни на нескольких, ни на спец.режиме компиляции в предыдущих билдах, то заключаю, что это не исправление бага, а приписка. И поэтому ставлю 0,5 балла за возможное неполное описание техписателем.

Schema Extractor 90% из-за неполного описания
• The object list in the Schema Extractor is no longer empty.
Список объектов в экстракторе схем больше никогда не пустует.
Поясню: список объектов в Schema Extractor можно увидеть только если включена опция "Schema Extractor / Options / Preview list of objects before extract".  Поскольку она по-умолчанию включена, то для теста экспортируем любую схему в предыдущем билде и текущем. Из чего выяснилось, что раньше выгружались только триггеры, хоть и были выбраны все типы объектов. Так что баг исправлен на 0,9 баллов. Но меня смущает тот факт, что не исправляется не менее важная проблема - скорость, особенно для юзера без DBA привилегий. Schema Extractor работает в полтора раза медленнее Compare Schemas, а обычный юзер в два раза медленнее админского. Также был подмечен баг прятания модульного окна со списком объектов за основное окно приложения, если во время выгрузки переключаться на другие приложения.

Main Window 75% из-за регрессии
• When the “Show active session window only” option is enabled, objects of inactive sessions are no longer shown in the taskbar pop-up menu.
Объекты неактивных сессий больше не показываются в контекстном меню линейки задач при включенной опции "Show active session window only".
Поясню: опция "Show active session window only" переключается в главном меню "View / Active Session" или по кнопке главного тулбара в правом нижнем углу, а контекстным меню для описанного случая считается список не уместившихся кнопок на строке задач. Для теста, кроме включенной опции "Show active session window only" желательно включить опцию "Preferences / General / Task Bar / Dislay captions" и нет смысла включать опцию "Preferences / General / Task Bar / Combine buttons". При такой комбинации настроек надо сделать несколько подключений к базе (одинаковые или разные схемы), в которых открыть много мастеров объекта (любого типа, но проверить и пересечение типов, и наименований). Окна с фичей мультисессии (Stored Program Editor, Schema Extractor и другие) для теста не показательны, но могут дать баги при внутреннем переключении сессий, если это не было проверено при внедрении фич по визуальному разделению сессий и масштабированию панели задач.
В рамках воспроизведения бага на предыдущей версии выяснилось, что панель задач может вообще быть пустой для второго подключения базы. Так что фикс получился более широким, а техписатель коротким описанием принизил масштаб и важность исправления.
По результатам тестов можно отрапортовать о следующих багах:
1. Выполнение Close All для панели задач не учитывает режим показа кнопок только активной сессии. Для меня была неожиданностью пустота taskbar во второй сессии после выполнения Close All в рамках первой при включенной опции "Show active session window only".
2. В подписях кнопок (или хотя бы в хинтах) и пунктов выпадающего списка панели задач не хватает информации о сессии (connection string, color), особенно для окон с поддержкой мультисессионности. Понимаю, что это сложно реализовать для SmartDataset и Stored Program Editor, работающих одновременно с разными сессиями без фильтрации по ним. Но когда в нескольких SQL Editor ведётся работа по отдельным сессиям, то именно подобная подпись смогла бы улучшить интерфейс. На самом деле отсутствие хинтов - это баг регрессии, особенно если выключить опцию "Preferences / General / Task Bar / Dislay captions".
3. Анимация значков не работает в выпадающем списке панели задач. График двигается для модуля DB Monitor и давно ожидается для PL/SQL Profiler на кнопках taskbar. Но когда они в списке невидимых, то иконка модуля только статична.
4. Мультисессионные окна никак не реагируют на переключение между активными сессиями при включенной опции "Show active session window only".
5. Множественное открытие окон SQL Editor и Stored Program Editor для нескольких подключенных сессий в режиме включенной опции "Show active session window only" прячет окно Preferences на моменте его открытия.

Object Wizards 0%
• The “Compress data” check box no longer appears unavailable (grayed out) in the Index Wizard, Materialized View Wizard, Materialized View Log Wizard, Tablespace Wizard.
Чек-бокс "Compress data" больше не рисуется в недоступном режиме в мастерах объектов Индекса, Материализованного Представления, Лога материализованного представления, Табличного Пространства.
Во-первых, ни в одном из мастеров нет опции под названием "Compress data". Во-вторых, аналогично её нет и при выгрузке DDL (как-то промелькнула мысль, что техписательница опечаталась с модулями). В-третьих, в мастере сегмента есть опция компрессии, но это давно комбобокс, а не чек-бокс. В-четвёртых, комбобокс недоступен для изменений при значении Unavailable для компрессии объекта в рамках базы. Из чего заключаю, что этот фикс либо приписка из числа давно неактуальных багов, либо техписательница абсолютно неверно описала фикс. Не могу поставить даже полбалла.

User Wizard 100%
• The “Account Lock” check box no longer appears unavailable (grayed out).
Чек-бокс "Account Lock" больше не рисуется в недоступном режиме.
Стоит отметить, что вместе с опцией "Account lock", возможно в рамках текущего фикса, поправлена и соседняя "Password expire". Так что плюс в карму программиста, но минус в карму техписателя. А фиксу даю 1 балл.


Итого готовность билда: (85+0+80)/3=55% импрувами и (100+0+75+90+50+100)/6=69,16%  багами даёт 62% общей готовности.

ТО о SD 5.1.1.146

Отчёт о тестировании SQLDetective 5.1.1 по Release Notes для билда #146, выпущенного 27 июня 2019 года, с готовностью на 52% (= (14+12)/(21+29) ) и не заявленными 19-ю недоделками.
План тестирования совпадает со списком фиксов от производителя. По каждому пункту произведены смоук-тесты (по мере возможности).
При установке нового минора выясняется, что расширены системные требования до Oracle 19c, о чём ни слова нет в Release Notes.

IMPROVEMENTS
Баллы за реализации ставлю по факту возможности проверки, т.е. не полностью объективно, но за регрессию и недоделки снимаю баллы по минимуму.

Core (3 из 3, -3.5 за недоделки)
• Added the ability to execute an external SQL script file after logon. This behavior can be disabled at “Preferences / Session / Execute the file on logon.”
Переводим и осознаём новшество.
Добавлена возможность выполнения внешних файлов с sql скриптами после коннекта к базе. Поведение может быть отключено в настройках приложения “Preferences / Session / Execute the file on logon”.
Первый затык вызвал перевод фразы "an external SQL script file", в которой явно не хватает предлога перед словом "file". По наименованию пути к опции догадываемся, что под "logon" стоит понимать коннект к базе. Третий вопрос (функционирования опции) к слову "disabled", поскольку вся фраза заставляет напрячься: "Уже есть какая-та настройка? Какой скрипт выполнится без моего ведома? Выполнение будет для всех подключений или только для мною выбранных?". Из опасения, что коннект к базе будет предварён каким-нибудь скриптом, открываем приложение без подключения к базе и открываем страницу "Session" в настройках приложения. Действительно, появилась новая опция "Execute the file on logon" с возможностью ввода символов, выбора файла и загрузки этого файла в SQL Editor. Тест стандартов интерфейса в целом положителен: подписи ясные, пробелы между элементами в рамках стандартов, разве что, центровка эдитора и вышележащих комбобоксов не совпадает. К нашему спокойствию убеждаемся, что поле пустое, а значит ничего лишнего не выполняется. Для проверки функционала во внешнем редакторе (Windows OS / Notepad) создаём sql скрипт с простейшей командой SQL*Plus "set echo off". Кстати, диалог выбора файла не фильтрует по расширению: в выпадающем списке фильтров только "*.*", нет "sql" или иных служебных расширений, как это возможно в иных модулях. А ведь в этом же окне на странице "File Handling" имеется настройка расширений служебных файлов со скриптами. Странно, что не использована имеющаяся функциональность. Недоработка разработчика. Проверяем далее. Если путь к файлу длинный, то в хинте появляется полный путь и имя файла. Положительный тест. А вот клик по "Load file in SQL Editor" приводит к неудобствам. Дело в том, что окно "Preferences" - модальное, то есть показывается поверх иных до самого его закрытия. А значит и просмотреть или редактировать скрипт придётся только после закрытия окна "Preferences". Напомню, что в SD имеется отдельный текстовый редактор, из которого уже по мере надобности можно переносить весь или выделенный текст в SQL Editor, но функционал либо забыт, либо не известен был программисту. Из этого заключаем, что кнопка не приносит удобств, а наоборот вызывает раздражение. Usability тест негативный. Применение опции выполняет проверку на существование файла, поэтому при настраивании этой или других опций доступ к файлу и сам файл должны быть актуальными. Но это касается только одной этой страницы. Для выяснения этого факта закрываем окно "Preferences", в файловой системе переименовываем файл скрипта, открываем окно "Preferences" из SQL Editor, меняем значение любой опции на открывшейся странице (не "General / Session"), применение изменений не предупреждает об отсутствии файла скрипта. Переходим на страницу "General / Session" и здесь меняем любую опцию, применение изменений предупреждает о неверном файле. Тест положительный. Пока имя файла несовпадающее, выполняем коннект к базе через модуль приложения "Oracle Database Connection", потому что выполнение скрипта не будет, если в SQL Editor локально подключиться к базе. Тесты положительные: 1) SQL Editor не пытался выполнить скрипт из файла; 2) диалог с ошибкой о пути или имени файла показан из окна "Oracle Database Connection"; 3) коннект к базе из окна "Oracle Database Connection" совершён благополучно после закрытия диалога об ошибке файла. Восстанавливаем имя файла и выполняем коннекты - тест положительный для простой SQL*Plus команды. Как проверить, что скрипт выполнился действительно? Напишем DDL создания объекта, например,
CREATE USER BBB  
IDENTIFIED BY "a"  
ACCOUNT UNLOCK 
/ 
Тест положительный: объект создаётся при логине юзера с достаточными привилегиями и показан диалог ошибки при логине юзером без достаточных грантов. Но спорна лишь ссылка "Open in editor", которая открывает файл в SQL Editor, перекрытый теперь уже двумя окнами: диалог с ошибкой файла и окном "Oracle Database Connection". И ещё, кнопка "OK" в диалоге ошибки выглядит как-то нелепо. На мой взгляд юзера, она должна быть подписана более нейтрально - "Close", поскольку по функционалу совпадает с правым верхним крестиком: лог-файл "%AppData%\Roaming\SQLDetective\SD.log" пополняется на оба клика.
Из области комплексного тестирования. При наведении мышки на подписи к чек-боксам в окне "Preferences" они моргают. Знаю, что эти элементы созданы самими разработчиками Conquest Software Solutions, поэтому такое раздражение для глаз от перерисовки имён опций должно быть поправлено программистами из Conquest Software Solutions, а не из Delphi, на котором написано приложение.
• Added the ability to change the password of the current user. The command “Change Password” is now available from the Session menu and from the Object Navigator pop-up menu.
Переводим и осознаём новшество.
Добавлена возможность изменять пароль текущего юзера. Команда теперь доступна из главного меню "Session" и контекстного меню Объектного Навигатора.
В зависимости от причин внедрения этого новшества будут и тесты. В Release Notes причина не указана, но подразумеваю, что это стало полезно после вступления в силу обновлённого GDPR, согласно правил которого пароль надо менять чаще. Но вместе с этим упрощением по изменению свойств юзера можно было бы и некоторые иные свойства юзера быстро менять из пункта меню, а не открывать мастер объекта, например, блокирование аккаунта. На эти мысли навела формулировка о местах доступа к фиче: главное меню Session и контекстное меню Навигатора Объектов. Почему в рамках приложения user считается объектом базы, но действие по его изменению не добавлено в группу "Object" главного меню? Тест на полноценность реализации не пройден, поскольку в Icon Dictionary забыли добавить глобальный экшен. А вот в рамках Объектного Навигатора новшество перевыполнено: пункт контекстного меню "Change Password..." появился не только для верхней ноды с именем коннекта, но и для всех пунктов в папке Users. Хотя, диалог для текущего коннекта чуть отличается от окна для смены пароля обычного юзера: 1) ни в том, ни в другом окне не указывается для какого конкретно юзера меняется пароль (в заголовке окна не хватает имени юзера); 2) левый нижний угол подсвечивается жёлтым цветом, не соответствующим цвету текущего коннекта; 3) имя юзера и базы прописывается в статусной строке в форме строки подключения (через символ "@"); 4) в окне для смены пароля текущего пользователя имеется поле для старого пароля, а для остальных юзеров только два (новый и подтверждение). Поскольку фича новая, но окно уже давно в приложении (использовалось при разблокировке аккаунта), то странным выглядит опция "Display password" в виде чек-бокса, а не "глазка" в самом редакторе.
В рамках комплексного тестирования выяснилась нелогичность пунктов контекстного меню Объектного Навигатора. Четыре пункта, касающиеся только текущего объекта (Object Properties, Compare with Another Object, Show Differences to Another Object, Change Password...), расположены в отдельном блоке после двух групп общих экшенов (для нескольких нод). Эти четыре пункта более логично расположить хоть и в отдельном блоке, но сразу под пунктом "Drop...".
Доступность обработана по минимуму: в случае попытки смены пароля не текущего пользователя юзером без достаточных привилегий в контекстном меню у всех нод папки Users активен экшен "Change Password...", а его выполнение порождает оракловую ошибку. Это говорит о том, что программист не сильно задумывался над реализацией и реализовал задачу минимальными средствами. Но, коль скоро уж приложение распространяется и в качестве учебной лицензии, то для сторонних простых юзеров пункт меню стоило выключить. 
• The startup window is now closed immediately after selecting an action.
Переводим и осознаём новшество.
Окно старта теперь закрывается сразу после выбора действия.
Это больше похоже на исправление юзабилити-бага, нежели улучшение. Тем более, что в приложении существует несколько приветственных окон: 1) в версиях до SD 5.0 первый запуск приложения начинался с проигрывания видео о возможностях продукта; 2) давние пользователи продукта вполне возможно считают splash окно "Oracle Database Connection" с минимальной информацией о лицензии тем самым приветственным; 3) если продукт запускается без определённого ключа, то в качестве приветственного стоит считать окно выбора лицензии; 4) триальному юзеру невозможно понять, что на самом деле имеется ввиду окно без подписи, но с инфой о ключе и тремя кнопками выбора коннекта к базе. Поясню перемудрённое программирование. Опция показа start-up window в режиме триала включена в Preferences и недоступна для смены, а в самом окне нет чек-бокса, дублирующего опцию. И даже если выключить опцию в Preferences через обходные пути (реестр или лицензионный ключ), то окно всё-равно будет появлятся в триальном режиме.
Для проверки основного исправленного функционала нажмём на все три кнопки окна в SD 5.0 (в версиях #4.Х ещё не было окна с описанным исправлением) и 5.1: в 5.0 окно закрывается после полного коннекта к базе или вместо появляющегося окна "Oracle Database Connection", а в 5.1 коннект к базе проходит уже после закрытия start-up window. Такое поведение доказывает, что это исправление интерфейсного бага, а не улучшение. На улучшение могло тянуть только добавление анимации, показывающей затягивающийся процесс коннекта к базе, а убирание лишнего интерфейсного элемента в софтверном тестировании считается только исправлением дефекта.
В рамках комплексного тестирования выяснено самопроизвольное изменение ширины (или кто-то может назвать это передёргиванием, сдвигом) главного toolbar. Если в одном сеансе приложения подключаться к базам с различной длиной строки коннекта (имя юзера + имя базы меняются по количеству символов), то комбобокс в главном тулбаре Session подгоняет свою ширину, тем самым сдвигая вправо панели последующих тулбаров. Но сдвиг происходит только на увеличении комбобокса, а если строка коннекта уменьшается, то последующие панели не сдвигаются обратно влево. Подгонка ширины комбобокса сессий происходит только после двух действий: подключение и отключение базы. Радует, что хоть при переключении между подключенными сессиями нет этого моргания в главном тулбаре.

Object Navigator (2 из 8, -2 за регрессии)
• Object properties now include general properties from the all_objects dictionary view.
Переводим и осознаём новшество.
Свойства объекта теперь включают основные свойства из системного вьювера all_objects.
Не понятно, что конкретно хотели этим сказать: толи перестали использовать админские вьювера, толи перестали брать основные свойства объекта из объектного вьювера. Поясню. Свойства объекта в Навигаторе Объектов открываются в области ContentSelector по нажатию горячей клавиши F4 или выполнением экшена из контекстного меню. Кстати, странное дело - в главном меню "Object" нет пункта "Object Properties", но он расположен в блоке "View". Логично? По мне, так нет.
Для проверки основного сделанного функционала воспользуемся самим же приложением, а именно "Session Navigator / Current Statement" и "Database Examiner / Top SQL". В обеих версиях SD 5.0 и SD 5.1 обращаются к одинаковым вьюверам. В чём заключался фикс? Не понятно. Включение или отключение опции "Preferences / General / Session / Use DBA dictionary views if available" тоже никакого результата не дало. Возможно, если бы описание в Release Notes было более подробным, то мы смогли бы увидеть полезность фикса.
А заодно в рамках комплексного тестирования выяснилось, что Session Navigator открывается с ошибкой "ora-29275: partial multibyte character" в версиях 5.0 и 5.1 при коннекте юзером с достаточными правами, а работать в нём невозможно даже после закрытия окна с ошибкой. В предыдущих версиях на той же машине и с той же базой модуль работает благополучно. Значит это какой-то баг регрессии. Аналогично нашёлся баг в DB Examiner: выставить пользовательский фильтр (PARSING_SCHEMA_NAME LIKE 'US%' + sort=BUFFER_GETS DESC, LAST_ACTIVE_TIME DESC) на странице Top SQL; переоткрыть приложение и модуль; основной грид без данных и закрашен чёрным цветом, нет списка колонок, но после закрытия сообщения об ошибке "Cannot perform this operation on a closed dataset." работа в модуле возможна полноценно.

Проблемное открытие DB Examiner

• All sequences are now shown in the Object Navigator tree.
Переводим и осознаём новшество.
Все последовательности теперь показываются в дереве Объектного Навигатора.
Если прочесть нижеследующие пункты Release Notes, то можно предположить, что под словом "все" подразумевались какие-то последовательности, сгенерённые системой. Но на всякий случай перечитаем документацию Oracle DB (ver#10, 11, 12, 18) на объекты sequences, в которой нет слов о каких-либо "системных последовательностях". Согласно документации для Oracle 12c в структуре Sequence DDL появился параметр "SESSION | GLOBAL", но в мастере объекта нет нового элемента. Значит разработчик опять выполнил задачу не думая о пользе продукта для конечного пользователя, либо аналитик, оформлявший задачу, посчитал это требование пользователя очередной прихотью, а полноценную поддержку новых свойств объекта отнёс к излишествам.
Но если речь о столбцах таблицы с авто-инкрементом, то проверку, к сожалению, сделать не на чем - нет доступа к базам версии 12 и выше.
• Sequences are now shown under Columns and under the object type node in which these sequences occur.
Переводим и осознаём новшество.
Последовательности теперь показываются под колонками и нодами объектных типов, в которых они используются
В этом улучшении явно речь об авто-инкрементных полях таблиц и коллекций. Но, поскольку такие свойства появились у объектов в версии после 12с, то что-либо проверить у меня нет возможности. А вот тестировщик, принимавший этот фикс, врядли не заметил, что мастер коллекции не открывается для создания нового объекта. В рамках локализации бага выясняем, что баг невозможности создания объекта через его мастер актуален не только для коллекции, но и для триггера и кластера.

Нода в навигаторе добавляется, но даже имя объекту присвоить невозможно

• System generated sequences are now also available in such modules as “Find Objects”, “Compare”, etc.
Переводим и осознаём новшество.
Последовательности, сгенерённые системой, теперь также доступны в таких модулях, как “Find Objects”, “Compare” и других.
Подозреваю, что под системными последовательностями подразумеваются дополнения к колонкам таблиц с авто-инкрементом. Но, поскольку такие свойства появились у объектов в версии после 12с, то что-либо проверить у меня нет возможности.
• When the “Refresh tree on object change” is enabled, an object tree folder is now required only if a new object is created.
Переводим и осознаём новшество.
При включенной опции “Refresh tree on object change” папка в дереве объектов запрашивается только если создан новый объект.
Сразу же вопрос к формулировке: о каком таком "запросе/необходимости папки" речь? Или это опечатка техписателя? Напомню, опция “Refresh tree on object change” доступна для изменения в "Preferences / General / Object Navigator" окне, а функционально это отражалось в дереве Объектного Навигатора при создании или удалении объектов после исполнения скрипта в SQL Editor, но значение опции не касалось мастеров объектов или изменений свойств объекта после команды "alter". Иными словами, разработчики решили уменьшить визуализацию процессов, а не расширить, как об этом говорилось ранее в моих безвозмездных отчётах о тестировании.
Поскольку функционал (создать и удалить объект через мастер и SQL Editor) абсолютно не изменился, то могу уверенно заявить, что этот фикс - обман, пустая приписка к списку улучшений.
• An object node is now refreshed only if its status changes: VALID > INVALID or INVALID > VALID.
Переводим и осознаём новшество.
Нода объекта обновляется теперь только если статус объекта меняется между VALID и INVALID.
Скорее всего данное улучшение должно работать вкупе с предыдущим, то есть в зависимости от опции “Refresh tree on object change”. Факт: и этот пункт Release Notes тоже фикция, так как компиляция объекта для смены статуса и ранее отражалась в дереве объектов только после его открытия в мастере, либо при непосредственной компиляции из Объектного Навигатора. Аналогично и про другие статусы объектов, например, unusable.
• Improved the look&feel of the Public Synonyms in the Object Navigator.
Переводим и осознаём новшество.
Улучшена работа с Public Synonyms в Навигаторе Объектов.
Поскольку использованы довольно общие фразы, то предполагаем, что изменения довольно мелкие или внутри-корпоративные. Визуально папка Synonyms в схеме Public никак не изменилась, разве что - её дубликат появился вне схем. Но в рамках всего продукта - мастер синонима заменён на новый интерфейс. А это повлекло за собой новые баги. По прежнему по-умолчанию создаётся синоним Public, но если выполнить "Create..." из контекстного меню папки "Схема / Объект / Synonyms", то в мастере синонима имя объекта не проставлено автоматически, а пропечатано имя ноды "Synonyms". Регрессия, а не улучшение. В рамках комплексного тестирования выявлен интерфейсный баг в дереве всех мастеров объекта: каждый последующий клик мышкой в области дерева страниц увеличивает затемнённость подложки вплоть до "чёрного текста на чёрном фоне".

После пары-тройки кликов по белой области нода чернеет

• Rearranged the menu commands on the pop-up menu of the Data tab in the ContentSelector.
Переводим и осознаём новшество.
Переструктурированы команды в контекстном меню для закладки Data в области ContentSelector.
К сожалению, реструктуризация прошла не в лучшую сторону для пользователя, поскольку все первоочередные команды функционирования грида спрятаны в подпункт. То есть теперь придётся делать больше движений мышью или курсором для выполнения табличных команд. А нововведение поиска тоже скрыто в подменю. Так что никак не могу назвать этот пункт улучшением, а только ухудшением.

SQL Editor (3 из 3, -(2*0,5) за недоделки)
• Once code is modified, the caption of a code editor tab is shown in italics.
Переводим и осознаём новшество.
Как только код изменён, то заголовок редактора кода показывается курсивом.
Интерфейсное удобство реализовано, как и описано. Странно, что не упомянут Stored Program Editor, в котором сделано аналогичное улучшение.
• Added elapsed time to the SQL output of failed executions.
Переводим и осознаём новшество.
Добавлено время неудачного исполнения в SQL Output.
Улучшение реализовано, как и описано: после успешно выполненной команды по прежнему синим приписывается "Elapsed time:" с использованным значением и красным - после выражений с ошибками.
• Moved the session drop-down list to the first place on the toolbar.
Переводим и осознаём новшество.
Комбобокс со списком подключенных сессий перемещён на первое место в тулбаре.
Перенос комбобокса сессий из отдельной панели на первое место в общий ряд и добавление подписи к элементу - действительное интерфейсное улучшение. Но элемент не входит в число экшенов Icon Dictionary, как это было и есть с аналогичным элементом "Session Dropdown" в группе "Session" на главном тулбаре приложения.

Stored Program Editor (0 из 1, за старый баг снимать баллы не буду)
• The “Toggle Code Explorer” toolbar button is now disabled by default on the toolbars of the Stored Program Editor and SQL Editor.
Переводим и осознаём новшество.
Кнопка "Переключение кодэксплорера" теперь выключена по-умолчанию на тулбарах SPE и SE.
Изначально подобное описание слабо тянет на новшество, более похоже на исправление интерфейсного бага.
Для проверки существует два способа - установить продукт на "чистую" машину, на которую никогда до этого не устанавливался SD; либо закомментировать настройки модулей в реестре. В таком случае, при первом открытии окон SPE и SE не должно быть дополнительного окна в редакторе и кнопка в тулбаре должна быть отжата. Но поведение программы противоположно описанию при комментировании настроек модулей и запуске с чистого листа: окно Code Explorer в обоих случаях есть в обоих модулях, кнопка нажата в SE и отжата в SPE. При чём, такое же поведение и в SD 5.1.1.160, 5.0.1.124 по части SPE. Вывод: либо техписателю неверно истолковали фикс, либо забыли его включить в билды. А уж тот факт, что тестирования не было - очевиден.
Кстати, при запуске "чистого" приложения в очередной раз проявилась скрытая слежка: первый запуск приложения сразу, без юзерского ведома отправляет инфу на сайт разработчика.

Code Explorer (2 из 2, -2 за недоделки)
• Added the Code Explorer to the SQL Editor.
• Added the ability to filter Code Explorer.
Переводим и осознаём новшества.
Редактор SQL обзавёлся навигатором кода. Добавлена фильтрация в модуль Code Explorer.
Да, SE расширился функционально. Но первое появление окна Code Explorer вызывает недоумение "что это?" даже у меня - пользователя "с пелёнок" этим продуктом, потому что оно без опознавательных знаков. Подпись появляется только для новой закладки в редакторе кода, а первое пустое открытие - забытый для проверки тест-кейс.
Фильтрации нод дерева кода ранее не было. Но отсеить можно только по пяти стандартным условиям, без возможности создать пользовательский фильтр. Вероятно разработчики ждут теперь предложений по расширению списка: только функции/процедуры, только STATIC/MEMBER и другое подобное. Но зацикливаться на тестировании (функциональное, интерфейсное, нагрузочное, межмодульное) новой фичи не буду, поскольку на первый взгляд работает сносно: фильтрует соответственно выбранному пункту и сохраняет/восстанавливает установки, курсор не пропадает, от отрисовки большого количества не рябит в глазах, в некоторых случаях настройки пересекаются в SE и SPE.
Полагаю, следующим шагом SE доработают до недостающих выходных закладок SPE и, наконец-то, откажутся от SPE. А потом начнут прикручивать настройку видимости закладок с результатами выполнения.

Database Monitor (1 из 1, -1 за недоделку)
• To run a query, SQLDetective now starts a separate database session to avoid blocking the active session.
Переводим и осознаём новшество.
Выполнение запроса для монитора базы запускает отдельную сессию базы для избегания блокировки текущей сессии.
Правильное решение разделить работу DBMonitor и текущего юзера базы, поскольку утилита выполняет множество разных запросов без возможности "прикрыть" некоторые из них. Дело в том, что одновременно выполняется более двух десятков запросов каждые 10 (или более) секунд - это значительная нагрузка на клиента базы. Утилита позволяет не записывать историю результатов запросов, но не выполнять какие-то из запросов - такой возможности не предусмотрено разработчиками. Да и страницу Overview настроить (добавить, поменять график) уже нельзя. Для проверки новшества достаточно воспользоваться самим же приложением, а именно Session Navigator, который показывает все сессии по приложению. Но только Session Navigator придётся запустить в какой-нибудь старой версии SD, поскольку в 5.0 и 5.1 работать невозможно из-за ошибки "ora-29275: partial multibyte character" на старте. Дополнительная сессия "SQLDetective 5.1 (32-bit) (DatabaseMonitor)" появляется после старта сбора статистики, но не пропадает после остановки и закрытия модуля DBMonitor. А если запустить мониторинг в двух окнах, то ещё одна сессия не появится. Звучит как недоработка, поскольку основная цель новшества - избегать блокировки активной сессии.

Dataset/Datagrid (2 из 2, -2 выявленных бага)
• Added the ability to search for text occurrences in datagrids.
• Added the ability to select datagrid styles: background color and grid intensity.
Переводим и осознаём новшества.
Добавлена возможность искать текст в гридах данных. Добавилась возможность выбирать стиль гриду: цвет подложки и интенсивность грида.
Оба новшества имеют краткое описание в хелпе продукта, но по поводу стилей пришлось экспериментировать, так как интерфейс настройки не даёт однозначного понимания каждого из пунктов для выбора. Обе фичи работают, на первый взгляд, а в полное тестирование погружаться не буду, дабы не портить статистику. Поскольку даже первое открытие диалога для поиска дало сразу два бага: отрисовка курсора не в окне ввода текста, подписи элементов взяты из стандартов OS вместо англоязычности всего приложения.

Code Analyzer (1 сделано из 1, -7 баллов за каждый выявленный баг и недоделку)
• Improved the look&feel of the code analysis results for overload procedures.
Переводим и осознаём новшество.
Улучшено визуальное восприятие результатов анализатора кода процедур переполнения.
Для сравнения открываем пакет с одноимёнными процедурами, но разными параметрами в старой и новой версии продукта, анализируем его код и поочерёдно открываем закладки визуализаторов и метрик кода. Напомню, что аналогичное изменение было в CS 8.1.1.258. Результаты в "Code Review" в основном завязаны на номер строки, но для некоторых правил прописывается полный список параметров, а для иных вместо переменных в таких же круглых скобках выведен номер по порядку процедуры в исходнике - последнее и есть новшество, а остальное без изменений.

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

Закладка "Structure" некоторые результаты показывает с/без индексов без списка параметров, но спасают номера строк - изменений не замечено. Закладка "Code Metrics" для спецификации пакета не смогла справиться с именем пакета и показала только одну круглую скобку, а для тела пакета никаких опознавательных знаков процедур переполнения не добавлено - изменений не замечено. Аналогично нет никаких отличий для имён Flowchart диаграмм. Список для "Call Tree", как и прежде, имеет индексацию процедур переполнения. Матрица "CRUD1", как и прежде, показывает процедуры с индексами. В общем, только некоторые правила на закладке "Code Review" обзавелись полезностью. А если бы тестирование фичи проводилось в комплексе с соседними закладками, то юзеры не стали бы репортить дополнительно баги.

BUGS FIXED
Немалое количество исправленных багов можно классифицировать, в отличие от импрувов, по степени исполнения. Реальному фиксу будем присваивать "1", половинчатому "0.5", отсутствию фикса - "0". Процент от общего числа покажет степень готовности билда.

Core (из 4 возможных ставлю 1,5)
• Changing date and time on the PC where SQLDetective is running no longer causes external errors.
Изменение даты и времени на машине с запущенным приложением не вызывает внешних ошибок.
Дополнительно поясню, что речь идёт о ручной смене параметров времени в операционной среде и это критично было для триальной версии, а сейчас для анализатора кода по контракту с учётом обработанных строк.
Для полной проверки необходимо иметь не только триальную версию, но и оба вида ключей. А поскольку я не обладаю вторым, то проверка будет половинчатой. Также не рассчитывайте на мой совет по длительной работе в рамках триала. Последний раз этот функционал проверялся мной ещё в версии 4.4 и пробных билдах 4.7: результат перевода календаря тогда давал перерасчёт рабочего периода с соответствующими предупреждениями и ограничениями. Для теста запускаем 5.0 в триале, переводим сначала время на несколько часов, потом дату на 3 (меньше триала) и 6 (больше триала) дней и после трёх-минутного ожидания (таков был ранее таймер) при отсутствии сообщений в трее пытаемся открыть любое функциональное окно, например, SQL Editor - это раньше было признаком для срабатывания перерасчёта рабочего периода. По результатам тестов могу заключить, что либо описание бага не конкретизировано и существует множество дополнительных условий, либо бага не было в опубликованной предыдущей версии. Так что считаем этот пункт Release Notes голимой припиской сделанного.
• Large number values are no longer cut or omitted.
Значения больших чисел больше не обрезаются или пропускаются.
Заявляя о подобной правке в блоке "Core" техписатель подкладывает свинью программисту, так как в приложении масса мест для показа больших числовых значений - от грида с калькулятором в качестве редактора до мастеров объектов со значениями из системы или результаты выполнения скриптов. Конечно же проверить абсолютно все интерфейсные элементы для показа чисел - это непомерная задача. Поэтому проведём самый простой тест: в таблицу с различной размерностью полей введём данные в трёх видах установки "Preferences / General / Number Format / Display Numbers as" = "Numeric", "Scientific", "Scientific if digits > 15".
К сожалению, мои предсказания полностью сбылись и этому фиксу могу поставить аналогичную оценку - приписка, так как никаких отличий с предыдущим билдом не обнаружено. Где и какие числа теперь не обрезаются - загадка для юзера.
• Empty values are no longer fetched for the RAW data type.
Пустые значения больше не считываются и подгружаются для типа данных RAW.
Напомню, что в Oracle тип данных RAW применяется как к колонке таблицы, так и к структуре объектного типа, например коллекции "SYS.aq$_jms_array_msgids". Кстати, попутно выяснилось, что мастера коллекции теперь нет в SD и новый объект создать невозможно, а существующие открываются для правки и просмотра в SPE.
Как проверить фикс? Судя по описанию - это сугубо внутренний процесс работы приложения с базой, который возможно отследить только дополнительными инструментами. Визуализацию в приложении получить можно, но для этого нужны обширные знания самой базы Oracle и возможности не junior юзера, а уровня системы. Любой минимальный пример займёт немало усилий для воспроизведения. Ок, примем на веру, что фикс существует, хоть и обнаружена проблема ввода данных через мастер nested столбца.
• On updating the tool via the Online Support Desk, the user is no longer prompted to delete program data and other application settings.
При обновлении приложения через OSD теперь не предлагается юзеру удалить данные и настройки продукта.
Странно, что фикс в блоке "Core", а не в "OSD" или "Installer", поскольку это их функциональность. Для проверки запускаем апдейт с пред-предыдущей на предыдущую, с предыдущей версии на текущую и с текущей до будущей. Минимальный билд можно брать 4.7.2, в котором апдейтер был разделён на два шага и встроен полный инсталлятор. Где взять апдейтеры - не скажу из-за секретности. Фактически фикс состоит в том, что юзер больше не оповещается о существующих установках предыдущих версий, а не предлагается что-либо удалять. Более понятным был бы текст: "The info message about installed old versions of product was removed from OSD Updater.". Так что с мелкой семантической опечаткой можно считать исправление сделанным.

SQL Editor (из 5 возможных ставлю 3,5)
• Ctrl+click on the variable declaration now navigates to its first occurrence in the code.
Клик с нажатым CTRL по имени переменной в редакторе ранее вызывал поиск объекта с подобным именем в дереве навигатора объектов. После добавления Code Explorer в SQL Editor стало возможным навигировать курсор в коде по его составляющим. Но вот как баг мне этот пункт не очень симпатизирует, его бы в число импрувов.
• Fixed the ability to change the password of the current user via the “Password” command.
Исправлена возможность менять пароль текущего юзера через исполнение команды “Password”. В предыдущем билде старый пароль не воспринимался как верный, видимо что-то попутали с кодировками.
• The “Show query for the current dataset” option now works correctly for all SQL statements.
Опция показа запроса для текущего грида теперь работает верно для всех выражений. К этой формулировке у меня три вопроса: 1) корректность по какой шкале мерить; 2) почему функционал называют "опцией", ведь это ухудшает однозначность понимания используемых терминов; 3) как понимать эпитет "все" по отношению к sql выражениям - любые типы или несколько в одном скрипте. К сожалению, невозможно проверить вариант нескольких команд в одном скрипте из-за рекурсивной av-ошибки на каком-то модуле "а". А функционал этой кнопки теперь является дубликатом включенности опции "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Editor and Data tab synchronization": в редакторе кода и открывающемся текстовом редакторе аналогичные тексты, если в гриде не выставлены дополнительные фильтры и сортировки. При этом фактическим фиксом можно считать вообще открытие этого текстового редактора, поскольку в предыдущем билде приложение молчит на клик по кнопке “Show query for the current dataset”. Проведённые тесты ещё раз меня усомнили в корректности правки - на что равняться?
• After closing all editor tabs, the last opened file is no longer marked as opened on the SQL Editor pop-up menu.
После закрытия всех закладок редактора последний открывавшийся файл не помечен открытым в списке. Поясняю по-фразно: 1) закрытие всех закладок кода не ведёт к закрытию всего окна, останется одна пустая; 2) на тулбаре редактора есть кнопка "папка" со списком открытых сейчас и ранее файлов, текущий активный помечается галочкой; 3) из контекстного меню закладки или самого редактора можно закрыть все редакторы одним экшеном. В предыдущем билде на последнем активном файле в списке оставалась галочка до закрытия всего окна SQL Editor.
• Fixed the work of the “Make current statement updatable” option.
Исправлена работа опции "Делать текущее выражение редактируемым". Пояснения: 1) термин "опция" читаем как "действие", а не "настройка"; 2) на тулбаре редактора есть кнопка "жёлтый плюсик и буквы rowid" с длинным хинтом - это нужный нам экшен. Поскольку функционал довольно однозначен - к списку полей select-выражения должен добавиться столбец ROWID. Какие могли быть проблемы ранее? Предполагаю из-за сложности выражения: 1) наличие алиасов в списке объектов FROM; 2) порядок объектов в списке объектов FROM; 3) вложенность запросов; 4) структура запроса с использованием WITH, JOIN и других служебных слов. Но скорее всего подправили только один частный случай. Поскольку все примеры вышеописанных кейсов работают одинаково в предыдущей и текущей версиях, то считаю фикс липой.

Code Analyzer (из 5 возможных даю 1,5)
• An access violation error no longer occurs on trying to save code analysis results into a file.
AV-ошибка больше не случается при попытке сохранить результаты анализатора кода в файл. Поясняю: 1) форматтер и анализатор кода разделены, поэтому не берём в расчёт сохранение отформатированного кода в файл из редактора кода; 2) результаты анализатора можно получить в двух видах - визуализация и метрики - на 8 закладках (Code Review, Structure, Autofixes, Errors, Code Metrics, Flowchart, Call Tree, CRUD). Кроме того, проанализировать код можно не только в SPE и SE, но и в мастерах объектов, Object Navigator, некоторых текстовых редакторах, используемых для показа DDL или скриптов. Причиной к av-ошибке могло быть что угодно, даже специфичная операционка. Но поскольку в описании нет конкретики, то будем рассчитывать на общий случай и проверим только SPE. Кстати, если вы комплексно тестируете, то эту проверку могли сделать во время исследования улучшения показа результатов анализа процедур переполнения. После попытки сохранения "Code Review" действительно была ошибка в предыдущем билде; результаты из "Structure", "Code Metrics", "Errors" сохранялись без проблем; из закладки "Autofixes" и всех списков диаграмм нет возможности сохранять в файл, а сохранение самих диаграмм в файл производится уже в другом модуле - HTML Viewer. В рамках того же комплексного тестирования выявлено следующее: 1) "Code Metrics" сохраняются в htm файл в нечитабельном виде - строки сохранены, но столбцы не имеют разделителей и подписей; 2) дерево "Structure" и "Code Review" сохраняется в htm файл в полностью развёрнутом виде без какой-либо возможности сворачивать ноды; 3) сохраняя одну диаграмму Flowchart или Call Tree из множества пакетных подпрограмм вы прицепом получаете не открывавшиеся во вьювере, но сгенерённые, диаграммы всех подпрограмм и для каждой разноимённые файлы, но с идентичным содержимым - не заказанные и не отображённые легенды. То есть куча ненужных файлов не только зря формируется при генерации диаграммы, но и навязывается всё скопом при сохранении одной; 4) HTML Viewer при сохранении фильтрует файлы по "htm" расширению, но сохраняет с расширением "html" и в строке с типами файлов показано расширение "html", что не показывает имеющиеся html-файлы и приводит к проблеме пользователя - пересохранение с тем же именем; 5) сохранение CRUD матриц сопровождается Call Tree диаграммами и их составляющими (картинки кнопок для дополнительного окна и зачем-то в двух вариантах сами диаграммы), но не добавляется текст кода для срабатывания линков (при сохранении в таком случае следовало бы либо удалить линки, либо добавить текст кода и скорректировать эти линки); 6) иконка приложения в заголовке экспортированных данных, кроме "Code Review", устарела. Если перефразировать в "Code Review results now are saved into file without an access violation error.", то фикс сделан.
• Fixed the case of the INTO keyword applied during code formatting.
Исправлен случай применения служебного слова INTO при форматировании кода. Двоякая формулировка, да? Толи стиль не применялся, толи какой-то частный случай использования служебного слова. Для теста отформатируем выражение "select..into..from.." с разным значением опции "Code Analyzer Options / Formatter Options / Case / Keywords / Default Case" = "Uppercase, Lowercase, Initcaps". Действительно, предыдущий билд форматировал только слово "select", а к "from" и "into" применялась настройка чужая, например, Datatypes или Identifiers. Так что из-за неполноты описания бага даю ему только половинчатую оценку.
• Longs strings of the Program Structure are now shown correctly.
Длинные строки Program Structure теперь показываются корректно. Во-первых, какой смысл включается в слово "корректно"? Согласно каким правилам? Полностью видно за счёт автораздвигания колонки или приписывается троеточие, а полное имя в хинте выводится, или уменьшается шрифт для втискивания в столбец и видимую часть таблицы, или к названию применяется авто-перенос? И где это записи корректны - в интерфейсе или в экспортированных результатах? Такое множество вопросов - это результат применения театральных методик "Ударный тест" (особое внимание на каждое из слов) и "История героя" (в предыдущем баге работали с экспортом). Для теста используем всё тот же пакет и без компиляции в базу "лёгкими пробежками по клавиатуре" удлиняем имена подпрограмм. Результаты анализа в интерфейсе позволяют изменять ширину столбцов с наименованием категории и количеством. В предыдущей версии длинные значения обоих столбцов обрезались без троеточий в конце, но полное значение выводилось в хинт при наведении курсора. Также в экспорт не попадал столбец "Count", что можно было бы приписать к новшествам. Теперь значения просто переносятся, без соблюдения лингвистических правил. А экспортный вариант имеет лимит на минимальную ширину столбцов при сужении браузера. Так что, если слово "correctly" заменить на "fully", то фикс сделан. 
• Fixed indexation of overload subroutines.
Исправлена индексация процедур переполнения. На самом деле - это дубликат ранее проверенного новшества.
• Analyzing objects imported from an Oracle Database 18c no longer raises parser issues.
Анализируемые объекты, импортированные из базы Oracle 18c больше не дают ошибки парсера. Когда разработчики заявляли, что SD стал поддерживать новую версию базы, они должны были перепроверить не только коннект к этой базе, но и возможность просматривать, редактировать и анализировать объекты с обновлённой структурой. Более всего это не исправленный баг, а новшество по добавлению в поддержку какого-то выражения или команды, или объекта нового типа. Поэтому что-то тестировать даже не буду пытаться, а баг не засчитываю.

Object Navigator (из 2 возможных даю 1,5)
• An access violation error no longer occurs on trying to create a synonym via the Object Navigator pop-up menu.
AV-ошибка больше не случается при попытке создать синоним из контекстного меню Объектного Навигатора. Этот баг был обнаружен мной ещё год назад в билде 4.7.2.247. Тогда разработчики бесплатно получали мои отчёты о выявленных багах напрямую. Для воспроизведения бага  можно воспользоваться версией 5.0 и попытаться создать синоним для таблицы: выбираем в навигаторе свою таблицу, из контекстного меню выполняем "Create Synonym", без применения к базе закрываем мастер синонима. В результате получаем зацикленные av-ошибки, вплоть до необходимости снимать приложение через диспетчер задач. В новом билде фикс есть, но он сделан за счёт не описанного новшества - мастер объекта Synonym заменён на новый интерфейс. Поэтому даю только полбалла.
А в рамках комплексного тестирования выяснилось, что больше половины мастеров объектов всё ещё не отвязаны от навигатора объектов: при создании нового или открытии существующего объекта для редактирования в мастере его нода излишне навигируется в навигаторе объектов.
• An access violation error no longer occurs on trying to purge several RECYCLE_BIN objects.
AV-ошибка больше не случается при попытке уничтожить несколько объектов из корзины базы. Поясняю: корзину удалённых объектов база Oracle начала поддерживать с 10-11 версии, обслуживание корзины в продукте реализовано только в навигаторе. К сожалению, в SD нет фичи клонирования объектов, поэтому для создания тестовых данных использую мастер таблицы, генерацию DDL и выполнение скрипта в редакторе, затем в SmartDataset наполняю данными, а через экспорт и импорт данных переношу и их в размноженные таблицы. Все эти скрипты автоматически запоминаются в истории выполненных команд SQL Editor, поэтому не откладываю в спец.файлы. К чему эти описания? Не стесняйтесь использовать тестируемое приложение для точечных тестов. Это поможет выявить вам стандартные юзерские кейсы и их следствия (предложения, баги). Удалив в корзину без галок Flashback и Purge проходит благополучно в обеих версиях SD, а последующее выполнение Purge для нескольких объектов давало ошибку отрисовки, судя по логу, в предыдущем билде, и проходит благополучно в текущем. Примечание к вопросу о граничных значениях: поскольку причиной бага, судя по логам была отрисовка (умею читать и понимать данные EurekaLog), то в тесте рассматривался случай полной очистки папки RECYCLE_BIN, а количество объектов - больше трёх.

Database Monitor (0 баллов из 1 возможного)
• An access violation error no longer occurs on closing the Database Monitor after several database reconnections.
AV-ошибка больше не случается при закрытии окна Database Monitor после нескольких реконнектов к базе. Поскольку в описании бага не конкретизируется состояние утилиты (может включен сбор статистики, может просматривается история), то проверять будем только открытое окно, без дальнейших действий и на коннекте (один и тот же юзер) с достаточными правами. Тутже нарисовался баг: запустить сбор статистики можно без подключения к базе = кнопка не гасится при пустом комбобоксе сессий. А исходный по описанию никак не удалось воспроизвести, поэтому считаю его припиской.

Session Navigator (0,5 из 1)
• Each next automatic refreshing is now made exactly 20 seconds after the previous one.
Каждое следующее автоматическое обновление данных теперь выполняется ровно через 20 секунд после предыдущего. Насколько мне известно, периодичность обновлений - величина, устанавливаемая пользователем, и не обязательно должна быть 20 секунд. А минимальное значение изначально было 1 и по-умолчанию - 60. Так что странным выглядит величина "20". Может это новое дефолтное значение? К сожалению, последний работающий модуль был в версии 4.7.2, а не 5.0, поэтому не забудьте предварительно позаботиться о сохранности паролей. Ну да, в предыдущей версии подпись в статусной строке появляется неравномерно через выставленный интервал: достаточно поставить "5 секунд" в настройку, предварительно её включив, и открыть поверх SD или  рядом секундомер. Но проверить фикс в текущей версии невозможно из-за уже описанного мной ранее бага "ora-29275: partial multibyte character".

Describe Object (0,5 из 1)
• Fixed the look&feel of the Describe Object window when DPI 125% is applied.
Исправлен внешний вид  окна "Describe Object" при разрешении экрана в 125%. Правильнее было бы формулировать фикс словами "масштабирование интерфейсных элементов соответствует стандартам". А проверять стоит не только 125%, но и иные размерности. Примечание: для применения этих системных настроек в Win10 перезагружать операционную систему не надо, но менять их при запущенном SD не рекомендую, хоть и текст гласит "после применения настройки". На самом деле  это не фикс, а замена старого стиля окна на современный, соответствующий операционной системе. По чести, никаких исправлений визуальной корявости не случилось и можно этот пункт размещать в блоке новшеств, поэтому полбалла. Кстати, если вы за комплексное тестирование, то загляните и в другие модули (у меня, например, отсутствует иконка приложения на кнопке SD в строке/столбце работающих приложений), пока не вернули системную настройку на свою привычную.

Schema Compiler (1 из 1)
• Removed the duplication of Materialized Views.
Убрано дублирование материализованных представлений. Поясню: 1) в список для компиляции попадают объекты со статусом INVALID; 2) статус м/в может быть различен в системных вьюверах (all_objects, all_views, ...); 3) м/в может дублироваться по имени в качестве вьювера и таблицы в общем списке объектов; 4) запрос для вывода списка вполне мог быть неверен и излишне прибавлять данные (ошибка копи-паста); 5) минимально речь идёт о закладке "Invalid Objects", но возможно какой-то внутренний процесс (способ компиляции или логгирование) не был полноценно запрограммирован и проверен до компиляции билда в прод. Так что гипотетически причин у бага может быть несколько. Попутно выявился интерфейсный баг на странице Columns мастера м/в: после написания или исправления запроса на странице SubQuery список столбцов нечем обновить и первое открытие списка колонок остаётся пустым вплоть до клика по кнопке с иконкой "Редактировать", но хинтом "Получить список столбцов из запроса". Моё второе пояснение заметно по Object Navigator, в дереве которого только что созданный м/в инвалиден (иконка с красной подсветкой), а в списке ContentSelector он имеет статус VALID Минимальный кейс для ошибки копипаста (создаём м/в по всем столбцам таблицы, которую не жалко испортить, и удаляем из родительской таблицы одну колонку = м/в становится инвалидным) показывает две записи в предыдущем билде и одна запись в текущем билде одного и того же м/в в списке инвалидных модуля Schema Compiler. Так что фикс есть.

Dataset/Datagrid (0 из 1)
• The options to fix/unfix columns now work correctly.
Опции по закреплению и откреплению столбцов теперь работают корректно. Опять первейший вопрос - по какой мерке исчисляется корректность? Что конкретно было не верно или всего лишь не удобно? Фиксация одной или нескольких колонок, подряд выбирать или первую/последнюю и "зеброй"? О каких конкретно гридах речь - только SmartDataset или в расчёт идут и гриды в мастерах таблицы/вьювера, админских утилитах? Проведя опыт замораживания среднего столбца в ContentSelector (средняя часть навигатора объектов), а потом нескольких первых в обеих версиях продукта, убеждаюсь, что нет никакой разницы в поведении. Из чего заключаю, что это не фикс, а приписка.

Materialized View Wizard (0 из 1)
• Fixed the SQL statements generated for Materialized Views when “Parallel” is set to “degree default.”
Исправлена генерация sql выражения для м/в при значении “degree default” для параметра “Parallel”. Мелкое примечание: точка в тексте должна быть после последней кавычки. Поясняю фикс с точки зрения "старого" пользователя SD: речь идёт о DDL, текст которого автоматически формируется на соответствующей вкладке мастера при создании и редактировании объекта, либо при выгрузке всего DDL. Но, подозреваю, речь идёт о первом кейсе. После проведения тестов на создание и редактирование м/в никаких отличий в текстах правого окна мастера не выявлено. Посему считаю баг припиской к Release Notes. Если бы описание было более конкретным, то возможно удалось бы воспроизвести проблему в предыдущем билде или на какой-то конкретной версии базы. К тому же увиден баг в расположении элементов блока "Build Table Properties" в мастере м/в: 1) чек-боксы и кнопка не выровнены ни по подписям, ни по комбобоксам слева; 2) кнопка не выровнена по вертикали с чек-боксами; 3) подпись блока перечёркнута верхней линией бордюра.

Цветные линии указывают на разницу в вертикальных и горизонтальных координатах. Бордюр не должен перечёркивать имя элемента.

Scenes (0 из 1)
• The scene creation and modification dates are now correctly restored after changing the date and time format in Preferences.
Даты создания и модификации сцен теперь корректно восстанавливаются после изменения форматов даты и времени в настройках приложения. Поясняю: сцены - это помощники для отображения часто используемых объектов и их свойств в ContentSelector области навигатора объектов. Подозреваю, что смена формата дат в рамках приложения не применялась к уже имеющимся данным о сценах. Для проверки запиниваем первые попавшиеся закладки в ContentSelector и сохраняем сцену, затем меняем формат дат и оцениваем результат, не перезапуская приложение. Поскольку разницы в билдах не обнаружено, то считаю фикс припиской. А вот в закладке "Description" (средняя панель менеджера сцен и грида) выявилось два бага: 1) странная буква "М:" вместо более понятной подписи "Modified:"; 2) содержимое закладки не обновляется после закрытия Preferences или применения изменённых настроек. Ещё один баг - западание модального окна - проявился при открытии Preferences сразу после разворачивания навигатора объектов и раздвигания панели с менеджером сцен.

Fast Copier (0 из 1)
• Changing the priority engine for DDL extraction now works correctly.
Изменение способа выгрузки DDL теперь работает корректно. А что же было "не корректным" и по отношению к чему? Допустим, что тип выгрузки в модуле не совпадал с общепродуктовой настройкой и не синхронизировался. О том, что опции копировщика как-то странно сохранялись и восстанавливались при следующем обращении к утилите не раз репортилось мной и в бытность тестером CSS, и позже. Окно настроек выгрузки DDL в модуле Fast Copier имеет три закладки. Для нашего теста интересны такие факты: выбор режима расположен на первой закладке, вторая или третья закладка открывается по принципу "smart" при следующем вызове окна. Наилучшим способом для проверки этого фикса считаю построение матрицы переходов, где рассмотрим изменение глобальной настройки и локальной в зависимости от способов открытия окна.

Legend:
E1	Built-In Engine
E2	Oracle's DBMS_METADATA package
Tab1	Common Options
Tab2	DBMS_METADATA
Tab3	Built-in Engine
Pref	Preferences / General / Extract DDL - глобальная опция
Opt	button "DDL Options" in Fast Copier - локальная опция
безупречный результат
сомнительный результат

	Pref = E1	Pref = E2	Opt = E1	Opt = E2	Opt закрыто на Tab1
Открытие окна после запуска приложения	Tab2	Tab3	Opt = Pref, Tab2 или Tab3 по значению Pref	Opt = Pref, Tab2 или Tab3 по значению Pref	Tab2 или Tab3 по значению Pref
Переоткрытие окна Opt без перезапуска утилиты Fast Copier	Tab2 или Tab3 по значению Opt	Tab2 или Tab3 по значению Opt	Tab2	Tab3	Tab2 или Tab3 по значению Opt
Preferences открывались при запущенном Fast Copier	Tab2 или Tab3 по значению Opt	Tab2 или Tab3 по значению Opt	Tab2	Tab3	Tab2 или Tab3 по значению Opt

Результаты тестов в предыдущей и текущей версиях идентичны, значит фикс - приписка.

Telegram (0,5 из 1)
• Screenshots taken from the Telegram now include all the open modules, not only the main application form.
Скриншоты из Telegram теперь включают все открытые модули, а не только основное окно приложения. В формулировке скорее всего опечатка, так как для утилиты Telegram, встроенной в SD для быстрого общения с абонентами и пользователями SD, существует фича отправки текстов и картинок из SD. То есть вместо "from" надо было написать "for". Смысл фикса более тянет на новшество, а не баг. К тому же, модуль OSD был перенесён из самостоятельного окна в общее рабочее скорее всего как дополнение к этой теме. К сожалению, не могу проверить этот фикс, так как не обладаю нужным аккаунтом. Но интересно было бы увидеть результат по тем китам, которые всё ещё не встроены в основное окно (Code Assistant, Oracle Documentation Browser, ...). Принимаю на веру правку и ставлю полбалла.

Preferences (1 из 2)
• Resetting preferences to default now works correctly after applying changes on the Color tab of the Code Editors page.
Восстановление установок до начального состояния теперь работает корректно после применения изменений на закладке "Color" для редакторов кода. А что именно было не корректно - процесс или значения, восстановление текущей страницы или всего модуля? Проверим минимальный кейс: изменим первую настройку на заявленной странице, применим изменения и, не переоткрывая окна Preferences, выполним восстановление на текущей странице. Оценим результат на текущей закладке, соседних закладках и страницах модуля. Перед тестом обязательно сделаем копию всех настроек по кнопке "Preferences / Save". В глобальном смысле никаких изменений в работе восстановителя не замечено: все три закладки на странице "Code Editors" восстанавливают значения опций до дефолтных без затрагивания настроек на других страницах в обеих версиях приложения. Если рассматривать закладки как отдельные страницы, то, по-моему, корректность правки не соблюдена, поскольку это весьма неожиданный результат. С обеих сторон фикс не принимается.
• The grid columns on the License Key page are no longer duplicated after clicking the "Apply" button.
Колонки грида на странице ключа лицензии больше не дублируются после клика по кнопке "Apply". Насколько мне известно, изменение ключа вручную через настройки применяется автоматически и не нуждается в дополнительном коике по кнопке "Apply". Поэтому менять будем настройки на других страницах, а нажимать кнопку применения после активации страницы "General / License Key". Но если вы имеете файл ключа, то после применения не удивляйтесь скрытой смене настроек для проверок апдейтов, поскольку до сих пор в дереве настроек не появляется галка и кнопка "Apply" не загорается, хотя проверка апдейтов автоматически меняется на ежедневность - процесс скрытый от глаз пользователя. А описанный кейс действительно воспроизводится в предыдущем билде и отсутствует в текущем.

Online Support Desk (0,5 из 2)
• An empty message box no longer appears if the internet connection is lost during the application update.
Пустое сообщение больше не появляется при потере интернет коннекта во время апдейта приложения. Воспроизвести описанное считаю довольно сложным, так как апдейт обращается к интернету несколько раз, а в тексте не конкретизирован шаг. К тому же, при современных скоростях довольно сложно поймать момент, который был недостаточно обработан. Примем на веру.
• The “List index out of bounds (4)” error is not raised, too.
Ошибка “List index out of bounds (4)” тоже больше не появляется. Ну, подобное описание я вообще сразу выкидываю из рассмотрения, поскольку абсолютно ничего не указано: на каком окне (сообщения или апдейт), на каком шаге работы (открытие окна, исполнение процесса, закрытие, обрыв связи, и т.д.), по какой причине (подсчёт сообщений или апгрейд с ключом не уместился в списке, внутренние процессы зациклились).