Когда кликать QA

Моя статья "Tester's KPI" и участившиеся билды продуктов компании ConquestSS без тестирования сподвигли меня объединить данные обоих исследований и попытаться найти лучшую пропорцию количества тестировщиков и курируемых продуктов в команде разработки. Видеоролик "Нужен ли тестировщик на проекте?" от ПОИНТ-курсов утверждает, что наилучшее сочетание - это 1 тестировщик на 3 программиста, и в данных для моих графиков оно почти соблюдено.
Давайте оценим соотношения по фактическим цифрам.

Соотношение билдов в месяц и продуктов

Компания ConquestSS за 37 месяцев разработки одного продукта опубликовала 33 билда, за 8 месяцев параллельной разработки двух продуктов опубликовала 12 билдов, за 76 месяцев параллельной разработки трёх продуктов опубликовала 51 билд, за 37 месяцев параллельной разработки 4 продуктов опубликовала 59 билдов, за 12 месяцев разработки двух продуктов опубликовала 26 билдов. Примерная пропорция 1месяц/1продукт сбилась в правой части графика из-за отсутствия тестировщиков. Это хорошо заметно по следующему графику.

Соотношение тестировщиков и выпускаемых билдов

На всём протяжении выбранного периода, за который у меня накопились данные из публичных источников, пропорция 1тестировщик/3программиста сохранялась до последней части, когда команда ConquestSS совсем исключила тестировщиков-профессионалов (осталась лишь тех.писательница, слегка обучившаяся тестированию) и штат программистов сократился в 4 раза. В первом периоде один тестировщик параллельно обслуживал 3 продукта и за 107 месяцев было опубликовано 82 билда, два тестировщика на 3 продукта и 6 программистов помогли выпустить 12 билдов за 11 месяцев, 3 тестировщика на 9 программистов выпустили 17 билдов за 18 месяцев, 4 тестировщика на 10 программистов за 3 месяца выложили 5 билдов, 3 тестировщика (без ведущего специалиста) на 11 программистов за 13 месяцев выпустили 22 билда, а оставщиеся два с полтиной программиста за 17 месяцев выложили 42 билда. Эти цифры убеждают меня в моём мнении, что пропорция продуктов и тестировщиков более эффективна при соотношении 1/1. В предпоследнем периоде количество билдов в месяц возросло, поскольку все три тестировщика остались из числа юниоров, а шестой период при полном отсутствии тестировщиков подтверждает моё мнение, что программисты с лёгкостю пропускают в прод критичные баги, из-за которых приходится срочно выкладывать фикс-билды.
Графики показывают интенсивность билдов по точкам. Если точки расположены на одной прямой, значит номер версии не увеличивался и билд собирался для исправления какого-то важного бага юзера. По вертикали - номера версий продуктов, по горизонтали - даты выпуска, четыре цвета точек (синий, рыжий, зелёный, голубой) соответствуют четырём основным (без WEB сайта и портала) продуктам (SQLDetective, ClearSQL, ClearDB, docuVIEWER). У группы разработки ConquestSS существует правило: если от пользователя приходит критичный баг, то фикс-билд выкладывается всем в течение одной-двух недель. Но если баг важный для юзера, но готовится к выпуску следующая версия продукта, то юзеру даётся индивидуальный билд, а фикс официально публикуется в новой версии. По прижатости точек на графике вы можете заметить, как росло и падало качество продуктов со временем "взросления" одного тестировщика (первый период), приходом и уходом мидлов (второй и третий периоды), при полностью обновлённой группе тестирования (четвёртый период - один синьор и три юниора, пятый период - три юниора)  и при полном отсутствии профессиональных тестировщиков (последний период).
Прежде чем приглашать в команду тестировщика, хорошенько подумайте, а нужен ли вообще кто-то ещё вашей команде. Например, фин.директор и маркетолог ConquestSS, избавляясь от ведущего QA инженера или справляясь о житье-бытие, оговариваются по Фрейду, заявляя, что своих багоделов всегда достаточно, чтобы развалить компанию. Судя по вышеизложенным цифрам, группа разработки может работать стабильно, если раз в месяц концентрируется над одним продуктом. Вполне оправдан спринт в месяц для десктопного продукта, но слегка назойлив для юзера. Но если учесть, что компания ConquestSS поддерживает 3-4 продукта, то стабильные публикации билдов одного продукта раз в квартал смогли бы успокоить клиентов в плане надёжности поставщика, а группа разработки не распылялась бы на все продукты ежедневно. А там, глядишь и с глобалами бы проблема отпала, поскольку на ежемесячных планёрках такие задачи не смогли бы забыться.
Для себя, нас - тестировщиков, делю на четыре группы:
- инженер QA (quality assurance) постоянно задаёт неудобные вопросы, ведущие к развитию продукта и команды, лезет во все дела, имеет право голоса и влияния. Преподаватели из "Стратоплан" зовут таких бунтарями (смотрите доклады М. Завилейского "Три составляющие" и Олега М. Вайнбера "Зачем мы приходим в организацию и почему она нанимает именно нас");
- инженер QC (quality checker) - констататор фактов без собственного мнения, покладистый и безмолвный;
- инженер BA/BI (business analyst, business intelligence) - идейный лоббист юзерского и своего мнения;
- тестировщик на техподдержке - сборщик фактов и переводчик между пользователем и кодировщиком без права собственного мнения.
Не смотря на давнишнее рождение компании ConquestSS (с 2005 года) группа разработки придерживается позиции стартапа, поэтому так легко пренебрегает качеством продуктов. Хорошо бы на эти графики наложить суммы продаж, но у меня нет такой информации, которая бы доказала РМ-у необходимость профессионального тестирования. Программист никогда не проверит свой код так, как этим продуктом пользовался бы конечный юзер.
После просмотра доклада "Как QA инженеры могут повлиять на качество продукта? Или не могут?" Николая Алименкова на QA Fest 2016 у меня сформировалось мнение, что бизнесу разного уровня нужен определённый специалист:
* начальная стадия бизнеса (стартап, 1..5 разработчиков, нет или мало отзывов юзеров)
*-* роли тестировщика, аналитика, внедренца, техподдержки выполняют сами разработчики и владелец продукта, бизнес-аналитик выполняет роль технического консультанта
* средняя стадия бизнеса (продукту несколько лет на рынке, 5-20 разработчиков и аналитиков, отзывы регулярные)
*-* достаточно тестировщика на техподдержке и толкового аналитика-внедренца с функцией тех-консультанта
* стабильный бизнес (продукт сертифицируется по ТУ-ISO-ГОСТ, командный состав не важен, отзывы потребителей выходят на уровень юридических претензий)
*-* обязательная выделенная команда тестирования и контроля качества, совмещающая техподдержку, но отдельная от группы аналитиков и тех.консультантов.

