Громозека

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

ТнаТ

Тестировщик на техподдержке (ТнаТ) или Слуга на все четыре стороны

Кто есть тестировщик на техподдержке? Сотрудники техподдержки первого, второго уровня (бывшие аналитики, бета-тестеры) обязаны досконально знать продукт, чтобы максимально быстро дать ответ пользователю. Третий уровень техподдержки - программисты - знают код продукта, то есть его внутренности. Тестировщики знакомы с продуктом как со стороны пользователя, так и со стороны кодеров. К тому же у тестировщиков выше уровень грамотности, что является важным фактором при оформлении ответов пользователям и задач в баг-трекинговую систему. Поэтому на первый уровень техподдержки обычно ставят тестировщиков, иногда аналитиков. Но поскольку у тестировщиков есть ещё и знания кодирования, то тестировщик на должности техподдержки получается более дешёвым сотрудником.
Общепринято считать, что тестировщик и сотрудник техподдержки должны в первую очередь защищать сторону пользователя, то есть быть адвокатом юзера. ТнаТ должен уметь общаться с пользователем наравне - грамотно, но не заумно; на доступном для обеих сторон языке; о пользовательских нуждах, воплощённых в коде. Любой отчёт пользователя приходится рассматривать как критичный баг, убеждать кодеров и руководство в необходимости правки. Программисты, как всегда, ведут разъяснительные беседы о новшествах, которые плохо описаны в аннотации к билду, поэтому юзер считает фичи багами.
Соглашусь, что напору проггеров сложно противостоять, и вскоре мнение тестировщика склоняется в сторону фичи, а не бага. Но при этом техподдержке приходится вуалировать или откровенно врать пользователю о явном баге, который по мнению аналитиков и программистов тянет на фичу. Выясняя подробности отчёта юзера, сотрудник техподдержки оказывает неоценимую услугу аналитику и программисту, облегчая им работу, или, попросту говоря, работает вместо них: переформулирует вопросы с кодерского языка на юзерский и ответы обратно, уговаривает пользователя принять ошибку за новшество. Вот и первая ступень борьбы ТнаТ с совестью. В моей практике было не мало примеров, когда программист заменял логичное "два плюс два" по задаче от аналитика "два и два" в более быстрое по мнению кодера "дважды два". При этом результат в большинстве случаев не менялся, но никакое предупреждение пользователя в продукт или аннотацию к билду не включали сотрудники, выпускавшие билд. Когда пользователь обнаруживал такое несовпадение, то непременно репортил его как баг, а то и отказывался от продукта с заявлением о возврате потраченных им средств. Баг ли это или рефакторинг, промах  разработчиков или выпускавших билд - решение принимал всегда шеф не в пользу тестировщиков и техподдержки.
Но как ни печально, далее ещё сложнее, поскольку врать приходится ради денег фирмы. Ложь для собственной единоличной наживы совесть позволяет оправдать. А групповой обман подпадает под уголовную статью второй-третьей частей, то есть более сильную. Отдел маркетинга проводит опросы, собирает статистику, распространяет рекламу. Вся информация в оба конца проходит через руки ТнаТ, который группирует её по контрагентам, анализирует при исследовании проблемы, передаёт часть маркетологу, часть аналитику и программисту, часть руководству. Конечно, из настроек продукта ТнаТ может вычленить много полезного для локализации бага, но вместе с этим приходится пропускать (с 25 мая 2018 года шифровать, маскировать и фильтровать в рамках GDPR) индивидуальную инфу. Некоторые ошибки тесно связаны с персональными данными, но у ТнаТ не всегда есть право распространять инфу третьим лицам, которыми вполне можно считать кодировщиков. Итого, сначала ТнаТ шлёт рекламу пользователю с обещаниями всяческих плюшек, а чуть позже ему же приходится оправдываться в их отсутствии или иной реализации, при этом быть политкорректным настолько, чтобы фирма не потеряла свои финансы. Но виноватыми в этой ситуации остаются сами же ТнаТ, как в глазах пользователя (ТнаТ - лицо компании), так и по мнению руководства, для которого за успех продукта поощряются программисты, а за провал наказываются тестировщики. Для избежания подобных проблем ТнаТ должно быть позволительно влиять продукт: участвовать в планировании спринта (особенно если реклама обещает новшества к определённому сроку), проверять аннотацию (Release Notes) к выпуску, тесно сотрудничать с финансовым отделом для ограничения распространения спама о скидках или регулярных платежах за техподдержку. Тогда ТнаТ может проявить всю свою политкорректность в переписке с пользователем не споря с собственной совестью.
Ну, и самый тёмный угол - это соблюдение законов, которые подчас могут противоречить друг другу. Например, корпоративная этика, минимизирующая бюрократизм, и закон о сохранности персональных данных, обязывающий логировать передачу индивидуальной информации. ТнаТ тяжело удерживаться на своём месте и не противоречить сотрудникам фирмы, поскольку маркетолог, программист и пользователь как лебедь, рак и щука тянут продукт в свои стороны. А ТнаТ вынужден меж этих огней ещё и соблюдать законность, политкорректность и дружелюбность в общении пользователя и фирмы. Сотруднику техподдержки бывает очень сложно убедить руководство не обманывать пользователя для соблюдения законности: предупреждать об объёме собираемой и пересылаемой в фирму индивидуальной информации пользователя; отвечать за обещанное рекламой и фактически поставленное продуктом в рамках лицензионного соглашения; скрывать от пользователя конкретику работы фирмы в рамках соглашения о нераспространении внутрикорпоративной информации и подробно описывать шаги группы разработки для спокойствия пользователя.
Миссия ТнаТ не легка. При переходе на должность сотрудника техподдержки непременно подтяните свои знания в области юриспруденции, психологии, грамотности (русский или английский язык переписки с пользователями) и дикции (для случаев аудио-связи), наряду с отличным знанием продукта.

