Зал-гармошка

Любительские театры ограничены пространством. Зачастую, им достаются небольшие кабинеты в Доме Культуры или школе. Удача, если на части пространства выстроен подиум, ограничивающий сцену и зрительный зал. Тогда зрителям задних рядов хоть что-то видно.
Если стулья для зрителей складные, то для репетиций и тренингов можно расчищать зал.
Самым эргономичным и удобным решением может стать зал-гармошка, задние ряды которого располагаются высоко (зрителям не придётся вытягивать шею из-за спин впереди сидящих), а на время репетиций весь пол кабинета свободен для тренировки сценодвижений.
Три ряда в разложенном состоянии:
 
Верхняя полка - сидячие места. Верхняя точка спинки на высоте 2,5м от уровня пола, сидушки на высоте 2м от пола. Спинка и сидушка оббиты поролоном (бирюзовые линии), соединяются по методу треугольника гибкими верёвочными креплениями сверху (зелёная линия) и съёмными жёсткими (металлическими) креплениями, как в кроватях-раскладушках, снизу сидушек к стойке подножки (вторая слева вертикальная линия сиреневого цвета) . Стойка со спинкой верхнего ряда (крайняя левая линия синего цвета) крепится к задней стене зала анкерными болтами. Между стойками можно для устойчивости добавить жёсткое металлическое крепление (крючок и петля), параллельное полу на высоте до 0,5м от пола (на всех схемах отсутствует).
Вторая полка - проход верхнего ряда (коричневая линия) и через перегородку (средняя синяя линия) - сиденья среднего ряда расположены на высоте 1,5м от пола. Верхняя точка спинки среднего ряда - 2м. Полка прохода среднего ряда соединяется со стойкой спинки нижнего ряда, сидушка среднего ряда соединяется со стойкой прохода верхнего и среднего ряда съёмным металлическим креплением (крючок и петля) - линии серого цвета. Между каждыми соседними стойками можно для устойчивости добавить жёсткое металлическое крепление (крючок и петля), параллельное полу на высоте до 0,5м от пола.
Аналогично устроен нижний ряд: верхняя точка спинки - 1,5м, сидушка - 1м, подножка - 0,5м от пола. Первый, нулевой ряд (или больше) можно приставить из стульев (лучше со спинкой) к стойке подножки (правая синяя линия) нижнего ряда зала-гармошки. Глубина зала-гармошки в разложенном состоянии - 3м от задней стены. Размеры можно уменьшить, но для данного макета выбран стандарт: высота сидушки и спинки, глубина сидушки, ширина прохода - по 0,5м.
Сократив высоту рядов с 0,5м до 0,25м за счёт опускания проходов, имеем следующую конструкцию:
 
Верхняя точка спинки заднего ряда - 1,75м. Сидушка заднего ряда - 1,25м. Проход заднего ряда - 0,75м. Верхняя точка спинки среднего ряда - 1,5м. Сидушка среднего ряда - 1м. Проход среднего ряда - 0,5м. Верхняя точка спинки нижнего ряда - 1,25м. Сидушка нижнего ряда - 0,75м. Проход нижнего ряда - 0,25м.
В сложенном состоянии все ряды сдвигаются в плоскость к задней стене:
 
Жёсткие крепления-крючки (серые линии) снимаются. Верёвочные (зелёные) соединения сгибаются. Поскольку полки имеют соединения со стойками через дверные навесы, то полки и стойки собираются по направлению к задней стойке. Для удержания сложенного состояния стойки крепятся друг к другу маленькими крючками. Глубина сложенной конструкции будет зависеть от толщины стоек, например, для трёх рядов из 7 стоек - около 0,5м. Максимальная высота сложенного зала-гармошки - до 3,5м. Но если высоту последующих рядов снизить, то высота сложенной конструкции будет 3,25м.
 
Есть ещё один вариант уменьшить высоту сложенной конструкции. Сидушки, как и прежде, складывать вверх к спинке, а подножки раскладывать вниз по задней стойке. Тогда высота сложенной конструкции будет равняться задней стойке 2,5м или 1,75м.
 
В случае складывания горизонтальных щитов всех рядов только вверх, раскладывать придётся всю конструкцию (все три ряда в моём примере). В случае попеременного складывания горизонтальных рядов (сидушки - вверх, подножки - вниз) конструкцию можно растягивать по-рядно, то есть только один ряд или только два ряда, потому что нижняя точка стоек спинки в идеале будет на полу.
Для стоек, сидушек и проходов (синие, сиреневые, бирюзовые и коричневые прямые на схемах) можно использовать деревянные щиты (доски сбитые или клееные, фанера, OSB). Жёсткие крепления (серые линии на схемах) должны быть металлическими, чтобы не увеличивать объём и вес конструкции. Для гибких креплений (зелёные линии на схемах) подойдут верёвки, жгуты или тканевые треугольники, чтобы избежать лишних мобильных креплений (крючки, липучки). Подушки для сидушек и спинок (бирюзовые линии на схемах) следует изготовить из ткани, поролона и приклеить, прибить к щитам или предусмотреть их съёмными на липах (это позволит более плотно собирать конструкцию, но для подушек нужно будет дополнительное место хранения, но эти же маты можно использовать на тренингах). Для постоянных соединений (на схемах места креплений - это углы 0, 90, 180 градусов между прямыми, кроме серых) между вертикальными (стойки, спинки) и горизонтальными (сидушки, подножки) щитами следует использовать дверные навесы, позволяющие складывать конструкцию и удерживать углы.
Для лестницы следует использовать аналогичную технологию. На каждый уровень (подножка, сидушка) делаются ступеньки высотой 0,25м и глубиной 0,25м. Стойку каждой нижней ступеньки не стоит крепить на навес к нижнему щиту, потому что каждые две (в случае единой высоты подножки верхнего/среднего ряда с сидушкой среднего/нижнего ряда), три (в случае межрядовой высоты 0,25м) ступеньки складываются и крепятся к очередной стойке (синие и сиреневые линии на схемах).
Оптимальное количество мест в секции - 3 штуки (ширина ~1,5-2м в зависимости от степени устойчивости и жёсткости щитов-сидушек). Лесенки можно вставлять между каждыми секциями, либо сэкономить место и сделать одну лесенку на 3-5 секций.
Количество рядов может быть любым: от одного до бесконечности. :) Зависит от расстояния между сценой и задней стеной кабинета, отведённого театру, и доступной высоты до потолка.
На внутренней стороне щитов можно расположить крючки или кармашки, которые станут полезны только в собранной конструкции. На них можно развесить костюмы, реквизит в упаковке в дни между спектаклями.
Многофункциональность конструкции заключается в экономии рабочего пространства, удобстве разноуровневых рядов, использовании изнанки в качестве места для хранения вещей.
Фоторяд картонного макета:

Вид сверху на сидушки и проходы.

Вид снизу на соединения по принципу дверных навесов и разъёмных крючков.

Вид сбоку на процесс складывания, раскладывания.

Вид сбоку на собранную конструкцию - не забудьте про удерживающие элементы.

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

Вид сзади на собранную конструкцию - не забудьте про удерживающие элементы.

Тестировщики ПО, зал-гармошка - это напоминание вам:
- об эффективном использовании пространства в интерфейсе продукта;
- о своевременной и полноценной очистке рабочего пространства после использования;
- о своевременности подготовки переменных перед непосредственным использованием;
- о конструктивном и многофункциональном подходе при написании и обращении к подпрограммам в коде;
- о выявлении и проверке граничных значений;
- о знании и применении стандартов удобств.

ПэйджСэйвер

ПэйджСэйвер = PageSaver
Современное общество всё чаще получает информацию из Интернет источников: газеты, блоги, соц.сети и прочие сайты СМИ.
Случается, что текст или картинку, или видео необходимо передать в юридические инстанции. А некоторым порталам отказывают в распространении на определённой территории из-за ограниченного доступа силовикам.
Конечно, можно сделать копию страницы в присутствии нотариуса. Но наличие специфической функции на портале соц.сети или СМИ, да и любых других распространителей информации, например, оферта магазина или турагентства, упростила бы процедуру. И не только облегчила бы работу юристов, но и повысила бы авторитет компании, предоставляющей контент.
Представьте, что каждая страница сайта имеет кнопку для сохранения всего видимого содержимого с авторской подписью издателя и датой публикации без возможности правки.
Возможно? Да, технологий достаточно!
Просто? Да, программисту работы на чашку кофе!
Удобно? Да, всем: издатель получает своеобразный патент, рядовой пользователь не напрягает юристов, силовые инстанции получают быстро и без затрат достаточный объём подтверждений дела!

P.S.: о необходимости таких кнопок для тестировщиков и говорить излишне.
Интерфейс в большинстве случаев проверяется по скрин-шотам. А тут - готовое решение:
- неизменное содержимое;
- полнота данных за счёт авто-скроллирования;
- данные актуальны на момент действия и полностью соответствуют текущим условиям;
- дата и автор проведения теста в свойствах файла.
И всё это лишь в один клик.

ТО о CS 8.0.1.169

Отчёт о тестировании ClearSQL 8.0.1 (build 169), выпущенном 17 января 2019  года, будет проведён по тексту Release Notes, который вы можете найти в самом приложении, но нигде на официальном сайте компании ConquestSS. Предыдущий билд был месяц назад, а этот - сразу после новогодних каникул, значит юзер опять выявил некий критичный баг. Давайте искать, какого фикса билд.

IMPROVEMENTS   1.5+1+0=2.5  из 2+1+1=4 возможных, -1 за баг
Link Manager / Project Assistant / Import Wizard   0.5+1=1.5  из 2 возможных, -1 за баг
⦁ Added the ability to link a root node of a project tree with a database connection node. Unlink, relink and other related options are also available.
Добавлена возможность линковать ведущую ноду дерева проекта с нодой коннекта к базе. Отвязывать, перелинковывать и прочие соответствующие опции также доступны.
В который раз тех.писательница вместо термина action использует option, что приводит юзера, читающего инструкцию, в замешательство. Второе замечание к тексту заключается в том, что по неизвестной нам причине забыт вариант импорта из файловой системы. Мастер нового проекта и импорта пополнился функциональной кнопкой: рядом с добавлением линкованных и простых скриптов в проект появилась самостоятельная кнопка для линковки или перелинковки. Основной тест проделаем следующим образом. Сначала попытаемся создать новый проект, линкуя его верхнюю папку на какую-нибудь ноду  базы, а вторым тестом испробуем перелинковку и синхронизацию верхней папки проекта. Чтобы в базе получить минимальное число объектов, уберём из дерева объектов (левая часть мастера нового проекта) системные и демо-схемы, а на часть папок со слишком большим количеством объектов наложим фильтр по имени. И тут проявляется первый сопутствующий баг: применив фильтр к подпапке объектов в верхней ноде схемы количество объектов не меняется. Выбрав верхнюю ноду объектов базы "ИмяКоннекта@ИмяБазы" или "Schemas" вы никогда не сможете слинковать их с какой-нибудь папкой проекта, потому что кнопка линковки для них не активируется.  Это значит, что тестируемое утверждение является ложью из-за термина "connection node". А вот в иной формулировке "верхнюю ноду проекта можно слинковать с любой папкой файловой системы или базы, кроме самого верхнего уровня" новшество действительно актуально для текущего билда. Вторая часть тестирования (перелинковка, синхронизация) выявили проблему отсутствия удаления скриптов из проекта, если соответствующих объектов нет в прилинкованных подпапках, и импорт однотипных объектов в дубликаты папок даже при включенной опции "Options / Preferences / Global Synchronization Settings / DB Objects / Script / Remove the script from the project if its source link breaks on refresh". 

