DB IDE

26 апреля 2002 года на общем собрании Кольчугинского филиала компании "Real System for Corp." (RSC) было объявлено о самостоятельном направлении в развитии продукта "Table Magic", который начал своё существование ещё на базе отдела АСУП при заводе "Электрокабель" (ЭКЗ), а затем в 2000 году вместе с "родителем" исходники перекочевали в маленькую компанию разработчиков. В мае 2002 года на московской конференции продуктом, состоящим из "умного грида данных" и редактора хранимых подпрограмм, заинтересовался австрийский бизнесмен, поэтому в июле команду укрепили вторым программистом. Поскольку на тот момент мне приходилось тестировать смежный продукт этой же компании, то мои знания "Table Magic" сначала помогли "подчистить" презентацию и впоследствии привели на место тестировщика. Европейский аналитик порекомендовал множество идей, в том числе переименование в "DatabaseVoyager" (DV) и формирование американской компании "Conquest Software Solutions" (ConquestSS). К началу моей деятельности в августе 2003 года навигатор объектов насчитывал около полутора десятка типов объектов, которые и надо было мне тестировать. Каждый из объектов, добавляемый в список поддерживаемых, имел свой мастер по обработке и некоторые функции в отдельных модулях DV. Постоянно прибавляясь к 2017 году их накопилось более шести десятков. И только спустя пятнадцать лет у владельца продукта единожды возник вопрос о том, как проводится тестирование к тому времени уже давно переименованного продукта SQLDetective (SD).

Как вы понимаете, изначально никакого процесса тестирования в RSC не существовало, поэтому мне пришлось искать варианты самостоятельно. К тому же, руководитель проекта ставил программистов на несколько ступеней выше меня и не позволял вытягивать знания из них, а вместо этого отсылал все мои вопросы к самостоятельному изучению документации базы данных Oracle, собственно говоря для которой и создавался интерфейсный продукт, конкурирующий с TOAD от Quest Software. Итак, знания о новом объекте существенно отличались у программиста и тестировщика, а все задачи на разработку и тестирование были весьма краткие: "добавить поддержку объекта NN". В понимании программиста это зачастую ограничивалось созданием мастера объекта, поскольку он опирался лишь на статьи по его созданию (CREATE), редактированию (ALTER) и удалению (DROP). Но взгляд тестировщика на термин "поддержка объекта в продукте" более широк и рассматривает все операции (GRANT, REVOKE, ANALYZE, PURGE, ...) над объектом, доступные в базе данных. Эти мои обширные знания вынуждали формировать лишь на этапе тестирования, а не в процессе планирования, множество заданий на доработку.

Итак, первым шагом в тестировании нового поддерживаемого объекта было изучение документации. На это в моём плане по тестированию отводился целый день, поскольку в SD поддерживалось несколько версий базы. Сначала для последней версии базы распечатывались статьи по созданию (CREATE), редактированию (ALTER) и удалению (DROP) объекта. Затем тексты сравнивались с каждой предыдущей версией и в распечатке делались пометки о новшествах и утилизациях опций. Документация по объектам Oracle довольно хорошо структурирована, поэтому легко вычленялись необходимые статьи, в которых достаточно было сравнить лишь схемы DDL. Со временем в помощь разработчикам и тестировщикам в SD появился модуль "Oracle Documentation Browser", в котором можно было проиндексировать сразу все пять (на тот момент - 7.3, 8.0, 8.1, 9.0, 9.2, а позже к ним добавлялись 10.1, 10.2, 11.1, 11.2, 12) версий базы. Поиск в этом модуле позволил расширять тестирование статьями про иную (GRANT, REVOKE, ANALYZE, PURGE, ...) обработку объектов и связи, зависимости с другими объектами (точки восстановления с архивами, логи м/в и группы м/в, таблицы и их индексы, триггеры, констрейнты). Но некоторые (POLICY, MV GROUP, RESOURCE PLAN, ...) объекты БД Oracle регулируются не самостоятельными командами, а системными (DBMS_RLS, DBMS_REFRESH, DBMS_RESOURCE_MANAGER, ...) пакетами. Для их тестирования достаточно одной статьи, в которой пакетными процедурами и функциями описаны все действия над объектом, что немного упрощало дело. К концу первого дня у меня получался распечатанный план тестирования в разрезе версий БД и по операциям над объектом, по объёму которых можно было определить необходимое время на все последующие проверки. Так, на "большие" объекты (таблицы, шедулеры) минимально требовалось от пяти дней, а на самые "маленькие" (последовательности, операторы) - до двух дней.
Второй шаг - основное тестирование функциональности - проверяет корректность создания, редактирования и удаления объекта средствами нового интерфейса. Все эти операции в минимальном объёме выполняются на каждой из поддерживаемых версий БД. Следующим проходом по версиям базы тестируются различия схем DDL. И самое сложное, оставленное на закуску, заключается в детальной проверке всех опций DDL, которые в большинстве случаев достаточно посмотреть на последней версии базы.
На третьем шаге тестирования поддержки нового объекта в SD проверяется возможность выдачи и отъёма привилегий на объект через мастер привилегий, если таковые предусмотрены документацией Oracle. Здесь же рассматривается принадлежность объекта юзерской схеме или его системное положение. Не стоит забывать и про версионность базы данных.
Четвёртый шаг рассматривает взаимосвязи объектов через их мастера и панели выгрузки DDL. Например, мастер триггера вызывается из мастера таблицы, а индексный кластер можно создать в базе только после создания индекса. Тестирование SD расширяется модулями Schema Extractor, Compare DB и другими, где как-то фигурирует DDL нового объекта. Очень серьёзно здесь стоит приглядываться к различиям в версиях БД.

