Когда кликать 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 не отразилась.

Tester's KPI

Product Manager (РМ) команды разработки в ConquestSS многие годы опирался на количество задач при оценке уровня специалиста. Поэтому, когда команда разрослась, поручил мне еженедельно публиковать в чате отчёт об обработанных задачах в разрезе продуктов (от трёх до шести приложений) и о переписке тех.поддержки (сколько получено писем, сколько отправлено ответов, сколько застряло в обработке). В те недели, когда у меня были отпуска, количество обработанных задач резко падало, и это первым заметил PM. Сделав выборку значений и подставив периоды моего отсутствия, у меня получился нижеследующий график.

Схождение отпусков и провалов задач

Скачки снижения количества задач (голубая и рыжая кривые) в точности совпали помесячно с периодами моих отпусков (коричневая кривая, где 100 - наличие отпуска, 0 - рабочий период). Что в точности подтвердило гипотезу РМ.
Но мне стали интересны и другие мои идеи.
1. Как часто стоит менять курируемый продукт? Ежедневно, как это делал РМ на стендапах, или закрепить один продукт за каждым тестировщиком на весь период спринта?
2. Зависит ли производительность тестировщика от его гендерности?
3. Кто эффективнее обучает новичка?
Для этого была собрана нижеследующая таблица.

Данные о сроках и количестве задач в разрезе тестировщиков

Имя (пол)		Tester_1 (F)	Tester_2 (F)	Tester_3 (F)	Tester_4 (F)	Tester_5 (M)	Tester_6 (F)	Tester_7 (M)
Через N дней оформлен "свой" баг		1	13	4	15	11	9	23
Через N дней оформлена первая задача из техподдержки		16	46	3	15	11	9	23
Срок в команде (месяцы)		165	26	16	26	6	5	2
Обработано всего задач за весь период		32457	4510	2181	1632	548	427	157
Скорость (обработано задач в месяц)		196,7	173,5	136,3	62,8	91,3	85,4	78,5
Количество оформленных задач (найденные баги самостоятельно и предложения из техподдержки)	всего	17204	1697	814	1362	188	148	51
	в т.ч. своих	12187	994	497	707	91	65	35
	%	71	59	61	52	48	44	69
Курируемый продукт		All	P_1, P_2, P_3	P_1, P_4	All	P_1, P_3, P_4	P_2	P_1, P_4
Количество обработанных задач по Product_1	всего	4981	3042	1116	926	288	16	147
	в т.ч. новые	3779	1136	260	798	101	10	44
	закрытые	1202	1906	856	128	187	6	103
Количество обработанных задач по Product_2	всего	5920	923	86	324	16	400	0
	в т.ч. новые	3701	328	16	292	12	128	0
	закрытые	2219	595	70	32	4	272	0
Количество обработанных задач по Product_3	всего	21016	336	31	163	164	11	0
	в т.ч. новые	11388	174	6	152	42	10	0
	закрытые	9628	162	25	11	122	1	0
Количество обработанных задач по Product_4	всего	540	209	948	219	80	0	10
	в т.ч. новые	444	59	532	120	33	0	7
	закрытые	96	150	416	99	47	0	3
Кто обучал внутренним правилам		самостоятельно	Tester_1	Tester_1	PM	Tester_3	PM	Tester_5

Если рассмотреть цифры в строке "Скорость (обработано задач в месяц)" в зависимости от строки "Курируемый продукт", то можно предположить, что тестировщик - универсальный солдат, легко перескакивающий с одной темы на другую. Но если учесть "Срок в команде (месяцы)", то гипотеза становится сомнительной. Особенно после отчёта на одном из стендапов, когда Tester_6 отчиталась об оформлении одного бага, а от Tester_1 за этот же день было добавлено в BTS более 20-ти задач.
На второй мой вопрос о половой принадлежности цифры мало что могут ответить. Поскольку не было возможности разбить задачи по их тематичности, которая в большей степени влияет на эффективность распределения работ. Более подробно об этом читайте в моей статье "Гендерность на страже качества или Вам Девочку или Мальчика?".
А вот на третий вопрос об обучении цифры вполне подтвердили мою гипотезу, что передавать знания должен единый лидер. Скорость учеников прямопропорциональна скорости учителя. Взгляните на строки "Скорость (обработано задач в месяц)" и "Кто обучал внутренним правилам" в купе со значениями "Курируемый продукт".
По таблице может у вас возникнуть вопрос о наличии данных в продуктовых деталях у тестировщиков, занимавшихся не всеми продуктами. Это последствия частой смены кураторов, которую так усердно лоббировал РМ, желая превратить нас в универсальных солдатов. Как следствие, одна из тестировщиц на указания шефа стала отвечать смайликом "Yes, Sir!", но он воспринял это лишь шуткой, не придав значения хлипкости командного духа подчинённых.
Количеством закрытых в спринте задач любил бахвалиться РМ и перед вышестоящим руководством, не вдаваясь в подробности того, что половина из них были элементарным откатом к функционалу прошлых версий. На каждое изменение в продукте "деды" тестирования всегда оформят, как минимум, две задачи. А если тестировщик более внимательно слышит пользователя, нежели сборщик бэклога РМ, то процесс его пополнения будет бесконечным: РМ навязывает свой взгляд на решение, а тестировщик инвертирует к пожеланиям пользователей.

