ТО о CDB 5.0.2.477

Неожиданно, после более годовалого молчания, 12 марта 2020 года опубликован билд ClearDB Documenter 5.0.2.477 (далее - CDB). Чтобы понять вескость  причины для смены номера релиза, обратимся к Release Notes, текст которых не выложен на сайте, но имеется в самом продукте (кнопка Help и её пункт меню "Release Notes ClearDB Documenter"). Возможно, что это последний билд от ConquestSS, поскольку с сайта пропали пункты меню о CDB, только некоторые рекламные тизеры о нём упоминают и возможны открытия страниц по прямым ссылкам. Но не буду сеять панику об отпачковывании CDB от ConquestSS или закрытии проекта, хотя их юристы - те ещё знатоки, оттяпают бизнес и оставят "без порток", как это уже было не раз (отобрали CS у первого создателя, увольняли через скайп после восьми вечера в пятницу или с утра отрезали коннект). Надеюсь, все пользователи CDB будут вовремя оповещены о смене владельца продукта, а пока займёмся технической частью.

IMPROVEMENTS    0.3+1.5=1.8  из 1+2=3 возможных, -1.2-0.8=-2  за баги
Core   0.3  из 1 возможного, -1-0.2=-1.2 за баги
⦁ Improved license key processing.
Усовершенствован процесс лицензирования.
Предвижу ваш вопрос о том, где взять новые ключи, но для проверки текущей реализации нам, по-моему, будет достаточно триального.
Во-первых, поищем разницу в текстах хелпа и лицензионного соглашения. К сожалению, её нет. Хелп генерился 11 октября 2018 года, так что нет смысла искать что-то изменённое. Хотя давно пора было заменить 30-ти дневный период пятидневкой, ведь месячные периодичные версии были введены перед выпуском предыдущего билда в ноябре 2018 года.

Статья хелпа об ограничениях пробной версии ClearDB

Про отсутствие заголовка в топике хелпа отчёт был отправлен в ConquestSS ещё пару лет назад.

Кстати, за поданную мной осенью 2017 года идею вернуться к периодичной аренде продукта мне до сих пор ничего не перепало. А ведь это самый удобный способ "стричь клиентов", когда команда разработки истощилась с идеями по развитию продукта. Да и все мои отчёты, альтруистично отправленные напрямую в ConquestSS, не возымели своего истинного назначения - улучшить качество продуктов. Поэтому цикл статей ТО хотя бы в моём блоге поможет начинающим тестировщикам научиться применять разнообразные техники.

А тексты лицензий можно сравнить либо в MS Word, либо в "SQLDetective / View Differences". О внесённых изменениях нигде не указано. Это существенная недоработка тех.писательницы, потому что она могла бы не сеять в умах пользователей чёрные подозрения, потому что при малейших изменениях лицензирования первейшим документом, подлежащим корректировке, является само лицензионное соглашение. Компания ConquestSS считается американской, а в США жутко ревностно относятся ко всем юридическим вопросам.
Во-вторых, поглядим состав ключа на главной странице и в настройках приложения "Preferences / License Key", также в кратком описании продукта "Help / About". Здесь можно заметить, что в деталях ключа появилась строка о количестве лицензий на Security Audit Report (далее - SAR).

Краткие подробности о продукте в окне About 

Случайным образом в процессе перегенерации доки обнаружилось, что SAR теперь является самостоятельным плагином, а не ограничивается только 32-х битным CDB. Но на него забыли дать права в триальном ключе.
В-третьих, CDB не имеет дополнительного welcome-окна, как это есть в SD и CS, которое предоставляет варианты выбора и получения ключа. Поэтому все мои догадки об изменениях лицензирования ограничены лишь SAR. Поскольку основным поставщиком этого модуля является Pete Finnigan, то подозреваю, что вынос модуля в самостоятельный плагин сделан по финансовым причинам. Но они нас не касаются. Мы будем смотреть только на функциональную часть новшества, которая совсем не в пользу программистов. Мало того, что новшество не описано подробно в документах для пользователя, так кодер ещё и сократил рекламность и без того маленького триала. Поэтому и название временного ключа "extended trial" звучит теперь как насмешка над пользователем. Итого, новшество получает лишь 0.3 балла, а теряет за счёт критичных багов -1 балл.

Главное окно продукта и нотификация о триале

