Гипотезы

Прошедшая неделя заставила меня искать причины багов на порталах для ведения блогов.
Началось с того, что Blogger.COM перестал отображать некоторые картинки. Пройдясь по советам для решения аналогичных проблем, мне не помогло следующее:
- проверка на использование последней версии браузера;
- очистка памяти;
- кроссбраузерные тесты.
Эти все стандартные советы от техподдержки портала блоггеров были испробованы, о чём и было упомянуто в моей первой жалобе. Но золотые и платиновые советчики всё равно мурыжили меня первые дни всё теми же советами.
В первом же моём отчёте о проблеме был описан кейс со скриншотом, где конкретно описывалось место нестыковки back-end-а с front-end-ом. Но моя гипотеза о несоответствии лимитов на стороне пользователя и серверов была проигнорирована. Почему? Это прояснилось позже, когда техподдержка призналась в полном непонимании причин проблемы.
Суть проблемы в том, что картинки блоггер загружает через один интерфейс, который изначально благополучно фиксирует и отражает залитый на портал image, но в режиме просмотра картинка становится недоступной для некоторых пользователей и читателей блога. Из одного из разбирательств, а также проанализировав свои статьи с прикреплениями, выяснилось, что только с  1.bp.blogger.com  и  2.bp.blogger.com  доменов картинки не отображаются, а с  3.bp.blogger.com  и  4.bp.blogger.com  просмотр работает полноценно и в сжатом, и в галерейном режимах.
Поскольку мне известны принципы работы с partition, storage, rac, tns в Oracle DB, то одной из моих гипотез было то, что данные портал хранит разделяя на несколько серверов. И естесственным был вопрос к техподдержке для выяснения несоответствий лимитов при добавлении данных и при их считывании. По моей догадке владелец блога загружал картинки по одним условиям, не имея возможности выбрать сервер, а читатели блога получают данные только из лимитированных доменов. Поэтому мне, как пользователю, нужна настройка выбора места хранения images на момент их загрузки на портал. Но эта заявка, как и гипотеза, оказались излишними после того, как техподдержка разъяснила, что Blogger как бы хранит каждый мой аттач в четырёх экземплярах!
Такая структура данных мне очень импонирует, но всё же, как могло произойти такое, что в один (не-)прекрасный день часть картинок стала недоступна? Заливка всё также осталась автоматической с точки распределения доменов, но некоторым читателям после неизвестного апдейта портала был перекрыт доступ к  1.bp.blogger.com  и  2.bp.blogger.com  доменам. То есть мне, как владельцу блога, пришлось вручную в каждой статье для каждой картинки менять номера хранилищ с 1 и 2 на 3 или 4.
Здесь родилась вторая гипотеза о причине проблемы. Не могу похвастаться своими глубокими знаниями в серверных технологиях, но вполне понимаю, что ограничения на домен могут быть выставлены на обоих концах: как у моего провайдера, так и на исходном сервере. Далее мои рассуждения сводились только к стороне поставщика портала, потому что провайдер интернета обычно перекрывает домен верхнего уровня, а не третьего-четвёртого. К тому же сообщение в браузере о недоступности какого-то IP адреса по причине его внесения в чёрный список значительно отличается от предупреждения об отсутствии адреса.

Так сообщается о сайте из чёрного списка

Edge предлагает несколько workaround

А вы дописываете в описании бага свои гипотезы о причинах проблемы? Конечно, программисты сильно обижаются, когда их как котят тыкают в место причины, но ведь это значительно сокращает время исправления.

К сожалению, мои гипотезы пока не подтвердились и не отверглись, поскольку техподдержка портала Blogger ещё не выяснила конкретные причины ограничения на просмотр картинок с   1.bp.blogger.com  и  2.bp.blogger.com  доменов.
А одним из моих обходных шагов было создание блога-спутника. На выбор альтернативного портала блоггеров ушёл день. В инете много советов по подбору места хранилища ваших мыслей:
12 лучших бесплатных блог-платформ
Какую платформу для блога выбрать
С чего начинается блог: 10 лучших бесплатных платформ
Выбираем платформу для ведения блога