UI appearance

Компания ConquestSS производит интерфейсные продукты для разработчиков БД Oracle, а ClearSQL (далее - CS) полезен тестировщикам PL/SQL кода. Поскольку продукт в большинстве своём - визуализатор, то посмотрим на его производительность в области интерфейса. Примечания: приложение десктопное, все установки были на Windows 64bit, замеры (кадрирование через VideoPad) интерфейсной производительности проводились по видеозаписям.
Для теста были взяты версии CS 7.0, 7.1, 8.0, 8.1, 9.0 для Windows 32bit и 64bit, а последний релиз в "светлом" и "тёмном" исполнениях. Каждая инсталляция запускалась по три раза, в каждом из которых анализировался демо-проект. Первые два идентичны по установке на "чистую" машину и полному анализу демо-проекта со всеми диаграммами. Третий запуск отличается от второго тем, что приложению нет необходимости доустанавливать продукт (создавать папки, выставлять опции по-умолчанию и прочее), а анализ проекта проводился без генерации диаграмм. Количество скриптов в демо-проекте уменьшилось на один ("Wrapped function.fnc") с версии CS 9, то есть примем везде по 60 скриптов. Настройки анализатора во всех тестах идентичны, так как взяты дефолтные.
Но сначала поглядим на запуск приложения. До версии CS 9 процесс открытия приложения проходил в так называемом "невидимом" режиме, когда пользователь не понимал, что происходит в системе: на панели задач не было кнопки приложения, на рабочем столе никаких новых окон. Спасибо, в CS 9 через 5 секунд молчания добавили "пропеллер" загрузки, а в предыдущих версиях какой-либо реакции по запуску приложения приходилось ждать иногда и более двух минут. Окно выбора лицензии мелькнуло на 5-10 секунде, а далее - пустое молчание.

Зависание старта

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

Ожидание полно-рабочего интерфейса

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

Затраты на выбор проекта

Накручивание каких-то скрытых обработок от версии к версии неблагоприятно сказывается на работоспособности интерфейсного приложения. Когда ваш маркетолог или аналитик просит вставить сбор статистики, то хорошенько  оцените конкретное место для этого действия: при каждом запуске приложения или перед конкретными кликами. Любое ожидание пользователя - это его нервы, особенно, если экран никак не отображает процесс.
Например, программисты ConquestSS, как говорится в Release Notes, от версии к версии что-то ускоряют. Но мои замеры показывают, что это какие-то пустые хлопоты. Взгляните на значения для CS 7.1 64bit и сравните их с другими. Только в этой версии по-умолчанию открывалась панель Script Editor (редактор, дерево кода и первая из панелей с результатами анализа скрипта - Errors), тогда как во всех других (в том числе и в CS 7.1 32bit) отрисовывалась более красочная закладка Summary с множеством графиков.

Прорисовка главного окна при запуске приложения с открытием демо-проекта

Раздражительность пользователя растёт от непонимания происходящего и, как факт, обновление главного окна юзеру приходится ожидать более 10 секунд при открытии проекта и по 5 секунд после каждого анализа.

Прорисовка главного окна после анализа проекта