Не могу оставить не учтённым баг интерфейса. При первом открытии CDB на главном окне и в других местах о содержимом ключа рисуется 100% красная шкала. Это сразу наводит на мысль, что все 100% уже использованы. Я-то понимаю, что это всего лишь наследие предыдущей 30-ти дневной реализации, когда градусник был синим первые 25 дней триала, и лишь на последние пять дней окрашивался в красный цвет. Тогда эта цветовая ориентация была логична для понимания, а теперь красный цвет не только часть остатков подсвечивает, но и пугает сочетанием ста процентов и цвета опасности. Более логичным было бы после перехода от 30-ти к 5-ти дням триала показывать градусник использованности также частично сначала синим 4 дня, а в последний день уже перекрасить градусник и подписи в красный. Очень странно, что один из владельцев продукта, весьма ревностно относящийся к подбору цветов (именно он подбирал эти подложки цветов "детской неожиданности" для столь серьёзной инфы в дереве доки и типах док - кремовый, салатовый, небесный, лососевый) упустил из виду эту интерфейсную неурядицу. Так что, за давний баг сниму ещё -0.2 балла.
Installer/Updater   1+0.5=1.5  из 2 возможных, -0.3-0.5=-0.8  за баги
⦁ On installing a new product version, the application now checks the presences of both 64- and 32-bit versions and deletes their data before the new installation.
При инсталляции новой версии продукта теперь проверяются существующие версии обоих типов 64-, 32-битной разрядности и удаляются их данные перед новой инсталляцией.
Поскольку инсталлятор во всех трёх продуктах ConquestSS является глобальным модулем и проходил мои тесты в других продуктах, то подробно останавливаться на CDB не буду. Отмечу лишь, что тех.писательница опечаталась: вместо фразы "deletes their data" стоило сказать "allows to delete old installations". Да, новый инсталлятор определяет имеющиеся версии CDB вне зависимости от разрядности, но предлагает удалить не сгенерённые ими данные, а всего лишь программы. Если же вы желаете оставить обе инсталляции и пользоваться разными билдами одинаковой версии, то перед запуском инсталлятора всего лишь переименуйте папку продукта в файловой системе, и пропустите шаг инсталлятора для удаления предустановленного продукта (не ставьте галочки и нажмите кнопку Next). Это новшество получает балл.
Но эта же информация нужна не только при инсталляции. Во всех продуктах ConquestSS есть модуль для отображения и пересылки в тех.поддержку информации о системе "Help / System Information". В этом файле блок Application не собирает полную инфу про все версии CDB. А если запустить продукт из переименованной папки, то и для текущего приложения номер версии окажется неопределённым и путь к продукту указан "старый", не из файловой системы, а из реестра операционки. Описанная проблема является багом комплексного тестирования или недоработкой. Поэтому билд теряет -0.3 балла.
О баге смежного модуля (деинсталлятор) расскажу в рамках следующего пункта RNs.
⦁ On uninstalling the Conquest tool, the user is now forwarded to the website to fill out a short form explaining the reasons to quit.
При деинсталляции утилиты от Conquest юзер теперь перенаправляется на форму сайта для заполнения коротких объяснений о причинах завершения.
Да, действительно, после закрытия мастера деинсталляции автоматически открывается интернет-браузер и пытается подключиться к уже (или изначально) не существующей странице "https://sqldev.tech/product_feedback_documenter". Все мои попытки подобрать иное имя страницы путём смены названия продукта не увенчались успехом. Возможно это по причине отсутствия продукта CDB на сайте ConquestSS. Но суть проблемы не столько в отсутствии страницы на сайте, сколько в способе реализации передачи данных об отказе от продукта. Во-первых, если юзер не читал RNs, то его очень сильно смутит автоматическая попытка прорваться в интернет, особенно с машины с ограниченными правами (доки в CDB обычно генерит админ базы, который предпочитает перекрывать лишние выходы). Во-вторых, перенаправление на страницу сайта происходит без предупреждений о предназначении этого опроса. Более учтивым был бы интерфейс последнего диалогового окна мастера по деинсталляции с явным линком на страницу сайта и соответствующими разъяснениями: "Продукт удалён. Просим пройти опрос на нашем сайте для последующего улучшения продукта и работы нашей технической поддержки. Потраченные Вами 2-3 минуты помогут не только нашей группе разработки, но и другим пользователям." Либо можно было реализовать третий вариант: сформировать e-mail письмо, вложив в него необходимые системные сведения. Так что, новшество получает лишь 0.5 балла.

Путь удаления продукта

К тому же, деинсталлятор не даёт выбрать данные для удаления. Позже вручную пользователю приходится стирать созданные папки, список которых мало совпадает с действительностью. Диалоги о существующих инсталляциях для 32-битного и 64-битного продуктов разные: 64-битный деинсталлятор не видит 32-битные инсталляции, и наоборот. За эти баги есть смысл снять с билда -0.5 балла.

BUGS FIXED   0.8 из 1 возможного, -2.8 за баги
Code Review Rules  0.8  из 1 возможного, -0.8-0.2-1.8=-2.8  за баги
⦁ The rule “Runtime concatenations of string literals affect performance” now works correctly.
Правило неэкономного использования ресурсов при мгновенном соединении символьных строк теперь работает корректно.
Для теста придётся в своей базе создать объект, например, тело пакета HR.ET_DEBUG из доки примеров (триального ограничения в 300 строк кода нам будет достаточно). Моя попытка перегенерить Sample Docu по типу 4 не дала ожидаемого переанализа кода, за что билд продолжает (давнишний баг - нет деталей Code Review в переанализированных объектах доки, перегенерённой по типу 4 Extract Subset без подключения к базе) недополучать -0.8 балла.

Code Review в перегенерённой доке по типу 4 без деталей и ссылок на строки кода

Поскольку в окне опций анализатора кода всё ещё невозможно выбрать все правила, чтобы массово их отключить и оставить только проверяемое, то билд недополучает за неудобство -0.2 балла. В текущем билде генерим доку по типу 1 New (регистрация базы не будет нужна, если пакет создан в схемах HR или SCOTT) и сравниваем результаты Code Review нашей новой доки с тем же объектом в Sample Docu. Хоть тех.писательница и не уточнила смысл правки, но по этому примеру мне стало понятно, что предупреждения теперь касаются только тех символьных сложений, которые подряд не перемежаются переменными, то есть два сложения вполне можно было бы вместить в одних кавычках. Поскольку это не было точно описано в RNs, то исправление получает только 0.8 балла.
Комплексное тестирование в очередной раз подтвердило наличие проблемы с EurekaLog в сопутствующем продукте docuVIEWER (далее - DV). Открыв доку для просмотра в только что установленном CDB+DV на чистую машину меня огорчили следующие интерфейсные глюки:
1) количество док для закладки Docu Explorer в DV всегда нулевое при открытии продукта;

Открытие DV

2) нет номера версии DV, для которого показаны "пустые" RNs во всегда открывающемся по-умолчнию окне;
3) закрытие DV сопровождается сообщением об ошибке про отсутствие встроенности EurekaLog в DV;

Закрытие DV

4) после закрытия DV в тулбаре страницы Docu Manager в CDB странным образом гасятся некоторые кнопки;

Частичное гашение кнопок тулбара

5) ни по двойному клику, ни через контекстное меню доки больше не открываются в DV после случившегося бага с неподключенным логом вплоть до перезагрузки CDB.
За них в общем сниму -1.8 балла.