А как в вашей команде соотносятся количества тестировщиков с программистами, продуктами и регулярностью выпусков?

ТО о CS 9.1.1.147

Тест-отчёт о ClearSQL 9.1.1.147, выпущенном 3 декабря 2019 года, основан не только на его текущих Release Notes, но и на промежуточных, которые выходили весьма неравномерно:

Дата	Билд
21.10.2019	9.1.1.124
25.11.2019	9.1.1.129
26.11.2019	9.1.1.133

Как видно по аннотациям к этим билдам, текст фактически не изменился с 124(125) билда, который был первым в линейке минора. За исключением одного пункта исправленных багов:
Code Analyzer
⦁ A range check error no longer occurs on trying to analyze scripts containing "slash"+"ampersand"+"varname"
Ошибка проверки ранга больше не случается при попытке проанализировать скрипты, содержащие "slash"+"ampersand"+"varname"
Да, в конце текста добавленного фикса значится некий набор символов, который абсолютно не ясен ни юзеру CS, ни юзеру БД Oracle. То ли недопечатанный многострочный комментарий, то ли переменная подстановки с опечаткой, то ли что-то из стороннего языка программирования. Вероятно поэтому составленный мной пример "select /&varname from dual;" не определил в предыдущей версии и первом билде версии CS 9.1 ни наличие проблемы, ни тем более исправления описанного бага. За что текущий билд недополучает балл.

Рассмотрим подробнее исправления ClearSQL 9.1.1 (build 147) с учётом 0 баллов из 1 возможного за описанный пункт RNs промежуточных билдов

IMPROVEMENTS 0+0.5=0.5 из 1+1=2 возможных, -0.2 за баги
Flowcharts, Call Trees, CRUD Matrices 0 из 1 возможного
⦁ Added a progress bar indicating the process of diagram/matrix generation.
Добавлен прогрессовый индикатор процесса генерации диаграмм и матриц.
Мои поиски разницы между первым билдом минора и текущим не принесли успеха. При анализе скрипта с генерацией диаграмм и матриц "градусники" процесса давно существуют и не изменились. Также неизменны остались всплывающие окна при их перегенерации в панелях скриптовых и проектных результатов анализа. Если бы тех.писательница уточнила место изменения, то можно было бы положительно судить о работе программиста. А так - ничего дать за пункт RNs дать не могу.
CRUD Matrices 0.5 из 1 возможного, -0.2 за баги
⦁ Significantly accelerated the process of displaying generated CRUD2 matrices when multiple objects are selected in the tree.
Значительно ускорен процесс отображения сгенерированных матриц CRUD2, когда несколько объектов выбраны в дереве.
Для тестирования откроем демо-проект в 125 билде на закладке CRUD2. Запустим видеозапись и выполним несколько типов работы с курсором, как это принято в Проводнике операционной системы:
1. В дереве объектов закладки CRUD2 поставим курсор мышью на один объект. Удерживая клавишу CTRL покликаем по трём-четырём объектам из этого же дерева. Дождёмся полной перерисовки матриц.
2. В дереве объектов закладки CRUD2 поставим курсор мышью на один объект. Удерживая клавишу SHIFT кликнем мышью на 4-5 объекте из этого же дерева, но ниже или выше. Дождёмся полной перерисовки матриц.
3. В дереве объектов закладки CRUD2 поставим курсор мышью на один объект. Удерживая клавишу SHIFT нажмём стрелку вниз или вверх 4-5 раз. Дождёмся полной перерисовки матриц.
4. В дереве объектов закладки CRUD2 в любом месте кликнем мышью левой клавишей и, не отпуская нажатую левую клавишу мыши, протянем выделение вниз или вверх на 4-5 объектов. Подождём несколько секунд.
Все эти же вариации запишем в видео-ролик на текущем билде. После сравнения записей по картинкам и времени, заметим следующее:
а) прошлый билд не отображал несколько объектов в одной матрице ни при каких видах выборки объектов, так что ни о каком "ускорении" речи быть не может, а лишь о самом сводном отображении в единой матрице, что говорит о неверной формулировке RNs;
б) четвёртый тип выделения объектов так и не заработал в текущем билде, что является недоправленным багом;
в) выделение объектов по типу 3 позволяет отметить не более двух объектов, что является либо недоработкой ускорителя из-за слишком быстрой переброски активного курсора из дерева в матрицу, либо старым багом об отсутствии таймера для прорисовки матрицы.
Из всего выявленного могу дать лишь 0.5 балла за новшество и снять -0.2 за обнаруженные баги.