Дубликаты папок после импорта

Можете сами попробовать: создайте пустой проект, подключитесь к базе простым юзером и прилинкуйте к верней папке проекта свою папку USER1 без добавления объектов, выполните синхронизацию из базы, переподключитесь к базе другим простым юзером без прав на чужие объекты и перелинкуйте верхнюю папку проекта на USER2 без добавления объектов, выполните синхронизацию верхней папки проекта с базой. В проекте у вас получатся дубликаты папок типов с различным наполнением скриптами из двух схем, хотя верхняя папка проекта связана лишь с одной схемой. Программист добавил возможности, но архитектор не продумал логичность ограничений. Итого, новшество зарабатывает лишь полбалла.

⦁ On opening the Links Manager or Project Assistant, the project tree is now filtered the same way as in the main window.
При открытии мастера линковки или ассистента проекта дерево проекта теперь фильтруется одинаково с главным окном.
Поясню, что под ассистентом проекта имеются ввиду мастера для создания проекта (для этого случая не подходит) и импорта в него файлов или объектов базы, а деревом проекта в этих мастерах считается то, что в правой панели. Выставим фильтр в дереве проекта через "Project Manager / Filter" и откроем мастер импорта скриптов и линковки. Да, дерево проекта отфильтровано аналогично, подложка его идентична и есть возможность обнулить фильтр в рамках мастера. Хорошо, что выключение фильтра не отражается на проекте в основном рабочем окне. При возвращении из мастера в основное окно добавленные или изменённые объекты отображаются согласно условиям фильтра. Новшество приносит балл билду. Единственный неприятный момент - снять фильтр в основной рабочей области довольно сложно кликом по кнопке и не только потому, что не с первого раза срабатывает отмена, но ещё и излишне активируется опустошённый мастер установки фильтра.
Project Tree    1 из 1 возможного
⦁ Selection of items in the project tree is now restored after analysis is completed and after closing the Analyzer Progress window, even if the analysis was not started.
Выбор элементов в дереве проекта теперь восстанавливается после окончания анализа и после закрытия окна процесса анализа, даже если анализ не начинался.
Весьма удобное новшество, которое было очень давно мной предложено по аналогии с выводом в отчёт лишь выбранных объектов проекта. Но, как уже говорилось в отчёте по предыдущему билду, в самом окне процесса анализа не хватает отображения количества выбранных для анализа элементов, в частности - скриптов. Да, их имена перечисляются при анализе и имена объектов при генерации диаграмм, но общее количество ещё не обработанных скриптов не известно.
Job Manager    0 из 1 возможного
⦁ Added the ability to delete scheduled jobs executed via a third-party scheduler if their scripts are no longer available.
Добавлена возможность удалять задачи по расписанию, выполняемые внешним запуском, если их скрипты больше не доступны.
Очень запутанное описание новшества придётся пояснять. В рамках менеджера задач термином "скрипт" можно назвать как объект проекта, так и bat-файл или scr-файл для запуска задачи. Какой из этих трёх скриптов может стать недоступным? Проект и его скрипты могут быть перемещены в недоступное пользователю CS место. Но настройки задачи таковы, что вместе с ними хранится только встроенный проект, а все остальные проекты могут быть на любых иных носителях. В любом случае, удалить задачу через менеджер расписаний можно всегда. Если говорить о scr-файлах, то их недоступность может быть только после переноса приложения на другую машину. Но даже в этом случае, список задач и расписание формируются по папке "%AppData%\Roaming\ClearSQL\Command Line Scripts\" из файловой системы, а значит в списке задач будут только доступные скрипты. Если говорить о bat-файлах, которые напрямую могут использовать именно сторонние запускатели, например, Jenkins, то после создания такими скриптами управляет лишь файловая система, поскольку в менеджере задач они не отображаются. В итоге, размытое описание новшества не даёт возможности как-бы то ни было его опробовать и даже понять смысл. То есть, за него не могу дать ни балла билду.