Помимо вышеперечисленного, в процессе тестирования билда на глаза попались и другие недоделки.
1) Oracle  в этом году уже создал новую версию базы - 20, а в инсталляторе ConquestSS всё ещё указан лимит до 18-й версии, тогда как в файле ReadMe - 19.

Инсталлятор и документация о системных требованиях

2) Комментарии Sample Docu говорят о поддержке версий базы вплоть до 12с, а сама дока создана на 18-й версии.

Комментарий к Sample Docu и версия базы самой доки

3) При перегенерации доки из примеров по типу 4 зачем-то выскакивает предупреждение о режимах подсчёта MI. Странность в том, что значение этой опции по-умолчанию в приложении и в готовой доке примеров должно быть идентично.

Предупреждение о смене важной опции

4) Если вы вручную выбрали все правила проверки кода, то это не отображается после закрытия окна Code Analyzer Options в списке опций для генерации доки.

Выбор опций в дополнительном окне не обновляется в рабочем

5) Странно, что такой простенький продукт DV до сих пор не переведён в 64-битную разрядность. Даже если CDB установлен 64-битный, то вьювер всё ещё вкладывается 32-битный.

Разрядность приложения

6) Все страницы мастера генерации док имеют подсказки, но они только занимают полезное пространство: высота окна такова, что на некоторых 16:9-мониторах функциональные кнопки подрезаются таскбаром Windows OS, а вместо лишнего текста лучше было бы подписать как минимум блок Feature Navigator.
7) При перегенерации доки по типу 4  из Sample Docu для будущей доки предлагается путь в корне диска "C:\".

Путь к новой доке автоматически подставляется из исходной

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

Итого по билду:  заслужено 1.8+0.8=2.6 балла  из 3+1=4 возможных, что составляет 2.6/4=65% готовности, а баги отнимают -2-2.8-1=-5.8 балла.

Обратная совместимость

Регрессионное тестирование для каждого продукта проводится в своём направлении. В случае обнаружения критичного бага у пользователя должна быть возможность отката до предыдущей версии. Но если в результате такого отката данным будет нанесён урон больший, нежели неудобства новой версии, то считайте такую проблему не просто регрессией, но и фатальной.
Очередной пример вышеописанной регрессии предоставила компания ConquestSS сразу в двух продуктах ClearSQL ver#7.1 и SQLDetective ver#5. Когда в 2015 году для ClearDB персональные данные (пароль к БД) стали шифроваться, то моё замечание о невозможности восстановления паролей через возврат к предыдущей версии восприняли как негативный и нежелательный тест. Разработчик в новой версии добавил кодирование пароля, но не делал конвертацию старых данных. Тогда не было владельцев продукта, готовых обновиться до новой версии. На стороне пользователя потеря паролей не проявилась. Да, соглашусь с мнением, что пароль - это не те данные, которые стоит хранить даже в зашифрованном виде, но у разработчиков ConquestSS и к любым другим настройкам аналогичное отношение. Старые, привычные установки не конвертируются в новую версию, а затираются значениями по-умолчанию без предупреждения. О чём не раз жаловались юзеры. Алгоритм перевода на новые настройки давно известен (сохранить старые, добавить новые параметры, предупредить о новых возможностях и вариантах восстановления прежних), но в среде программистов ConquestSS им напрочь пренебрегают.
Поскольку ни в Online Help, ни в Release Notes ничего не сказано о том, что после апгрейда пропадут данные, то считаю своим долгом тестировщика предупредить текущих пользователей ClearSQL ver#7.0 и SQLDetective ver#4 о необходимости сохранить прямо сейчас ветки реестра "HKEY_CURRENT_USER\Software\ClearSQL\DB Connect" и "HKEY_CURRENT_USER\Software\SQLDetective\Splash\ConnectionHistory" соответственно продуктам или Preferences в файл. Это позволит вам вручную восстановить в предыдущей версии утерянные при апгрейде пароли. Напоминаю, что в ClearSQL ver#7.1 (and higher) и SQLDetective ver#5 пароли к БД, сохранённые в предыдущих версиях, обнуляются при первом же запуске без какой бы то ни было возможности восстановления.
О простоте кодирования паролей в ClearSQL ver#7.0 и SQLDetective ver#4 уже говорилось в статье "Telegram in application with DB connection". Команде разработки потребовалось полтора года после моего напоминания для перенесения алгоритма более серьёзного кодирования паролей из ClearDB ver#4 в ClearSQL ver#7.1 и в SQLDetective ver#5. Так что, перед обновлением до сегодняшних версий не поленитесь и сделайте себе памятку, ведь столь удобная галка "сохранить пароль" может сыграть с вами очень злую шутку - не восстановит значения в новой версии, и даже механическая память рук ничем не поможет.
А всем тестировщикам ПО рекомендую не только проводить тест на обратную совместимость, но и вести профилактическую работу по предотвращению багов. Вроде бы удобство - опция для сохранения и авто-восстановления данных, но не для всех значений она может поддерживать законы безопасности приложения. Ещё одним примером такой юзерской прихоти является отдельная возможность выгрузки в XML файл всех сохранённых на машине коннектов к базе. В своё время мне пришлось потратить немало усилий, чтобы из прикреплений к OSD сообщению удаляли эти записи, потому что они несут персональную информацию, зачастую бесполезную для техподдержки ConquestSS. Но полагаю, что тот же юзер, который предложил сохранять пароли, сам и предложил экспортировать коннекты. А ведь это первый путь к хакерству. Если пользователь меняет комп, то в Online Help есть подробная инструкция по переносу настроек. Насколько часто нужна фича экспорта-импорта всего списка коннектов и кому? Ответ очевиден - только тому, кому временно стал доступен чужой ПК. Да, через сохранение всех настроек (Preferences) в файл тоже быстро можно скопировать все коннекты, но при этом ещё много локальных параметров (ключ лицензии, опции анализатора) придётся корректировать после импорта. Так что, считаю фичу экспорта-импорта коннектов вредной, а не полезной. И рекомендую подобные им новшества пресекать на первоначальном этапе разработки. Тогда не придётся выдумывать "защиту от дурака" в виде излишних шифрований или подтверждений опасных шагов. А владельцы продуктов и особенно администраторы баз должны перестать использовать опцию сохранения паролей, дабы хоть малость усложнить нежелательным элементам доступ к данным. Хотя, подобрать пароль, зная имена схем и баз, можно довольно просто. О чём немало говорили и Pete Finnegan, и Александр Поляков.