BUGS FIXED 0.5+0.5+1+0=2 из 1+1+1+2=5 возможных
Core 0.5 из 1 возможного
⦁ Files in UTF-8 (with no BOM) and UTF-16 are now imported and analyzed correctly.
Файлы в UTF-8(без BOM) и UTF-16 форматах теперь импортируются и анализируются правильно.
Весьма обширное заявление тех.писательницы без отсылки к конкретным правилам сразу можно оценить нулевым баллом. Корректность новой работы импорта и анализа невозможно выяснить без конкретных примеров или хотя бы подробностей. Но поскольку минимальный тест на случайном скрипте в юникоде показал, что хотя бы импорт теперь проходит без коверкования символов, а анализ не изменился, то дам фиксу 0.5 балла. Вообще-то, такой фикс вполне можно было бы считать усовершенствованием, а не правкой бага.
Flowcharts, Call Trees, CRUD Matrices 0.5 из 1 возможного
⦁ The error “An error has occurred in the script on this page” is no longer raised on trying to open a diagram.
При открытии диаграммы больше не появляется диалог об ошибке скрипта на странице.
Поскольку тестируемым модулем являются страницы отображения диаграмм и матриц, то могу подразумевать, что исправлен баг из моего отчёта. В нём речь шла об HTML-скрипте для отображения результатов анализа. Эти закладки работают на движке HTML-браузера. После глобальных изменений в ядре приложения старые результаты анализа проекта получились несовместимы с новым движком. Это явное подтверждение того, что в ConquestSS абсолютно не производится регрессионное тестирование продуктов. Для чистоты эксперимента создайте проект со скриптами в CS старой версии 6 или 7, а затем откройте в 9 версии. Учтите, что первое открытие старых проектов в новой версии CS производит их перекодирование, так что для каждого теста нужны свои проекты. Но даже если вы создадите собственноручно эти проекты, то у меня нет никакой убеждённости, что они окажутся требуемого формата, потому что при обнаружении бага мне не удалось выяснить его точные причины. Авансом засчитаю баг исправленным, поэтому дам 0.5 балла.
Call Trees 1 из 1 возможного
⦁ Selecting all diagrams on the "All Call Trees" tab no longer causes the application to crash.
Выбор всех диаграмм дерева вызовов уровня проекта больше не приводит к краху приложения.
Осторожно! Последние версии CS автоматически открывают проект не только на последней активной закладке, но и восстанавливают положения курсора, то есть все выделенные объекты дерева, что является причиной краха приложения при самом старте. Если вы однажды откроете проект в прошлом билде и в дереве вызовов всего проекта развернёте третью папку демо-проекта до появления вертикального скроллера, выберете курсором вторую папку и все видимые объекты третьей, то баг отсутствия доступа к чему-то зациклится в этом билде. Исправить баг можно будет лишь в текущем билде, либо ручной правкой настроек проекта, которые нигде в хелпах не описаны (потому и я не буду раскрывать секреты). Наконец-то исправлен серьёзный баг, чем повышается готовность билда к публикации.
Project Report Generation 0+0=0 из 2 возможных
⦁ Libraries are now correctly extracted into a project report.
Библиотеки теперь правильно выгружаются в отчёт по проекту.
Скорее всего имеются ввиду библиотеки Oracle Forms. Их примеры есть в демо-проекте. Делаем два отчёта из прошлого и текущего билдов для выяснения объёма фикса, поскольку тех.писательница не удосужилась описать конкретику или дать отсылку на какие-нибудь стандарты. Визуально мне не удалось обнаружить ни единого различия, а для детального необходимо писать особый парсер. Поэтому никак не могу засчитать фикс.
⦁ A project report is now correctly shown in IE.
Отчёт по проекту теперь правильно показывается в Internet Explorer.
Взяв тестовые данные предыдущего пункта RNs попробуйте найти разницу. Мои варианты не показали никакой разницы, а значит и фикс не приносит билду балл.

Итого по билду: 0+0.5+2=2.5 из 1+2+5=8 возможных баллов дают 2.5/8=31.25% готовности, к сожалению, придётся ещё снять -0.2 балла за баги.

ТО о SD 5.1.1.239

Отчёт о тестировании SQLDetective 5.1.1 (build 239), опубликованном  28 ноября 2019. Тесты основаны на пунктах Release Notes. Предыдущий билд выпустили месяц назад и в текущий попали фиксы накопившихся проблем.