BUGS FIXED    1.5+1+0.8+0+1+0+0.7+0+0.6+1=6.6    из  4+3+3+1+1+1+1+1+1+1=17 возможных, -0.5-1-1-1-1=-4.5 за баги
Link Manager / Project Assistant / Import Wizard   0.8+0.7+0+0=1.5  из 4 возможных, -0.5 за баг
⦁ When a filter is applied to a parent node, its subnodes are now highlighted as filtered, too
Когда применён фильтр к родительской ноде, её подноды тоже подсвечиваются как фильтрованные.
В тестируемом окне всех трёх типов (новый проект, линковка или импорт) имеется три вида деревьев: файловая система и объекты базы в левой панели, макет дерева проекта в правой. О каком из деревьев речь, придётся нам самим выяснять, поскольку тех.писательница не удосужилась это конкретизировать. Файловую систему можно отфильтровать по имени и расширению файлов, по видимости скрытых, но на отдельную папку поставить фильтр возможности не существует. Значит его нет смысла тестировать. Дерево объектов базы можно отфильтровать по типам схем, исключив системные и демо. Но также в этом дереве можно устанавливать фильтры на каждую папку схем или типов объектов. Дерево макета проекта можно фильтровать по типам линковки и статусам скриптов, либо открыть уже отфильтрованное в главном окне. Похоже, что нам для теста нужно будет дерево объектов базы и вариант заранее отфильтрованного дерева проекта, потому что дерево файловой системы никаких пометок, кроме статусной строки, не отображает в самом фильтрованном дереве. Дерево проекта при наложении фильтра меняет цвет подложки, но применить к нодам можно фильтр лишь из одного источника: главного окна или текущего мастера. Да и фильтрации подвержено сразу всё дерево, а не отдельные его ноды и подноды. Поэтому остаётся проверить только дерево объектов. Маленькая подсказка: для сокращения тестов нет необходимости проверять поведение во всех трёх мастерах, поскольку технически они лишь меняют заголовки, а движок у всех единый. Выставим какой-нибудь фильтр на свёрнутую и развёрнутую ноды схем. Включение фильтра подкрашивает подноды развёрнутой ветки, а после разворачивания отфильтрованной ветки её папки типов объектов не имеют подложки в прошлом билде. А в текущем билде подсвеченными становятся папки типов после разворачивания отфильтрованной схемы. Но в обоих билдах существует проблема с очисткой фильтра, поскольку подложка не обнуляется со стиранием значения из поля условий фильтра, а лишь по уже бессмысленному клику по чекеру. Фикс есть, но из-за неточного описания получает лишь 0.8 балла. К тому же стоит снять -0.5 за интерфейсный баг при обнулении фильтра.
⦁ The caption of a filter condition applied to a linked node now correctly fits in the Filter Condition field.
Заголовок условия фильтра, применённый к линкованной ноде, теперь корректно умещается в поле условий фильтра.
В рамках предыдущего теста можно было подметить, что поле условий фильтра имеется только в дереве объектов базы. Также он показал, что текст условия фильтра на активную папку в прошлом билде имел задвоенный шрифт. Дополнительные тесты по размеру строки условий фильтра (длинное, автоподпор ширины столбца) не дали никакой разницы. Придётся считать, что фактически поправлен фонт шрифта значений в поле условия фильтра для локализованной ноды. Фонт не задваивался в других слинкованных папках, поскольку единовременно локализовать можно только одну папку. Вы видите, что текст RNs говорит совсем об иных вещах (заголовок - значение, вместимость - фонт, линкованная - локализованная), поэтому даю только 0.7 балла. И это ещё много, потому что нет точного указания на место фикса.
⦁ Fixed background coloring of a filtered database object tree.
Исправлена подложка, подкашивающая отфильтрованное дерево объектов базы.
Это дубликат первого пункта в группе RNs, поэтому балл не получает.
⦁ Fixed the autofit of the “Linked Source” column, applied after linking a root node with a Windows folder.
Исправлен автоподбор ширины колонки связанного источника, применяемый после линковки верхней ноды с папкой системы.
Это классический пример бага-фикции или временного. В прошлом билде этот баг не существовал, потому что привязку верхней ноды проекта стало можно осуществить только в текущем билде. А автоподбор ширины колонки для других папок работает идентично в обоих билдах. Приписка балла не приносит.
Analyzer View  0+0+1=1  из 3 возможных, -1 за баг
⦁ Fixed the autofit of the columns on the Project Analysis History tab.
Исправлен подбор ширины колонок на закладке историй анализов проекта.
Автоподбором ширины колонки называется такое изменение интерфейса, при котором становится полновидимым заголовок столбца и его содержимое. Автоматически ширина  колонки устанавливается при прорисовке грида и его фильтрации, а вручную - по двойному клику на правом разделителе заголовков столбцов. Растянем одну из колонок и дважды кликнем по правому разделителю. Ширина колонки не подбирается в обоих билдах. Изменим в настройках приложения формат даты и времени с малого на большой, например, полное наименование месяца, и для обновления данных в гриде отфильтруем их. Опять же, никакой разницы в поведении интерфейсов обоих билдов, и к тому же дата с полным наименованием месяца не вмещается в заголовках столбцов. Итог - никакого фикса не было, баг с длинным форматом даты не исправлен. Ни балла дать не могу, стоит ещё и снять за такое напоминание о старом баге.
⦁ Code review results now always fit in correctly regardless of the size of the main window.
Результаты правил кодирования теперь всегда корректно распределяются в ячейках, относительно размера главного окна.
Для теста поглядим на результаты демо-проекта суммарные и в разрезе скрипта. У скрипта ET_DEBUG_BODY есть длинные значения по правилу "Exception is not handled inside the unit", но двустрочные значения никак не вытягивают ширину первой колонки, хоть справа у таблицы и есть достаточно свободного места. Либо программист поправил что-то другое, либо тех.писательница придумала описание, но в любом случае билд недополучает балл.
⦁ Fixed the width of tab headers in the Script Analyzer View when only the “Modified script warning” instant help is enabled.
Исправлена ширина заголовков закладок в результатах анализа по скрипту, только когда встроенная подсказка о внесённых изменениях в скрипт включена.
Напомню, что панель с предупреждением о внесённых правках в скрипт появляется в области с результатами анализа скрипта и текстом кода, если включена опция "Options / Preferences / Main Window / Visibility of Instant Help for Analyzer View Panels / Miscellaneous / Modified script warning" и выбранный скрипт в статусе Modified. Эта панель перекрывает подсказку для закладки о результатах анализа, а в прошлом билде заголовок текущей закладки оставался прежней ширины, но без иконки для отображения его собственной панели с пояснениями. Хоть и очень мелкий, но фикс сделан, а значит билд зарабатывает балл.
Job Manager   0+0.8+0=0.8  из 3 возможных
⦁ Job execution no longer fails when the project root folder is linked to a database schema.
Исполнение джоба больше не прерывается ошибкой, если верхняя папка проекта связана со схемой базы.
Поскольку линковать верхнюю ноду проекта разрешено только с текущего билда, то баг никак не мог проявиться ранее. Это значит, что он был выявлен внутри команды разработки и считается временным. За его исправление нельзя дать балл, ведь нет никакой возможности утверждать наличие бага в предыдущих билдах.
⦁ The welcome screen no longer appears on job execution when a subscription license is applied.
Приветственное окно больше не появляется при выполнении джоба, когда применена лицензия подписки.
В чек-листе смоук-теста издавна имеется пункт о перекрытии всех излишних окон при исполнении джоба в скрытом режиме. Почему это не проверили сразу после изменения интерфейса окна старта и нового типа лицензии? Потому что в ConquestSS исключили тестирование из процесса разработки. И вот эта банальщина проявилась на стороне пользователя. Хоть мне и не начем проверить фикс, но могу авансом его засчитать. Только вот полный балл дать не получится, потому что в тексте не указали об особом режиме запуска джоба.
⦁ Removed broken links from HTML files generated as a part of job execution.
Удалены битые ссылки из html-файлов, генерируемых как часть выполнения джоба.
После выполнения джоба могут сгенериться html-файлы, как часть отчёта по проекту, либо отдельные файлы, как экспортированные данные результатов анализа. О каких конкретно идёт речь - не понятно. Также проблематично установить, какие из ссылок ConquestSS считает битыми: устаревшие ссылки на сайт компании или незакрытые теги. Поскольку структура отчёта и экспортированных файлов не менялись, то и о появлении в них битых, в прямом смысле, ссылок речи быть не может. К тому же, механизмы генерации отчётов и экспортов едины, как для джобов, так и для самостоятельных функциональностей. Поскольку об исправлении аналогичных багов не сказано в рамках Отчёта по Проекту и Экспорта, то можно не тратить время на исполнение джобов в разных билдах и последующее сравнение всех результатов по всем возможным вариантам файлов. Приписка к RNs балл не заслуживает.
Code Review Rules  0   из 1 возможного, -1 за баг
⦁ Fixed the layout of the Code Review Options page when DPI125% is applied.
Зафиксирован интерфейс страницы с опциями правил кодирования при масштабировании экрана до 125%.
В одном из предыдущих билдов мы уже смотрели проблему масштабирования этой страницы, касаемо панели фильтров. Проверка исправности окна на недосягаемость функционала не увенчалась успехом, а вместе с ней и не получилось выявить описаный фикс. Пункт RNs не приносит балл билду, а старый баг отнимает ещё один. Напомню, что в ConquestSS есть чит-лист обязательных проверок для нового и изменённого интерфейса, в числе которых доступность всего функционала при масштабировании экрана.
Project Report Assistant   1  из 1 возможного
⦁ Windows can no longer go into sleep mode while project report generation is running.
Окна больше не могут уходить в режим сна, пока выполняется генерация отчёта проекта.
Скорее всего под термином окон в данном случае имеется ввиду операционная система. Для теста придётся создать очень большой проект, чтобы формирование отчёта по нему выполнялось долше, чем выставлен таймер до перехода системы (только монитор или весь компьютер) в спящий режим. Да, в прошлом билде можно было остаться в неведении об окончании генерации отчёта, либо потерять впустую время до ухода компа в сон. Стоит заметить, что подобных длительных процессов, нуждающихся в ограничении системы от несанкционированного отключения, довольно много: сохранение громадных проектов, автоматическая работа джобов, экспорты из проанализированных проектов. В рамках комплексного тестирования подтвердилось, что процесс анализа давно уже контролирует отключение машины. Странным выглядит тот факт, что это удобство не было сразу применено ко всем длительным процессам в рамках приложения. Балл заслужен.
Link Manager  0   из 1 возможного
⦁ Applied consistent formatting to linked project items.
Применено последовательное форматирование к связанным пунктам проекта.
Никак не могу пояснить термин последовательного форматирования, поскольку никакой интерфейсной разницы в дереве проекта мастера линковки не замечено. Поэтому и балл дать не за что.
Synchronization Settings   0.7  из 1 возможного, -1 за баг
⦁ Removed the options “Recursively” and “Add empty folders” from the database objects sync settings as irrelevant.
Убраны опции рекурсивности и добавления пустых папок из настроек синхронизации объектов базы как утративших значимость.
Пустые папки из базы данных в большинстве случаев лишние и эта опция меня изначально смущала. Да и рекурсия для возможной вложенности только в два уровня папок базы данных всегда должна выполняться. Проверку изменения, которому мето не в числе багов, а в отдельном блоке удалений, проведём в два приёма: интерфейс настроек, регрессия функционала. Сверим внешний вид окон "Options / Preferences / Global Synchronization Settings / DB Object" и "Sync / Selection Sync Settings": в обоих случаях из блока "Folder / Import New Child DB Objects on Refresh from Linked Source" убраны две опции, но по непонятной причине оставлена "Folder / Write Back to Linked Source / Process child items recursively". Ещё раз напомню, что вложенность дерева объектов по схемам и типам объектов значима только для самих объектов, которых не бывает в верхней папке схемы, а две верхнии папки всего коннекта слинковать нельзя, да и несхемные объекты не считаются скриптами для проекта. То есть, интерфейсно изменение сделано только на две трети. Регрессию функционала проверим переключением удалённых опций в прошлом билде и выполнением импорта, обновления, перезаписи линкованных папок в текущем билде. К сожалению, текущий билд использует значения удалённых опций из предыдущего. То есть юзер нового билда всегда будет добавлять и обновлять линкованные ноды в зависимости от значений более недоступных опций, которые он выставил последний раз до перехода на текущий билд. Но если бы в текущем билде всегда принималось некое дефолтное значение удалённых опций, то регрессию можно было бы не оформлять. А так, за пункт RNs даю 0.7 балла и снимаю балл за регрессию.
Code Synchronization   0  из 1 возможного
⦁ Fixed the layout of messages that appear on adding and refreshing project tree items.
Исправлен внешний вид сообщений, которые появляются при добавлении и обновлении элементов дерева проекта.
Добавление элементов в дерево проекта происходит в рамках функции синхронизации при двух действиях: при ручном добавлении скриптов через мастер импорта, либо после синхронизации папки с ресурсом. Когда мы проверяли первое новшество этого билда, то могли проверить и этот фикс, откладывая скриншоты сообщений для последующей сверки. Это один из принципов комплексного тестирования, когда результаты одного теста пригождаются для закрытия различных тестовых вариаций. К сожалению, ни один из моих случаев добавления и обновления элементов дерева не показал разницы в сообщениях. Это значит, либо фикса не было, либо описание не конкретизировано. Поэтому не могу дать ни балла.
Analyzer Progress   0.6  из 1 возможного, -1 за баг
⦁ When call tree generation is turned off, “0” is shown next to the Call Tree label.
Когда дерево вызовов выключено из генерации, ноль показывается рядом с лейблой дерева вызовов.
Не генеря диаграмму, её можно провалидировать. В этом случае хоть чекер около строки прогресса и выключен, но "градусник" всё-равно будет пройден и в строке с количеством диаграмм отображается фактическое число деревьев вызова. Но если анализ скрипта сделать с удалением без валидации, то в текущем билде действительно их число будет отображено нулевым значением. Но, к сожалению, в списках диаграмм вызовов они становятся серыми без возможности отобразить контент только после валидации с удалением инвалидных, а не после более логичного простого удаления без перегенерации. То есть давнишний, более важный функциональный баг всё ещё не исправлен. Билд зарабатывает 0.6 балла, так как описание подразумевает три случая, а исполнен лишь один. И старый баг снижает ценность билда на балл.
Project Tree    1 из 1 возможного
⦁ The recycle bin is now located correctly even if the recycle bin node is not visible in the tree.
Корзина теперь корректно позиционируется, даже если нода корзины не видна в дереве.
Под видимостью ноды в дереве понимается её позиция в области видимых веток, а не какой-нибудь особый статус или фильтр. Для позиционирования на ветке корзины существует специальный пункт в главном и контекстном меню. Для воспроизведения бага развернём ветки дерева проекта, для чего вполне подходит демо-проект, и попробуем позиционироваться на корзине через экшены. Да, в текущем билде дерево проекта прокручивается само до нужной ветки, а не только обновляется информация в панелях результатов анализа. Балл за фикс даю, но термин "корректно" всё-же не стоит использовать без ссылки на документы или правила.

Итого по билду:   2.5+6.6=9.1  из  4+17=21  возможных, что равняется  9.1/21~43%  готовности билда, за выявленные баги придётся снять -1-4.5=-5.5 баллов.

Инфо-обмен

