QA, QC или иначе

На примере отношений тестировщика с программистом хотелось бы уточнить разницу между должностями QA и QC. Соглашусь, что многие тестировщики в своих блогах касаются этой темы. Да и у меня уже была слабая попытка (читай - "Тестировщик или QA"). Ни в коей мере не хочу дублировать их или утверждать, что моё мнение по этому вопросу единственно верное и окончательное. Просто каждый из нас, тестировщиков, стремится разъяснить понятия и принципы работы ПО так, как это более доступно обеим сторонам производства ПО от точки проверки качества: вправо - программисту, влево - пользователю. Да, это профессиональная привычка - делать всё понятным и доступным. ;)
Капитан Врунгель, отправляясь в плавание, напевал: "Как вы лодку назовёте, так она и поплывёт.", а будущие специалисты, желающие внедриться в сферу информационных технологий, частенько встают в тупик при выборе вакансий. Какую должность искать? Что вбивать в строку поиска, кроме принадлежности к IT-сфере?
На мой взгляд войти в IT можно легко, если начинать с мелкого. Раньше, годах в 1980-90х, существовала специальность "оператор ПК", но когда компьютерной грамотностью овладело всё работоспособное население, то в этой должности отпала необходимость также, как и в машинистках. Нажимать на клавиши сегодня может любой, понимающий принцип хранения информации. А с приходом искусственного разума стало возможным преобразовывать звук в печатный текст, то есть даже по клавиатуре клацать уже не требуется. Этот факт, конечно, ускоряет процессы производства, но и лишает человека занятия мелкой моторикой, что в значительной мере напрямую влияет на мозговую деятельность, то есть замораживает мыслительные процессы через атрофирование нервных окончаний. Но, сегодня я не об этом.
Инженеры по тестированию программного обеспечения (должность в реестре России зарегистрирована с мая 2014 года), а в простонародье - тестировщики, бывают разные: ручники и автоматизаторы, безопасники и нагрузочники, исследователи и производственники, да ещё всякие разные. Поначалу, всех называли просто "тестировщиками", но не "тестерами", потому что второе имя означает прибор, например, - амперметр или индикаторная отвёртка, а не такое, более сложное существо, как - человек. Тестер-прибор показывает довольно быстро информацию о том, работает ли проверяемая конструкция правильно, то есть в ожидаемом режиме, к тому же в большинстве случаев даёт количественные показатели. Например, спиртометр указывает процент сахара и алкоголя в сусле при брожении будущих напитков, а вольтметр - наличие заряда в батарейке.
Исходя из истории возникновения профессии тестировщика (плата не отработала задумываемым образом из-за погибшего на ней мотылька) могу убедительно утверждать, что первейший принцип тестирования ПО - исследование причин, по которым ПО не работает ожидаемым путём. А это совершенно иное, нежели простое измерение величины или детекция наличия/отсутствия контакта, давления, электричества прибором, именуемым - тестер. Да, нашу работу тестировщиков постоянно хотят измерить количеством багов, затраченным временем или финансовыми сбережениями, но эти показатели совершенно иная сфера, нежели простые величины стрелок и шкал приборов-тестеров.
Ещё не так давно появилось разделение тестировщиков на QA и QC. Расшифруем, переведём и попытаемся найти меж ними отличия. Quality Assurance - обеспечение качества. Quality Check - проверка качества. Как видно из наименований, должности различны по своему предназначению. Тестировщики, только проверяющие качество (QC), наиболее схожи с сотрудниками отделов технического контроля (ОТК), которым на входе подают изделия и список требуемых соответствий определённому уровню качества. После того, как в ОТК заполнены чек-листы, проставлены в них положительные галочки, вычеркнуты отрицательные (негативные) несоответствия, заполнены параметры проверки (что проверялось, кто и когда проводил проверку, конкретизация продукта и вспомогательного оборудования), сотрудник ОТК передаёт такие ведомости в производство или сбыт для подтверждения качества, либо направляет претензии к поставщикам и промежуточным производителям в случае выявления несоответствий требуемому качеству. Если же тестировщик, кроме вышеперечисленного для QC (проверка по готовому чек-листу, подтверждение уровня качества, составление претензий о несоответствии уровню качества) сам определяет направления проверок, формулирует параметры качества, исследует весь цикл производства и внедряет дополнительные шаги, либо исключает лишние, для предотвращения проблем как в конечном продукте, так и в процессе производства, способствует внедрению наиболее совершенных практик для достижения качества продукта, то такого специалиста я со всей ответственностью могу назвать QA. Но вот уже чуть больше года в реестре вакансий мелькают такие названия, как DevOps и TestOps. Они расширяют полномочия QA до уровня всей команды разработки. Если путь от QC до QA считать вертикальным продвижением по карьерной лестнице, то от QA до TestOps (сокращение от "Testing + Operations", что в переводе - "тестирование + системное администрирование") - горизонтальным обогащением профессионализма на всех уровнях производства.