Заключительным пятым шагом проверяются всевозможные операции над новым объектом в различных утилитах SD. Например, релокацией партиций занимается "Storage Manager", перекомпиляция хранимой подпрограммы автоматически происходит при её открытии в "Stored Program Editor", для анализа вьювера существуют самостоятельные интерфейсы в рамках одного объекта или целой схемы. Как уже ранее говорилось, именно этот шаг даёт максимальный прирост задач программисту на доработку.

Тесты доступности, удобства, производительности и безопасности лучше проводить не самостоятельным шагом, а в рамках каждого из описанных. Набив руку на первом десятке объектов, у меня сформировалось устойчивое понимание, что только комплексное тестирование может сократить время на проверки, предусмотренные шагами со второго по пятый. К сожалению, владелец продукта никогда не жаловал процесс тестирования, поэтому ни при waterfall, ни при agile не был приверженцем декомпозиции задач и детального планирования, даже совмещая роль скрам-мастера. Менеджер продукта и первый программист откосили в своё время от армии, поэтому и не стремились к порядку, не умеют и до сих пор чётко следовать правилам и сдерживать данные обещания, как это принято у честных бизнесменов.  Очевидно поэтому вопрос РМ-а о вышеописанном стал чисто риторическим с его стороны, а ответ оформился в статью только спустя ровно семнадцать лет после оформления моего первого бага по SD, но уже не для команды ConquestSS, а для вас - простых тестировщиков.

СУТ

Стратегия утилизационного тестирования ("сут" в переводе с казахского - молоко, если нет попаданий в цель, то это синоним аутов) в период кризиса выходит на первый план. Текущее время - самое подходящее для разворота направления работ отдела тестирования в сторону сворачивания бизнеса, помогая руководителю проекта оставить продукт пользователям в наилучшем состоянии для очистки совести ответственных за качество.
По результатам моих исследований нижеследующий чит-лист ни единожды спасал компанию от излишних расходов на поддержку производства после расторжения договоров.
1.  Изучить лицензионное соглашение юзера и выделить параметры:
1.1. период действия купленного продукта. Опираться на него при планировании фиксов;
1.2. период техподдержки. Выполнять работы только для оплаченных сервисов и пользователей;
1.3. объём работ по тех.поддержке: править баги, искать обходные пути, предоставлять обновления билдов и версий. Ограничить план тестирования только теми задачами, которые имеют юридическую силу
2. Вычленить из BTS мега-критичные баги (регрессия, нагрузка, обновление внешних систем) для срочной правки. Предоставить по ним отчёт руководителю проекта для согласования тест-плана.
3. Закрыть магазин и продажи для новых покупателей без остановки форумов, сообществ, мест обратной связи:
3.1. уведомить весь список дилеров об ограничении продаж;
3.2. личный кабинет пользователя ограничить доступной версией;
3.3. фильтровать рассылку писем пользователям по доступности продаж.
4. Контролировать публикацию инфы в открытых источниках о возможностях продукта (сайты компании и дилеров, хелп продукта).
5. При приёме заявок от актуальных пользователей критичность и важность входящих багов определять по массовости использования модуля.
6. Прекратить приём и оформление предложений по усовершенствованию продукта.
7. Работа тестировщика продолжается вплоть до завершения периода техподдержки, если лицензионным соглашением определено исправление критичных багов и поставка обновлений.

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

ТП cheat-sheet

Очень часто технической поддержкой программных продуктов обязывают заниматься тестировщиков. Но и как самостоятельный объект тестирования ТП вполне должна занимать определённое место в тест-плане.
Долгие годы мне приходилось осуществлять ТП продуктов, совмещая с тестированием и постановкой задач. Хоть это порой и сложная задача, но весьма полезная во всех отношениях. Общее качество продукта складывается и из качества (оперативность, экспертиза, внимание к каждому пользователю) его поддержки, как одного из завершающих этапов.
Скомпоновать потребности технической поддержки мне захотелось не только для того, чтобы тестировщики могли упростить свой процесс тестирования этой грани продукта, но и в качестве идеи для тех StartUp-ов, которые хотят и могут создать универсальные утилиты для встраивания их в любые продукты. Личным опытом стоит делиться, но он субъективен. Поэтому, собрав воедино некоторые аспекты ТП, хочу доставить свои знания не только тем, кто о них не задумывался, но также и тем, кто желает усовершенствовать поддержку своего продукта. Наличие каждого артефакта разделено по типу продукта с уровнем потребности:

обязательно

желательно, можно, опционально

ненужное, лишнее

Вполне допускаю, что какие-то из сторон дела упущены. Моя благодарность уже летит к тем, кто поможет дополнить и расширить список:

			Desktop без доступа в Интернет	Desktop с выходом в Интернет	WEB	Mobile	IoT	IoT + PC/mobile menu