Для понимания этого графика стоит учесть, что процесс прорисовки юзер видит собственными глазами. Но в некоторых версиях были отличия: 1) как уже было сказано, CS 7.1 64bit активировал Script Editor (текст и пара таблиц) закладку, а все остальные - Summary (несколько чартов); 2) в 7-мых версиях после анализа курсор в дереве проекта перескакивал на первый скрипт и, следовательно, значения в панели с результатами анализа просчитывались только для одного скрипта; 3) в 8-мых и 9-тых версиях выбранные для анализа ноды в дереве проекта не теряли своих чекеров и, следовательно, значения в панели с результатами анализа просчитывались для всех выбранных скриптов и папок; 4) CS 7.1 64bit  отличилась и в числе подсвеченных нод после анализа тем, что курсор в дереве раздваивался - на верхней ноде оставалась подсветка и на первом скрипте прорисовывался курсор-подсветка. Как видите из графика, снижение ожидания было за счёт закладки Script Editor в CS 7.1 64bit  и, вероятно, за счёт каких-то снижений затрат на обработку интерфейса в 8-мых и 9-тых версиях.

CS 9 black - Summary tab

CS 7.1 64bit - Script Editor tab

Cs 7.1 64bit - Project Tree node highlighting

Ещё некоторые графики мне показались интерсными. В них выведены цифры из панели самого процесса анализа. Напомню, что в каждой версии продукта ожидались идентичные данные для первых двух анализов и значительное снижение за счёт избегания генерации диаграмм и сбора инфы для них (убраны чекеры с Call Tree, Flowchart, CRUD1, CRUD2 и выбрано Delete при валидации диаграммных данных).

Время общего анализа и генерации Call Tree 

Добавив ещё по паре-тройке тестов для каждой версии и выкинув результаты анализа без генерации диаграмм, результаты не приблизились к желаемой скорости.

серая линия - весь анализ, коричневая - call  tree

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

Время выборки данных анализатора и форматирования кода

Для того, чтобы легче вам было разглядеть графики, они сгруппированы только по временным величинам (первая группа - полное время анализа и генерация call tree, второй - только форматирование или обработка данных для проверки правил кодирования, третья - генерация матриц crud и диаграмм flowchart).

Время генерации матриц crud и диаграмм flowchart

Очень странно, что полный анализ (серая линия на первом графике и второй график) проходит за разное время во впервые открытом приложении и при повторном запуске проги. Весьма заметно, что в 9-й версии что-то "накрутили" (светло-зелёная линия) при генерации flowchart, и с версии 8.1 что-то намудрили (синяя линия резко взлетела) для CRUD1.
В демо-проекте 60 скриптов, по полсотни flowchart и call tree диаграмм, десяток crud матриц. Все запуски имели равные условия (одна машина и рабочий день, без лишних  параллельных процессов), а линия обработки проекта показывает, что время не различается при генерации с диаграммами или только с анализом, без диаграмм. Соглашусь, что количество проведённых тестов для таких выводов маловато. Но тенденции по "совершенствованию" продукта вполне можно обнаружить.
Красота, конечно, требует жертв, но это совершенно нельзя применять к интерфейсным продуктам, которые хоть и помогают юзеру общаться с данными в упрощённом режиме, но пользователь в первую очередь желает не терять скорость обращения к данным и получать отчёты. Так, например, HTML Project Report с каждой версией замедляется.

Время генерации отчётов проекта

График показывает время формирования отчёта по демо-проекту: впервые открытого в чистом триале, после полного анализа, после анализа без диаграмм и ещё раз после полного переанализа. Наименьшие значения по версиям соответствует проекту без диаграмм. Но среднее время по версиям отчего-то растёт, хотя ни в каких RNs не упоминалось ни о каких изменениях в алгоритме генерации отчёта. Значит общие интерфейсные изменения в продукте отрицательно сказывались на генерации отчёта.