AutoRN

Как ваш техписатель (ТП) или выпускающий билд тестировщик (Т) собирает текст для Release Notes (РН)? РН всегда собирает один человек или любой в состоянии сделать это? На всех стадиях разработки и выпуска продукта проводится проверка текста на адекватность или полагаетесь только на ТП, который в последний день перед выпуском шерстит все закрытые задачи и выписывает нечто приблизительное? А может только выбирает подряд все Summary из задач, вошедших в билд? Храните ли вручную собранные РН в Системе Контроля Версий (СКВ), легко ли их найти и вставить в инсталлятор продукта?
Как создавать описание билда, которое будет понятно пользователю, и он его обязательно изучит – об этом и расскажу.
ConquestSS публикует билды десктопных продуктов не часто (максимум – раз в полгода), а посему существует система бета (b) и предвыпускных (rc) билдов, для которых нет надобности компоновать РН. Вместо текста показывается шаблонный текст: "RELEASE NOTES [ProductName] [MajorNumber].[MinorNumber] Release [ReleaseNumber] (draft, not completed)".
Общепринятая структура РН: Новинки (Н – Features), Улучшения (У - Improvements), Исправленные Ошибки (ИО – Fixed Bugs), Исключено (И – Deleted/Deprecated), Возможные Проблемы (ВП – Detected Bugs). На каком этапе удобнее группировать? Для автоматизации конечно же надо начинать с низов – каждую задачу сразу распределять по структуре РН.
Из каких источников ТП может брать информацию для составления РН? К каждому сабмиту в СКВ разработчик обязательно пишет короткий комментарий о сделанных изменениях, который понятен сотрудникам со знанием языка программирования. Хоть СКВ и имеет самое правильное распределение задач по номерам билдов, но тексты комментариев к сабмитам мало подходят для РН, ведь их будет читать пользователь, не знающий "кухни" продукта. Поэтому инфу лучше брать из Баг-Трекинговой Системы (БТС). Но в БТС задачи ведутся для параллельных билдов или даже продуктов, поэтому нужны определённые пометки. В Jira есть очень полезная и удобная штука – лейблы, которые может добавлять и менять любой пользователь БТС, а также по ним легко фильтровать. Поскольку одна задача может содержать несколько лейбл, то и проблема параллельных билдов/продуктов вполне разрешима. Для автоматизации сбора РН была предложена система лейбл: "RN_[MinProductName]_[MajorNumber].[MinorNumber].[ReleaseNumber].[LastPublishedBuildNumber]+", где префикс "RN_" означает причастность задачи к РН, "MinProductName" – короткое наименование продукта, " [MajorNumber].[MinorNumber].[ReleaseNumber].[LastPublishedBuildNumber]" – полный номер последнего опубликованного билда, "+" – символ плюса означает последующий выпускаемый билд/версию. Например, в феврале выпустили Продукт Компании (ПК) версии "3.5.7.123", а в апреле собираются выпустить "ПК 3.6.2.ХХХ", в таком случае лейбла для задач, которые необходимо описать в РН ближайшего выпускаемого билда, будет "RN_ПК_3.5.7.123+".
Из какого поля брать тексты, чтоб это было быстро, при минимальном влиянии человеческого фактора? Значение из Summary вряд ли будет понятно пользователю, так как его составляют коротко, понятно лишь для проектировщиков и тестировщиков. Полное описание из Description совсем не подходит для РН, так как много технических деталей, а выбирать пару строк значит прикручивать парсер. Хоть у задач Jira и есть поле Components, но в нём может быть указано несколько модулей продукта, и для РН группировка станет сложной. И самое трудное – тип задачи Н/У/ИО/И/ВП – нельзя брать из поля Type, так как в БТС оформленный баг вполне может быть описан в РН как улучшение, а закрытая новинка без полного тестирования должна быть в блоке исключённых функциональностей. Учитывая вышеизложенные проблемы, было предложено создать текстовое поле "Release Notes Text", не обязательное для заполнения, но с возможностью правки для любого вида задач. История правок в Jira после ревизии аналитиком или разработчиком помогает обучать ТП. Черновой вариант от разработчика способствует составлению тест-аналитиком более полного комплекса тестовых случаев, а подправленный тестировщиком текст добавляет его понятливости конечным пользователем.
Для автоматизации сбора РН пришлось чётко описать во внутренней Wiki схему заполнения поля "Release Notes Text":
- в первой строке указать имя блока группировки РН кратко (Н/У/ИО/И/ВП) или подробно (Новшество/Улучшение/Исправленные Ошибки/Исключено/Возможные Проблемы);
- во второй строке указать одно наименование модуля или функциональной страницы продукта;
- в остальных строках описать задачу понятным для конечного пользователя языком.
При соблюдении такой структуры становится легко и просто распарсить и сгруппировать текст РН. А если показ РН в продукте делается в HTML формате, то необходимое форматирование удобно делать сразу в поле Jira.
Черновой вариант текста к каждой задаче хорошо бы оформлять программисту, потом подправлять тестировщику, а уже ТП завершит процесс форматирования и лексической пригодности.
Сочетание "непустое поле РН" и "наличие лейблы" является итоговым фильтром задач, которые должны быть отмечены в РН ближайшего выпускаемого билда. Лейблу проставляет ТП после полной проверки РН. Сбор текстов из спец.поля Jira – элементарное действие, но необходим самописный парсер для отсева дубликатов, группирования без излишних заголовков и выставления сортировки, соответствующей маркетинговым целям. Этот же автосборщик РН делает тексты в двух вариантах – с указанием номеров задач для промежуточных билдов и отчёта о наличии текстов, их корректности функциональной и лингвистической. Примечание: из РН, собираемых в html-формате, работают линки номеров задач Jira.
Аннотация к билду удобна для налаживания обратной связи с пользователем. К каждому пункту новшества и изменения в РН стоит добавить три чекера "Помогло", "Незаметно", "Лишнее". А в конце текста РН добавить функцию отправки результатов в Вашу техподдержку с возможностью дописать личное мнение о билде. Маркетинг может простимулировать какими-нибудь бонусами отправленную анкету. Будьте уверены, анализ анкет даст огромное поле деятельности аналитикам и тестировщикам.