1. Обмен сообщениями с ТП			++	++	++	++	++	++
	1.1. e-mail		++	++	++	?	?	?
		1.1.1. внешний клиент	++	++	++	++	++	++
		1.1.2. встроенный клиент	__	++	?	?	__	?
		1.1.3. учёт обращений	++	++	++	++	++	++
	1.2. форум-сообщество и BTS на сайте производителя		?	?	?	?	?	?
		1.2.1. вход через интерфейс ПО	__	++	++	++	__	++
		1.2.2. единый ID пользователя	++	++	++	++	++	++
		1.2.3. закрытость/открытость	++	++	++	++	++	++
		1.2.4. самописные (ресурсы, цена, поддержка)	++	++	++	++	++	++
		1.2.5. учёт обращений	++	++	++	++	++	++
	1.3. группа в общественных сетях, облачная BTS		?	?	?	?	?	?
		1.3.1. открытая	?	?	?	?	?	?
		1.3.2. закрытая	++	++	++	++	++	++
		1.3.3. линк с сайта производителя ПО	?	?	?	?	?	?
		1.3.4. QR-код, линк в документации пользователя	__	++	++	++	?	++
		1.3.5. оплата внешних сервисов	?	?	?	?	?	?
		1.3.6. привязка к внутреннему учёту обращений	++	++	++	++	++	++
	1.4. интернет-канал телефонных сетей		?	?	?	?	?	?
		1.4.1. с дубляжем на сайте сети	?	?	?	?	?	?
		1.4.2. общие группы	__	?	?	?	?	?
		1.4.3. индивидуальные звонки	++	++	++	++	++	++
		1.4.4. видео-звонок	?	?	?	?	?	?
		1.4.5. учёт обращений	++	++	++	++	++	++
	1.5. голосовой звонок		?	?	?	?	?	?
		1.5.1. авто-набор телефонного номера	__	++	++	++	__	++
		1.5.2. многоканальный сервис	++	++	++	++	++	++
		1.5.3. запись разговоров	++	++	++	++	++	++
		1.5.4. учёт звонков	++	++	++	++	++	++
	1.6. прикрепления к сообщению при баге ПО		++	++	++	++	++	++
		1.6.1. скриншот	?	?	?	?	?	?
		1.6.2. логи	?	?	?	?	?	?
		1.6.3. макрос шагов, видео с экрана	?	?	?	?	?	?
		1.6.4. настройки ПО, ОС, РС (железо)	?	?	?	?	?	?
	1.7. письменно на бумажном носителе		++	?	?	?	++	?
	1.8. личное обращение без средств связи		++	?	?	?	++	?
	1.9. авто-сообщение при баге			++	++	++	?	++
		1.9.1. нотификация и подтверждение отправления	++	++	++	++	?	++
		1.9.2. редактирование текста	?	?	?	?	__	?
		1.9.3. контроль, редактирование прикреплений	++	++	++	++	?	++
		1.9.4. отложенная отправка	++	?	?	?	?	?
		1.9.5. дубляж на e-mail отправителя	++	++	++	++	++	++
2. Обновление ПО			++	++	++	++	++	++
	2.1. самостоятельно		++	?	__	?	++	?
		2.1.1. контроль оплаты	++	?	__	?	?	?
		2.1.2. версионность вверх и вниз	++	++	__	++	++	++
		2.1.3. совместимость ПО и ОС, версий ПО и плагинов	++	++	__	++	++	++
		2.1.4. инсталляция и настройка	++	++	__	++	++	++
		2.1.5. получение апдейта (нашёл-скачал, линк в спам-письме)	++	++	__	?	?	?
		2.1.6. апдейт из первых рук или от посредника	?	?	__	?	?	?
	2.2. автоматически		__	++	++	?	?	++
		2.2.1. период для сканирования обновлений	__	++	++	?	?	++
		2.2.2. видимый/скрытый режимы проверки и установки	__	++	++	?	?	++
3. Обучение пользователей, внедрение, бета-тестирование			++	++	++	++	++	++
	3.1. вебинары, лекции, курсы		?	?	++	?	++	?
	3.2. встроенный в ПО хелп (текст, картинки, видео)		++	++	?	?	__	++
	3.3. обучающий режим ПО		++	++	?	++	?	?
4. Оплата			?	?	?	?	?	?
	4.1. бесплатный/триальный период		++	++	++	++	++	++
	4.2. периодичный сервис (годовая оплата All-included)		++	++	++	++	++	++
	4.3. по критериям (общение бесплатно, апдейт за деньги)		?	?	?	?	?	?
	4.4. внешний сервис оплаты или встроенный "кошелёк"		?	?	?	?	?	?