Из вышеизложенного могу порекомендовать тестировщикам и программистам интерфейсных десктопных приложений следующее.
1. Все внутренние процессы должны иметь визуализацию: конечную в виде "градусника" с процентами или таймерную анимацию в виде "пропеллера". Даже движущийся "пропеллер" не всегда даёт уверенность, что процесс когда-то закончится. А наличие сменяемого счётчика (хотя бы с 5-ти секундным интервалом) обнадёживает юзера благополучным исходом.
2. Десктопное приложение с первых секунд запуска должно быть обозначено на рабочем столе, на панели задач или трее. Юзер не должен рыскать по Диспетчеру Задач в поисках причин визуальной тишины. Причём подписи должны быть адекватными: обязательно актуальное название продукта (не как в CS 9 - пустая кнопка), информация о текущем состоянии продукта (инсталлируется, настраивается, запускается, закрывается, сохраняет или восстаналивает данные и тому подобное).
3. Сбор статистики для аналитиков или маркетологов не должен отягощать обычную работу пользователя. Если же это временно или срочно необходимо производителям, то перед выпуском проведите замеры и в Release Notes перечислите все процессы, которые станут замедляться.
4. Прежде чем кардинально менять интерфейс на новомодные элементы, замерьте прорисовку часто используемых окон по времени и объёму памяти.
5. Перерисовку основного окна не стоит выполнять бэкграундом. Закрывайте текущее окно, а затем ОДИН раз обновляйте главное. Иначе, ваше основное окно будет затрачивать ресурсы дважды: под текущим и при активации (например, в CS по завершении анализа моргают панели в основном окне, а после закрытия диалога опять прорисовывают тоже самое).

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

Рухлядь

Спектакль "Самая большая маленькая драма" начинается словами: "Рухнет потолок в театре, а сами скажут, что в городе Н. рухнула культура!", которые можно было взять лейтмотивом полвекового юбилея ТЮЗа, если бы не изворотливость организатора АКТ. В шестом кабинете (малая сцена ДК г. Кольчугино) истёрся до дыр линолеум, а под ним развалился паркет. Этим фактом грозил Рыжов пропесочить всех ответственных за ремонт на капустнике. Но тут подвернулся грант и режиссёр решил за его счёт укрепить пол так, чтобы не провалится однажды в бухгалтерию. К сожалению, распространение и укрепление культуры не подразумевает ремонт окружающего пространства. Подобное отношение к делу мне напоминает стартап, который не заглядывает в будущее, а лишь надеется на единоразовый успех. Обеспечение качества в быстрых проектах не предусмотрено, поскольку это удлинит процесс и себестоимость продукта увеличится.
Отказ в ремонте, ради которого и устраивался конкурс сельских театров, не сильно подкосил упрямство выигравшего грант руководителя АКТ и средства на обновление стен и пола выкроил из своего бюджета ДК. Вот что написала об этом местная пресса: "... как нам стало известно, средства полученного гранта в сумме 500 тысяч рублей нельзя было направить на ремонт малой сцены ДК, а так не хотелось новое оборудование, закупленное в рамках гранта, размещать в неотремонтированном зале. И Дворец культуры из собственных средств выделил порядка 200 тысяч рублей на ремонт малой сцены. Браво! Это настоящая поддержка театрального искусства."
Ремонт закипел с первых дней лета, а уже через месяц меценат городской культуры завод "Электрокабель" в честь собственного 80-летия расщедрился на 30 миллионов рублей для ремонта ДК. Знаменательным при этом был факт того, что среди столичных артистов в праздничном концерте участвовал лишь один местный коллектив, порождённый из театралов. Образцовая студия эстрадного танца "Dell`Arte" сформировалась в нулевых из актёров ТЮЗа, а неизменная руководительница О.Н. Никанорова (Архипова) ставит и репетирует шедевры хореографии не только у себя в коллективе, но и тесно до сих пор сотрудничает с АКТ. Поэтому считаю, что средства, поступившие в городской бюджет, должны в первую очередь покрывать потребности "Dell`Arte" и АКТ, соорудивших своими силами мизерные гримёрки-костюмерные для текущих представлений. Стоит заметить, что уровень постановки и исполнения номеров девочками из "Dell`Arte" превышал на пару голов столичные, уж поверьте моему хореографическому стажу с 1974 года, в числе которого 20 лет отдано полупрофессиональным коллективам. Застенчивость Ольги Николаевны не позволяет ей истребовать от директора ДК заработанные средства на организацию раздевалки для танцоров, ну что ж, пусть и дальше СЭС прикрывает глаза на то, что верхняя одежда и обувь использует столы и стулья буфета не по назначению. И чтоб этот баг вам не вышел боком, прошу за скромную и работящую принять во внимание наличие проблемы и уже начать её исправлять, благо достаточные средства пришли к вам не без помощи Никаноровой. За пронырливого Рыжова просить ничего не буду, так как он сам обладает достаточной фантазией и связями для осуществления любых своих хотелок.