Попытки создать новое пространство для моих записей с полноценным отображением картинок ни единожды заставило меня чертыхаться. Например, LiveJournal был отвергнут из-за малого пространства для прикреплений (до 500МБ), а Яндекс.Дзен и Инстаграм-подобные - из-за размера сообщений (для моих достоевско-толстовских широт никак не хватит нескольких строк). К сожалению, WordPress не оказался таким же простым и удобным, как Blogger.COM:
* наполнение контента страницы очень быстро начинает тормозить, то есть у портала есть серьёзные проблемы при обмене данными во время активности черновика, буквально после вставки 4-5 блоков. Blogger тормозить на черновике начинает намного позже, при объёме раз в 5-10 большем;
* нет возможности быстрого перехода от режима html-редактора к пред-просмотру, как это работает в Blogger. Точнее сказать, мне совсем не удалось найти в WordPress какой-то редактор текста html, чтоб не таскать "недвижимые" блоки и не удалять наугад пустые. Да, в Blogger в режиме просмотра тоже не видны границы пустых блоков и нет построителя таблиц, но их быстро можно переделать в html-режиме;
* те типы блоков, которые предлагаются для автоматической вставки, не могут удовлетворить все мои запросы: раскрасить часть текста, задать фонт отдельному слову и другие мелочи, либо интерфейс WordPress не столь интуитивен;
* дизайнерские штучки оказались совсем не юзабельными, поскольку обучающий режим не очищает за собой интерфейс и последняя плашка не пропадает даже после перезагрузки браузера;
* с большим трудом удалось вставить некоторые плагины для фильтрации, поиска и статистики;
* в WordPress при ведении блога обязательно наличие двух страниц (Home, Blog Feed), а в Blogger страницы можно вообще не показывать;
* Blogger нигде не ограничивает по объёму при бесплатности услуги, а WordPress даёт максимальное пространство (до 1ГБ) без оплаты среди альтернативных "дневников";
* из положительного: в WordPress есть структурированные рубрики и дополнительно метки, а в Blogger только метки.

На моё счастье техподдержка Blogger разродилась подсказкой для временного обхода проблемы (вручную поменять 1 и 2 на 3 или 4 в ссылках на картинки), поэтому дальнейшее сравнение функционала откладываю до следующей критичной проблемы на Blogger.COM.

Докладное добро