Наименования графикой

Визуально для меня QC представляется палочкой или латинской буквой "I". Её ассоциирую со словом "Inside", потому что QC зациклен лишь в тестировании, смотрит только в одном направлении. Он не точка, потому что в любом случае набирается и опытом, и знаниями. QA же специалист в моих глазах представляется буквой "T", где в вертикальной палочке накопились умения в области тестирования, а ответвления вправо и влево означают развитие в смежных областях: программирование, аналитика, внедрение ПО и поддержка юзера. Буквой "Т" начинается слово "Transform", то есть QA в состоянии менять себя и окружающие процессы. А TestOps видится мне буквой "E", с которой начинается слово "Extend". TestOps расширяет себя и всю группу разработки на всех ступенях, по краям и в центре, стремясь в одну сторону - к качеству.
Напомню, что такое "качество" с точки зрения пользователя, к которому в производственной цепочке ближе всех тестировщик. Понятие "Качество" определяется тремя составляющими: точность исполнения требуемого, получение желаемого в означенное время, денежные затраты. На все эти три направления и направлена работа тестировщика: зелёные чек-листы гарантируют полное соответствие требуемому, ускорение процессов разработки сокращают период от запроса юзера до поставки готового продукта, совершенствование процессов и пресекание проблем на корню снижает себестоимость конечного продукта.

Отношения QA - QC - Dev

При движении продукта между программистом и тестировщиком его ореол состоит из вопросов программиста к тестировщику про состояние продукта. QA определяет круг вопросов и проблем, которые необходимо сверить с эталоном. QC исполняет намеченные проверки и выдаёт программисту весь перечень выявленных новых проблем и заключение о соответствии продукта техническим требованиям.
Для того, чтобы стать QC, достаточно знаний школьной программы. Для продвижения по служебной лестнице к QA необходимо расширять свои знания и умения не только в науке тестирования, но и глубоко постигать предметную область (например, экономику для создателей интернет-магазинов, географию для развития онлайн-туризма), а также новые способы сбора, обработки и хранения информации (программирование, аналитика и управление данными), чтобы в любой момент вы смогли стать TestOps, то есть на любом этапе разработки ПО быть в состоянии подменить аналитика, программиста, внедренца. Если QA отличается от QC лишь наличием более широких знаний, то TestOps лучше QA из-за его возможностей не только подсказать в нужный момент, но и самостоятельно внести в нужное время коррективы для производства более качественного продукта.

Все эти растолковывания приурочены к Дню Учителя. Именно с его деятельностью тесно связана наша - тестирование, когда нам приходится самим разбираться во всём том новом, что создали программисты, и затем подробно доносить полученные знания всем заинтересованным лицам (пользователю, руководителю проекта, кодеру и другим участникам разработки).

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

Профессионалы в процессе

В 2000-2003 годах офшорная компания RSC создавала и поддерживала программный комплекс "Практик-А", написанный на Oracle Forms (упоминаются актуальные горячие клавиши). Основатели компании в 2002 году отмечали юбилей и предложили всем сотрудникам творческий конкурс. На тот момент в мои обязанности входили тестирование и тех.поддержка (СТП - служба технической поддержки), но тестировщики всюду суют свой нос, поэтому рассказ получился более чем полный. Никакого приза моя работа не выиграла. К сегодняшнему Дню Тестировщика публикую свой опус. Может кого-то из вас он сподвигнет на что-то большее.

Как RSC создаёт "Практик-А".