Команда из экспертов по информационным технологиям не только помогает другим обрабатывать информацию, но и сама вынуждена обмениваться знаниями.
В школе нас научили, что прежде чем передавать кому-то информацию, её необходимо систематизировать. На этом принципе основаны все учебники: тема, цели и задачи, оперируемые субъекты, основной материал, закрепление, проверка усвоенного. Цель моей статьи - описать knowledge management в группе разработки ПО. Задача - показать варианты обмена знаниями.
Будем считать, что группа разработки ПО состоит из руководства (шефы, директора), продавцов и техподдержки (сбыт-снабжение), разработчиков (аналитики, программисты), отк (тестировщики и пользователи). Какими знаниями они должны делиться друг с дружкой? На мой взгляд - всеми, касающимися продукта и процессов производства, распространения. Любой момент знаний в одной области может сыграть решающую роль в смежной. Вся группа нацелена получить максимальную выгоду и не только в денежном эквиваленте, а, например, в виде отзыва: "Именно это я давно хотел!". Моё совмещение техподдержки с тестированием на протяжении многих лет обязывало глубоко вникать в предметную область, что дало возможность генерировать множество полезных идей, воплощённых в выпускаемых продуктах. К сожалению, каждый раз приходилось заниматься самообразованием, а потом, терпя презрительные взгляды аналитиков, доказывать пользу моих идей. А если бы разработчики вовремя делились своими знаниями, то скорее всего идентичные предложения внедрялись бы от их имени, без "оскорбления их статуса".
Поскольку знания - это информация, то передавать и усваивать её человечество научилось несколькими способами:
- на слух: лекция, прослушивание аудио-записи, улавливание звуковых сигналов аппаратуры, диалог;
- просмотр видео и картинок, невербально мимикой и жестами;
- чтение текстов и схем;
- сенсорно через запахи и тактильность;
- очень редко с помощью телепатии.
Фантасты, конечно, предлагают и иные варианты, но современные технологии пока могут предложить только скорочтение и поиск по индексированному содержимому, доступные не искусственному интеллекту.
Переход поступающей информации в знания и есть процесс обучения. Курс "методика преподавания [предмета]" не ограничивается освоением таких методик, как лекция и практическое занятие. Обучать можно через игру и зазубривание, доказывая и веря на слово учителю, совершая открытия и отрицая гипотезы, строя логические цепочки и впитывая множественность хаотичных потоков. Пока мы в роли ученика, студента или стажёра, наши усваиваемые знания контролируются и оцениваются в явном виде (оценки в журнале и зачётке, контрольные работы, экзамены). В большинстве случаев объём и качество получаемой информации были в прямой зависимости со статусом в обществе через рейтинг отметок.
Аналогично кадровики рекомендуют изменения в зарплатах и карьере, исходя из данных матриц достижений (некоторые называют их матрицами знаний и навыков). Для большинства же работников приятнее осознавать свою значимость в проекте за счёт эксклюзивных умений и владения важной инфой. К сожалению, такие индивидуалы реже других готовы делиться знаниями, аргументируя тем, что ему самому они дались недёшево и просто так выкладывать новичку свои мозги не в его интересах. Подобному сотруднику предложите составить курс лекций с соблюдением всех правил методики преподавания, дайте в качестве дополнительной нагрузки (естественно с оплатой) учеников и обяжите создать подробное описание всех своих предыдущих и текущих дел, работ. Со временем он либо переквалифицируется в преподавателя и уйдёт в учебное заведение, если выдаваемые им знания довольно общие, либо он сбросит с себя нимб всезнайки и в дружеских беседах станет делиться тем, что приобрёл благодаря вашей компании. Для ускорения осознания снобом временности и ничтожности своей уникальности можно подсунуть ему в число учеников дотошного и любопытного новичка. Но это из разряда жестоких шефов.
По-моему, наиболее экономичный и эффективный способ передачи знаний новичку команды - это библиотека видео-записей. Рассказ вчерашнего новичка очередному стажёру - это игра в испорченный телефон. Обязательно забудутся важные моменты, готовый сотрудник тратит время на уже выполненную работу, вопросы остаются без ответа, либо переадресуются в исходную точку. Так было в Conquest:
- о работе тестировщика мой рассказ передавался в телефонных беседах более пяти раз, поэтому у последнего кандидата взгляд на работу отдела тестирования резко контрастировал с моим изначальным;
- о возможностях продуктов вначале рассказывал сам шеф, в качестве репетиции вебинаров для потенциальных покупателей. Но моё предложение записать хоть одну конфу для последующего сокращения своего же рабочего времени было отвергнуто. Взамен, он эту обязанность возложил на меня. Моя запись о возможностях одного из ведущих продуктов положила основу для библиотеки аудио- и видео-записей собраний (передача внутренних знаний новичкам, демо новых фич, обсуждение разработок, стендапы и ретроспективы) и сэкономила мне кучу времени впоследствии (текучка кадров была очень стремительной);
- видео-лекции о внутреннем распорядке (регламенты собраний, как оформлять код и документацию, схема утверждения задач и глобальная структура продуктов, структура движения ответов техподдержки) тоже следует делать один раз, поскольку попугайские повторения тим-лида раздражают не только его самого, но и слушатель перестаёт воспринимать информацию, выданную без эмоций, на автомате.
Хотя видео и аудио-записи пока ещё с трудом поддаются индексации для последующего поиска и актуализация содержимого равна полной переделке, но этот вариант передачи информации на сегодняшний день является наилегчайшим для восприятия. Аудио- и видео-обмен знаниями эффективен тем, что вполне легко можно применить способ закрепления - троекратное повторение мысли в различных интерпретациях (например, теорему Пифагора предлагают не только стандартно "квадрат гипотенузы равен сумме квадратов катетов", но и как графическую и стихотворную аналогию с "Пифагоровыми штанами").
Второй по восприимчивости тип передачи инфы - это картинки, схемы. Визуализация текста ярче запоминается. На этом факте был основан метод опор Шаталова. По этому же принципу создаются комиксы, столь популярные сейчас во всех возрастах. Mind-карта, созданная в процессе обсуждения разработки, вполне отчётливо может служить стенограммой встречи и готовой весомой частью техзадания или хелпа. Матрицы переходов состояния - лёгкий и удобный вариант описания теста. Flowchart, Call Tree и многие другие виды диаграмм - лучший способ визуализации продукта. Тем более, что современные технологии позволяют частичное редактирование и поиск для актуализации содержимого во всё более многих форматах (SVG, XML,..).
На мой взгляд собрания, типа стэндапов и ретроспектив, вполне подходят для совмещения обмена информацией в целях оповещения всей команды о ходе дел и параллельного обучения не только скрытым или сложным местам разрабатываемого продукта, но и новым, сторонним технологиям, которые вполне могут повлиять на развитие продукта. Если внимательно слушать каждого выступающего на стендапе, то обязательно появятся вопросы. Это упражнение было моим советом новичкам для повышения их авторитета в команде - шеф подмечал такое неравнодушие к изложению темы, как глубокое погружение в продукт. Тем не менее, осведомлённость деталями всегда способствовала качеству продукта - более главной цели при приобретении новых знаний. А в рамках еженедельных ретроспектив всегда полезно отчитаться перед всей командой о том новом, что удалось узнать о разрабатываемом продукте, его альтернативах, сторонних технологиях для улучшения своей работы. Небольшой рассказ или обычное перечисление узнанного в течение 3-5 минут экономит время сразу всей команде (известно становится, к кому можно будет в последствии обратиться за деталями, основы теории доносятся каждому одновременно), а по результатам заинтересованности составляется план обсуждений и разработок.
Классика жанра передачи знаний - текст в книгах и учебниках, статьях и научных работах, wiki всеобщего и внутреннего пользования. Для удобства и эффективности восприятия придерживайтесь общепринятых стандартов в структуре документа, отмечайте важные моменты, будьте краткими и содержательными при создании текстов, используйте простой язык и синтаксические конструкции. Немаловажна помощь каталогизации всей библиотеки. В последнее время актуальным стал словарь внутренних терминов и сокращений, а новообразованные слова от креативных сотрудников особенно требуют расшифровки. Например, от слов "эстимация" и "обфускация" новый сотрудник, знающий английский на уровне средней школы, входит в ступор. Также стоит составить список запрещённых к использованию слов и тем, поднимаемых на собраниях или в чатах. Например, шеф заставлял вместо "elucidate, describe" использовать только "explain", набрав в русскоязычную команду ребят из Восточной Украины под запретом стала тема мировой политики. Отрицательные моменты в познании нового через прочтение тоже, конечно, есть: самообучение без возможности задать сопутствующие и более подробно разъясняющие вопросы, нехватка условий (задания с ответами или примерами, оборудование для проб) для закрепления знаний, затраты времени на осознание (перевод) слов и терминов. Зато затраты на создание, хранение и актуализацию текстовых документов являются наименьшими в линейке типов передачи инфы. 
Передача знаний тактильно и по запаху возможна для некоторых продуктов: игры, кино, реабилитация здоровья, симуляторы редких и опасных профессий. Формы хранения, актуализации и передачи информации подобного типа пока ещё являются дорогостоящими и малодоступными широкому потребителю. Поэтому в качестве задания на закрепление мной излагаемого материала предлагаю эксклюзивным владельцам знаний тактильности и запахов описать способы передачи своего превосходства. К сожалению, мои примеры ограничиваются лишь 20 годами хореографии, развившими во мне мышечную память. Её применение помогает в тестировании довольно часто. Вы когда-нибудь задавали себе вопрос: "Почему в трёхпальцевой комбинации клавиш для перезагрузки 'Ctrl+Alt+Del' вы используете левые или правые клавиши 'Ctrl' и 'Alt'?" Как вас научили расставлять пальцы в первый раз, так вы и пытаетесь нащупать клавиши на любой клавиатуре. Пользуетесь обеими кистями рук или одним жестом Фиксиков? Чертыхаетесь на новом девайсе, когда не нащупывают в привычном месте нужную клавишу? А замечали за собой, что, прежде чем включить зарядку девайса, поглаживаете пальцами штекер? Да, это срабатывает ваша мышечная память для определения корректного положения "папа-мама/верх-низ".
Телепатия, как способ передачи знаний и прочей информации, некоторыми владельцами или заказчиками продукта считается наиболее приемлемым способом пояснить свои запросы. Вспомните те нередкие случаи, когда у собеседника кончались свои слова, а вы красиво и точно умудрялись описать его хотелки. Только они не учитывают тот факт, что подчинённые изначально не владеют чтением мыслей. Эта способность приобретается с годами при наличии постоянного контакта (наблюдение за процессом разработки, подслушивание обсуждений, получение информации из всех доступных и закрытых источников) и умении строить логические цепочки, в дальнейшем позволяет сотрудникам предугадывать желания руководства.
Соблюдая условия жанра, подведём итоги. Знаниями, которые вам кто-то дал или вы их приобрели самостоятельно, когда-нибудь надо делиться, передавать другим. Эффективность передачи знаний зависит от вашей подготовленности, но вы всегда получите дополнительную пользу - глубже поймёте суть и расширите собственный интеллект. Библейская заповедь о возврате розданного работает быстро и в ощутимом количестве. Знания не уходят в пустоту, существует много видов хранения и обогащения информации. Учитесь сами, обучайте других и затраты окупятся.

Про-хак