IMPROVEMENTS  0.8 балла из 1 возможного, -0.2 за баги
Database Connection
⦁ Added the option “Switch to a new connection in the active window” to Preferences > Session, enabled by default. When disabled, starting a new database session does not change the database connection in the active window.
Добавлена опция переключения коннекта в активном окне в настройки приложения на страницу сессий, которая по-умолчанию включена. При выключенном состоянии запуск новой сессии базы данных не изменяет строку подключения к базе в активном окне.
Поскольку это новая опция в приложении, то тесты стоит осуществлять по чит-листу: название интуитивно понятное, краткое описание в хелпе имеется, расположение опции на странице "General / Session" логично и соответствует UI стандартам, сохранение и восстановление не отражается на других настройках, её можно найти в Preferences по наименованию. Для проверки функциональности выберем подходящие окна. Все окна в SD делятся на мультисессионные и коннекто-зависимые. К первым относятся те, что имеют комбобокс для смены строки коннекта и могут быть открыты без подключения к базе, ко вторым относятся те, что отображают содержимое базы без возможности мобильной смены сессии. Для новой опции необходимо проверить её распространение на окна первой группы и отсутствие воздействия на окна второй группы. Ко второй группе относятся мастера всех типов объектов, SmartDataset, Stored Program Editor. Перечислю мультисессионные окна, согласно структуре главного меню: Object Navigator (комбобокс на главном тулбаре), SQL Editor, HTM Editor (генерирует код для текущей схемы), Object List, View Differences, PL/SQL Profiler, Object Privileges (для открытия окна нужен хотя бы один коннект к базе), Find Object, Data Dependency Analyzer, Report Generator, Export Data (для открытия окна нужен хотя бы один коннект к базе), Import Data (для открытия окна нужен хотя бы один коннект к базе), Fast Copier, DB/Schema/Objects Compare, Schema Extractor, Schema Compiler, Schema Analyzer, Session Navigator, Storage Manager, DB Examiner, DB Monitor, Top Session Locator. Для ускорения теста открываем все перечисленные окна и подключаем или отключаем сессии БД. Осторожнее при работе с админскими утилитами, поскольку ошибки подключения обычного юзера могут прятаться под другие окна, чаще всего - за Fast Copier. Кроме подключения к базе надо проверять и отключение от сессии БД. Для интерфейсного продукта давно стоило внедрить эту экономию перерисовки. Но тесты показали, что не все окна его поддерживают при подключении сессии и все окна обновляют список коннектов при отключении сессии БД. Такая реализация говорит о непродуманности переделки UI и получает 0.8 балла. А поскольку некоторые окна меняют коннект с ошибкой базы "ORA-29275: partial multibyte character" и окно Fast Copier постоянно перекрывает диалоговые окна с предупреждениями и ошибками, то новшество теряет -0.2 балла за эти старые баги, до сих пор не исправленные.