Этап первичный. Все на старте. У аналитика разгон:

Собрать все нужные нюансы готов, бумажки собирает он.

То с шефом часик поболтает, то с рядовыми день иль два.

За все мучения награда ему - подробностей стопа.

И маркетолог потихоньку в контракте правит пункт "Права":

Для конкурентов нет лазейки, им предстоит всё сызнова.

А тестировщик пишет планы: с кого начать и что потом,

Чем протестировать экраны, чтоб не осталось за бортом

Предупрежденье: интерфейсы - не для слепых и старых дам,

И каждому объекту - место, чтобы не рыться по хелпам.

Этап второй - разгар событий. У каждого заданий тьма.

Тут время маленьких открытий. Без плана - хаос и кутерьма.

С завода аналитик едет в родные стены напрямки,

Где и в жару и в холод лютый рисует, как Малевич, уголки.

Для главного определяет он место в центре, а затем

Для "дочек" сущности вставляет, связуя их в контексте тем.

Пока что он один лишь знает, как будет выглядеть Проект,

Какие будут отношенья, с чем, сколько, видно или нет.

Он программёру составляет набросок действий, чтобы тот

Без промедленья и задержки составил правильнейший код.

Проектировщики в короткий срок набьют пакетов кучи строк.

Ошибки ввода ограничит "primary" или "unique" ключик.

Ну, а для верности значений есть "trigger", "view" и "value check".

Они - такие, они - шальные. И целый день глядят в экраны, как хмельные,

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

"Create"-ом и "insert" таблицу сляпают, а если что не так, то тут же "alter"-нут.

На ввод - "commit"-ы есть, не хочешь - "rollback". Готов проект, на тест несут.

Здесь тестировщицы - вреднюги. Заметят каждый баг и ляп.

Где хелп? И что за сокращенья? Симметрий нет! А выйти как?!

Бедняжка форма стонет, плачет под натиском таких задач,

Считая ввод запоминает и направляет на печать.

Сто раз поправят программёры, сто двадцать тестер скажет: "Нет".

Чтобы Проект стал идеален, не жалко им ни сил, ни лет.

Когда порядок полный на этапе, на все ошибки исправленья есть,

Тут техподдержка и рекламодатель в свою узду впрягают всех.

Новинки или дополненья описаны уже давно.

Вот начался этап внедренья. Для праздника время пришло.

И на заводе оживленье: команда к ним летит от нас.

Научат, сервер установят и юзерам покажут класс.

Горячих клавиш стройный ряд любой проблеме будет рад.

Что делать - "F1" нажмите, не ладится, тогда с "Shift"-ом.

А коль забыли "кто есть в кнопках", то - "Ctrl" с "F1". Всё в нём.

Чтоб сосчитать объёмы строк - с "Shift"-ом "F2". Ну, и потом

"F3" дублирует объект, а с "F4" проблем нет:

Всю предыдущую строку в пустую вставит, как свою.

Неверно? Есть "Shift+F4": очистит строчку, как и было.

Гулять в режимах и по окнам "F5" поможет, а с "Shift"-ом,

Мой друг, уж будь ты осторожен: всё пусто будет в блоке том.

Достопочтенная "F6". Нужна строка? Вот она есть!

Всё лишнее с "Shift"-ом "F6" как зверь голодный может съесть.

На пару кнопок честь возложена запросом базу фильтровать:

"F7", и вводишь всё искомое, "F8" не забудь нажать!

Когда же в форме всё не так - с "Shift"-ом "F7" - она пуста.

"Shift+F8". Сбросьте страх: через принтер - на листах.

Значенье подобрать из списка "F9" Вам поможет быстро,

Лишь с "Ctrl"-ом её нажмёте, иерархией пункт подберёте.

Пора запомнить измененья: "F10" - и итог мученьям.

"Tab" переходит по полям, "Shift+Tab" по ним же, но назад.

Вас "Ctrl+Tab" вперёд ведёт, а всё с "Shift"-ом в окно вернёт.

Не только "Esc"-ом отменяешь, есть "Ctrl+U" им очищаешь.

По окнам "Page Up Down" ходят, когда их с "Ctrl" наберёшь.

А стрелки по строкам поводят, при спешке их с "Shift"-ом нажмёшь.