Про-хак

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

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

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

Скриншоты в доке

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

Техническая подсказка - скриншот окна со скроллером может делать PicPick. Поскольку у меня есть надежда, что опасности будут исправлены вовремя, то намеренно был усложнён полный просмотр.
Первым шагом упор делается на клиента базы данных, но в приложении ClearSQL вполне можно работать и без этой настройки: скрипты в проект импортировать из обычных текстовых файлов, а выполнять в базе напрямую в SQL*Plus (из редактора ClearSQL запускается в один клик и не требует клиента базы). Картинки и текст про версии клиентов базы, приложения и операционной системы в исследуемом нами документе не полноценны:
- в картинках нет пояснения о каком клиенте речь (не хватает слова Oracle - смотри  пункты 1 и 2), потому что чуть ниже прописаны настройки приложения и операционной системы. Такие двойные стандарты путают читателя - сочетать приложение только с операционкой или и с клиентом базы тоже;
- 32-битное приложение работает только с 32-битным клиентом Oracle, но вполне спокойно функционирует в 64-битной операционной системе (смотри пункт 3), а инструкция строго ограничивает 32-битного клиента базы, при этом напрочь забыт универсальный Instant Client. Полноценную информацию следовало разместить в матрице сочетаний.
Инструкция пользователя должна давать необходимую и достаточную информацию для верного выбора шагов применения приложения. Для этого документация проходит тест полноценности.
Четвёртым пунктом отмечена самая опасная информация - персональная. Ответственный тестировщик никогда бы не допустил распространения индивидуальных данных, с помощью которых халявщики могут достать лицензию через запрос о восстановлении (Forgot password) пароля к сайту (customerID имеется, по имени и географии владельца иммитировать e-mail - простая задача даже для junior-tester), а иные мошеники могут начать вытягивать из пользователя приложения мнимую оплату за лицензию. При этом пострадает не только раскрытая всему миру персона, но и компания-владелец продукта на потере оплат за лицензии, спам-атаках по "восстановлению" пароля и исков

о нарушении GDPR. И это после многочисленных статей о пользе и применимости GDPR в продуктах самой же компании.
Интерфейсный тестировщик не пропустил бы такие ляпы, как помечены пункты 5, 7 и 8:
- лишний двойной разделитель в тулбаре;
- разношёрстные кнопки в одном блоке тулбара - разворачиваемость обозначена как соседняя или встроенная функциональность;
- лишний разделитель кнопок в тулбаре, где и без того места мало.
Инструкция рассказывает об импорте скриптов, но создатель скриншотов пожадничал информацией с собственного компа, а тестовый стенд со стандартным набором папок и файлов развернуть поленился. Из-за этого скриншот получился абсолютно бесполезной картинкой: дерево проекта из мастера импорта бессмысленно без дерева файловой системы или объектов базы данных, без кнопок по добавлению скриптов и формированию проекта.
Вроде бы над сайтом и продуктами работает единая команда, но поскольку в блоге существует иная статья про начальные шаги в ClearSQL (смотри пункты 9 и 10), то очевидно отсутствие в команде координатора, который помнит в первую очередь про нужды пользователя и умеет переводить с языка разработчика на доступный пользователю лексикон. То, что важно для программиста, чаще всего является излишним или непонятным для конечного пользователя.
Это был конкретный пример необходимости тестирования любой информации, предназначенной для обычного пользователя и распространяемой в общем доступе.
Игнорирование проверок документации отрицательно сказывается не только на имидже производителя, но и может серьёзно подорвать всю работу над продуктом. Такая болезнь стартаперов зачастую банкротит вполне устойчивые разработки. Предупрежу желающих заработать на конкретной доке от Conquest Software Solutions - пустая затея. Максимум, который вы получите за отчёт об ошибках - подтверждение о получении и последующая публикация исправлений. Моему альтруизму уже много лет, и его первоочередной смысл - в предупреждении и уменьшении чужих пробелов (ошибки программистов, повышение знаний тестировщиков). Но, имея ClearSQL, очень не плохо можно подняться на баг-баунти в любой другой группе разработки (подробнее говорилось в Easy white-box testing).

GDPR - доверяй и проверяй

Возврат к бюрократии или Сотрудник на доверии
(рубрика - Нюх на баги)