ТО о SD 5.1.1.212

Отчёт о тестировании SQLDetective 5.1.1 (build 212), выпущенном 25 октября 2019 года. Проверка осуществлялась по Release Notes, которые не слишком велики, а значит этот билд был выпущен для исправления важного бага, обнаруженного пользователем. После просмотра всего отчёта, надеюсь, вы легко ответите на вопрос "какого бага билд?".

IMPROVEMENTS 1 из 1 возможного
Online Support Desk
⦁ The process of the update downloading is now indicated on the Windows taskbar.
Процесс скачивания апдейта теперь отображается на системном таскбаре.
Такое интерфейсное новшество стоит проверять на всех доступных операционных сестемах (они перечислены в файле Readme.htm или на сайте продукта в блоке System requirements, на сегодняшний день это "Microsoft Windows 7 and above") и их вариациях (стандартная или пользовательская тема расцветки и контрастности, масштабирование). Для теста не обязательно ждать появления следующего билда, а достаточно выбрать ручной режим обновления. Для этого в окне OSD Updater включите опцию "Allow available items to be selected manually". Новшество можно увидеть не только при наличии интернета и скачивании апдейта с сайта, но и при апдейте из файловой системы. Как тестировать, выбирайте сами: либо машину с установленным SD подключить к интернету (не стоит забывать, что в этом случае ваши данные будут переданы на сайт поставщика безусловно и без дополнительных предупреждений), либо скачайте zip-файл с апдейтом (не инсталлятор) и тестируйте много раз на разных системах без тревоги за то, что данные о вашей машине куда-то утекут. Во время копирования апдейта на кнопке приложения, что отображается на таскбаре операционки, заметно течение данных. Имплементация получает балл, хоть и проверен только один случай.

BUGS FIXED  0+0=0 из 5 возможных, -1.5-0.2=-1.7 за баги
Core  0+0-1+1=0 из 4 возможных, -1-0.5=-1.5 за баги
⦁ The error “ORA-00933: SQL command not properly ended” is no longer raised on a script execution if a DDL statement contains an empty string.
Теперь не случается ошибка о неожиданном окончании sql-команды при исполнении скрипта с пустыми стоками в выражениях.
Поскольку баг в группе Core, то проверять исполнение sql-команды придётся не только в SQL Editor, но и через диалог запуска подпрограмм, что доступен из Stored Program Editor. К сожалению, формулировка фикса никак не поясняет какие скрипты невозможно было исполнить, поскольку термин empty string имеет двоякий смысл: толи это просто пустые строки в тексте скрипта, толи это пустые литеральные команды (параметр для выражения EXECUTE IMMEDIATE), толи это пустые значения символьных переменных или ещё что подобное. Ошибка базы ORA-00933  чаще случается для команд, у которых потерялся конец, поэтому возмём простейший случай и вставим пустую строку между служебными словами SELECT и FROM, из череды которых сформируем небольшой скрипт (3-4 выражения, разделённые слешем или точкой с запятой). Например,
select 1

from dual

;
select 2

from dual

/
select 3

from dual
;

Если проверять диалог выполнения подпрограммы из Stored Program Editor, то в предыдущем билде описанная ошибка не проявляется. Если проверять SQL Editor, то выполнять скрипт необходимо не только по четырём доступным кнопкам на тулбаре редактора (весь скрипт, скрипт от курсора, одно выражение под курсором, одну команду под курсором), но и через запуск файла (через команду @). Мне не удалось получить ошибку ORA-00933  в предыдущем билде, поэтому этот пункт RNs считаю припиской и балла не даю. К тому же выяснилось, что так и не исправлен баг с подвисанием окна процесса в SQL Editor (выполните предложенный скрипт в редакторе через Ctrl+Enter, окно процесса не закроется само после окончания выполнения, а при попытке закрыть его и редактор вручную вам будет предложено отправить Eureka-лог ошибки приложения). Поэтому снимаю балл.
⦁ The error “FROM clause not found in SQL” no longer occurs on trying to execute a statement with the apostrophe in a q-notation.
Ошибка необнаружения служебного слова в выражении теперь не случается при выполнении выражения с апострофом в q-нотации.
Стоит вспомнить, что альтернативные кавычки для символьных переменных бажили и в позапрошлом билде. Для теста придётся составить символьное выражение с апострофом внутри (кстати, апостроф и одинарная кавычка - это разные символы) и вложить его в dml-команду с последующим служебным словом FROM (это может быть как и простая команда SELECT, так и вложенные INSERT, DELETE, UPDATE, MERGE), например, select q'[`]' from dual. Поскольку тех.писательница ошиблась и включила пункт RNs не в блок SQL Editor, то верну вас на тропу истины и ограничу тестируемые модули одним редактором, в котором одном можно было бы воспроизвести баг. К сожалению, предыдущий билд не дал описанную ошибку, поэтому и этот пункт причисляю к припискам. 
⦁ Fixed the highlighting of a literal if the opening bracket of a q-notation is followed by a break.
Исправлена подсветка символов, если открываемая кавычка q-нотации следует за переводом строки.
Подсветка текста осуществляется в окнах для просмотра или редактирования кода. Значит этот пункт RNs затерялся в группе Core. За это минус в карму тех.писательницы. У тех, кто фиксил это, должны быть красными уши, потому что вместо улучшения подсветки сделано её ухудшение. В некоторых случаях остаток команды подсвечивается как продолжение символьного выражения в альтернативных кавычках.