Вполне возможно, что некоторые пункты не раскрывают сути в таблице, поэтому постараюсь дополнить их пояснениями.
1. Обмен сообщениями с ТП одно из основных предназначений ТП, как элемент общения производителя с потребителем.
1.1. e-mail письма наиболее популярный вид современного общения с хорошей конфиденциальностью пересылаемых данных.
1.1.1. внешний клиент доступен пользователям любых типов продуктов, но сложен для производителя в плане учёта сообщений (конвертация в BTS, группирование по юзерам или типам обращений). Также в их редакторах иногда возникают проблемы с кодировкой языка и локализацией времени. Но из готовых клиентов стоит присмотреться к их функционалу: фильтрация сообщений, планирование событий, шаблонизация ответных текстов, форматирование текстов, размещение и хранение прикреплений и другие полезности.
1.1.2. встроенный клиент требует серверного пространства на сайте производителя, внутренних ресурсов команды (знания, время). Нет возможности встроить в некоторые типы продуктов. Но такая система самая гибкая.
Огромную часть оформления можно переложить на пользователя и авто-сборщик:
- дата-время создания сообщения должна конвертироваться в единый формат и региональный пояс;
- уникальный номер входящего сообщения автоматически может формироваться в системе приёма (ID юзера + timestamp получения поддержкой) или отправки (ID юзера + timestamp создания пользователем);
- параметры кастомера (территория, дилер, корпорация кастомеров, и т.д.) для группирования аналитических данных;
- категория (жалоба, благодарность, предложение, запрос на покупку или дополнения, и т.д.) может выбираться из оговоренного списка;
- уровень (критичное, важное, мелочёвка) может выбираться из оговоренного списка;
- краткий заголовок задачи автоматически попадает из Subject письма в Summary поле BTS;
- содержимое письма Body автоматически разделяется на текст для Description и прикрепления в BTS:
- распарсивание логов и настроек для последующего бизнес-анализа;
- расчёт конечной даты ответа автоматически производится по типу лицензии и критериям сообщения;
- автоматически в ТП формируются напоминания о неотвеченных сообщениях;
- обратная совместимость BTS с отправщиком писем;
- авто-ответ с отметкой о регистрации входящего сообщения (обязательная или настраиваемая отправка).
Любой бизнес-аналитик подтвердит, что по данным, полученным через встроенный сервис, можно сделать множество реальных прогнозов (или даже финансовых планов). Активность пользователей легко поддерживать массовой рассылкой новостей.
1.1.3. учёт обращений легко и быстро автоматизируется при наличии встроенного клиента. Внешние клиенты писем пока не разрешают совместное использование, поэтому учёт ограничен одним сотрудником ТП, а не распространяется на тестировщиков и владельцев продукта.
1.2. форум-сообщество и BTS на сайте производителя как часть системы встроенного клиента e-mail писем, но может нарушаться конфиденциальность публикуемых данных.
1.2.1. вход через интерфейс ПО возможно осуществить при наличии определённого интерфейса (главное меню, единый футер web-страниц, и другое) в продукте и доступа в Интернет с машины пользователя.
1.2.2. единый ID пользователя на портале производителя и в форуме пользователей, экспертов.
1.2.3. закрытость/открытость самого сервиса влияет на доверие пользователя при публикации внутренних данных. Но открытые форумы или их часть могут способствовать рекламе продукта.
1.2.4. самописные (ресурсы, цена, поддержка) порталы гибкие в настройке и управлении, но могут быть дороги в обслуживании.
1.2.5. учёт обращений всегда возможен в автоматическом режиме, но ограничен общедоступными параметрами сообщений.
1.3. группа в общественных сетях, облачная BTS как любое готовое решение не всегда имеет необходимый набор возможностей. В большинстве случаев требуется постоянная оплата сервисов.
1.3.1. открытая исключает конфиденциальность, обилие жалоб и неотвеченных сообщений снижает рейтинг производителя, но вполне может быть бесплатным рекламным субъектом.
1.3.2. закрытая группа нуждается в модераторе (подключение участников, контроль конфиденциальности), малополезна в качестве рекламного щита.
1.3.3. линк с сайта производителя ПО или из интерфейса продукта будет не только полезным, но и удобным путём обращения пользователя в ТП.
1.3.4. QR-код, линк в документации пользователя необходим в современном мире для ускорения общения. Некоторые сотрудники ТП даже считают его наличие хорошим тоном.
1.3.5. оплата внешних сервисов может быть завышена или абсолютно отсутствовать. Этот критерий весьма важен при выборе между самописным и внешним сервисом.
1.3.6. привязка к внутреннему учёту обращений уже существует в некоторых утилитах. Как пример, между Slack и Jira имеется экспорт, либо можно дописать на Python.
1.4. интернет-канал телефонных сетей весьма важен для современных пользователей.
1.4.1. с дубляжем на сайте сети канал расширяет восможности продукта, связывая интерфейс ПО с возможностью быстрого общения.
1.4.2. общие группы телефонных сетей аналогичны закрытым группам соц.сетей по многим параметрам.
1.4.3. индивидуальные звонки являются наилучшими каналами для передачи конфиденциальных данных.
1.4.4. видео-звонок расширяет возможность общения, но не приемлем для продуктов, установленных на том же самом устройстве, если не поддерживает расшаривание экрана.
1.4.5. учёт обращений требует дополнительных сервисов, которых пока нет на рынке.
1.5. голосовой звонок чаще выбирают пользователи-экстраверты. У сотрудника ТП, кроме экспертизы технической, должны быть на высоте навыки общения, знания иностранных языков, готовность к сменной и круглосуточной работе.
1.5.1. авто-набор телефонного номера имеется почти во всех интернет-браузерах, но вполне возможен и будет полезен в десктопных интерфейсах (About окно, главное меню) или хелпах.
1.5.2. многоканальный сервис позволяет иметь множество пользователей, но требует не только технической возможности, но и достаточного числа сотрудников.
1.5.3. запись разговоров важна как для обработки обращения, так и для последующего учёта.
1.5.4. учёт звонков требует дополнительных сервисов, которых пока мало на рынке.
1.6. прикрепления к сообщению при баге ПО очень нужны программистам и ТП для актуализации, вполне помогут бизнес-аналитикам составлять прогнозы на востребованность будущих новшеств. Самописные утилиты для отправки сообщений в ТП должны автоматически формировать полный комплект.
1.6.1. скриншот считают первоочередным источником для конкретизации источника проблемы.
1.6.2. логи бывают разные - от открытия приложения до бага, от запуска ОС до добавления в список задач текущего ПО, автоматически собираемые системой или специально формируемые продуктом. Их важность велика не только для исправления бага, но может содержать полезную информацию для бизнес-анализа. Критичным моментом стоит считать соблюдение законов о конфиденциальности данных.
1.6.3. макрос шагов, видео с экрана весьма удобные вещи, но случается, что утилиты для передачи сообщений в ТП ограничивают типы вложений по объёму или неопознанному содержимому.
1.6.4. настройки ПО, ОС, РС (железо) иногда помогают выяснить причины бага, весьма полезны своим набором данных для анализов и прогнозов бизнеса. Особое внимание стоит уделять конфиденциальности и прозрачности.
1.7. письменно на бумажном носителе обратиться в ТП могут те, кому нужны неоспоримые артефакты в юридическом смысле.
1.8. личное обращение без средств связи чаще используют юзеры ближнего круга (альфа- и бета-тестеры, владелец продукта, и т.д.)
1.9. авто-сообщение при баге считаю наиболее удобным способом передачи данных в ТП.
1.9.1. нотификация и подтверждение отправления должно происходить только с согласия пользователя ПО. Также хорошей практикой считаю уведомление отправителя о получении его сообщения службой ТП.
1.9.2. редактирование текста сообщения в ТП - весьма полезно, если у юзера есть возможность более подробно описать предшествующие багу шаги.
1.9.3. контроль, редактирование прикреплений обязательны для спокойствия пользователя, поскольку конфиденциальные данные могут быть зашифрованы так, что нарушат закон о невмешательстве в персональные действия.
1.9.4. отложенная отправка сообщеня бывает удобна в случае временного отсутствия связи с ТП.
1.9.5. дубляж на e-mail отправителя или сохранение отправленного контента весьма важно для учёта на стороне пользователя. Это поможет ему не спамить ваш отдел ТП повторными однообразными багами.
2. Обновление ПО вторая обязанность ТП. За качество (вовремя, требуемая версия за оговоренную плату) поставки новых версий ПО ответственны сотрудники ТП.
2.1. самостоятельно обновить ПО юзеру должно быть позволительно при любом раскладе работы ТП.
2.1.1. контроль оплаты является важным моментом бизнеса, аналогичен присказке "вечером деньги, утром стулья". Сам юзер в момент приобретения обновдения должен видеть прозрачно процесс движения денежных средств и объём поставки.
2.1.2. версионность вверх и вниз должна не только контролироваться инсталлятором, но и поддерживаться деинсталлятором.
2.1.3. совместимость ПО и ОС, версий ПО и плагинов должна быть собрана тестировщиками и разработчиками в процессе исследования ПО, а итоги этих анализов должны информировать пользователя в открытых источниках (ReadMe, Release Notes, ...).
2.1.4. инсталляция и настройка должны являться прозрачными процессами, чтобы юзер сам мог контролировать версионность и совместимость.
2.1.5. получение апдейта (нашёл-скачал, линк в спам-письме) необходимо максимально упрощать, чтобы избегать проблемы несовместимости системы и ПО, своевременно подстёгивать пользователя к приобретению новых версий.
2.1.6. апдейт из первых рук или от посредника может сильно разниться, поэтому владелец продукта обязан контролировать дилеров не только в плане получения прибыли, но и вовремя актуализировать версии.
2.2. автоматически получать и запускать апдейт - это наилучший способ удовлетворять клиентов.
2.2.1. период для сканирования обновлений должен быть напрямую связан с длиной спринта группы разработки. В качестве отрицательного примера могу процитировать маркетолога ConquestSS, который рекомендует юзерам сканировать наличие апдейтов ежедневно, тогда как версии ПО выпускаются весьма нерегулярно (раз в квартал или три года).
2.2.2. видимый/скрытый режимы проверки и установки должны выбираться и переключаться для продуктов, умеющих работать в непрерывном режиме. Но лучшей практикой считаю вариант скрытого поиска обновления и запуск инсталлятора только после юзерского одобрения.
3. Обучение пользователей, внедрение, бета-тестирование некоторые считают прерогативой отдела аналитиков, но на мой взгляд отдел ТП для того и формируется, чтобы пользователи работали в продукте так, как это запрограммировано разработчиками.
3.1. вебинары, лекции, курсы можно проводить и удалённо, и на стороне пользователя. Конференции и семинары на нейтральной стороне весьма способствуют привлечению новых юзеров. Сотрудник ТП является лучшим презентатором ПО, потому что знает внутренности продукта, легко догадывается о требованиях пользователя, обладает высоким уровнем навыков общения.
3.2. встроенный в ПО хелп (текст, картинки, видео) является нейтральным способом передачи знаний от разработчиков пользователям. Содержимое этих документов формируется на понятном юзеру языке, не спамится рекламой. Не даром повсеместно она вызывается по первой горячей клавише и зовётся "помощью".
3.3. обучающий режим ПО весьма полезен тем, кто ленится читать инструкцию пользователя.
4. Оплата сервисов - дело двустороннее. Производитель ПО может единожды вложиться в сторонние сервисы, но при этом со своих пользователей взымать плату за предоставление ТП.
4.1. бесплатный/триальный период обычно предоставляется в рекламных целях. Соглашусь с ТП, что он должен быть минимальным, поскольку это прямое недополучение ими платы за оказываемые услуги.
4.2. периодичный сервис (годовая оплата All-included) можно назвать "окладным" способом оплаты работы ТП. За предоплаченный период у юзера может и не случиться проблем, разработчики не опубликуют новую версию, но пользователь уже отдал деньги за "будущие" услуги.
4.3. по критериям (общение бесплатно, апдейт за деньги) сервис можно назвать "сдельным", то есть ТП получает свою долю за конкретно предоставленные услуги.
4.4. внешний сервис оплаты или встроенный "кошелёк" выбирает владелец продукта для сокрытия или прозрачности денежных потоков, проверенные сервисы для сохранности операций. ТП может подсказывать маркетологам направления развития, контролируя объёмы общения с пользователем.