Есть "Ctrl+E" для тех, кто хочет значенье в поле поменять.

И "Ctrl+Q" в Проекте пашет, чтобы закрыть иль отменять.

А пользователь не лыком шит, чуть что не так, и в СТП звонит.

Скрипты, скрипты… Им нет предела. Исправить то, добавить сё.

На СТП опять облава, успеть им надо пропатчить всё.

Домой вновь едет аналитик с заданьями, чтобы Проект

Шире и дальше развивался, добротно работал много лет.

Всё смогут наши программисты, когда у них есть за спиной

Hi-аналитики - специалисты. А SQL для них - родной.

Команда к трудностям готова, исполнит каждый Ваш каприз.

Для современных технологий есть "Практик-А". На цену не скупись.

P.S.

Коль слишком гладко, не кривитесь, ведь строчки сами легли в ряд.

Кому не любо, не гневитесь, e-mail мой примет всякий баг.

Свои рецензии оставьте. За труд прочтения себя поздравьте.

(июль 2002 года)

Пророчества

Иностранная литература о профессии тестировщика называет то, о чём хочу сегодня поговорить, - ShiftLeft. А по-русски такой метод работы можно назвать - пророчество.
В обязанности тестировщика входит оценка существующего программного обеспечения на предмет его совершенствования. При внедрении новшеств именно тестировщик должен просчитать положительные и отрицательные моменты для пользователя при реализации функционала. Тем самым, тестировщик становится прорицателем ситуации, если не доносит проектировщикам неопровержимые доказательства своих гипотез. Но поскольку большинство предположений тестировщика строятся на интуиции, то зачастую к нам относятся негативно и считают, что это мы "накаркали провал".
Генеря идею аналитики рассчитывают только на успешный исход, но тут вмешиваются тестировщики и, задавая самые неудобные вопросы, превращают "красивую картинку" проектировщика в прах. Группы разработчиков, прислушивающиеся к комментариям тестировщика, вовремя реагирующие на упаднические линии в производстве, умудряются действительно прийти к положительному результату при внедрении своего ПО. Ну а самовлюблённые руководители проекта, надеющиеся на авось, упрямо продвигают лишь собственное мнение. И, конечно же, при полной неудаче в конце концов всю вину скидывают на нас же, тестировщиков, как на "мальчиков для битья".
Из этих комментариев стажёры IT-индустрии могут сложить картину своего будущего. Никаких результатов своего труда вы не сможете "пощупать", если станете тестировщиком ПО. Хотя, здесь есть лазейка. На обсуждениях новшеств постарайтесь записать все слова, сказанные каждым членом группы разработки. А после успешного и провального внедрения переслушайте (или перечитайте) записи. Этим вы сможете проанализировать собственную интуицию: предугадали ли вы исход спринта, задали ли вы конкретные вопросы уточнения мелочей производства, заставили ли вы аналитиков продумать все возможные ситуации пользователя.
О фразе "я же говорил(а)" в монологе одного из начинающих артистов оригинального жанра есть мнение довольно неприемлемое в профессии тестировщика. Комик агитирует уходить от тех, кто выслушал ваше мнение на этапе идеи, но не последовал вашим рецептам в процессе реализации. Он аргументирует такой совет тем, что если эти люди забили на вас в начале пути, то по прошествии события в точности по вашим пророчествам во фразе "я же говорил(а)" смысла уже никакого нет. Но здесь никак не могу с ним согласиться. После спринта проходит ретроспектива, где вся группа разработки обсуждает успехи и неудачи прошедшего этапа. Именно на этом мероприятии тестировщик может в полной мере ощутить ценность своей работы, сравнив свои предсказания с полученным результатом.
Приведу несколько примеров из собственного опыта.
Долгие годы компания ConquestSS разрабатывала десктопный продукт SQLDetective для работы с базой данных Oracle в операционной системе Windows. По примеру ОС в приложении существовала панель с кнопками открытых в рабочей области модулей. Однажды владельцу продукта пришла мысль реализовать функционал таскбара в приложении наиболее приближенно к общеизвестному в операционной системе. Но шеф, выступавший иногда в роли аналитика, не собрал воедино весь известный функционал, а решил воплотить только то, чем пользовался он один. Кнопки одноимённых окон всегда автоматически объединялись, при наведении курсора на группу кнопок показывался лишь список кратких имён без отображения содержимого в минимизированном виде. Моё замечание о том, что новый функционал не имеет настроек пользователя и будет работать в неудобном формате, было письменно зафиксировано. Но упрямый владелец продукта категорично отверг моё предложение добавить настройку пользователя по выбору режима отображения кнопок в собранном по модулю режиме или самостоятельно для каждого окна. Как только новшество попало конечному пользователю, посыпалось юзерское негодование о потерянных из виду рабочих окнах. Только после этого моё первоначальное замечание было внедрено хотя бы частично. К тому же, на его реализацию потребовалось больше времени, нежели его было бы израсходовано сразу, поскольку произошла ротация ответственных программистов по продуктам и новичку пришлось изучать легаси (старый код предыдущего разработчика). Но, дабы не портить отношения с руководством, сокровенная фраза была произнесена лишь в уме, да и к тому времени у меня не было особой надобности выпячивать свой профессионализм: зарплата повышалась сама собой, авторитет у сотрудников давно заработан обильными подобными случаями.
Несмотря на то, что с момента описанных событий прошло более четырёх лет, явно действовавших лиц называть не буду, как меня приучили в ConquestSS. Да, полное совпадение поведения с героями Григоря Остера, которые не хотели предавать друга - Слонёнка. Поэтому вместо имён даю линки на их аккаунты в соцсетях.
Вторая история, которую хочу вам поведать, закончилась менее благополучно для пользователя, нежели предыдущая. Но обе ничего приятного мне, как добропорядочному тестировщику, не принесли. К сожалению, руководитель проекта всегда слишком ревностно относился к своему детищу, и это его погубило. После увеличения группы разработки неприятие чужих идей стало проявляться в нём более явно. Он игнорировал мнение разработчиков на обсуждениях замалчиванием или резкой фразой "я так решил, это не обсуждается". Удалял без предупреждения не свои задачи с предложениями из BTS и в этот же или на следующий день оформлял точно такую же, но от своего имени. То есть элементарным плагиатом пытался увеличить своё барско-собственническое отношение к продукту, реализуемому целой группой разработки. Поскольку мне, как тестировщику, была давно привычна роль "на отшибе команды", то моё недовольство за игнорирование своих идей направлялось приватно лишь самому руководителю группы. Но когда подобное негативное отношение к чужому стало распространяться на всех членов команды, то взыграло моё обострённое чувство справедливости, упроченное и развитое должностью ответственного за качество, и жалоба о безалаберности самовлюблённого руководителя группы легла на стол вышестоящего босса. К сожалению, тот, кто платит, не является сильным руководителем. Босс проявил себя слабым начальником и вместо того, чтобы отдать должное "серому кардиналу" и воспользоваться его заслугами по сплочению коллектива для достижения общей цели, оставил во главе группы разработки плагиатора. На тот момент босс утверждал, что даже такой нерадивый начальник будет делать именно то, что ему нужно, то есть сводить проект к полному уничтожению. Но, как показала практика, быстрого краха им добиться не удалось, потому что группа разработки была заряжена "серым кардиналом" на довольно длительную систематичную и добротно налаженную работу. На том объёме предложений, что были мной ранее оформлены, ConquestSS продержались год (до июля 2018) в полном составе и ещё пару лет в минимальном. Под шумок эпидемии закрыли два продукта (ClearDB в марте 2020, FADEX в июле 2020), а оставшиеся два (ClearSQL, SQLDetective) вместо того, чтобы стать лучшими в линейке подобных или уникальными через реформации и декомпозицию, скорее всего исчезнут с рынка, поскольку уже слишком долго (полгода-год) нет обновлений, да и сайт застрял в 2020 году (дата копирайта внизу главной страницы). Но это только мои предположения. А что же сбылось из ранее напророченного?
Когда в ConquestSS отказались от качества и на моё место взяли маркетолога, провалившего бум провайдера-новичка, то ему были даны несколько советов по построению работы. Все мои предложения (в области лицензирования, обучения пользователей, поднятия статуса продуктов у самих разработчиков, ученических версий для привыкания к продукту), не требующие глубокого погружения в предметную область, были реализованы специалистом по продвижению продукта на рынке и сыграли свою благоприятную роль. А вот к предупреждениям о возможных подлянках со стороны владельца продукта маркетолог вероятно не прислушался. Вся его годовая работа по привлечению пользователей была одномоментно выброшена в мусор. Статья "ПроЛОГОведение" частично об этом случае рассказывает. Лично мне было бы очень обидно, если бы группу в соц.сетях, набравшую моими усилиями большое количество подписчиков, вдруг кто-то удалил без возможности восстановления, да ещё и переименовал проект. То есть маркетологу оставалось только начать абсолютно всё с нуля - привлекать юзеров к новоимённому проекту, потеряв доброе имя поставщика стабильного продукта. Как уже было сказано, маркетолог не сильно разбирался в предметной области, поэтому не смог реализовать мои предложения по развитию самих продуктов. А ведь именно это могло спасти проект в тот момент, когда начался конец ConquestSS. Но он был неминуем. Во время моего разговора с боссом прозвучала его оговорка по-Фрейду, смысл которой был озвучен основной группе разработки: "Боссу мы не нужны и он мечтает о закрытии ConquestSS". Да, он давно жаловался, что мы - убыточный проект. Но эти верные работники много раз его выручали и соглашались на низкую оплату труда, либо бесплатную поддержку. Только ни CustDev, ни Agile в исполнении шефа не спасли проекты, а чуйка ответственного за качество никак не пробила упрямство самовлюблённого начальника. И, как итог такого эгоизма, крах неизбежно наступил. Даже предупреждённые программисты лишились работы. А тестировщик - не пророк, это просто его должностная обязанность читать между строк и слышать мысли, увязывая их с предшествующими событиями.
Надеюсь, что моё третье пророчество будет с хэппи-эндом. IT-сфера меня привлекла и тутже поглотила в 1986 году. Как понимаете, знания мне приходилось выуживать не из готовых учебников, а собственным опытом. В последнее время повышать квалификацию стало проще, ведь появились конференции наших специалистов, где в результате быстрого общения объём нового моментально распространяется. SQA Days явились первыми вестниками знаний широкого круга и даже выделили в отдельное течение аналитиков, охватили европейскую аудиторию тестировщиков. Когда конференции были в диковинку, тем и докладчиков было намного больше свободных мест. Но с годами наблюдаю, что в докладах исчезла новизна идей. Вероятно с приходом сертификации нашей работы, то есть сконцентрировав все правила в одном документе, у специалистов нашей профессии наступила остановка вливания новых идей. Мы вышли на плато. Все накопленные опытом знания уже озвучены, доклады на последних конференциях за пару лет повторяют себя в основном. Зачем же теперь стремиться поучаствовать в SQA Days? Разве что, ради бесплатной рекламы самого себя. Никаких прорывных новых идей, к сожалению, уловить на них не получается. А мусолить то, что уже известно всем - только трата времени попусту. Однажды выступив на конференции и получив положительный отзыв от куратора, меня активно зазывают стать докладчиком. Но за этими звонками я с точки слуха тестировщика предчувствую, что мной просто на просто пытаются закрыть дыры снизившейся популярности мероприятия. Но, уж если на то пошло и организаторы конференций не способны достичь кворума, может объединить все три конференции в одну? Тем более, что между тестировщиками и аналитиками к сегодняшнему дню уже почти стёрлась граница в должностных обязанностях. Ситуация закрытых границ между странами только положительно влияет на конференции, потому что для он-лайн режима появились, или вернее сказать улучшились, условия связи и проведения мероприятий. К тому же цена такого общения значительно дешевле, нежели очного. Так что, если организаторы конференций IT-Conf объединят все три мероприятия в одно, пригласят к участию больше иностранцев, переведут всё в он-лайн режим и максимально снизят плату за участие (в данном случае возможность быстрого общения с знаменитостью или получение ответа на жгучие вопросы от большой аудитории), то конференция останется в топе аналогичных. Появившиеся недавно конкуренты (Heisenbug, TechTrain и иные подобные) очень быстро наступают на пятки и даже в каком-то смысле обгоняют, привлекая к участию более глубоко практикующих специалистов.
В рамках профориентации эта статья скорее сослужит недобрую службу, поскольку показывает нашу профессию с самой неприятной стороны. Тестировщик одновременно должен и предугадать конец, и предложить несколько путей по минимизации провала. Но в любом случае вину за неудачи скинут на того, кто их "пророчил". Психологически быть тестировщиком - очень сложная задача. Постоянный риск комплекса "носителя плохих вестей", если вы добросовестный и ответственный работник, на мой взгляд минимизировать можно лишь двумя путями. Либо программисты перестанут плодить баги, тогда вы прекратите грустно отчитываться на стендапах об увеличенном потоке возвратов и регрессов. Либо вы станете пофигистом, тогда рост багов вас никак не будет задевать, но в этом случае вероятна потеря интереса к профессии. А если вы приучите свою психику радоваться чужим ошибкам, то никакой социум вас не подпустит к себе, поэтому сначала вы перейдёте в разряд интровертов, потом мизантропов и аутистов. Но к этому моменту вас лишат рабочего места в группе разработки, да и на аутсорсе одиночки-фрилансеры - явление редкостное. Так что, вовремя контролируйте свой внутренний конфликт отношения к чужим промахам. Не бойтесь обрисовать во всех чёрных красках плохой конец, но при этом подготовьте и "рояль в кустах", и "туза в рукаве" в виде альтернативных путей по достижению цели постановщика задачи и в качестве отходных манёвров при приближении к пропасти. Не скрывайте свои способности пророка, развивайте интуицию, если в ваших планах восхождение по карьерной лестнице. Нет, мы - тестировщики - не прорицатели, но картину будущего продукта можем обрисовать в сочных (чаще тёмных) красках.