17 сентября 2019г. семейство московских тестировщиков под пиццу и напитки от ФИНАМ согрелось в подвале учебного центра вместо крыши идеями от Алексея Петрова и Андрея Мясникова.
Алексей проделал масштабную аналитическую работу, собрав в своей выкладке факты вертикальных и горизонтальных срезов за 10-15 лет. Подробно рассказал на собственных примерах как было и как стало в IT области. С большинством случаев слушатели активно соглашались, поскольку многих аналогичные пути привели к сегодняшним реалиям. Но, поскольку Алексей не мечтатель, то о подробном будущем пришлось угадывать самостоятельно. Лично меня посетила мысль, что профессия тестировщика уже не перспективна для желающих войти в IT. Об этом он упоминал ещё на SQADays-25 в докладе "Мексиканские страсти по мидлу": набор навыков и знаний требуется сейчас более высокий даже к юниору. Куда же стоит уже сейчас направить своё развитие? Полагаю, что учебным заведениям пора обзаводится курсом МОИР-ов (мастер обучения искусственного разума). И эту идею усилили прослушанные доклады с SQADays-25 "Когда научная фантастика становится реальностью тестировщика", "Расширяем идею статического анализа от проверки кода до других процессов разработки" и многие другие.
Согласно правилам развития, спираль неизбежна. Техники и инструменты тестирования развиваются также быстро, как и проверяемые продукты, технологии. Автоматическое code-review не только подсказывает, как правильно писать код, но и уже исправляет некоторые проблемы, например, фича Autofixes в ClearSQL. Искусственный интеллект явно в скором времени заменит тестировщиков. Если ещё недавно достаточно было иметь навык тест-чекера для начала, то через 5-10 лет "мартышками", по-моему, будут звать МОИР-ов.
В прошлых пятилетках следовали все waterfall-у, а сегодня поголовный agile. Завтра, думаю, наступит эпоха lean или "бирюзовых организаций". Ха, лозунг "Вперёд, к коммунизму!" весьма пророческий был и опять проявляется.
Алексей напомнил о зоопарке BTS, а мне припомнилось разнообразие и самописные комплексы по автоматизации документооборота (Галактика, Axapta, OEBS). Сегодня и те и другие выбрали одного, постоянного производителя. Или взять транспорт в Москве: ещё недавно в глазах рябило от рекламы в переходах и на корпусе машин, а сегодня все перевозчики объединились и живут на свои "живые" деньги. Это ли не принцип стабильности и процветания? Пусть мало и дёшево, но регулярно. А некачаственные конкуренты, не соблюдающие правило ВВС (критерии качества - верно работает, вовремя поставлено, сумма затрат), сами отвалятся. Регулярность выработки позволяет увеличивать срок планирования. Вот уже и гос.бюджет с годового планирования вырос до 5-20 летнего.
Да, мне не хватило мечтаний от Алексея. Но не только для того, чтобы сравнить их с реальностью через десяток лет, а для подсказок производителям тех технологий, на которых нам жить в следующих пятилетках.
Два доклада Андрея Мясникова, заменившего приболевшего Антона Семенченко, не вызвали моментально вопросов, но заставили серьёзно задуматься. Вроде бы из каждого проблемного угла был указан светлый путь, но почему-то логическая нить опять возвращалась. Андрей советовал записывать все контакты, но тем не менее утверждал, что всё равно в итоге всё повесят на тебя и ты же останешься виновным во всех грехах. Зачем поддерживать регулярный контакт с ответственным из смежной компании, если с обратной стороны нет взаимности и долгосрочных планов? Если вы раскрепощённый человек, то любую проблему можете решить не через личные связи, а напрямую с руководством смежников. А вот отношение Андрея к любителям сверхурочной работы меня порядовало. Хотя возможно, что не все причины (нравится занятие, увлёкся и не заметил, гипертрофированное чувство долга, нежелание спешить домой) ему известны. Но в любом случае, Андрей молится на своих энтузиастов, в отличие от шефа ConquestSS, который выгонял из команды ответственных сотрудников. Никаких тебе "спасибо" или мясниковских молитв и оплат, потому что для вечного стартапера привычнее пинать молодых и ему неведом принцип ошибки выживших.

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, дабы не отвлекать народ от важных дел.
Но в целом польза от ведения публикации через чек-лист велика. Благодаря наличию чек-листов выпуска для каждого продукта, трёх физических машин и двух виртуальных мне удавалось делать перепубликации четырёх продуктов в один день!

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

Размышлизмы

Многие великие писатели приходят к одной мысли: "Живи так, как хочется тебе здесь и сейчас, а не по велению других. Только тогда почувствуешь счастье. А иначе, будешь лишь существовать." (читай "Чёрный монах" А.П. Чехова, "На дне" М. Горького).
Другие же сами хотят себе счастья, потому и требуют от тебя своего желаемого.
Вот взять, например, советчика. Кого вы себе предпочтёте: старшего брата (СБ), младшую сестру (МС) или собственный ум (СУ)?
СБ
Если у вас возник сложный жизненный вопрос, и вы обращаетесь к старшему брату с просьбой его разрешить, то СБ, обладающий большими жизненными знаниями и опытом станет предлагать вам такие решения, которые потребуют значительных разъяснений. В этом случае вы будете лишь слушателем, учеником, вынужденным принимать чужую точку зрения. А поскольку СБ придётся много аргументировать, то вы заметите своё низкое положение молчаливого незнайки. Говорить будет в основном СБ, а значит ваша потребность в представлении себя миру будет отвергаться. Тем самым ваша самооценка будет снижаться. Если же в конце концов дело разрешиться благополучно, то ваше самомнение повысится только в вашем собственном мирке, хоть и будут в голове бродить мысли: "Правильную идею подсказал СБ. Я - молодец, что её осуществил(а).". Но если ситуация усугубилась от советов СБ, то вам легко и просто скинуть вину  на СБ. Только тогда ваши отношения с СБ вряд ли станут ещё теплее и доверчивее. Обелив себя, потеряете наставника, который может быть в другой раз окажется более прав.
МС
Когда же в качестве свободных ушей вы используете МС, то однозначно ваше самомнение зашкаливает. Вы обеспечите себе  один из пунктов счастья - рассказ о себе любимом кому-то. Да, МС будет внимать все ваши сказки с открытым ртом. Но вот совет от неё вы врядли получите толковый. Может она и выберет что-то, но наугад, без толковых аргументов. И опять в результате негативного исхода дела вы сможете обвинить МС, а не себя. А за положительное разрешение жизненной ситуации будете гордиться лишь собой. Ведь оба варианта были предложены самостоятельно, а МС послужила по-сути лишь жребием. Укрепит ли такой случай семейные узы? Сомневаюсь. Ваше мнение о себе любимом останется при вас и даже может возрастёт, а любовь к ближним врядли увеличится.
СУ
Частично в обоих вариантах уже была затронута золотая середина - разбирать условия и искать выход, опираясь лишь на собственные знания. Да, только в вашей одной голове умещается вся информация о ситуации, требующей решения. И только вы знаете, чего желаете от всего имеющегося положения дел. Рассматривая задачу сам на сам вы обязательно найдёте единственный верный путь, за который никого не будете винить. А значит ваше мнение об окружающих не ухудшится. О, да - самомнение зашкалит! Но разве не это и есть счастье осознания себя в мире? Только с собой вы можете быть откровенно честным и правдивым, ведь никто не узнает вашей тайны. А точное взвешивание положительного и отрицательного исходов дела, желаемого и ненавистного разрешений ситуации однозначно покажет вам узкие места, где приложив усилия вы развернёте ход в нужную вам сторону.