Одной из профессиональных черт тестировщика является хакерство, направленное на выявление слабых мест продукта. Любой производитель стремится выгодно продать свой товар. А чтобы получить наибольшую прибыль, предложение должно соответствовать запрашиваемому качеству. Обязательная или добровольная сертификация позволяет устанавливать высокую цену. Но современные бизнесмены, стартаперы чаще пытаются сыграть на раскрученных брендах, чтобы быстро разбогатеть. Поэтому давним поставщикам приходится защищаться, в том числе и лицензированием своего труда. И этот этап производства тоже должен быть протестирован, хотя не все уделяют ему должное внимание, сваливая его только на тестировщиков по безопасности.
Давайте рассмотрим несколько приложений, являющихся платными для постоянного использования тестировщиком. Но поскольку "бизнес по-русски" любит халяву, то любой из ниже перечисленных продуктов можно применять бесплатно неограниченное количество времени или раз, если взглянуть на них глазами истого тестировщика. Да, профессия обязывает нас обладать способностями хакера, и именно это качество помогает выявить злостные негативные тесты. Не буду вдаваться в юридические тонкости лицензионных соглашений, пусть эти тексты останутся на совести владельцев продукта. Нашей технической направленности вполне достаточно, чтобы показать несовершенство функционала, а значит и возможные пути потери прибыли.
WINDOWS
Операционная система, наиболее популярная у тестировщиков десктопных продуктов, вполне может обойтись без Интернета. И это является основополагающей причиной "украсть" лицензию.
Подтверждение серийного ключа происходит обычно в автоматическом режиме или индивидуальном через интернет, телефон. Да, лицензия ставится на одну машину, но может быть и переставлена на другую, более (менее) новую с точки зрения оборудования. Этот обходной манёвр чаще всего используют завхозы (сисадмины, девопсеры). Степень защиты, завязанная на "железо", в век быстро меняющихся технологий нельзя считать высокой. Компания Microsoft, понимая тенденции рынка компьютеров, сама отказалась от некоторой части прибыли, видимо посчитав её незначительной. Конечно, обновить такую версию можно только на одной из машин, но для отдела тестирования парк устройств чаще всего выстраивается именно в стиле разнообразия и надолго.
TestComplete
Среда тестирования десктопных, web- и мобильных приложений имеет пробный бесплатный период, длиною в месяц. Цена продукта самая низкая в линейке ему подобных, но и это не всегда по карману стартапам. Поэтому основные пользователи TestComplete чаще вынуждены извращаться и ограничиваться триалом. Даже триальный ключ имеет три стадии защиты: временной, привязка к оборудованию и операционной системе, генерация ключа на сайте компании. Но все эти уровни тоже можно обойти. Персональная информация для триального ключа не завязана на факте существования e-mail - хотя поле и обязательное для заполнения, но вводить можно не существующий адрес, например "aa@aa.aa". Персональную инфу собирают только для статистики, а не в целях уникального использования ключа. Наличие доступа в интернет на компе тоже не обязательное, ключ можно получить через соседнюю машину, да и существующий коннект не контролирует триальщика. Поскольку операционная система позволяет не закрывать сеанс годами, то это позволяет работать в одной запущенной сессии приложения более одного месяца. На моей памяти 7 месяцев на виртуальной машине без перезагрузки, поскольку однажды запущенное приложение не замечает регулярной смены дат. Но когда виртуальную машину пришлось перезапустить, а не остановить с открытым TestComplete, то только переустановка виртуалки и приложения позволила продолжить тестирование. Опасно, конечно, переводить дату на компах виртуальном и основном, это  "сжигает" триал, даже если вы не вышли за рамки периода. Моим выходом из ситуации стало следующее: на основной машине ставилась чистая виртуальная машина, копия файла виртуальной машины откладывалась в запасник, на виртуалку ставился TestComplete, запускалась среда тестирования и по возможности не закрывалась (если тесты не валили среду) длительное время, виртуальная машина тоже не гасилась, а только сеанс с самой виртуалкой закрывался. Поскольку запуск тестов никогда не проверял триальный период, то работать можно бесконечно долго, если тесты не требуют ручного перевода дат на компе. 
Продукты компании Atlassian (Jira, Confuence,..)
Почему из двух вариаций (облачной и серверной) русские бизнесмены выбирают серверную? Думаете, чтобы сохранить конфиденциальность разработок? Отнюдь нет. В серверном варианте доступно мелкое перепрограммирование, и минимальная версия на 10 пользователей вырастает в безлимитную. А ведь для небольших команд в 15-20 человек вполне достаточно работать в двух честно купленных 10-пользовательских приложениях, потому что работает импорт-экспорт задач, а команда тестировщиков вполне может пользоваться отдельной системой трекинга задач. Тестировщик не имеет права менять техзадание, нам достаточно только описания задачи. И программистам не важны шаги тестов, кроме новых локализованных багов и утверждённых лидом на правку. Халявщики-бизнесмены даже из фичи синхронизации могут извлечь собственную выгоду.
TOAD
Самая популярная среда разработки и тестирования базы данных Oracle хоть и имеет бесплатный триальный период, но его давно научились переводить в бесконечный и неограниченный. Не могу придумать причину, почему такой большой спектр пользователей-халявщиков не принимается во внимание. Программулька генерит ключ на персональной машине, как минимум до 12 версии. Запуск TOAD и весь его функционал не проверяет лицензию через сайт компании Quest ни в прямом, ни в скрытом режимах. Ключ теоретически имеет лишь две ступени защиты: реестр и файловая система. На мой взгляд - это слишком слабая охрана для столь распространённого приложения, которая не приносит прибыли ни Quest, ни альтернативным компаниям. Зачем создавать новый клон и пытаться на нём заработать, если оригинал в свободном доступе знают и используют давно?
Продукты компании Conquest Software Solutions
Излишество наворотов лицензионных ключей SQLDetective, ClearSQL и ClearDB не спасает от утечек. Любой из уровней защиты имеет способ обхода.  Двойной щит из реестра и файловой системы сам себя обходит единым IP-адресом машины с несколькими внутренними пользователями и подвиртуалками. Отключение интернета на момент старта приложения и выключение опций для скрытой отправки на сайт статистики пользователя охраняет нелегальных владельцев от разоблачения. Впрочем, сама инфа о владельце (количество и срок лицензий, AMS) компания Conquest автоматически отслеживает только по дате, а не уникальности пользователей, чем пользуются временные сотрудники, забирая домой или в иную организацию купленный ключ. На предоставленные мной факты незаконного использования лицензий CEO никогда не предъявлял претензии пользователям. Так что, как бы ни был лицензионный ключ  уникален по времени покупки в рамках данных по продукту и покупателю, и как бы не контролировала MySQL база одновременно-уникальные транзакции собственными средствами, но элементарный вывод компа с продуктом Conquest из локальной сети или перевод даты в рамках триального/арендуемого срока позволяют работать с продуктами многим и долго. Да, ограничение по дате контролируется стартом внутреннего функционала, но при этом не выполняется никакая синхронизация дат. Поскольку триальный ключ входит в инсталлятор, то он никак не зависит от данных пользователя и компа, только операционная система подсказывает дату окончания триала.

Что и на каких этапах обязан проверять тестировщик для подтверждения устойчивости лицензий и сертификатов?
Перечислю стандартный минимум, доступный тестировщику даже без стажа. Пропуск какой-либо нижеописанной проверки ведёт к проблемам с несанкционированным использованием вашего продукта, а иногда к отказу продолжать оплачивать лицензию. Своеобразный cheat-sheet для проверки лицензионного ключа:
- юридическое обоснование лицензионного соглашения, наличие и полнота системных требований для использования продукта в описательном документе, точность описания инструкции пользователя в хелпе и иных подсказках, полнота описания нового функционала и возможных проблем с вариантами решения в Release Notes;
- способы и места ввода персональной информации, влияющей на ключ продукта: sql-инъекции, региональные языки, спец-символы и тэги, размер данных (пустые-нулевые, максимум-минимум, переполнение, граничные,..), формат (текст, число, дата,..) и маска (разделители дробей, времени, имя с большой буквы,..), полнота заполненности и  обязательность полей;
- объём и содержание переданной информации для генерации ключа: необходимые и достаточные данные, поддержка региональных языков на сервере генерации ключа;
- объём и содержание переданного ключа пользователю: соответствие функционального набора оплаченным/заявленным опциям и полнота функционирования ограничений, защищённость передачи (файл прикреплён к e-mail письму, заархивирован с паролем, скачан с сайта производителя, код продиктован по телефону,..), поддержка в системе пользователя;
- техподдержка лицензии: автоматическая, регулярная, скрытая, ручной режим, оплата, база клиентов.

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

Храни меня..

Главное в работе тестировщика - сравнивать реализацию со стандартами. Для операции сохранения объекта стандартов нигде не прописано, значит мы в своих исследованиях должны оперировать привычными действиями от большинства крупных продуктов. Но с появлением Windows 10, как минимум одно приложение Notepad/Блокнот перестало быть логичным: окно редактора не закрывается по нажатию кнопки "х" с новосозданным файлом. Особенно странным выглядит это поведение на фоне всех остальных подобных редакторов, например, WordPad и MS Word.
Возможно аналогично размышляли и разработчики ClearSQL, когда программировали свой алгоритм для операции "Save As". По их мнению все изменения должны сохраняться как в новом проекте, так и в исходном оригинале.

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

Расширенная схема операций с объектом

1. SAVE / Операция доступна как для новосозданного объекта, так и для всех последующих его вариаций
1.1. объект существует
1.1.1. объект изменён
1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление
1.1.1.1.1. замена предыдущей версии объекта его новым вариантом / Обработка ошибок может выполняться на уровне операционной системы
1.1.2. объект не менялся
1.1.2.1. проверки файловой системы: доступ на запись/перезапись, изменение, удаление; разрешены изменения параметров объекта
1.1.2.1.1. замена параметров: даты-времени сохранения, без изменения даты создания объекта
1.2. новый объект создан
1.2.1. выбор места хранения нового объекта / Диалог выбора сервера/диска, папки для хранения объекта
1.2.1.1. присвоение имени новому объекту
1.2.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
1.2.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться  на уровне операционной системы
1.2.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
2. SAVE AS.. / Все изменения сохраняются только в новый объект. Первоначально открытая версия остаётся неизменной на момент открытия объекта в редакторе
2.1. выбор нового места хранения  / Диалог выбора сервера/диска, папки для хранения объекта
2.1.1. присвоение имени новому объекту
2.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
2.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
2.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
3. COPY TO..  / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
3.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
3.1.1. присвоение имени новому объекту
3.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
3.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
3.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
4. ARCHIVE / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
4.1. выбор одного или нескольких объектов для операции
4.1.1. уменьшение объёмов объектов / Функция стороннего архиватора
4.1.1.1. переформирование нескольких объектов в один / Функция стороннего архиватора
4.1.1.1.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
4.1.1.1.1.1. присвоение имени новому объекту
4.1.1.1.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
4.1.1.1.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
4.1.1.1.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
5. BACK UP / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
5.1. выбор одного или нескольких объектов для операции
5.1.1. сжатие, группировка объектов в один объект или папку / Опциональная функция стороннего копировальщика
5.1.1.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
5.1.1.1.1. присвоение имени новому объекту
5.1.1.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
5.1.1.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
5.1.1.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
6. DUPLICATE / Операция выполняется на основе последней сохранённой версии объекта. Количество дубликатов и новые уникальные идентификаторы объектов изменяются в процессе операции.
6.1. определение количества копий
6.1.1. авто-определение места хранения новых объектов / Используется внутренняя настройка редактора
6.1.1.1. проверки: прав на создание новых объектов, на объём свободного пространства / Обработка ошибок может выполняться на уровне операционной системы
6.1.1.1.1. авто-присвоение новых имён объектам  / Используется внутренняя настройка редактора
6.1.1.1.1.1. создание новых объектов / Внутренняя функция редактора
7. CLONE / Операция выполняется на основе последней сохранённой версии объекта. Копия возможна только одна, уникальный идентификатор объекта изменяется в процессе операции.
7.1. авто-определение места хранения нового объекта / Используется внутренняя настройка редактора
7.1.1. проверки прав на создание нового объекта, на объём свободного пространства / Обработка ошибок может выполняться на уровне операционной системы
7.1.1.1. авто-присвоение нового имени объекту / Используется внутренняя настройка редактора
7.1.1.1.1. создание нового объекта / Внутренняя функция редактора
8. Закрытие редактора с сохранением объекта / Диалог Save или Save As.. для сохранения объекта открывается в перечисленных случаях
8.1. кнопка ОК
8.2. кнопка Yes to All
8.3. кнопка "х"
9. Закрытие редактора без сохранения объекта / Редактор закрывается без предложения о сохранении изменений объекта в перечисленных случаях
9.1. кнопка Cancel
9.2. кнопка No to All
9.3. кнопка Skip
10. Параметры объекта, устанавливаемые/изменяемые в редакторе / Настройки объекта определяются в параметрах редактора, но могут изменяться в процессе сохранения
10.1. формат/расширение файла
10.2. тип данных столбца в таблице БД
10.3. статус подобъекта в проекте
11. Полезняшки/Удобства
11.1. горячие клавиши
11.1.1. Ctrl+S
11.1.2. Ctrl+Shift+S
11.1.3. самонастраиваемые/внутренние для редактора
11.2. стандартные окна и диалоги операционной системы
11.3. авто-предложение места хранения, локализация папки
11.4. фильтр расширений файла
11.5. авто-предложение нового имени объекта
11.5.1. по шаблону
11.5.2. постфиксы/префиксы
11.5.3. с добавлением даты-времени