Огромная просьба к тем, чья экспертиза в ТП больше моей, дополните или исправьте вышеописанный набор знаний.

ТО о SD 5.1.1.239

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

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

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

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

Publishing cheat-sheet

Эта статья будет полезна тем, у кого разрабатывается десктопный продукт, распространяемый через инет-магазин.
Компания Conquest Software Solutions вышла на рынок с одним десктопным продуктом в 2002 году, с 2005 года стала продавать его через свой сайт, а с 2007 расширяла линейку продуктов. На сегодняшний день это 4 (SD, CS, CDB, FADEX) платных продукта, 1 (DV) бесплатный вспомогательный и 2 веб-продукта (site, WDV). Публикация некоторых из них всегда связана с дочерними, но в основном шаги к успешной публикации одинаковы. Несколько вариантов установки и обновления продукта упрощают работу конечному пользователю, но в теже несколько раз усложняют уровни проверок при публикации. Если в день получения бага от юзера тестировщик - это его адвокат, то в день выпуска QA становится на тёмную сторону и готов быть не только судьёй, но и прокурором для всех юзеро-хотелок.
До тех пор, пока публикацией заведовали только единственный тестировщик и единственный веб-разработчик, процесс протекал без сбоев. Но случалось так, что у кого-то был отпуск, а выложить билд надо было срочно. Тогда процесс не соблюдался в точности, потому что план действий лежал только в голове тестировщика, а веб-программист нажимал кнопки по его запросу. В итоге, конечный пользователь испытал проблемы со скачкой.
Шеф однажды спросил у меня, почему когда я выкладываю билды, то юзер никогда не жалуется. Мой ответ был прост: действия отработаны до автоматизма, и в день билда на листочке с Release Notes публикуемого продукта все пройденные этапы из моей головы перекочевывали на визуальный элемент. К сожалению, хоть и некоторые шаги были одинаковы для продуктов или типов (официальный, бета, специальный) билдов, но автоматизировать процесс даже частично было не на чем (фин.директор жадничал на тулзы, а бесплатных для самописных Delphi-элементов не было и нет). Тогда шеф решил частично помочь. Поскольку BTS у нас была самописная, то в Oracle базе он добавил таблицы, столбцы и триггеры на них, то есть автоматически формируемый список шагов для публикации.