Тесты Евровидения

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

Итак, мы с вами протестировали телевизионный песенный конкурс "Евровидение". Как вы сами убедились, даже к такой казалось бы отдалённой тематике можно приложить наши знания и умения тестирования. Аналогично моим предыдущим отчётам о тестировании некоторые моменты подсвечены: жёлтым - объект тестирования, зелёным - положительный исход теста, красным - проваленный тест, сиреневым - сомнительный результат или невозможность исполнения, голубым - предложение по исправлению. Прикладывайте свой опыт и разум ко всем случаям окружающей жизни, тогда все ваши действия и предложения станут конструктивными, и никто не сможет вас осудить в голословности. А ваш дар критика разовьётся сам по себе.

Программа иль дитя

Конечный результат любой группы разработки - продукт. Если речь о ПО, то каждый из группы разработки относится к своей работе и программному продукту, как к некому детищу, в которое вкладывают свои силы и умения по мере возможности. Даже программист-одиночка и тот не может выпустить программу без минимального тестирования, то есть код он пишет моментально, как Папа оплодотворяет Маму, а потом довольно долго отлаживает и тестирует, подгоняет и исправляет, то есть вынашивает Дитя, как беременная самка. Редко в мире и программном производстве встречаются гермафродиты, которые качественно могут проверить свой же код. Также, как и в большой семье, жить и развиваться Дитя может только при генетической поддержке Дедов, Родителей, при финансовой поддержке богатых Дядюшек и Тётушек. Младенец нуждается в питании, точно также, как и программа в наполнении функционалом. Эта часть жизни очень схожа с периодом, когда продуктом занимается аналитик или ребёнком Няня (бабушка, тёща). Взрослея подростку уже нужны не только био-вливания, но и моральные, а этот период очень схож с воздействием на продукт со стороны техподдержки через отзывы пользователей, а на дитя - Гувернёром. Более научный опыт дитя получает от Репетиторов, а программа становится равнозначно понятной как производителям, так и потребителям за счёт усердий техписателя. Раскруткой и развитием Отрока в семье обычно занимаются Кузены, которые играют с ним, знакомят с обществом ровесников и выводят в свет, подобно рекламно-маркетинговому отделу при публикации программы. На программу в расцвете сил, как на совершеннолетнего человека, начинается охота со стороны пользователей, а на Молодёжь устремляют свои взгляды лица противоположного пола для создания новых семейств, производства и семьи сливаются словно интеграция продуктов. 