Эпитет "одиночество" присущ тем, кто живёт по первому или второму варианту. А те, кто опирается на третий вариант, не страдают от одиночества, поскольку всегда считают себя "самостоятельными".
Самостоятельные люди не страдают от одиночества.

День программиста

Большинство IT--шников считает своим профессиональным днём 13(12) сентября.
Первым представителем этой отрасли производства считается Ада Лавлейс - женщина.
На днях СМИ были обескуражены (ведущий федерального ТВ канала даже не сдержался в выражениях) новостью об отмене конференции IT--шников в Германии. По-моему, причина вполне очевидна, поскольку Европа толерантна и хорошо знает истоки.
А организаторы SQADays-26 незадолго до этих событий вынуждены были приглашать меня по телефону, не смотря на очень низкие отклики о предыдущем докладе.

Оценки слушавших в С-потоке.

Полагаю, оргкомитет SQADays быстро вынес урок из конфликта в Европе. Либо и у них наступил кризис - в дорогой Минск не захотели ехать большинство российских докладчиков или все выложились на юбилейной конференции и за полгода-лето ничего нового не выжали из своего опыта. Ещё один момент приходит на память. После столь неудачного моего выступления Рина Ужевко, будучи руководителем оргкомитета SQADays-22, весьма недальновидно отказала мне пообщаться с коллегами на тему "Девочку или Мальчика?". А ведь ещё два года назад можно было предупредить руководителей групп разработки о столь полезном привлечении работников, исходя из гендерных особенностей. Рина побоялась таких разговоров. А вот Андрей Бреслав на TechTrain-2019 поднял вопрос о женщинах-программистках. Актуальненько!

День красоты

9 сентября - Международный день красоты и тестировщика. Да, качество - это всегда красиво!

Улыбка придаёт обаяния, поэтому несколько зарисовок из нашей профессии.

Если тестишь долго-долго, то достигнешь дна тех.долга.

"Быстро поднятое не считается упавшим", - бормотал админ, запуская сервер.

Команда разработки не выдержала очередной кризис и вся отправилась на небеса.
Глядят, а там админы уже распоряжаются: проггеров - налево в ад, тестировщиков - направо в рай.
Подходит очередь РМ-а. Его спрашивают.
- Кем был в команде?
- Процессами и людьми управлял.
- А что полезного сотворил?
- Ничего не производил.
- Юзеров обманывал?
- Не знаю, я их не видел.
- Тогда возвращайся бестелесно и докажи, что ты был членом этой команды.
- А как это? И куда попаду после дел своих?
- Будешь лабать код, никому не нужный, - пойдёшь к проггерам в ад. Будешь правду выяснять и помогать пользователям - отвезём в рай, как тестировщиков.
Развернулся РМ и записался на курсы пользователей.

Было у Отца три сына: старший умный был детина, средний был и так и сяк, младший вовсе был дурак.
Кто стал аналитиком, кто - автоматизатором, а кто и скрам-мастером.
Только Мать отказалась рожать дочь со словами: "Вы её в тестировщицы определите, а мне жаль девочку. Вы ж на ней все пахать станете, и станет она некрасовской бабой.".