Краткая схема обращения с объектом

1. Запустить редактор
2. Открыть объект в редакторе
2.1. редактор оставляет исходник как резервную копию в оригинале (место, имя, другие параметры)
2.2. редактор делает копию объекта во временном пространстве, но с темже именем
2.2.1. редактор отображает объект для последующей работы
2.2.1.1. в объект вносятся изменения
2.2.1.1.1. выполнить Save
2.2.1.1.1.1. резервная копия заменяется рабочей версией
2.2.1.1.1.2. обе идентичны
2.2.1.1.2. выполнить Save As..
2.2.1.1.2.1. рабочая версия объекта сохраняется в новое место с новым именем
2.2.1.1.2.1.1. новая версия объекта копируется во временное рабочее пространство, но с темже новым именем
2.2.1.1.2.2. резервная копия остаётся со старыми параметрами: место, имя, без модификаций
2.2.1.1.3. выполнить Clone, Duplicate, Back Up, Archive
2.2.1.1.3.1. проверка на наличие изменений
2.2.1.1.3.1.1. рабочий объект отличен от оригинала, вносились изменения
2.2.1.1.3.1.1.1. предупредить об изменениях
2.2.1.1.3.1.1.1.1. предложить применять операцию к объекту с изменениями
2.2.1.1.3.1.1.1.1.1. изменения объекта сохраняются / Сохранение в авто-режиме или через диалоговое окно
2.2.1.1.3.1.1.1.1.1.1. выполняется операция для рабочей версии, идентичной оригиналу
2.2.1.1.3.1.1.1.2. предложить откатить все изменения и применить операцию к исходной копии
2.2.1.1.3.1.1.1.2.1. рабочая версия с последними несохранёнными изменениями уничтожается
2.2.1.1.3.1.1.1.2.1.1. создаётся новая рабочая версия объекта из оригинала
2.2.1.1.3.1.1.1.2.1.1.1. выполняется операция для рабочей версии, идентичной оригиналу
2.2.1.1.3.1.2. рабочий объект и его оригинал идентичны, изменений не вносилось
2.2.1.1.4. закрыть редактор / Закрыть окно редактора можно: из меню Exit/Close, по кнопкам интерфейса "х" или Close, по нажатию горячих клавиш Alt+F4 (стандарт в Windows). При наличии изменений в объекте закрытие редактора зависит от ответа в диалоге о сохранении объекта.
2.2.1.1.4.1. предупредить о наличии изменений
2.2.1.1.4.1.1. диалог о сохранении объекта закрывается по кнопке OK, Yes, Yes to All, Save
2.2.1.1.4.1.1.1. изменения объекта сохраняются  / Сохранение в авто-режиме
2.2.1.1.4.1.1.1.1. оригинал заменяется рабочей версией: запись поверх или уничтожение оригинала и копирование рабочей версии на место оригинала
2.2.1.1.4.1.1.1.1.1. удаление рабочей версии из временного пространства
2.2.1.1.4.1.1.1.1.1.1. закрытие редактора
2.2.1.1.4.1.2. диалог о сохранении объекта закрывается по кнопке No, No to All
2.2.1.1.4.1.2.1. оригинал остаётся неизменным
2.2.1.1.4.1.2.1.1. удаление рабочей версии из временного пространства
2.2.1.1.4.1.2.1.1.1. закрытие редактора
2.2.1.1.4.1.3. диалог о сохранении объекта закрывается по кнопке Cancel, Close, "x"
2.2.1.1.4.1.3.1. оригинал остаётся неизменным
2.2.1.1.4.1.3.1.1. рабочая версия остаётся в прежнем состоянии
2.2.1.1.4.1.3.1.1.1. редактор остаётся открыт с рабочей версией объекта
Дальнейшие операции (редактирование, перемещение) применяются к рабочей версии, идентичной оригиналу

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

Громозека

У Алисы в мультике "Тайна третьей планеты" показан друг с множеством рук и глаз - это типичный образ тестировщика, совмещающего техподдержку, devops и прикрывающего огрехи руководства. Многие годы мне приходилось работать на 2-5 машинах одновременно, благо, у каждой был свой монитор или даже два. Поэтому образ Громозеки - это был мой портрет.
В рамках повышения квалификации при отсутствии финансирования единственным выходом было прослушивание и краем глаза просматривание докладов с сайтов sqadays.com и analystdays.ru. Естественно, хотелось делиться знаниямя, и ссылки на лучшие доклады с рекомендательными описаниями публиковались от моего имени  в рабочем чате. Но такая инициатива была прервана шефом со словами: "Хватит устраивать избу-читальню.", а через несколько дней он сам стал публиковать в этом же чате ссылки, но уже не на аудио-видео-записи, а на статьи. Тоже в немалом количестве. Как видно из примера, практика двойных стандартов работает не на пользу горе-руководителю. Мой способ предлагал узнавать что-то новое, не отвлекаясь от основной работы, поскольку прослушивать доклады и изредка проглядывать слайды, останавливать запись или прокручивать на несколько минут назад - вполне реальные действия, которые можно совмещать с трудом monkey-кликальщиков или перепроверкой багов, тестов по check-list или наблюдением за работой авто-теста. К слову сказать, нагрузочные тесты, которые сжирают все ресурсы, выдавались PM-ом (Product Manager) тестировщикам с одной единственной машиной по VPN (Virtual Private Network), при этом собственный комп по-сути простаивал (процессы теста крутились на сервере и не мешали прогулкам по Интернету). Поэтому у них образовывалась отличная дыра по времени, которое очень полезно было использовать для самообучения.
Слушать доклады проще, чем читать аналогичную статью - докладчик голосом расставляет нужные акценты и восприятие материала увеличивается. А при прочтении внимание целиком погружается в текст и взглянуть на продвигающийся параллельно тест получается с опозданием. Дополнительно, обучение через прослушивание, а не прочтение, помогает развить человеческую многозадачность. Моя способность многопоточных действий развивалась за счёт прослушивания радио во время подготовки уроков в школе и институте. Привычка слушать Маяк, а потом Радио-РИФМА, и одновременно решать задачи или заучивать теорию увеличивала те самые нейронные связи, которыми очень удобно стало пользоваться при совмещении нескольких должностей, превратившись в Громозеку.
Моей рекомендации - совмещать прослушивание докладов с обычными рабочими задачами - последовали немногие. Мотивируя тем, что параллельный звук их сильно отвлекает. Да, программисту во время сочинения кода не стоит отвлекаться на иные теории, но если кодирование ограничено CopyPaste-ом, то это удобный случай начать развивать связи в головном мозге и повышать уровень знаний. Этаже многозадачность помогала мне одновременно отвечать в 3-5 каналах рабочего чата, сокращая в несколько раз время на излишние митинги.
Данная статья образовалась после прослушивания доклада Игоря Макарова "Социальная сеть для бизнес-анализа внутри компании", после которого моя позиция о пользе чатов (не надо ловить у других сотрудников свободное время для митинга или строго соблюдать часовые пояса, обсуждение и выводы уже задокументированы, параллельно можно вести несколько бесед, экономия своего и общекомандного времени) только укрепилась. Но странно, что вместо бесплатного Slack используется решение Workplace от Facebook. На фоне участившихся взломов аккаунтов многоизвестной соцсети распространение внутренней информации группы разработки в достаточно закрытом чате Slack выглядит более защищённым. Да, в Workplace есть возможность блогов, но группы открытые и персональные в Slack, а также цитирование, цепочки, отметки важности, закрепление на доске, поиск и связь с внутренними системами отслеживания задач - всё это говорит только в плюс при использовании самостоятельного чата вместо группы соцсети. А звонки в обоих приложениях входят в платную версию. На мой взгляд бесплатный чат в полном выигрыше, особенно для agile-команд, ценящих время, так как история переписки доступна в течение месяца, а значит есть стимул быстрее решать вопросы. 

ТО о CS 8.0.1.137

Тест-отчёт о ClearSQL 8.0.1 (build 137), выпущенном 6 декабря 2018 года, проведён по тексту Release Notes, который вы можете найти в самом приложении, но нигде на официальном сайте компании ConquestSS. Предыдущий билд был меньше месяца назад, значит этот содержит какой-то критичный фикс, выявленный конечным пользователем. Обычно такие билды содержат мелкие усовершенствования и фиксы нескольких минорных багов, что не успели включить в первый выпуск новой версии. Давайте поймём, какого бага билд.

IMPROVEMENTS 0.6+1.6+0.5+0.6+0.9=4.2 из 1+2+1+1+1=6 возможных
Project Backup 0.6 из 1 возможного
* Added the ability to password protect project backup files.
Добавлена возможность защищать паролем файлы копии проекта.
Архивированную копию проекта с результатами анализа можно сделать через пункт главного меню "Tools / Backup Project / Create". В этом окне появился ещё один блок "Protect Backup File" с двумя полями для ввода и подтверждения пароля. Странным выглядит опция отображения реальных символов пароля вместо имеющегося в приложении переключателя в виде иконки-глаза. Ограничения по назначению пароля описаны во встроенной справке, но они слишком преувеличены, поскольку длина и обязательность разных символов не всегда востребована. А сообщение об ошибке при попытке сохранить пароль, не удовлетворяющий хоть одному из правил, хотели отображать красиво, но не смогли.