Шаги делились на период ДО закрытия сайта для заливки и ПОСЛЕ операционные. Один триггер срабатывал для таблицы билдов и версий в момент добавления планируемого выпуска: в таблицу чек-листа добавлялся стандартный набор записей с указанием порядка действий для публикации определённой версии. В день публикации выпускающие тестировщик и программист проставляли дату-время каждой записи. Это значительно уменьшило количество проблем "заместителям публикаторов". А когда весь список очищался (таблица велась в "SD/Built-In VCS/SmartDataset" и активно использовались встроенные утилиты редактирования и фильтрации), то срабатывал следующий триггер, отправлявший e-mail нотификации руководству и иным заинтересованным лицам об успешном окончании работ с подробной инфой о выпущенном билде. 
На момент создания первого чек-листа выпуска он состоял из десятка пунктов, в основном касающихся сайта. Но со временем этот список стал пополняться и детализироваться проверками инсталлятора, апдейтера, лицензионных артефактов. Необходимость в расширении списка диктовалась процессом разработки, который касался различных сторон продуктов и сайта. Несколько систем апдейта (с сайта, из файловой системы, через инсталлятор или OSD Updater), заказанные пользователями, частая смена лицензирования, улучшения в системных требованиях увеличивали и количество пунктов чек-листа. Большей частью пункты дробились и конкретизировались.
С расширением штата и переходом на Jira+Confluence ведение чек-листа обзавелось документацией.

К сожалению, в Jira 2014 года не существовало аналога нашим чек-листам. Поэтому решено было оформлять задачи типа TASK (Feature, Improvement, Bug не очень подходили по стилистике, к тому же фича чек-боксов Jira Plug-in TODO была возможна только для одного типа задач) в каждом из выпускаемых продуктов.