Европейское сообщество решилось на усовершенствование охраны данных. Теперь тестировщикам и сотрудникам отделов тех-поддержки необходимо в срочном порядке совершенствовать свои знания в области юриспруденции.
Начать обучение следует с самого документа - "General Data Protection Regulation (GDPR)".
В большей мере вопрос касается персональных, конфиденциальных данных. А есть ли в них различие? Что об этом думают эксперты? Читайте "Experts on the GDPR #3: What is personal data under the GDPR?".
С технической точки зрения эксперты определили облачные сервисы для защиты данных - "Experts on the GDPR #4. Storing encrypted personal data in the cloud: What is the most secure option?", "EU GDPR: соблюдение требований регуляторов в сфере облачных вычислений".
Какая же ответственность теперь будет у сотрудников техподдержки первого уровня и тестировщиков? Для техподдержки объектом пристального внимания становится информация о кастомерах, которую необходимо дифференцировать по территориальному признаку - индивидуальные данные от покупателей и поставщиков следует хранить и обновлять в рамках GDPR, компаньонов из других стран позволено обслуживать в прежнем режиме, только если они не связаны с европейцами. Было бы проще ко всем применить политику GDPR, но Вы уверены, что иные страны не имеют более жёстких условий? Поэтому техподдержка первого уровня - одно из самых важных звеньев в процессе фильтрации данных. Например, баг от пользователя должен храниться во внутренней системе компании разработки, а все контакты пользователя в независимой базе, вплоть до отдельного сервера. Получается, связующее звено "техподдержка" при этом несёт полную ответственность за линковку данных об исправляемом баге и пересылаемом отчёте пользователю. Тестировщику, оформляющему баг в базу при этом придётся унифицировать проблему, применяя переименование и аггрегацию для сокрытия данных от сторонних глаз. А Ваши базы контрагентов и задач готовы к такой конфиденциальности?
Создавая и тестируя базы данных в программном продукте, выпускаемом Вашей компанией, следует более тщательно контролировать простоту наименований таблиц и полей, связей реляционных баз и доступность их описания. В этом плане хороший пример в OEBS, где таблицы и поля имеют нелогичные наименования, в основном состоящие из цифр, что хорошо запутывает взломщиков. Также должны быть усилены тесты по способам и местам хранения данных - физические носители, облачные сервисы, удалённое управление с ограничением прав доступа и функций. При пересылке данных должны использоваться высоко-защищённые от несанкционированного доступа способы, а пересылаемые данные защифрованы в обязательном порядке. Также не менее важно проверять объём информации, присылаемой с отчётом о баге, чтобы в ней не хранилось что-либо, идентифицирующее пользователя продукта. Объём и содержимое пересылаемых данных необходимо проверять на актуальность, необходимость и достаточность, предотвращать скрытые пересылки (без ведома пользователя) паролей, IP-адресов, списков баз и прав доступа, прочих идентификаторов.
Список ответственных за сохранность данных не ограничивается техподдержкой. Компания, выпускающая десктопный продукт и продающая его через свой сайт, вполне может быть распределённой: например, зарегистрирована компания в США, разработчики и тестировщики фактически раскиданы по России и Украине, маркетологи разъезжают по всему миру, сервера с исходниками и данными пользователей могут быть распределены  по всему миру. Удобнее иметь сервера с исходным кодом и задачами поближе к группе разработки, а сервис продаж в Европе. Но при этом копия базы данных покупателей обязана быть у разработчика в оригинале, а не переименованная, поскольку могут быть проблемы, напрямую зависящие от комбинации исходных данных. Такие моменты прописаны в GDPR как доступ к данным по запросу "Art. 15 GDPR  Right of access by the data subject". О предварительных действиях компании разработки рассказано в "How to prepare for Data Access Requests under GDPR", "GDPR data access portal: Logging into the GDPR data access portal, Making a data access request, The data access request excel template, Making a data deletion request, Making a data change request, Making a consent change request".

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

OSD - автоматизация техподдержки десктопного ПО