Красивая подпись не отобразилась

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

Региональная система или внутренние стандарты

Здесь также стоило упомянуть, что восстанавливать проект можно только в текущей и последующих версиях CS, потому что моя попытка восстановить запароленный проект в предыдущем билде привела к необработанному исключению. Но в качестве выхода из положения, такой архивный файл легко распознаёт Total Commander, а вот встроенный в операционную систему Explorer требует привязки архиваторов по расширению файла. Ещё одно, что меня смутило в обновлённом интерфейсе - это появляющиеся коричневые галочки рядом с корректно введённым паролем. Если набор символов полностью удовлетворяет правилам, то более логично пометить их зелёным (свободно) или синим (рабочий), но не красным (стоп) оттенком. Конечно же в рамках этого новшества необходимо протестировать и восстановление проекта из копии. Мастер, доступный из главного меню "Tools / Backup Project / Restore..", тоже пополнился блоком для ввода пароля, необходимость которого определяется автоматически. Лишней мне видится встроенная подсказка об обязательном наборе символов в строке пароля. Более полезным было бы дополнение с подсказкой, как это организовано для доки CDB, но сторонний архиватор (7z.dll) врядли поддерживает подобный функционал. Из-за излишних и нелогичных наворотов даю лишь 0.6 балла.

Technical Debt 0.8+0.8=1.6 из 2 возможных
* Moved the Technical Debt column to the beginning of all grids where this value is used.
Колонка технического долга сдвинута в начало всех гридов, где эта величина используется.
* Technical debt values in the grids and on the Summary page are now rounded to the nearest whole number.
Значения технического долга в гридах и на странице итогов теперь округляются до ближайшего целого числа.
Проверим оба изменения одновременно, поскольку они довольно мелкие и касаются одних и тех же мест. На самом деле изменению подверглись только две таблицы с метриками кода: в разрезе скрипта и на закладке Summary. А таблицы с историями анализов по скрипту и проекту изначально показывали величину технического долга округлённо до доллара и на первой позиции в списке метрик. Все же остальные визуализаторы результатов анализа (диаграммы и суммарные данные) не изменились. Когда-то из-за смены дефолтного значения одной из метрик пользователь требовал возврата затраченных средств. Возможно, предыдущее округление до цента тоже было более важно юзерам, нежели сегодняшнее - до доллара. По-моему, такие вещи надо предоставлять через настройку: хотите округлять или нет, до какого знака вам важно. Кстати, для отображения величин в новом формате совсем не требуется переанализировать проект или отдельные скрипты, то есть изменение прошло жёстко и безусловно. Поэтому за изменения даю только по 0.8 балла.

New Project Assistant 0.5 из 1 возможного
* Renamed options of the file extensions filter.
Переименованы опции фильтрации по расширению файлов.
Открыв мастер создания нового проекта на закладке "From Files" вы не найдёте никаких изменений даже в контекстном меню. А вот на странице "Options / Preferences / New Project, Import and Link Manager" настроек приложения действительно только одна опция для фильтров по расширению файлов претерпела изменения и не только в наименовании, но и обрела встроенную подсказку. За столь убогий текст RNs вините тех.писательницу. А билду дам лишь 0.5 балла.
CRUD Matrices 0.6 из 1 возможного
* Renamed “stored programs” to “subprograms” in the heading of CRUD1 matrices.
Хранимые программы переименованы в подпрограммы в заголовке матриц CRUD1.
Во-первых, никакого наименования хранимых программ в матрицах не существовало. В CRUD1 и CRUD2 хранимые объекты именовались как Stored Objects. Во-вторых, почему переименованию подверглись только CRUD1, а в матрицах CRUD2 оставлено старое наименование? В-третьих, в матрицах CRUD1 переименованию подверглись не все заголовки и идентично отражены в отчёте по проекту. И ещё, чтобы изменение заголовков произошло, необходимо переанализировать все скрипты с обращениями к объектам данных и обязательно их матрицы. Этого не сказано нигде. Из-а четырёх недочётов даю лишь 0.6 балла. 

Половинчатое переименование

Summary Info 0.9 из 1 возможного
* Updated the hint of the “Lock” button.
Обновлён хинт кнопки блокировки.
Напомню, что кнопка замка при красном значении замораживает текущие итоговые значения и не меняет их при смене нод в дереве проекта, а при зелёном состоянии автоматически обновляет итоги анализа в соответствии с выбранной нодой дерева проекта. В текущем билде хинт сменился только у зелёного замка на тулбаре (про такую же иконку на закладке Summary вроде речи не было). Текст стал однострочным вместо двустрочного и более понятным юзеру в плане смысла, но времени на прочтение такого длинного текста маловато. Странно, что не применено правило ConquestSS об удержании хинта до сдвига курсора. Несоблюдение внутреннего правила приносит билду лишь 0.9 балла.

BUGS FIXED 1+0.7+0+0+0.5+0.8+0+1+0.5+0=4.5 из 1+1+1+1+1+1+1+2+1+1=11 возможных, -2 балла за баги
Code Review Rules 1 из 1 возможного
* The rule “Unreferenced local variable” is no longer triggered in a compound trigger for the variables that are used in the code.
Правило локальных переменных без ссылок больше не срабатывает на переменных составных триггеров.
Для понимания сложных (составных) триггеров стоит изучить документацию базы данных Oracle. Для теста воспользуемся примером из документации Oracle 12.2:
-----Example 9-5 Compound Trigger Avoids Mutating-Table Error 

CREATE OR REPLACE TRIGGER Check_Employee_Salary_Raise 

  FOR UPDATE OF Salary ON Employees 

  COMPOUND TRIGGER 

  Ten_Percent CONSTANT NUMBER := 0.1; 

  TYPE Salaries_t IS TABLE OF Employees.Salary%TYPE; 

  Avg_Salaries Salaries_t; 

  TYPE Department_IDs_t IS TABLE OF Employees.Department_ID%TYPE; 

  Department_IDs Department_IDs_t; 

-- Declare collection type and variable: 

  TYPE Department_Salaries_t IS TABLE OF Employees.Salary%TYPE INDEX BY VARCHAR2(80);

  Department_Avg_Salaries Department_Salaries_t; 

  BEFORE STATEMENT IS 

    BEGIN 

      SELECT AVG(e.Salary), NVL(e.Department_ID, -1) 

        BULK COLLECT INTO Avg_Salaries, Department_IDs 

        FROM Employees e 

        GROUP BY e.Department_ID; 

      FOR j IN 1..Department_IDs.COUNT() 

        LOOP Department_Avg_Salaries(Department_IDs(j)) := Avg_Salaries(j); 

      END LOOP; 

  END BEFORE STATEMENT; 

  AFTER EACH ROW IS 

    BEGIN 

      IF :NEW.Salary - :Old.Salary > Ten_Percent*Department_Avg_Salaries(:NEW.Department_ID) 

        THEN Raise_Application_Error(-20000, 'Raise too big'); 

      END IF; 

  END AFTER EACH ROW; 

END Check_Employee_Salary_Raise;

Анализ этого скрипта в предыдущем билде даёт все четыре переменные, кроме типов, при проверке вышеозначенного правила №31, в текущем билде никакие переменные не подпадают под правило. Из чего заключаем, что смоук-тест приёмки фикса проведён успешно. Для полноценной проверки необходимо варьировать структуру скрипта и типы переменных. Нам же достаточно для пометки наличия изменений.
Core 0.7 из 1 возможного, -2 за баги
* Values of the Quality Trend no longer differ from the relevant values in the Project Analysis History.
Величины направления качества больше не отличаются от соответствующих значений в истории анализов проекта.
Согласно тексту хелп-топика "Project Analyzer View – Summary tab" в CS существует четыре параметра для оценки направления качества: количество критичных и важных багов, превышения метрик кода, технический долг и ошибки парсера. Для проверки фикса нам придётся вручную выписать значения из одного из источников (хинты графиков "Summary / General / Quality Trend"), а потом визуально сравнить их с соответствующими в другом (таблица на закладке "Project Analysis History" по проекту или "Script: Editor and Analyzer Info / Analysis History" по одному скрипту). К сожалению, в отчёт "Analyze / Analysis History Report" не попадают два параметра: общее количество критичных и важных проблем, объём технического долга. Также надо выполнить анализ одного скрипта или всего проекта в обеих версиях CS, не меняя параметры анализа. 

Различия помечены цветом

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