Для удобства работы были одобрены следующие мои предложения по оформлению задачи:
- Product = [ProductName]. Для каждого продукта создавались свои задачи, в префиксе которых значились буквы короткого имени продукта, но они же дублировались и в Summary для упрощения фильтрации;
- Summary оформляется по формату "Publish [ShortProductName] [Major].[Minor].[Release]  [major|minor|release|spec-build|fix-build] [official|beta]". По короткому имени задачи было ясно, что конкретно будет публиковаться - бета или спец.билд, новая версия или текущие исправления. Например, "Publishing SD 4.7.2 release official" - публикация всем второго релиза платной версии 4.7 продукта SQLDetective, "Publishing SD 5.0.1b spec-build" - выкладывание специального билда бета-версии 5.0 продукта SQLDetective;
- Type = "TASK". К сожалению, только для одного типа задач админ Jira смог прикрутить поле TODO;
- Priority = "Major". Важность задачи велика, но не критична и не блокирует иную работу. К тому же есть дополнительное поле Business Value с самым высоким значением;
- Affected Versions = [LastPublishedBuild]. Последний опубликованный билд давал информацию всем заинтересованным сторонам: скрам-мастер подбирал задачи для бэклога и отчитывался перед вышестоящими, исходя из дат билдов опубликованного ранее и текущей; тех.писатель собирал выполненные задачи для Release Notes, отсекая временные; выпускающий тестировщик ориентировался с билдами и версиями для проверок апдейтера;
- Labels = "internal". Задача не должна входить ни в какие RN и для этого фильтруется лейблой;
- Status меняется по стандартному workflow: создаётся со значением Open; когда становится известна дата публикации, то меняется на Planned и заполняется поле Due Date (эти же данные используются для пина в Slack); процесс публикации сопровождается статусами In Progress + Testing; и финализируется Done|Close;
- Component = "Core". У каждого продукта обязательно существует модуль Core;
- Description = Summary + некоторые детали или примечания об особенностях публикации (кому спец.билд);
- Assignee = выпускающий тестировщик. Хоть в выпуске и участвует несколько членов команды, но большинство шагов исполняет именно тестировщик. На него же и запишется всё время работы - чаще это один рабочий день, если не случалось откатов билда и завершения работ в иной день;
- TODO = чек-лист шагов публикации, выстроенные в порядке исполнения и с префиксами для задействованных членов команды: PT=ProductTester, WT=WebTester, PD=ProductDeveloper, WD=WebDeveloper, TW=TechWriter, DO=DevOps, PM= ProductManager. Пример и подробности будут чуть ниже, а пока немного примечаний. В Confluence поначалу была оформлена таблица с полным списком, их пояснениями и отметками для типов публикаций (официальная, бета, спец.билд), а позже для ускорения работы были созданы конкретные списки по продуктам. Но в них отпала необходимость, когда была освоена фича Jira по клонированию задач. Сразу после окончания публикации (потом и в сам список этот шаг был записан) уже закрытую задачу клонировали и редактировали следующие поля: Affected Versions = только что опубликованный билд; обнулялись чекеры TODO и поля Issue Links, Fixed Versions, Due Date; в Summary и Description увеличивался номер версии. Время от времени список актуализировался, поскольку некоторые процессы удавалось нивелировать (форматирование текстов RNs, LicAgreement, ReadMe в разных форматах - txt, rtf, doc) или автоматизировать (генерация SampleDocu, очистка компа, проверка подписи файлов), или убедить РМ в избыточности и отказаться от объёмных проверок (нагрузочные тесты очень долго были в первых шагах), заменив на более нужные (результаты проверки сайта фиксировались прикреплением скриншотов) или новые (техпрогресс расширял области применимости продуктов, а значит и увеличивал количество багов). Необходимость детализации и разбиения на мелкие шажки усугублялась после очередных "пинков" следующему публикатору, которому приходилось ещё и ещё раз пояснять смысл и назначение чека. А точный порядок шагов сократил сообщения в чате, где передавалась очерёдность, с трёхстрочных до одной фразы "твой ход". А он уже открывал задачу с чек-листом и видел не проставленные чеки, точно зная, что от него ждут. Единственная проблема - после проставления каждого чека необходимо было выполнять сохранение в базу Jira, а иначе очерёдник либо не увидит ваших чекеров, либо ставя свои затрёт ваши;
- Issue Links = список задач, прилинкованных по типу "blocks the TASK", без закрытия которых нельзя начинать публикацию. В простонародье эта часть звалась "КакогоБагаБилд". Поскольку РМ в Jira Structure планировал и отслеживал только Features+Improvements, то включаемые в билд баги решено было мной линковать к этой задаче. И поскольку возможности Jira ограничивались показом только первых пяти прилинкованных, то во время работы (за несколько дней до публикации тестировались именно эти блокеры чек-листа публикации) неудобство просмотра объёма незавершённых работ исправлялось обычной отлинковкой. Принцип сокращения списка был взят мной из самописной BTS, где у меня была отфильтрована база по запланированным на тестирование задачам и без даты окончания теста. Привычка - вторая натура, поэтому и блокеры выкидывались за ненадобностью. Но со временем команда стала извлекать из такой линковки свою выгоду: РМ стал отчитываться руководству по списку блокеров, техписатель фильтровала исправленные баги для написания RNs, программисты опирались на список блокеров только для оправдания занятости хот-багами вместо текущих разработок, группа веба опиралась только на этот список из-за невозможности включить их задачи в автобилдер. Единственная задача, которую никогда не выкидывали из списка блокеров, была с полным отредактированным текстом RNs, поскольку именно их впиливали в билд в последнюю очередь и пересобирали продукт. Видели бы вы глаза представительницы Atlassian на конференции SQADays-21, когда ей были описаны эти "танцы с бубнами" вместо полноценного использования Jira Structure. Но РМ ни за какие коврижки не соглашался вести бэклоги фикс-билдов с одними только багами в "его" Jira Structure, даже после моего рассказа о том, что бэклоги можно делать составными и отчитываться более точно руководству о затраченных усилиях. Из-за его упрямства команда только ещё больше отстраняла тестировщиков от программистов: спрос за импрувы (велись в Jira Structure) был с программистов, спрос за баги (велись блокерами чек-листа) был с тестировщиков. То есть в команде всегда было два разных бэклога, а не единый. Единственным аргументом было то, что баги никогда не проходили стадии эстимации, поскольку проггеры о багах отзывались: "Баг от импрува отличается тем, что его быстрее исправить, чем понять по тексту сколько это займёт времени", и никогда не планировали их или декомпозировали;
- Fixed Versions = публикуемый билд (четырёхзначная версия) выбирается во время закрывания задачи, а на момент оформления ставилась трёхзначная версия без указания билда. Она использовалась для планирования и иной фильтрации.