В мае 2002 года на рынок десктопных продуктов для разработчиков базы данных Oracle вышел коробочный продукт Table Magic российского производства. В течение года его переименовали в DatabaseVoyager и распространяли компакт-дисками по Европе, летали в Америку и Юго-Восточную Азию. Пользователей было не много, общение проводилось посредством электронной почты и ICQ. C увеличением разноязычных пользователей было принято решение о едином языке техподдержки. Отчёты пользователей добавлялись в имевшуюся Bug Tracking System отдельными задачами, с указанием имени юзера и параметров связи с ним (e-mail адрес или номер ICQ в самом тексте задачи). Высокий приоритет таких задач объяснялся именем автора, баги от внутреннего тестирования исправлялись во вторую очередь.
Мировой Интернет развивался и стало возможным оплачивать покупки и распространять ПО без затрат на пересылку, хранить и пересылать большие объёмы данных. Под это дело к 2005 году был создан сайт WWW.SQLDETECTIVE.COM (параллельно в очередной раз переименовали продукт в  SQLDetective) и выбран SWREG как готовый вариант проведения электронных платежей. Количество пользователей начало расти естественным образом. Одного адреса e-mail, указанного в About окне продукта, стало мало.
На сайте появился стандарт – Contact Us, с которого была настроена автопересылка e-mail писем на ящики QA, PM, CEO. Поскольку продукт был достаточного качества, которое было достигнуто 100% занятостью тестировщика пока не расширили обязанности до сотрудника техподдержки, то отдельного сотрудника для ведения техподдержки не нанимали. У одного тестировщика на 4-5 разработчиков хватало продуктовых знаний и способности совмещать весь цикл техподдержки (приём-составление-отправка сообщений, воспроизведение проблем и оценка предложений, оформление задач в BTS).
На сайте также был организован Форум, через который стали поступать отчёты пользователей о багах и предложениях. Нотификации о новых сообщениях в форуме автоматически рассылались на e-mail адреса QA, PM, CEO. Техподдержка всех уровней всё ещё была на плечах одного человека. Конечный вариант ответа утверждался руководством в плане английской грамматики и общей политкорректности. Для сокращения излишней работы шефов было принято решение о составлении шаблонов ответов: структура заголовка и подписи, набор стандартных фраз и ответов на идентичные вопросы.
Исторически сложилось так, что e-mail клиент ящика техподдержки был TheBat. Все письма удалялись с сервера и хранились на одной машине. Использовались полезные свойства клиента: расфасовка писем по папкам, авто-сохранение копии ящика по таймеру, поиск по письмам, блокировка неотвеченных писем для контроля работы техподдержки. Единый ящик копил базу писем пользователей и не засорял сайт (сервер). Ещё один положительный момент TheBat выявился при общении с разноязычными пользователями, когда Outlook стал автоподменять некоторые символы на русско-язычную раскладку (например, двойные кавычки открытие-закрытие, символы больше-меньше в html-формате). Такие символы не отображались или подменялись в ответах пользователям, и смысл текста искажался, что подрывало авторитет компании.
Электронные платежи, увеличенные объёмы серверов, ускорение загрузок сайта позволило распространять инсталлятор десктопного продукта через WEB. Хотя продукт и состоял из ядра и эдонов, но инсталлятор приходилось собирать единым большим файлом. Когда в версию вносились незначительные изменения, то юзеру было накладно качать полный большой инсталлятор. Поэтому апдейты решено было делать отдельными мелкими файлами. Инструкция по установке таких апдейтов была сложная и длинная, поэтому для упрощения жизни конечному пользователю был придуман OSD Updater.
Общение с пользователями через разные средства (direct e-mail, Forum, Contact Us) осложняло работу техподдержки, поэтому был придуман OSD Messenger.
OSD (Online Support Desk) модуль продукта SQLDetective стал выполнять полноценно всю работу техподдержки: переписка с пользователями, распространение апдейтов.
Как обычно конечный пользователь  десктопного продукта общается с разработчиком? Открывает сайт, чаще ещё и логинится, а потом выбирает более удобный вариант: Contact Us, Forum, Download  Updates, Release Notes. Чтоб написать небольшое сообщение без прикреплений обычно используют Contact Us форму. Чтоб сообщить о проблеме или выяснить особенности программы, пишут в Forum. Чтобы скачать обновления или купить продукт, открывают Download и Buy Now, предварительно сверившись по Release Notes об исправленных проблемах и новых возможностях. Все эти неудобства (большое множество путей с неизвестным маршрутом)  устраняются одним модулем в десктопном продукте – OSD.
Преимущества Contact Us есть только для пользователя: не надо регистрироваться на сайте, связь осуществляется быстро, бесплатно, сохраняя конфиденциальность сообщений. Недостатки для пользователя: к таким сообщениям не делают возможности прикрепить файлы (логи, скриншоты), чаще не делают копию сообщения на ящик отправителя, нет подтверждения о получении, недостаточный объём текста можно отправить. У техподдержки тоже в этом случае больше проблем, нежели преимуществ: нет привязки к данным пользователя (тип лицензии, оплаченные сервисы), приоритета и градации сообщения, настроек программы или screenshots.
Преимущества Direct e-mail сообщения для пользователя: не нужна регистрация на сайте, можно любой e-mail использовать, прикреплять картинки, файлы, текст не ограничен размером, бесплатно, индивидуально. Нет гарантии получить конфирмацию, есть опасность пересылки спама и вирусов. Тех.поддержка получает дополнительные файлы с настройками или логами и картинками, но всё также нет привязки к базе зарегистрированных пользователей со списком оплаченных сервисов, тип и важность сообщения определяется самим производителем-фиксатором.
Среди преимуществ Forum для пользователя можно отметить: вопросы и ответы сгруппированы по продуктам и темам, FAQ, модератор отсекает спам, бесплатно. Недостатками являются обязательность регистрации, не всегда есть возможность опубликовать картинки и логи, отсутствие защищенности конфиденциальных данных. Техподдержке такой тип общения помогает определить версию продукта по информации зарегистрированного пользователя, нет необходимости дублировать ответы на одинаковые вопросы. Но также нет полной информации о проблеме ввиду отсутствия конфиденциальности в публикуемых данных.
Зарегистрированный на сайте пользователь может скачать инсталлятор или патч для текущей купленной версии. Но для этого нужно открыть сайт, залогиниться, выбрать нужный файл, как-то его сохранить и выполнить, самостоятельно определив возможность апдейта.
Поняв и оценив все неудобства пользователя компания Conquest создала утилиту для общения конечного пользователя с группой техподдержки и разработчиками. OSD – Online Support Desk.
OSD Messenger, встроенный в десктопный продукт, является фактически e-mail клиентом. На стороне пользователя сообщения сгруппированы по стандартным папкам "Отправленные" и "Принятые", в рамках которых разделены по значимости: General, Suggestion, Support, Other, News. Значимость и приоритет сообщения выбирает сам юзер при создании сообщения, кроме News, присылаемых компанией в одностороннем порядке (своеобразная реклама деятельности компании).
Переписка через OSD хранится в базе, респонденты идентифицируются по ключу лицензии и ПК, с которого ведётся переписка. Пользователи триальных версий тоже имеют уникальные идентификаторы, но переписка не ограничена триальным периодом в отличие от возможности апдейтов. Поэтому у техподдержки и отдела маркетинга всегда есть под рукой информация для анализа. Сообщение содержит следующие параметры: уникальный номер сообщения со сквозной нумерацией входящих и исходящих сообщений; уникальный идентификатор пользователя в зависимости от лицензионного ключа и используемого ПК; идентификатор продукта, название и страна владельца ключа автоматически считываются из лицензии; имя пользователя и e-mail (юзер получит на него нотификацию об отправленном в OSD ответе) вводятся вручную самим юзером при создании первого сообщения и хранятся в настройках приложения на конкретном ПК; тема сообщения вводится вручную для каждого нового сообщения (кроме авто-создаваемых из EurekaLog); тип и приоритет сообщения юзер выбирает из списка для каждого нового сообщения; текст сообщения юзер вводит вручную, для автосформированных из EurekaLog имеется шаблон, для писем с историей предыдущие тексты видны только в режиме просмотра и недоступны для редактирования; пользовательские прикрепления разрешены стандартных типов, кроме исполняемых файлов, размером не более 4Мб как ограничение базы с сообщениями; в числе стандартных прикреплений лог приложения и лог ошибки в формате EurekaLog, скриншот рабочего стола при логировании ошибки с помощью EurekaLog, настройки приложения из реестра и файлов, настройки аудитора кода, параметры операционной системы и клиентов базы Oracle, некоторая инфа о лицензии продукта. Все эти данные позволяют быстро и эффективно, без лишних вопросов юзеру решать описанную проблему сразу на первой линии техподдержки.
Сообщение можно создать в несколько приёмов, для этого имеется папка Drafts. В последних версиях продуктов добавлена возможность создавать черновики сообщений без наличия Интернета, который ранее использовался для присвоения уникального номера сообщению. Теперь он создаётся в момент отправки на сайт.
К сожалению, пока что стандартные прикрепления актуальны на момент просмотра сообщения или на момент отправки.  Параметры системы, настройки приложения и системы могут быть изменены с момента появления ошибки и до момента отправки сообщения, и это может исказить условия проблемы. А также они не сохраняются при сохранении черновика.
Каждое сообщение, отправленное из OSD Messenger, регистрируется в базе и юзеру моментально отправляется ответ с подробностями о принятом сообщении: присвоенный уникальный номер, планируемая дата ответа, объём принятых прикреплений. Тем самым выказывается юзеру уважение о каждом его посте.
При появлении нового сообщения юзера в базе на ящик техподдержки высылается нотификация с важными подробностями, достаточными для рассмотрения проблемы: уникальный номер сообщения; параметры лицензии и юзера для определения доступных возможностей и приоритетов ответа; срок отправки ответа; линки для скачки прикреплений; дубликат заголовков и текста сообщения. Подробности о лицензии (оплаченный сервис техподдержки, срок действия лицензии, купленные эдоны) ранжируют сроки ответа: триальщики и пользователи с оплаченным сервисом должны получить ответ в день получения сообщения, но не позже двух рабочих дней; бета-тестерам ответы можно отправлять на следующий день после получения, но не позже 7 рабочих дней; пользователям с оконченной лицензией и с оплаченной лицензией, но без оплаченного сервиса техподдержки, ответ отправлять спустя 5 дней после получения, но не позже 10 дней. Такие сложности были придуманы как маркетинговый ход для покупки юзерами годового сервиса техподдержки. Подробности об эдонах из лицензии дают понимание о функциональных ограничениях на стороне пользователя.
Наличие нотификаций о сообщениях пользователя исключает утечку персональной инфы за пределы серверов и сети компании. Доступа к корпоративным ящикам и сайту достаточно в локальной сети для поддержания политики безопасности о нераспространении информации. С 2014 года команда разработки активно расширялась, на десяток разработчиков добрали трёх тестировщиков и распределили их по-продуктно. Каждому сотруднику техподдержки помимо личного корпоративного ящика определён был e-mail для ведения техподдержки. Но два ящика на сотрудника принесли только проблемы: команда стала путаться на какой ящик какого характера инфу отправлять; поскольку названия ящиков техподдержки унифицированы (например, tech-support-99), то имена владельцев путались до особого распоряжения об обязательной полной подписи владельца в теле письма и адресной книге.
Половинчато система получения и рассмотрения сообщений реализована на сайте, но поскольку на создание и переделку back-end для внутренних нужд всегда не хватает ресурсов и времени, то e-mail нотификаций вполне достаточно.
С полученной нотификацией техподдержка работает по следующей схеме. Тема нотификации префиксуется коротким именем продукта, а тестировщики распределены по-продуктно. Ответственный тестировщик при получении нотификации проводит расследование: воспроизводит проблему на билде, указанном в сообщении; пытается воспроизвести на последнем опубликованном билде, если он отличается от билда юзера; пытается воспроизвести на текущем разрабатываемом билде; при недостаточности знаний продукта обращается за помощью к продуктовым разработчикам. Любые подозрения об использовании лицензии уточняются с отделом маркетинга путём пересылки текущей нотификации топам с копией PM. Для выяснения таких проблем помогает база всех сообщений в разрезе пользователей. Поскольку сообщения на сайте время от времени архивируются, то удобней пользоваться e-mail клиентом, в котором за год добавляется около тысячи писем, а все прикрепления к письмам скачаны и лежат на быстром жёстком диске. Выявленные проблемы оформляются в BTS. Составляется черновой вариант ответа на английском языке (включаются пересылки прод.лидам в случаях сложных проблем), выделяется в пересылаемой нотификации особыми символами (одинарные фигурные скобки), сразу прописывается имя юзера по особо принятой схеме (первые пять ответов First Name + Last Name, остальные – только First Name), текст форматируется под обычный (форма ответов не располагает опциями html-форматирования, получаемые юзером ответы просматриваются как обычный текст), подпись конкретным именем отвечающего разрешена только для особых давних пользователей. Первый черновик отправляется лингвисту на проверку. Лингвист вносит исправления и добавляет второе выделение фигурными скобками, как признак пройденности вторичной проверки. Проверенный текст перенаправляется PM на утверждение технических и юридических сторон. При благополучном пройдении проверки у PM он разрешает отправку согласно графику (приписывает "OK" в начале пересылаемого письма) и отправляет первоначальному тестировщику, в иных ситуациях (ответ отложить или раньше времени отправить, ответ не соответствует ожиданиям) с соответствующей припиской нотификация возвращается на доделку тестировщику или лингвисту. Одобренный черновик ответа публикует тестировщик в строго отведённое время, чтоб пользователь в разных частях света не был потревожен e-mail нотификацией в его внерабочее время. Если юзер указал e-mail в OSD сообщении, то на него высылается нотификация о наличии ответа. Сам ответ юзер может прочитать только в OSD Messenger. После отправки ответа тестировщику тоже приходит нотификация об отправленном ответе с полным его текстом. Их фильтруют по папкам юзеров в e-mail клиенте.
Для выяснений всех обстоятельств проблемы техподдержке часто приходится беспокоить пользователя дополнительными вопросами. В Conquest было принято правило минимизации количества пересылаемых писем юзеру, которое может показать высокий уровень подготовленности кадров. В помощь для соблюдения этого правила, для сбора статистики отделом маркетинга, для полноты картины проблемы в сообщения OSD добавили авто-прикрепление настроек приложения, параметров системы и логи. Поскольку настройки приложения хранятся в разных местах (реестр, файлы в папках %AppData% и MyDocuments), то пользователю сложно выбрать и найти необходимый объём информации для пересылки в техподдержку. Но пользователь всегда должен иметь возможность просмотреть объём отправляемой информации, так как в ней может оказаться некоторая персональная/корпоративная тайна (пароли, параметры доступа и т.д.). Поэтому в рамках просмотра отправляемого сообщения должна быть возможность исключения настроек приложения и системы из пересылаемого прикрепления. В текущих версиях продуктов можно только увидеть список отправляемых файлов, без возможности просмотра и исправления их содержимого. Реализовать такое не сложно, но Conquest не тратит на это время, потому что каждый раз подписывается обещанием о нераспространении инфы третьим лицам. А отсутствие возможности править отправляемое стандартное прикрепление подрывает доверие пользователя, и во избежание недоразумений юзер совсем исключает стандартные прикрепления. Большая помощь техподдержке и программисту поступает из лога и скриншота EurekaLog. Внешнюю утилиту несложно встроить в десктопное приложение. При сложных багах утилита собирает информацию о приложении и системе (запущенные дополнительно приложения, выполненные команды приложения вплоть до номера строки в конкретном модуле/скрипте), которую можно напрямую отправить по электронной почте или в качестве прикрепления к OSD сообщению. Зачастую такой лог программисту говорит намного больше, чем картинка и описание шагов от юзера. Eureka может и сама составить письмо, но оно получается скупым, без настроек приложения и screenshot-а. А OSD сообщение имеет полноценный заголовок, развёрнутое тело и все прикрепления.
Описанная система техподдержки имеет много недостатков в случае текучки кадров, из-за задержек при работе с почтой, архивы базы сообщений разбросаны по разным машинам, клиент TheBat накладно переносить и распространять на другие машины. К тому же базы OSD, Contact Us и Direct сообщений разрознены. Поэтому была запущена реорганизация работы отдела техподдержки. Первым шагом был перенос архива переписки с пользователями из TheBat в Thunderbird. Процесс растянулся на несколько дней, так как нужно было каждую папку экспортировать отдельно для файлов "msf". В очередной раз пришлось отказаться от Outlook из-за его неудобства экспорта-импорта и последующих проблем излишнего форматирования текстов. В качестве второго шага было принято правило рассылки черновиков с ответами всем членам первого уровня техподдержки для повышения знаний продуктов. Но очень скоро выяснилось, что данное правило спамит сильно и отвлекает тестировщиков от своего продукта. Для исключения недостатков и объединения OSD сообщений с Contact Us в единую базу было предложено отказаться от почтовых пересылок за счёт хранения и обработки всей информации на сайте, но предложение усовершенствовали до более лёгкого в реализации – создавать задачи в Jira автоматически из сообщений пользователей. Если к Jira привлечь топов, то такая система имела бы место жить и эффективно работать. Но Product Manager никак не желал открывать внутреннюю BTS верхнему руководству. Здесь же аукнулась проблема языка межкомандного общения (с топами только по-английски, внутри разработчиков по-русски), которая не всегда позволяет полноценно описать и понять проблему ввиду ограниченности знаний. А пока техподдержка оборудована нотификациями о новых сообщениях, о предстоящем окончании срока отправки ответа, о просроченной отправке ответа.
Для бета-тестеров одно время существовала система публикации вопросов и ответов OSD сообщений, но её прикрыли во избежание обнародования всех продуктовых проблем. Даже в созданных группах соц.сетей модератор запрещает обсуждать какие бы-то ни было продуктовые проблемы и даже предложения.
В Conquest отказались от Forum, так как "OSD Messenger + Contact Us" решают все проблемы в полной мере, на сайте предостаточно описательной инфы продуктов и проводятся вебинары (по запросу).
Вторая немаловажная часть OSD – это Updater. Пользователю десктопного продукта со сложной структурой ядра и плагинов часто сложно определить наличие и доступность апдейтов. Большую проблему обновления десктопных продуктов приносят в ручном режиме. Хотя на сайте и существует блок аккаунта пользователя лицензий, но и в нём бывает сложно определиться – что скачать, куда и как ставить. OSD Updater в десктопном продукте с подключением к интернету выполняет апдейт в автоматическом режиме исходя из данных лицензии и установки: определяется пакет доступных обновлений, скачивается и распаковывается с достаточным количеством перезапусков.
OSD Updater может присылать и применять ключ для апгрейда. Но во всех других случаях (утеря, докупка или прерывание AMS сервиса, увеличение количества лицензий, смена персональных данных) дубликат или новый ключ можно получить только через сайт. Это предложение не запущено в разработку, поскольку ни один из реальных пользователей пока что не запросил подобное.
Для пользователей с очень закрытой системой, то есть без доступа в Интернет, была сделана доработка OSD Updater через файловую систему. В этом случае администратор продукта скачивает апдейт с сайта и выкладывает в общий локальный ресурс, а в приложении выставляется настройка на этот локальный ресурс. Но даже в режиме файловой системы апдейты могут определяться и устанавливаться автоматически при запуске приложения. OSD Updater в desktop приложении работает как и тихие апдейты сегодняшних web-приложений, сайты: стартует с приложением; определяет тип, версию приложения и ключа; определяет место установки конкретной версии; предлагает доступный билд или версию, если оплачен upgrade; проводит переинсталляцию; качает и применяет ключ новой версии (и в многопользовательской версии для нескольких филиалов). Юзеру остаётся только откинуться на кресле и подождать пару минут, не забыв кликать по кнопкам Next и OK.
Для заканчивающихся ключей и AMS (Annual Maintenance Support) придумали нотификатор в трее. Он может работать без Интернета, имеет настройку от спама.
В 2009 году линейка продуктов пополнилась ClearSQL и ClearDB Documenter. Для них OSD было вынесено в самостоятельную библиотеку и внедрено в оба продукта. В 2016 году появился бесплатный docuVIEWER, который тоже планируют пополнить модулем OSD.