1) даты и время анализов демо-проекта различны в отчёте и интерфейсе;
2) в отчёте показывается время начала и окончания анализа, а в интерфейсных данных только время окончания;
3) помимо отсутствующих данных по количеству критичных и важных проблем, технического долга в отчёте другие два параметра кардинально отличаются от интерфейсных.
Это говорит о том, что внутренняя база проекта хранит накопительные итоговые величины в дублируемых таблицах и полях, что в итоге запутывает пользователя CS. Поскольку основной фикс сделан лишь на три четверти, то и дам за него 0.7 балла. При этом сниму за сопутствующие баги (путаница с данными в демо-проекте, различные данные в отчёте и интерфейсе) -2 балла.
Link Manager / Import Wizard / New Project Assistant 0 из 1 возможного
* Fixed the autofit in the columns of the project tree pane.
Зафиксирован автоподбор ширины колонок панели дерева проекта.
К сожалению, тех.писательница не уточнила, при каком действии эта правка применима к интерфейсу. А поскольку при открытии мастеров и при добавлении в проект файлов или объектов с длинным именем первая колонка макета проекта CS по прежнему обрезает полное имя скрипта, то считаю пункт RNs припиской и не прибавляю билду ни балла.
Analyzer View 0 из 1 возможного
* Fixed the autofit on the Code Review tab when the “Show filtered violations only” option is enabled.
Исправлен автоподбор ширины закладки правил кодирования при включенной опции показа только отфильтрованных предупреждений.
Стоит пояснить, что речь идёт только о результатах анализа в разрезе скрипта, а именно о закладке "Script: Editor and Analyzer Info / Code Review". На тулбаре этой закладки может появиться опция для отображения только фильтрованных правил только в случае активации фильтра на дерево проекта по каким-нибудь правилам кодирования. Для этого надо включить опции "Project Manager / Filter / Filter Enabled " и "Project Manager / Filter / Filter Enabled / By Parser Status / OK Alert ", выбрать какие-нибудь значения из выпадающего списка "Project Manager / Filter / Filter Enabled / By Parser Status / OK Alert / By Code Review" и применить фильтр по кнопке "Project Manager / Filter / Apply". Включенная тестируемая опция прячет два комбобокса фильтров на тулбаре, а выключенная вновь их отображает. При этом никакой разницы в автоподборе ширины закладки не замечено ни в текущем, ни в предыдущем билдах. Поэтому балла дать не могу.
Analysis History 0.5 из 1 возможного
* Fixed the hierarchy of code metrics values.
Исправлена иерархия значений метрик кода.
Когда мы проверяли улучшение о техническом долге, то смотрели и на таблицы историй анализов. Там можно было подметить, что истории по проекту ветки Метрик и Правил кода из группы Ошибок и Предупреждений вынесены в самостоятельные, а в историях по скрипту только Метрики кода вынесены в самостоятельную группу, а Правила кодирования остались веткой группы Ошибок и Предупреждений. Поскольку фикс описан лишь половинчато, и фикс сделан только на три четверти, то даю только полбалла.
Database Connection Window 0.8 из 1 возможного
* The Database drop-down list is no longer limited to 8 values.
Выпадающий список баз больше не ограничен 8-ю значениями.
В окне подключения к базе данных имеется комбобокс "Database:" в блоке "Connection Type" при режиме TNS. По-умолчанию, интерфейсный компонент Delphi отображает первые 8 значений, но этого слишком мало для администраторов баз крупных предприятий. Немного странно, что это улучшение означено исправлением бага. Но за то, что изменение коснулось лишь одного из шести аналогичных компонентов на форме и в тексте нет точного указания о его расположении, за исправление дам лишь 0.8 балла.
CRUD Matrices 0 из 1 возможного
* Fixed the position of the stored program pop-up menu when a Call Tree diagram is opened.
Исправлена позиция контекстного меню хранимой программы, когда открыта диаграмма вызовов.
Когда чуть ранее проверяли переименование заголовка нужно было приметить описанный фикс, чтобы сократить общее время тестирования. Полагаю, что пытались исправить позицию контекстного меню для объектов в матрице CRUD2, поскольку дерево вызовов открывается рядом с CRUD1 и в самостоятельном плавающем окне для CRUD2. К тому же, линки объектов в CRUD1 однозначные, а в CRUD2 могут работать в трёх вариациях через это самое меню. К сожалению, когда в CRUD2 открыто окно с деревом вызовов, то тестируемое контекстное меню и в прошлом, и в текущем билдах позиционируется довольно далеко от самого линка с именем объекта. Так что, фикса нет и балла нет.
Summary Info 1+0=1 из 2 возможных
* Fixed the caption of the Code Review Options command on the pop-up menu of the Summary tab.
Зафиксирован заголовок команды опций правил кодирования в контекстном меню закладки итогов.
Для вызова опций анализатора на странице со списком правил кодирования в контекстном меню закладки "Summary / Code Review / Top Violated Code Review Rules" имелся пункт с глючным наименованием "aAnalyzerOptions". В текущем билде это имя поправлено на понятное юзеру, а не программисту. Балл добавляется.
* The “Synchronization” and “Parser Errors” panel no longer appears empty on first opening.
Панели синхронизации и ошибок парсера больше не появляются пустыми при первом открытии.
Во-первых, необходимо определиться, какое открытие и чего стоит считать первым: чистую установку приложения на комп или активацию закладки Summary сразу после запуска приложения? Момент второй в том, что обе панели по-умолчанию не входят в обязательный показ, а при ручном отображении располагаются где-то снизу, при этом вертикальный скроллер отсутствует на всех подзакладках Summary. В прошлом билде обе панели появляются с соответствующими значениями при любом их открытии, поэтому баг не засчитывается в процент готовности билда.
GUI 0.5 из 1 возможного
* Fixed the layout of options in the Startup window.
Зафиксировано расположение опций в окне старта приложения.
Как уже упоминалось в предыдущем билде, где окно старта как-бы поделили на два, а пользователям разных лицензий доступна различная информация, давайте определимся считать окном старта только то, где есть три типа выбора проекта, а не выбора лицензии. Момент второй: окно старта безусловно показывается триальщику, который не может выключить его последующий показ, так как опции нет в самом окне и она в недоступном режиме в настройках приложения "Options / Preferences / General / Application Launch / Show startup window". Это значит, что тех.писательница промахнулась с использованием термина options в смысле настроек. Тогда попробуем выяснить изменения функционала. Единственное, что мне удалось раздобыть - это добавление линка на сайт производителя для пользователя постоянной лицензией с оконченным AMS для продления сервиса. В этом плане пункт RNs совсем не является фиксом бага, а дополнительным усовершенствованием. Учитывая такие промахи тех.писательницы могу дать только 0.5 балла.
Telegram 0 из 1 возможного
* Opening Telegram no longer causes ClearSQL to stop working.
Открытие Телеграма больше не вызывает остановку работы CS.
Открытие интерфейса Телеграм-чата из главного меню тестируемого приложения автоматически выполняет коннект к настроенному интернет-каналу. Все длительные процессы (анализ, генерация отчёта, выполнение джоба, открытие или сохранение большого проекта и тому подобное), которые согласно тексту RNs ранее прерывал Телеграм, отображаются в модальных окнах. Это значит, что во время длительной работы CS главное меню недоступно и юзер никак не может открыть Телеграм. Даже если перефразировать и предположить, что открытие окна Телеграма блокирует весь остальной интерфейс CS, то и эта гипотеза не подтверждается тестами - не было бага и ничего не исправлено. Отсутствие конкретики в тексте RNs превращает их в нелогичную ложь, за которую билд теряет очередной балл.

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

Числовые не все подкрашены в одной строке

Соседние строки в разном шрифте

2. Перечитав хелп-топик про технический долг в глаза бросились две опечатки - математическая (сумма процентов больше 100) и синтаксическая (с предлогами или артиклями проблема у тех.писательницы). 

Сумма процентов

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

Строки и блоки кода равновелики

4. Наиболее обескураживающим выглядит дублированный сам результат о дубликатах: в расшифровке выявленного дубликата одним из значений считается сам исходник сравнения. То есть некий объём строк сравнивают не толлько с остальными строками скрипта, но и с самими же? 

Дублирование себя

5. Сортировка результатов о дублировании не логична: от большего к меньшему или никакой сортировки нет? 

Странность сортировки

6. Инструментирование кода автоматически форматирует скрипт, даже если в настройках анализатора выбран по-умолчанию режим без форматирования. 

Неожиданное изменение кода

7. В прошлом билде упоминалось, что комментарии к скрипту, добавляемые при импорте объекта из базы данных, должны показывать владельца и имя объекта. Но дело даже не в том, что эти поля пустые, а в том, что в этих комментариях не хватает информации о текущем Edition, при котором делался экспорт из базы. Также мастеру импорта объектов из базы не хватает опциональной смены Edition на время считывания хранимых объектов из этой базы.
8. Таблица метрик кода по скрипту в обычном режиме свёрнута по группам колонок. Но первое разворачивание одной из групп не добавляет закладке горизонтальный скроллер, из-за чего часть данных остаётся недоступной, поскольку здесь не работают клавиши перемещения курсора с клавиатуры. 

Недоступные колонки справа

9. Если список результатов о правилах кодирования сворачивать, начиная с нижних строк, то может возникнуть ситуация без вертикального скроллера и невидимых элементов начала списка. 

Ни верхних строк, ни скроллера

10. Правило кодирования №132 о проценте инструментирования гласит о каком-то специфицированном минимуме, но мастер по настройке правила не имеет опции по его изменению. Только в пояснении к правилу сказано о 50%. 

Параметры правил следует менять опционально

11. Синхронизация проекта с линкованными папками и скриптами проходит по всему проекту, не взирая на установленный фильтр в дереве проекта. Хинт кнопок синхронизации содержит волшебное слово "выбранные", которое абсолютно не учитывается их функционалом.
12. Ширина тулбара у дерева проекта в мастерах линковки, импорта или создания нового проекта предостаточно для отображения длинных наименований фильтров, но пустое пространство используется не по назначению. 

Бесполезные пустоты

13. В окне процесса анализа очень не хватает общего количества скриптов до и в процессе анализа. 

Нет полезной инфы о количестве анализируемых скриптов

14. Обнуление фильтра дерева проекта двойным кликом по соответствующей иконке (синяя воронка с красным сигналом) на заголовке колонки "Folders and Scripts" получается лишь на третий раз.
15. Переанализ скрипта с удалением диаграмм вызова на самом деле не удаляет их и не помечает неактуальными. Но если переанализ выполнить и без CRUD данных, то диаграммы вызовов удаляются.
16. Количество выбранных папок фантастическим образом подсчитывается для данных панели "Summary / General / Folders, Scripts, Script Statuses". В одном проекте у меня есть три папки первого уровня, в первой из которых содержится семь папок второго уровня, в некоторых из которых есть по одному-два скрипта. Итого, эта папка содержит 7 подпапок и 6 скриптов. Выбирая по одной из подпапок, галки с чекеров папок сами пропадают при выборе следующей, результат отображается реальный. Если же после этих кликов выбрать всю верхнюю папку, то количество скриптов показано верно - 6, а папок чарт насчитывает - 15. Далее ещё интересней. Начните снимать по одному чекеры с подпапок. Количество скриптов никак не будет меняться, а количество папок будет по одной уменьшаться. В итоге можно докликать до такого состояния, когда в дере проекта чекр стоит только у верхней папки, эта же нода одна подсвечена, а в чарте 8 папок и 6 скриптов при явно видимой выбранной одной ноде с постфиксом (7/6)! Ну да, вместе с папкой первого уровня их 8 и внутри папок всего 6 скриптов, и в заголовке панели Summary указан путь папки первого уровня. Но зачем же тогда на каждый клик в дереве проекта перерисовываются все чарты панели Summary? Чтобы запутать юзера! То ли они показывают инфу о подсвеченных нодах, то ли об имеющих чекер. Но у скриптов в дереве нет чекеров! Как юзеру их считать выбранными для Summary? Вот такая волшебная синхронизация дерева проекта с итоговыми данными.
17. В дереве проекта папки можно слинковать с файловой системой или базой данных. Но увидеть прилинкованный путь негде. Для этого есть лишь одно место - мастер линковки. А у скриптов такая информация доступна на закладке свойств среди результатов анализа.
18. Разлинковка папки через мастер линковки отвязывает лишь одну эту папку. А разлинковка через главное или контекстное меню "Sync / Unlink Selection" приводит также к отвязыванию всех входящих в папку элементов.
19. Попытка создать шаблон для исключённых правил кодирования привела меня к ошибке неполного оформления. Форма для создания и редактирования таких шаблонов не имеет пометок обязательности полей, поэтому работа юзера непременно становится неполноценной. 

Не отмеченные обязательные поля

Итого по билду: 4.2+4.5=8.7 из 6+11=17 возможных, что равняется 8.7/17~51% готовности билда, за выявленные баги придётся снять -2-18=-20 баллов.