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

Любительские театры ограничены пространством. Зачастую, им достаются небольшие кабинеты в Доме Культуры или школе. Удача, если на части пространства выстроен подиум, ограничивающий сцену и зрительный зал. Тогда зрителям задних рядов хоть что-то видно.
Если стулья для зрителей складные, то для репетиций и тренингов можно расчищать зал.
Самым эргономичным и удобным решением может стать зал-гармошка, задние ряды которого располагаются высоко (зрителям не придётся вытягивать шею из-за спин впереди сидящих), а на время репетиций весь пол кабинета свободен для тренировки сценодвижений.
Три ряда в разложенном состоянии:
 
Верхняя полка - сидячие места. Верхняя точка спинки на высоте 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 письму, заархивирован с паролем, скачан с сайта производителя, код продиктован по телефону,..), поддержка в системе пользователя;
- техподдержка лицензии: автоматическая, регулярная, скрытая, ручной режим, оплата, база клиентов.

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