Копим куки

Очень многие сайты, не исключая самых используемых, не в состоянии корректно обрабатывать куки из списка исключений.

Предварительная настройка:
- в FireFox отключить все куки ("Открыть меню / Настройки / Приватность и защита / Принимать куки с веб-сайтов" = отключено)
- очистить имеющиеся куки ("Открыть меню / Настройки / Приватность и защита / Показать куки" = "Удалить выбранные")
- можно перезапустить браузер, но не обязательно.

Пример 1
- открыть сайт "mail.ru"
- в левом верхнем углу набрать свои (полностью корректные) параметры входа в почту:

- по нажатию на кнопку "Войти" неожиданно появляется опять форма для входа в почту с пустыми данными:

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

Актуально: после второй попытки входа абсолютно неверное сообщение об ошибке в имени пользователя или пароле:


Ожидаемый результат: сообщение об ошибке должно говорить о некорректно настроенных или отключенных куках браузера.
Решение проблемы: добавить "https://mail.ru" и "https://account.mail.ru" (обратите внимание на протокол) в разрешённые веб-сайты для сбора куков.

Примеры 2, 3
Аккаунты в "Blogger.COM", "Blogspot.RU", "Google.COM" недоступны без включенных куков:






Актуально: неожиданное поведение в виде зацикленных пустых окон с предложением войти или создать аккаунт.
Ожидаемый результат: сообщение об ошибке или предупреждение о выключенных или неполноценно настроенных куках.

Пример 4
Аккаунт в Facebook становится доступным после добавления "https://www.facebook.com" в список веб-сайтов для сбора куков, но очень желательно перезапустить браузер после изменения настроек, чтоб не получить неожиданное сообщение:


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

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.