Было хорошо, а стало хуже

Такое исправление функционала даёт мне основание отнять балл, а не присудить.
⦁ A single-line comment is now highlighted correctly when it goes after a number.
Однострочный комментарий теперь подсвечивается правильно, если он следует после количества (номера, цифр).
Опять же странное расположение пункта RNs в группе Core, потому что подсветка текста применима в окнах для просмотра и редактирования кода (Code Editor, Text Viewer, SQL Editor, Stored Program Editor, ..). Вторая проблема с пониманием исправления тоже создалась от безалаберности тех.писательницы в выборе терминов. Что имелось ввиду под словами after a number? Толи предыдущая строка кода оканчивается цифрой, толи имелись ввиду номера строк на левом поле, а может и что иное. Для теста в редакторе кода наберём простенький текст:
select 5
--test
 from dual
и поиграем с местом однострочного комментария:
select 5--test
 from dual
Действительно, подсветка закоментированного остатка строки, следующего за цифрой без пробела между ними, не соответствовала ожиданиям в прошлом билде.

Символы после двух минусов в строке считаются комментариями для SQL Oracle

Поэтому даю балл и даже, по доброте душевной, прощаю использование запрещённого слова correctly.

Но поскольку в каждом пункте тех.писательница запутывала юзера, то за все эти промахи сниму полбалла.
Code Insight 0 из 1 возможного, -0.2 за проблемы
⦁ Ctrl+click now works correctly in INSERT and UPDATE statements.
Функциональный клик теперь работает корректно в выражениях INSERT и UPDATE.
Стоит пояснить, что в SD функциональный клик мышью по имени объекта или переменной позиционирует курсор на месте объявления переменной или подпрограммы (если редактор имеет Code Explorer, например "Trigger Wizard / Body" или "Stored Program Editor") и открывает мастер объекта или позиционирует на нём в Object Navigator. Недавно функциональный клик исправляли для нестандартных имён объектов, а теперь для каких-то составляющих или самих команд. Странно, что в список команд не попали остальные dml-выражения (например, MERGE). Поэтому для теста генерим простейшие все dml-выражения, хотя бы через контекстное меню Object Navigator для любой имеющейся у вас таблицы (или вьювера). Из SQL Editor, в который встроили Code Explorer, функционльный клик открывает без изменений мастер таблицы/вьювера для имени схемы и объекта, но ничего не находит для имён столбцов. То есть, никаких фактических изменений, а тем более корректных, найти мне не удалось. Аналогично без изменений остался и Stored Program Editor для перечисленных команд с объявленными и использованными переменными. Поэтому этот пункт однозначно считаю припиской и не даю ни балла. А использованный термин correctly без отсылки к стандартам и отсутствие конкретики при перечислении команд отнимает -0.2 балла.

Итого билд получает 1+0=1 балл из  1+5=6 возможных, то есть исполнен на 1/6=16%. А за баги теряет ещё -1.7 баллов. Предыдущий билд #210 был опубликован неделю назад, то есть этим фикс-билдом команда пыталась загладить свою вину перед пользователями. А как вы считаете, можно ли такими анти-фиксами получить положительную оценку юзеров?