BUGS FIXED   0.5+1+1.7-0.5+1+1+0+0=4.7  из 5+2+2+1+2+1+1+1=15 возможных, за баги -0.5-0.4=-0.9
SQL Editor  0+0.5+0+0+0=0.5  из 5 возможных
⦁ Fixed the work of the history panel splitter.
Исправлена работа сплиттера для панели с историей.
Поскольку баг конкретно не описан, то для воспроизведения в предыдущем билде поиграемся со статусом окна при открытии/закрытии и сворачивании/разворачивании/максимизации окна SQL Editor, смене позиций закладок вывода и редактора кода. Перечисленные места необходимо проверить в сочетании с опцией "Preferences / Code Editors / SQL Editor / Allow only one SQL Editor window". К сожалению, никакой разницы в работе сплиттера не выявлено по сравнению с предыдущим билдом, поэтому фикс не получает ни балла.
⦁ Splitter positions of the Dataset Manager and SQL History panels are now remembered and restored correctly.
Позиции сплиттеров настройщика данных и истории запросов теперь запоминаются и восстанавливаются корректно.
В чём может заключаться корректность по отношению к позициям сплиттера? Также, как и в предыдущем фиксе, изменения необходимо проверять в сочетании с опцией расположения закладок с результатами и редактора кода, поскольку программист мог пронумеровать элементы окна, чтобы не придумывать уникальные имена. С запоминанием и восстановлением позиции сплиттера были проблемы только у настройщика данных. Они исправлены, а пункт RNs получает лишь 0.5 балла, потому что описание фикса не соответствует действительности (упомянут элемент без изменений и использован эпитет correctly без отсылки к правилам).
⦁ The token with the leading ampersand “&” in a string literal is now always recognized as a possible substitution variable.
Вызовы через амперсанд в символьных строковых теперь всегда распознаются как возможные переменные подстановки.
Такое описание фикса более похоже на усовершенствование, а не на исправление проблемы. В настройках приложения существует опция "Preferences / Code Editors / Bind and Subst. Variables / When a Token with Leading '&' Appears in a String Literal" с доступными значениями: распознавать, не распознавать как переменную подстановки, предлагать пользователю выбрать вручную. Пользовательский вариант является дефолтным, как в предыдущем, так и в текущем билдах. Применяется распознавание амперсанда в SQL Editor и Stored Program Editor на одноимённых закладках. Так что описание пункта RNs не проясняет пользователю сделанные программистом изменения, а лишь запутывает. Надо полагать, что на самом деле поправлен лишь какой-то из частных случаев распознавания переменных подстановки. Любой из тестировщиков знает, сколько вариантов нужно для проверки символьного поля, эти же вариации применимы и к символьной строке с переменной подстановки. Поскольку программист пожадничал с собственными знаниями и не пояснил тех.писательнице подробности правки (а может ничего и не исправлено по-факту), то фикс не получает ни балла.
⦁ The height of the results panel is no longer minimized after switching back from the Stored Program Editor.
Высота панели с результатами больше не минимизируется после переключения из редактора хранимых программ.
Все мои попытки воспроизвести проблему в предыдущем билде не увенчались успехом, не спровоцировали её даже сочетания с опцией расположения редактора сверху результатов и максимизация окон, параллельное открытие нескольких окон одного типа и растяжение дополнительных панелей через сплиттер. Если бы описание было более конкретным и легко воспроизводилось, то можно было бы заметить работу программиста. Поэтому фикс не получает ни балла.
⦁ A literal is no longer truncated if there are line breaks in it.
Символьные больше не обнуляются, если в них есть перевод строки.
Совершенно непонятное описание фикса, для которого у меня нет никаких соображений, где и как такое можно было бы воспроизвести. Из-за неясной трактовки фикс не получает ни балла.
Smart Dataset  0+1=1  из 2 возможных
⦁ The “List index out of bounds” error no longer occurs on refreshing the dataset for a modified table.
Ошибка превышения количества больше не случается при обновлении данных для изменённой таблицы.
О том, как может быть изменена таблица следует искать в документации БД Oracle в рамках статьи ALTER TABLE. Поскольку ранее случалась ошибка о некоем количестве, то попробуем изменить состав таблицы по её столбцам. Будем полагать, что под модификацией таблицы подразумевается только структура объекта, а не его данные, поэтому побалуемся с таблицей из 3-4 полей без содержимого. Описание фикса не конкретизировано типами полей и наличием данных. Вероятно поэтому у меня не получилось воспроизвсти баг (открыть таблицу в SmartDataset, через мастер объекта удалить или добавить колонку, в гриде выполнить Refresh Data-F12 или Reopen Object) в предыдущем и текущем билдах. Пункту RNs не могу дать ни балла.
⦁ The error “ORA-00947: not enough values” no longer occurs on trying to perform an insert into tables with several object type fields of a similar type.
Ошибка о недостаточности значений больше не случается при попытке выполнить вставку данных в таблицы с несколькими полями объектного типа одинаковой вариации.
Первое, что меня смутило, это множественное число таблиц для вставки данных. Надеюсь, что это всего лишь опечатка тех.писательницы, поскольку через SmartDataset одномоментно редактируются данные только в одной таблице (служебное поле ROWID в запросе по правилам Oracle может быть лишь одно). Для минимального теста создаём объектный тип с одним атрибутом, на основе которого в таблице из трёх полей (символьное и два пользовательского типа) двум выбираем только что созданный тип. В гриде такая таблица будет состоять из трёх столбцов, два из которых имеют сложносоставные названия (имя поля и через точку имя атрибута объектного типа). В предыдущем билде описанный баг проявляется только при добавлении непустых данных, но не случается при их изменении. В текущем билде баг исправлен, то есть добавление и модификация данных в любом из столбцов этой таблицы не вызывают проблем. Исправление заслужило балл.
Database Examiner  1+0.7=1.7   из 2 возможных и -0.3-0.2=-0.5 за проблемы
⦁ The “Refresh Data” command is no longer active when a database connection is closed.
Команда обновления данных больше не активна после закрытия коннекта к базе.
Все страницы утилиты состоят из гридов, составленных из системных вьюверов, поэтому для теста выберем любую страницу. Баг проявлялся в предыдущем билде только для гридов, интерфейсным элементом для которых является самописный HisGrid, а простые списки из двух колонок на страницах Instances, Database и кнопка на основном тулбаре окна не оставляли подсвеченными две жёлтые стрелки. Поскольку аналогичные интерфейсные элементы используются повсеместно, то дисконнект следует поглядеть и во всех админских утилитах, окнах для работы с данными. Описанный баг оказался характерен лишь для окна DB Examiner. Но продолжение комплексного тестирования выявило проблему излишнего считывания привилегий при отсутствии коннекта к базе на странице Database. К сожалению, в ConquestSS игнорируеют полное тестирование и этот очевидный баг прошёл мимо группы разработки, то есть не исправлен в текущем билде. А текущим фиксом поправлен лишь мелкий интерфейсный глюк (клик по кнопке и горячей клавише F12 безопасный без коннекта). Пункт RNs получает балл за исправление и теряет -0.3 за невыявленный функциональный баг.
⦁ The “Find in All Columns” window now always opens on pressing Ctrl+F in the Database Examiner.
Окно поиска по всем колонкам теперь всегда открывается при нажатии горячей клавиши в окне утилиты.
Описание бага больше смахивает на усовершенствование, нежели исправление проблемы. На деле же горячая клавиша для поиска по данным гридов стала срабатывать только при наличии активного курсора в самом гриде, а вместо диалога поиска по тексту или файлам теперь открывается диалог поиска с интерфейсом локальной операционной системы, в котором всё ещё актуальны проблемы подписей элементов на региональном языке и мигающий курсор виден в области радио-кнопок вместо текстового поля ввода. Разность слов тех.писательницы и дела программиста приносит фиксу только 0.7 балла, а старые баги опять снимают -0.2.
Session Navigator  -0.5 из 1 возможного
⦁ If an Oracle directory does not exist in the database, it is now automatically created to get a trace file.
Если директория, как объект базы, не существует, то она автоматически создаётся для доступа к файлу трассировки.
Теоретическую часть об объекте Директория вам стоит изучить самостоятельно по статьям CREATE/ALTER/DROP DIRECTORY из документации Oracle DB. Только для Session Navigator этот объект, как и файл трассировки, не имеют надобности. Все данные, отображаемые в Session Navigator, берутся из системных вьюверов напрямую без директорий, а трассировка используется в SQL Editor и TKPROF Shell. Так что этот пункт RNs невозможно никак проверить из-за неадекватного описания или выбора модуля. К тому же опасные слова о том, что объект базы будет автоматически создан, тревожат меня отсутствием предупреждения о скрытых действиях в базе, которые может выполнять только юзер с админскими правами. Ни балла за такое дать не могу, да ещё сниму как минимум полбалла за возможные опасности и давно неправленный баг "ORA-29275: partial multibyte character" при открытии модуля.
Schema Compiler  1+0=1  из 2 возможных, но -0.4 за проблемы
⦁ When the “Auto Open” option is enabled, the Schema Compiler window now always opens automatically when a new session is created.
При включенной опции автооткрытия окно компилятора схемы автоматически открывается при создании новой сессии.
Опция автооткрытия окна настраивается в списке Window Settings рабочей области "Preferences / General / Workspace" и, как вы понимаете, должна одинаково работать для всех окон из этого списка. Для скорости теста включаем в настройках приложения автооткрытие всех окон и подключаем ещё одну сессию базы, желательно с админскими привилегиями. Компилятор схемы стал открываться при новом коннекте и фикс получает свой балл. Замечено было, что исправилась проблема с окнами ассистента кода и для быстрого копирования объектов, которые ранее всегда показывались поверх всех приложений, открытых в операционной системе. А встречающиеся проблемы в каждом открываемом окне (нехватка прав, испорченные скрипты браузера документации и прочее) всё также стопорят открытие последующих окон, за что есть смысл снять -0.2 балла. В списке окон на странице Preferences почему-то Telegram не расположен в алфавитном порядке. А вместе с компилятором схемы не открывалось (и до сих пор не открывается) автоматически окно Action Output с результатами действий приложения. Выявленные баги отнимают у билда ещё -0.2 балла. Почему-то последовательное групповое исключение окон из автооткрытия и в прошлом, и в текущем билдах включает галки для всех окон, но поскольку мне пока не удалось локализовать проблему, то за баг списывать баллы не буду.
⦁ The Schema Compiler customization is no longer cleared after disconnecting from an inactive session.
Настройки компилятора схемы теперь не очищаются после отключения активной сессии.
К настройкам утилиты относятся не только опции на соответствующей закладке, но и выбор типа компиляции, фильтры на объекты и схемы. Сравним все их в текущем и предыдущем билдах в сочетании с новой опцией про строку коннекта при подключении сессии. Кроме смены или сохранения строки подключения при новом коннекте никаких изменений в окне не замечено, поэтому считаю этот пункт RNs лишним и не даю за него балл. Опять же, бОльшая часть проблемы пришла от тех.писательницы, не конкретизировавшей фикс, и от программиста, не пожелавшего обучить её техническим вопросам.
Export Data Wizard 1 из 1 возможного
⦁ Exporting data from the Object Navigator no longer adds a non-existent object “.” to the export objects list.
Экспорт данных из навигатора объектов больше не добавляет несуществующий объект без имени и схемы в список объектов для экспорта.
Мастер экспорта данных можно открыть несколькими способами: из главного меню и главного тулбара, из открытого грида данных (SmartDataset, закладка Data в ContentSelector, все доступные гриды данных во всех утилитах приложения) по кнопке на тулбаре окна или из контекстного меню, через контекстное меню объекта данных в ObjectSelector. Из всех перечисленных вариантов только последний давал описанный баг в предыдущем билде и исправлен в текущем. Фикс получает балл, но тех.писательнице стоило вместо общего наименования окна Object Navigator указать его конкретное дерево - ObjectSelector.
Dataset/Datagrid  0 из 1 возможного
⦁ The QBE (Query By Example) and Find commands are no longer active when the dataset is closed.
Мастер настройки фильтров и диалог поиска больше нельзя активировать в закрытом наборе данных.
Очень странная формулировка, но попробуем её понять по фактической работе. О том, как вызвать мастер установки фильтров или диалог поиска, написано в топиках хелпа приложения. А вот что имелось ввиду под закрытым набором данных даже мне со знанием продукта с первых дней его разработки не понятно. На ум приходят такие действия: при открытом SmartDataset с данными закрыть сессию, открыть данные в SmartDataset в режиме только чтения без возможности редактирования, сменить активное окно. Но никакой из перечисленных вариантов поведения приложения не воспроизводит описанный баг. Поэтому не могу дать ни балла.
Main Window  0 из 1 возможного
⦁ The main application window no longer hides after opening the Database Connection window for the second time.
Главное окно приложения больше не прячется после открытия окна коннектов во второй раз.
Главное окно обязано быть под окном подключения к базе, в какой бы раз не делалось подключение. По описанному фиксу могу заключить, что тех.писательница скорее всего перепутала окна и, возможно, окно коннекта иногда пряталось под основное окно приложения. Но скорее всего проблема была и осталась совсем в другом. Это не раз мне удавалось воспроизвести в предыдущем и текущем билдах, когда новый коннект  автоматически открывал рабочие окна с какими-нибудь ошибками (недостаточно прав, проблемы с перекодировкой или в скриптах документации), диалоговые окна которых и прятались, создавая эффект подвисания приложения. Максимально за подобное описание проблемы и её якобы исправления не могу дать ни балла, а при плохом настроении (лучший подарок тестировщику - это билд с полностью закрытыми "зелёными" задачами и без порождённых багов) этот пункт получил бы от меня отрицательный балл.