Однообразие межродственных и производственных связей и влияний

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

Загадки QA

В одном из радиоэфиров как-то разгадывали профессию дозвонившегося слушателя. По десяти коротким описаниям ведущие должны были назвать не только отрасль, но и специализацию. За каждый неверный ответ радиостанция выкладывала приличное денежное вознаграждение игроку. Мне эта идея понравилась, и ниже перечислю свои загадки о профессии "специалиста по тестированию программного обеспечения" (далее - СТПО). Их у меня получилось больше десятка. К каждой загадке буду давать пояснения.

1. Этой профессии уже не мало лет, хотя признали её совсем недавно.

Программированием, а значит и тестированием, занимаются официально в мире с середины ХХ столетия. Должность СТПО включена в государственный реестр весной 2014 года.

2. До недавних пор этим делом занимались в основном представительницы женского пола, но современность привлекла и мужское население.

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

3. Многие считают эту профессию самым лёгким путём для начала карьеры.

Поскольку операторы ПК превратились в просто-пользователей, а тестировщиков считают юзерами альфа-версий, то и желающие "войти в IT" полагают, что освоив профессию QA, они быстрее станут одним из членов престижного клана по созданию информационных технологий.

4. Прежде чем занять свою нишу в производственной сфере, необходимо изучить и опробовать не только нижние ступени, но и хорошо знать верхние, а также уметь заменить любого в параллели. Профессия из числа ИТРиС (инженерно-технические работники и специалисты), но в ВУЗах специализированных факультетов до сих пор нет. На сегодня специальность можно освоить самостоятельно, либо по спец.курсам.

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