Примерный список чекеров (поле TODO)	Пояснения (статья в Confluence)
PT_All planned bugs fixed?	Проверить список багов - блокеров публикации, запланированных на фиксирование, и разработок из Structure
PT_Smoke tested?	После инсталляции проверить основной функционал на триальном и лицензионном ключе.
PT_Internal files in the setup program are correct and they are enough for first start or update, upgrade?	Проверить корректность и достаточность служебных файлов для инсталляции и апдейта
PT_The setup program tested against all supporting OS?	Проверить инсталляцию и открытие приложения на всех ОС из списка System Requirements
PT_Stress test passed?	Шеф не различал нагрузочные и стресс-тесты, а также слышать не хотел, что для тестирования больших данных нужно много времени. На выпуск давался только один день, и он наивно полагал, что мы проверяли обработку монстров на выпускаемом билде. Очевидно, что подобному пункту не место в чеклисте. Но если у вас есть автоматизтрованные регресс-тесты, которые выполняются за минимальное время, то слово stress меняйте на regress и смело оставляйте.
PT_DemoProject or SampleDocus included into installer and updater?	Примеры использования продукта включены в инсталятор, апдейтер. Версия примеров актуальная. Проверку этого пункта вполне можно совместить с иными (smoke, инсталлятор с ключом, апдейтер и апгрейд)
PT_Copyright date correct in the program, readme file?	Имя компании и год лицензирования проверить в файлах и интерфейсе продукта (About, Welcome Window, Preferences, ReadMe, …)
PT_The setup program correctly shows the program name, default installation path, etc.? The setup program shows "beta" in the program name and installs to the beta folder?	Проверить инсталлятор на корректность имени проги, установочного каталога, иконок., префиксы beta и др. Проверить инсталляцию на чистую машину(предварительно почистить реестр и папки ОС), на имеющуюся старую версию.
PT_License agreement file in the setup program is for an official/beta version? It's the latest version.	Проверить текст лицензионного соглашения на отсутствие/наличие Beta примечаний
PT_Release notes shown in the application on first start up?	"What’s New?" показывается при первом запуске нового приложения
PT_Readme file in the setup is for an official/beta version?	Проверить файл ReadMe на отсутствие/наличие Beta примечаний
PT_The trial key file in the setup program is for an official/beta version?	Проверить наличие и длительность триального ключа в файле инсталлятора и апдейтах
PT_Check license limits: trial, after trial, lic numbers.	Проверить триальный ключ на ограничения в период действия и вне его пределов, лицензионный ключ на количество юзеров при совместной работе.
PT_All executible files, including updater and installer e-signed?	Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении имеют электронную подпись
PT_All files checked by several antiviruses?	Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении не имеют препятствий антивирусами
WD_Close site. Make back-up.	Закрыть сайт для доступа обычным юзерам и сохранить копии заливаемых страниц и прочих файлов. Начало заливки считалось по американскому времени (для Москвы это 16-00). Все предыдущие пункты выполнялись с 10-00 утра (автосборка утреннего билда) до 15-00 или 16-00 часов дня, при сбоях билд пересобирался или сообщалось шефу о стоп-билде.
WD_All pages and child sites are updated? The product teaser on the website shows correct product version?	Каждый продукт имеет свою первоначальную страницу и коротко-названные сайты, которые надо обновлять самостоятельно. Некоторые продуктовые рекламные заставки могут размещаться на общих сайтовых страницах, но должны быть актуальны
WD_The setup file uploaded to the website?	Инсталлятор залит на сайт. Проверить скачивание через страницы Free Download, Upgrade/Update или Buy Online. Веб-разработчик обычно единым шагом заливал инсталляторы и апдейтеры во все места, менял номер версии и оформлял RNs. Так что разбивка сайтовских пунктов больше касалась веб-тестировщика.
WD_The OSD updates uploaded to the website? The OSD updates uploaded to the website to both folders (non-beta and beta if it's official publishing)?	Апдейты загружены на сайт. Проверить OSD Updater на скачивание Core и Kits, апдейт с беты на официальную
WT_Website pages and news ready? All modified webpages copied from the test website to the live website?	Веб-разработчик заливает обновления страниц сайта, а веб-тестировщик проверяет готовность сайта
WT_Copyright date correct in website?	Имя компании и год лицензирования проверить на сайте, прикрепить скриншоты
WT_Release notes availabe on the website?	Зайти на сайт и найти соответствующие выпускаемому билду Release Notes, сделать скриншот и прикрепить его к таске публикации.
WT_License is the same in website (updater from site) and application (installer, updater from file system, About).	Тексты лицензионного соглашения идентичны на сайте, в инсталляторе, апдейтере, продукте.
WT_The setup program available to download, correct and can be installed? Renaming folders enabled?	Скачать с сайта инсталляционный файл и установить на чистую машину, на старую версию в триале и лицензионно, проверить смену имён папок
WT_KeyGen works for current version? New key delivired? KeyDeliveryProcs includes data from the previous version?	Генератор ключа на сайте формирует файл для текущей версии и отправляет линки или сам файл всеми задуманными способами, смена версии продукта или генератора ключа не препятствует процессу обновления
PT_Release notes availabe in OSD Updater?	Запустить OSD Updater и проверить наличие Release Notes текущей и промежуточных версий.
PT_BETA release notes not visible in OSD Updater?	OSD Updater не должен показывать Release Notes для Beta версии, если выпуск официальной. В бета-версии должны быть видны RNs официальной и беты.
PT_OSD Updater updates the previous official/beta version to the new version? The product version on the website displayed correctly?	Проверить возможность апгрейда со старой версии триально и лицензионно, из файловой системы и с сайта. В личном кабинете юзера на сайте и в общедоступных местах скачивания актуализирована версия продукта
WD_Open site.	Обычно заливка и проверка обновлений через сайт занимала около часа времени, поэтому в 17-00 (окончание рабочего дня в Москве и 9 утра в Америке) можно было открывать сайт и рапортовать руководству об успешной публикации
DO_VCS branched, Slack pins updated, Jira builds updated, Installers renamed?	По окончании работы с опубликованным билдом начинается работа со следующим: разветвляется СКВ кода, в чате и на доске версий БТС убираются выполненные задачи и оформляются новые, в файловой системе перименовываются инсталляторы (добавляется постфикс "_р" - public)
TW_Wiki topics updated?	Одно время тех.писатель вела топики в Wiki и актуализировала инфу о доступных версиях, фичах. Но редакторы Wiki запретили эти статьи, т.к. они стали более рекламными, нежели информационными.

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

Пока RNs собирались вручную и хелп-примеры готовил первый член команды, публикация была неожиданностью для всех:

или

Приучив всех выпускающих к строгому порядку чек-листа процесс публикации стал проходить незаметно для всей команды, и в чате среди прочей болтовни можно было заметить:

или

Со временем шефу скучно стало ждать выпуска и моё предложение использовать канал билдов для связи в день публикации было поддержано:

И процесс потёк, как по маслу:

Новичков вливали постепенно:

или

Позже шеф просто умилялся:

Бывало, конечно, что новички, стесняясь общего канала, молча проставляли чеки. Тогда РМ дёргал весь отдел качества фразой: "Что там с выпуском? Почему тишина?" и приходилось его "посылать" в Jira, дабы не отвлекать народ от важных дел.
Но в целом польза от ведения публикации через чек-лист велика. Благодаря наличию чек-листов выпуска для каждого продукта, трёх физических машин и двух виртуальных мне удавалось делать перепубликации четырёх продуктов в один день!

И укладывались в ровно отведённый час. Перевыпуски, конечно, случались, но никак не по причине пропуска какого-то пункта публикации.