Итого по билду: 0.8+4.7=5.5 баллов из  1+15=16 возможных, что равняется 5.5/16=34%, из которых баги отнимают   -0.2-0.9=-1.1 балла.

Глобалы

Глобальными модулями в группе разработки продуктов компании ConquestSS называются такие компоненты трёх смежных приложений, код которых равнозначно применим в каждой программе. Например, самостоятельная библиотека OSD.DLL с полноценным интерфейсом и функционалом, интерфейсное окно ABOUT с информацией о продукте, текстовый парсер для сбора данных анализатора кода. Соответственно задачи, которые касаются только таких модулей, а не их внедрения в продукт, называются "глобалами". Для удобства фильтрации такие задачи объединены были в отдельный "продукт в BTS".
SQLDetective, ClearSQL, ClearDB - интерфейсные продукты, написанные в основном на Delphi. Но поскольку была внедрена система LFT, то многие стандартные элементы не могли удовлетворить требования, выработанные этой командой. Поэтому программисты ConquestSS вынуждены были дописывать или переделывать интерфейсные компоненты. Например, для выставления своих фонтов и отступов в ckeck-box, radio-button, list-view, плавное расцвечивание в progress-bar и многое другое. Переработка компонента оформлялась как глобал, а его внедрение в определённый продукт - задачей на конкретное приложение и его модуль. Но в большинстве своём задачи по внедрению в конкретный продукт игнорировались, не оформлялись, подразумевая процесс внедрения в рамках одной задачи-глобала.
Со временем появилась необходимость вести версионность некоторых глобальных модулей. До сих пор сохранилось отображение версии только для анализатора кода. Её номер вы можете увидеть в комментариях к отформатированному коду. Парсер кода - часто меняющийся в последнее время модуль, поскольку обязан поддерживать все новшества базы данных Oracle. Поэтому все три продукта вполне могут выпускаться регулярно, обновляя лишь один глобальный модуль - анализатор кода. А вот версионность другого глобала - OSD.DLL - помогла лишь однажды, когда он кардинально был переработан для работы отладчика. Но, к сожалению, не все старые версии смогли на лету сработаться с библиотекой, поэтому простое копирование файла в рабочую папку приложения не спасало положение, и для полноценной отладки приходилось пересобирать весь продукт с изменённой библиотекой. Не так давно OSD переместили в core продуктов и его версионность отжила свою надобность. У всех остальных модулей-глобалов вообще не велась версионность, достаточно было версий основных продуктов, в которые внедрялись эти глобалы. А при закрытии задач в BTS эти их внутренние версии вообще никогда не имели смысла.
Исходники продуктов, как и положено, хранятся в системе контроля версий (VCS), каждый в своей ветке. Для глобальных модулей была выделена самостоятельная ветка. При этом сборка каждого продукта, автоматизированная со временем, выбирала файлы не только из своей продуктовой ветки, но и мониторила обновления по дате редактирования ветку глобалов. Когда dev-ops реализовал полезняшку (подкинутую мной идею о добавлении комментариев в задачи Jira с номером билда, в который вошёл фикс), то это значительно упростило работу тестировщика, часто сомневавшегося "стоит ли начинать тест? перебилден ли продукт с требуемой версией глобала?". VCS Perforce связана с Jira через FishEye, а сборщик билдов написан на Python, поэтому кроме нотификаций в Slack о готовом билде, dev-ops легко реализовывал и многие другие важные для команды разработки напоминания и уведомления. Да, пока сборка велась в ручном режиме слишком силён был человеческий фактор и часто забывали включить в билд нужную версию глобала, либо ошибались с датами фиксов и накладывали старые баги на новый функционал. И тогда мы получали весьма жуткие временные баги от корявой сборки.
Конечно, такой вынос одинакового кода и интерфейса в отдельную папку VCS был весьма удобен программистам. Ведь у них значительно поубавилось работы. Код не приходилось триплить во все продукты, а лишь сделать одну правку. Но, к сожалению, не всегда задачи в BTS оформлялись на каждый конкретный продукт. Поэтому тестировщику приходилось в каждом из трёх продуктов проводить одни и теже тесты, да ещё удваивать (а то и утраивать) их из-за необходимости поддерживать несколько версий продукта (опубликованный, предыдущий опубликованный, разрабатываемый по спец.заказу или общий будущий). Программист комментировал свои фиксы только в VCS, по которым собирались внутренние Release Notes, то есть единожды. А тестировщик обязан был отметить фиксы в каждом продукте и его версиях. Поэтому пришлось в самописной BTS создать дополнительную таблицу (child для основной таблицы задач)  для таких отметок. Самописную BTS вполне удавалось заполнять в SmartDataset гриде своего же продукта SQLDetective, поскольку в основном это были обычные таблицы с набором справочников. Но для отметок глобалов в SD не сгодилась даже утилита DataDependencyAnalyzer. И после недолгих упрашиваний dev-ops смастерил мне формочку на пару гридов (parent - all_bugs, child - global_checks) со справочником версий продуктов. Да, такой дополнительный список усложнял сбор Release Notes для пользователей, поскольку РМ раньше фильтровал только общую таблицу задач, а теперь ему приходилось частенько припоминать о глобалах.
Когда же самописную BTS сменили на Jira, то систему глобалов не упразднили. Самостоятельный продукт Global Modules (GM) так и продолжил своё существование, но его ни минули пара революций. Команда разработки росла и новым тестировщикам тяжко было как понять систему глобалов, так и поддерживать её в актуальном состоянии. Некоторые модули имели реализацию только в определённых продуктах. Например, CRUD2 матрица или браузерный отчёт анализатора (CS Project Report, CDB Docu), которые формируются сразу для нескольких объектов базы, а потому не приемлемы для единичных объектов в SD. Участились отвлекания старожилов на разъяснения, поскольку даже пояснения к модулям, которое возможно заполнить в справочниках Jira, не отображается для выбираемых компонентов в процессе оформления задачи. Так что моя одноразовая акция по проставлению в комментариях каждого компонента продукта GM списка поддерживаемых продуктов не сильно помогла. Пришлось проводить проверку каждой новой задачи GM на применимость в продуктах и дописывать в Description важные примечания для разработчиков и тестировщиков, если фикс не должен был быть в каком-то из продуктов или его реализация имела продуктовые особенности. Тех.писательница, собиравшая Release Notes, тоже постоянно забывала упомянуть об изменениях за счёт глобалов, либо добавляла лишние пункты, не применимые в продукте, либо текст по опечатке содержал упоминание соседнего продукта. В продукте GM приходилось админу Jira дублировать версии конкретных продуктов после каждой сборки. Тогда ещё не был полноценно дописан авто-билдер, поэтому добавление производилось вручную после публикации, а поскольку не редки были случаи забывчивости, то чек-лист публикации пришлось пополнить отдельным пунктом для админа Jira. Даже РМ, собиравший бэклог публикации в Jira Structure, не всегда вспоминал, что стоит добавить и уже закрытую по другим продуктам GM-задачу, но ещё не внедрённую по текущему спринту. Эти неудобства послужили аргументом к прекращению поддержки GM. Несколько месяцев трёх тестировщиков было потрачено на перенесение имевшихся GM-задач в конкретные продукты. Спасибо, в Jira есть фичи клонирования и переноса задач из одного продукта в соседний, поэтому имевшиеся задачи разносились более менее быстро. А вот новые иногда забывались клонироваться. По окончании этой работы взвыли программисты, которые забывали открыть в Jira слинкованные одноимённые задачи, сменить им статус и отметить затраченное время, забывали в VCS упомянуть авто-фиксы по всем продуктам. Но те проггеры, которые не забывали про лишние телодвижения, были рады резкому скачку их производительности, ведь она утроилась по времени и количеству задач! Итак, тестировщики обрадовались конкретике, тех.писательница успокоилась при сборе Release Notes из-за уменьшения фильтра, но РМ в большей степени прислушивался к мнению программистов, которые ленились отмечать свою работу в клонированных задачах. Из-за этого РМ вопреки мнению большинства своим "царским указом" возобновил поддержку в Jira глобалов. Да притом изменил путь статусов на жёсткую схему, и один статус TESTING был разбит на несколько (сначала три, а потом и четыре) по количеству разрабатываемых продуктов TESTING_Prod1, TESTING_Prod2, TESTING_Prod3, TESTING_Prod4. Статусы можно было сменить только в обозначенном порядке, что очень осложнило работу тестировщикам, которые были закреплены за конкретными продуктами. Но РМ на это неудобство ответил распоряжением самоуправца и закрепил глобалы за одним тестировщиком из числа новичков. Юный тестировщик не возражал, так как не знал, что столкнётся с более сложной проблемой. На тот момент продукт ежедневно собирался при наличии фиксов в своей ветке, а поскольку какие-то из продуктов были "заморожены", то тестировщик не мог закрыть проверенную в продуктах 1 и 4 задачу, не имевшую реализации в продуктах 2 и 3 ввиду отсутствия нужного билда. Dev-ops-у пришлось опять менять авто-билдер, чтобы даже временно отложенные продукты всё равно ежедневно собирались, но лишь для тестирования. И РМ-у было наплевать на то, что некоторым задачам абсолютно не нужно было проходить хоть какую-то проверку в определённых продуктах, то есть авто-билдер гонялся впустую, тестировщик безрезультатно искал исполнения в пустом продукте, а тех.писательница опять стала ошибочно вносить "чужие" фиксы в Release Notes.
Из обеих революций для большинства членов команды разработки был вынесен единый вывод: "Глобалы - это зло!", но поскольку мнение ленивых и приближённых к РМ-у программистов перевешивало демократизм, то о каком бы-то ни было компромиссе мечтать не стоит. Кое-как соглашусь, что в VCS глобалы есть смысл сопровождать в собственной ветке, но и здесь не мало проблем с внутренней и общей версионностью. А в BTS никак не стоит объединять глобалы, поскольку они первые в числе забываемых. Если у вас Jira, то клонирование и перенос задач между продуктами легко снимут с вас проблемы актуализации багов и фич. Кабы в нашей старой самописной BTS была фича клонирования багов и разработок в другие продукты (SmartDataset в SD может дублировать строки только в одной таблице, а значит не давал полноценного клонирования по справочникам, да и не видно было потом линкованного исходника для клонов), то моя идея глобальных модулей ограничилась бы только VCS и в BTS не отразилась.