5. Наша работа из числа высокого неожиданного риска, но сертифицированный допуск не требуется.

Исследовательское тестирование чаще других может "повесить" или "убить" приложение. Хакерские секреты используются как принципы проверки безопасности.

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

Исследуя новый продукт тестировщик обязан найти его слабые места до момента продажи. Исправляют проблемы программисты и аналитики.

7. Наш вклад в производство настолько субъективная величина, что каждый потребитель мерит её по-своему.

Тестировщика часто называют специалистом по обеспечению (QA инженер) и поддержке качества продукта, а оно имеет три параметра: скорость поставки, цена, удовлетворённость функционалом. Их совокупность каждый пользователь определяет сам.

8. В наши обязанности входит подробное чтение документации.

Есть даже особый раздел про проверку требований к продукту, инструкций пользователя.

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

Требования к продукту, составленные аналитиком, перетекают в инструкцию пользователя после апробации тестировщиком и внесения исправлений, наиболее соответствующих истине.

10. У истоков профессии было насекомое.

Ошибки программирования называются "багами", потому что первой причиной проблемы ПО был мотылёк, а по-английски bug - жучок.

11. День красоты - профессиональный праздник.

Первую ошибку зарегистрировали в журнале проблем ПО 9 сентября 1947 года. В этот же день с 1995 года чествуют всех причастных к красоте в международных рамках. 

12. Представителям нашей касты приходится "рыться в чужом грязном белье".

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

13. Эта профессия требует особой психологической устойчивости, потому что во всех бедах виновными считают именно нас. Нас хвалят за то, что мы ругаем других.

Тестировщик - основной поставщик проблем для группы разработки.

14. Наш основной стиль работы - объективность. Нам нельзя рекламировать и продавать товар, не смотря на то, что мы о нём знаем всё лучше всех.

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

15. Сталкиваясь с вирусом мы кричим "Ура!" и, не боясь заразы, несём его на "лечение".

Хакерские атаки в мире программирования называют "вирусами", от которых систему освобождают программисты и администраторы сетей.

16. Эта профессия подвластна всем - среди нас не мало "желторотых" студентов и седых пенсионеров.

Юниоры входят в IT в основном через тестирование ПО.

17. Мы практику превращаем в теорию.

На основе наших проб пишутся инструкции пользователя.

18. На работе мы можем играть в игрушки целый день, и никто не будет против.

Есть особое направление Game-Dev или Test-Game. Программным обеспечением может быть игра. Но даже в серьёзном продукте элементы игры весьма хорошо применимы при тестировании. 

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

Поздравляю соратников с Днём Тестировщика!

Tester's KPI

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

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

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

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

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

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

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

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