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 из-за его возможностей не только подсказать в нужный момент, но и самостоятельно внести в нужное время коррективы для производства более качественного продукта.

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

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

С Днём профи-проггера!

Осенью 1986 года было моё первое погружение в IT через членство в клубе компьютерщиков при транспортном ВУЗ-е, а уже в феврале 1987 года результат моих  работ был представлен на внутривузовской конференции. На освоение компьютера и изучение языка ФОКАЛ мне понадобилось около двух месяцев. Да, чтобы начать программистскую деятельность нужны минимальные знания, а чтобы стать тестировщиком понадобится не только развитое логическое мышление, но и много разных навыков по всем стадиям разработки продукта. Официально в моей трудовой книжке запись о должности программиста появилась после двух классов школы и пяти лет института, а в тестировщики переход был только спустя девять лет программирования. В поэтическом плане роль тестировщика меня сподвигла на литературный выхлоп уже на третий месяц в деле, а вот программирование зрело долгие двенадцать лет. Ниже читайте о том, как мне работалось программистом в конце XX века.

Машина тоже чувствовать умеет.
Она с тобой болеет и сопереживает.
Не ладится судьба, - и у неё чой-то замыкает.
А если у тебя идёт всё гладко, тогда и ей не требуется отладка.
Моргнёт глазком зелёным, ритмично засверкает красным,
Засветится экран. И ты в строке, немногим ясной, но всё ж тебе во всём понятной,
Увидишь тот набор значков и закорючек, в которых смысл скрыт того, что он не глючит.
Но тут всё замолкает.
Клавиатура пискнет, принтер щёлкнет, и по модему огонёчки пробегают.
Для связи auto оставляю. И приложения постепенно запускаю:
Одно, второе. Это и вот это. У гороскопа* собственного спрошу совета.
Отмечу в хит-параде** все места, от "Ум за разум" - слово. И в дела!
На день рождения - акростих. Для друга - копию, чтоб от тоски не сник.
Так. На заказ на Delphi код в сто строк пишу лишь мышкой. И успею в срок.
Вот тут подправлю. Здесь чуть-чуть пошире, а остальное отрезаю. Пусть гниёт в корзине.
Пожалуй, всё готово. На проверку. 

Пример: один, второй, … , десятый. Для юзера дубового на этом хватит.

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

----------

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

**хит-парад - компьютерная программа для музыкального радио "РИФМА" была разработана, написана и внедрена в рамках семилетнего статуса радио-критика на общественных началах.

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

В 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 года)

Безоглядное родительство

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

Погода благоприятствует прогулкам, и на днях пред моими глазами на бульваре произошёл конфликт поколений. На скамейке отдыхала старушка и ела мороженое. Мимо шли мать с полугодовалой дочкой на руках и отец, одной рукой толкавший коляску, а другой держа за ручку двухгодовалого сынишку. Бульвар - место общественное и там постоянно проводят много свободного времени горожане. Конечно же, муниципальная собственность оборудована необходимыми социально полезными объектами: лавочки, спортивные снаряды и детские качели, санитарный уголок и продуктовые палатки с напитками и закусками. Семейство нагулялось и двигалось к парковке. Поравнявшись с вкушающей сладость старушкой, внимательная мамаша остановила своих родичей и стала допытывать сыночка: "Хочешь пи-пи? Давай, давай сейчас, а то до дома не дотерпишь." Уговорив дитя опорожниться, она обменялась с отцом детьми и сделала пару шагов до ближайшего деревца на газоне, снимая с малыша штанишки. 

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

Думаете, родители извинились перед ней? Нет! Они нагло посмеялись над отрыжкой старушки: "Детская моча деревьям не помеха." Понятное дело, что любящая мамаша готова зад целовать своему сыну, но такое безоглядное чувство демонстрирует её ограниченность. Мало того, что подобное поведение наглого семейства оскорбляет окружающих, но дети, наблюдающие поведение своих родителей, станут копировать его и впоследствии, то есть лет через двадцать ситуация вполне может повториться. А на месте отдыхающей старушки может оказаться та самая мамаша или не остановивший её отец семейства. С медицинской же точки зрения мать подвергла сына опасности подцепить клеща с ветки дерева, не приучая его пользоваться санитарным местом для справления нужды. Полагаю, что отец в этой ситуации оказался более благовоспитанным, поскольку он не потащил сына до неподалёку стоявшего их автомобиля, чтобы помочить колесо, как это принято у настоящих мужиков. Но с другой стороны, он проявил слабость и показал себя подкаблучником, не отведя сам сына в кабинку биотуалета. Но это не удивительно, поскольку скорее всего его воспитывала такая же безумно любящая мамаша. 

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

Для группы разработчиков их ПО тоже становится столь же близким детищем спустя некоторое время. Они его поддерживают, совершенствуют. Но у некоторых эта забота приобретает эгоистический характер. Кто-то из производителей счастлив тем, что конечный пользователь получает качественный по всем параметрам продукт, а эти генерят код только лишь для самого факта наличия сложного кода. По сути он никому не нужен, но он есть, создан, функционирует зазря, даже при всей его сложности и вычурности. Немного об этом уже было сказано в статье "Программа или дитя" (https://tjupka.blogspot.com/2020/11/blog-post.html). Здесь же хочу затронуть ту губительную сторону дела, когда ПО пожирает команду.

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

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

Ещё один подвох кроется в типе команды разработки. Многие шефы сейчас бравируют так называемыми "тёплыми, семейными" отношениями. Но никогда не раскрывают истинного стиля. И недаром лекторы Стратоплана настойчиво предупреждают избегать таких коллективов. Да, вас там будут "иметь и в хвост, и в гриву за просто так", без всякой благодарности и учтивости взвалят на вас всё самое муторное, как будто так и надо. Нет! На работе спать нельзя. В прямом и переносном смысле. Как только вы начнёте замечать благосклонность босса, то сразу постарайтесь выяснить напрямую причины и ожидаемые последствия таких перемен. Иначе вы внезапно окажетесь тем самым мальчиком для битья, виновным во всех проблемах. 

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

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

Пророчества

Иностранная литература о профессии тестировщика называет то, о чём хочу сегодня поговорить, - 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 лет, а на слуху не более десятка мелодий и пяток певцов. Это ли не подтверждение того, что конкурс из песенного давно перерос в геополитический.
Как и любой выпускаемый билд, Евровидение имеет своего ответственного тестировщика. Здесь его называют супервайзером. Именно он подтверждает благополучный исход производства и даёт своё заключение о полном совпадении принятых значений с отнесёнными к ним данными базы.

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

Решаем задачи

Отслеживание качества продукта - важнейшая функциональность тестировщика. В число характеристик качества входит и процесс производства, а его налаживание и есть та миссия, которая поручается тестировщику. Когда производственный процесс налажен чётко и ясно, прозрачно для всей группы разработки, то руководящему звену легко и просто отследить и выявить провисы и перегибы, а следовательно и принять вовремя меры по стабилизации процессов.
Для обеспечения прозрачности работы группа разработки использует какую-нибудь систему BTS (Bug-Tracking System), которая в свою очередь состоит из отдельных задач. У задач есть характеристика - жизненный цикл, который можно представить несколькими способами. Своим поделюсь в этой статье.
Этапы задачи разбиваю на следующие: создание, синхронизация, актуализация, исполнение. Шаг планирования пропущен, так как им занимается менеджер, а не рядовой тестировщик. При чём после каждого из первых трёх этапов вполне реально перепланирование, то есть смена сроков и ответственных. По этой же причине не выделяю отдельно декомпозирование задач. Остановлюсь на каждом из них подробнее в разрезе того, когда по моему мнению ими удобнее заниматься.
Созданием, как и ранее было сказано в статье МОПС, предлагаю заниматься в конце дня, когда в процессе основной работы над модулем или всем продуктом собрано достаточно информации для локализации проблемы. Полный набор сведений лучше собирать исходя из структуры ваших задач, как это было описано в статье "ГКЧП - Где, Как, Что Править?". Не забывайте, что из этих первичных документов, то есть тасков вашей BTS, формируется ваш отчёт о тестировании. Насколько точно и аккуратно будет оформлена каждая из задач, настолько же верно вы получите срез о качестве всего продукта. И дело тут не только в количестве и важности ошибок и предложений, но и в распределении их по модулям-компонентам, ответственным, а также подсчёт потраченного времени. Каждая мелочь, складываясь в общий график, даёт аналитические данные для последующего планирования.
А уже с утра следующего дня до ежеутренней планёрки (если вам привычнее - стендап) рекомендую читать, редактировать и синхронизаровать задачи, оформленные вами и всеми другими членами команды. Большинство советчиков по эффективности тайм-менеджмента предлагают начинать любую работу с лёгкого или мелкого. Придерживаясь этого мнения и я предлагаю начинать рабочий день с мелочёвки - почитать результаты чужих дел. О том, зачем нужно и как проводить оценку, подробно описано в моей статье "Issue review (ГКЧП-2)". Напомню только, что в процессе ознакомления с задачами всех вы упрощаете ежедневную встречу для отчёта о проделанной работе каждым членом команды. Их короткие речи станут вам понятнее, а также успеете сформулировать вопросы для уточнения пути развития продукта. Лишь после сбора всех мнений команды об отдельно взятой задаче для её декомпозиции и планирования будет набрано достаточное количество аргументов.
Актуализацию задач выделяю отдельным этапом, потому что это фактически работа с техническим долгом. Шеф ConquestSS предлагал отводить на это дело по полчаса с утра, но практика показала, что актуализировать забытые или отложенные задачи вы будете весь рабочий день. Зачастую с виду простенькие замечания или идеи требуют обильной проработки и многочисленных исследований в параллельных областях. Так что, тридцати минут даже на одну задачу не хватало. Раз в год или чаще в список для актуализации попадали задачи, давно заведённые в BTS, но до сих пор не попавшие ни в один билд, то есть вовремя не запланированные. В процессе актуализации некоторые задачи закрывались, как часть ранее реализованного, какие-то дополнялись для планирования на ближайший выпуск, остальная часть считалась несвоевременной фантастикой и откладывалась до будущих времён.
Исполнение полноценно оформленной задачи проводится в основное рабочее время. На каждое задание у вас уйдёт ровно столько времени, сколько запланировано, только если с задачей была ознакомлена вся команда, которая аргументированно дополнила, декомпозировала и запланировала её на исполнение. В процессе проверки исправленных багов, исследования новшеств, сбора данных по производительности продукта у вас непременно будут образовываться идеи для развития приложения, замечания по несоответствиям с нормативами, которые откладывайте по системе МОПС для замыкания спирали усовершенствования вашего продукта или, иными словами, жизненного цикла задач, то есть создавайте новые.
Некоторым из вас может показаться, что второй и третий этапы - синхронизация и актуализация - взаимозаменяемы, но уверяю вас, они не есть одно и тоже по нескольким причинам. Да, в обоих случаях проводится исследование и задачи дополняются, корректируются. Но! В синхронизации одной задачи участвуют много работников, в то время как для актуализации нескольких, объединённых по модулю, задач достаточно одного тестировщика. Синхронизация - процесс поверхностный, то есть не требующий больших временных затрат, а актуализировать надо проникая глубоко внутрь идеи. То есть, синхронизация идёт горизонтально вправо и влево в разрезе задач, а актуализация - вертикально вниз по продукту.
Надеюсь, мои вышеизложенные умозаключения помогут менеджерам и рядовым тестировщикам теперь более эффективно распределять рабочее время.

Трёхмерность жизни

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

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

Ось ХОЧУ

Определю желание или цель стрелкой вверх и влево, потому что всё сейчас недоступное обычно весит высоко, а более притягательное почему-то на дороге влево. Вспомнить хотя бы ходоков к чужим жёнам или сладкий плод в раю. Они тоже где-то слева вверху. Мечту чаще называют "розовой", потому и цвет оси "ХОЧУ" придам тёплый. Если же не в житейской терминологии её именовать, а юридической, то более подходит слово "ЦЕЛЬ". Или же можно назвать эту ось "птица счастья", у великого баснописца она, кстати, была Лебедем.

Двухмерность мечты и возможностей

Но любая хотелка, как уже ранее было сказано, не может материализоваться без вложений, то есть возможностей мечтателя. Поэтому определю наши силы для осуществления мечты синей стрелкой вправо и вверх.  Синий цвет оси "МОГУ" ассоциируется с работой и водой.  В той же басне за возможности отвечала Щука, ведь "без воды и ни туды, и ни сюды". Но не смотря на то, что вода обычно снизу, ось стремится тоже ввысь, потому что увеличивая свои возможности мы приобретаем опыта больше, чем в последствии тратим сил. Те, кто не разделяет сказочные объяснения, а желает придать моей теории научность, могут именовать эту ось юридическим термином "ПРАВА", по аналогии с документом, известном всем как "договор".

Трёхмерность желания

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

Расценки мечты

Итак, у нас получилась трёхмерная система координат жизни, которой мы придадим условное исчисление: от 0 до 3 или 10, как вам больше нравится.

Выделим в текущий момент жизни одну проблему, например, финансовый кризис после пандемии. Попытаемся начертить кривую для решения этой конкретной проблемы в системе координат наших желаний, возможностей и обязанностей.  Первым шагом сформулируем мечту или цель, которая должна быть адекватной, достижимой и конкретизированной. Например, выиграть миллион в лотерею - это неадекватная, слабо-достижимая мечта, но конкретизирована суммой. А вот желание "летний трёхнедельный отпуск провести на морском побережье и потратить двухмесячный оклад" отвечает всем условиям, потому что если на Карибское море вашей зарплаты может и не хватит, но на Чёрное или Каспийское - вполне. Тем самым мы укладываем свою мечту в рамки адекватности и достижимости, точно сформулировав конкретизацию. Поскольку мечта удовлетворяет всем трём условиям, то отмечаем её на цифре 3 своей оси. И начинаем считать возможности, то есть проводим линии до осей МОГУ и НАДО сначала к точке 1 или даже к 0, поскольку все три оси находятся во взаимосвязи, что поясню позже на примере законов физики.

Связь ХОЧУ-НАДО

Связь ХОЧУ-МОГУ

Если у вас есть регулярный доход (работа с ежемесячным окладом или вклад с квартальным причислением процентов), то по оси МОГУ можем встать на 1. Если вы нашли тур, который по цене совпадает с вашей зарплатой, то сдвигаемся на пункт 2. Если же работодатель точно даст вам дни отпуска в июле-августе, то смело сдвигаемся на цифру 3.

Если на время вашего отпуска на предприятии рабочий процесс не остановится или не развалится без вас, то ставьте точку на 1 оси НАДО. Если перемещаясь в другой регион вы не нарушите санитарные нормы, например, привились от COVID-19, то сдвигаемся по оси НАДО до 2.  Если вы гарантируете, что не нарушите в чужом месте никакие законы и благополучно вернётесь домой, например, не будете вывозить дары моря из Египта, то смещаемся до 3 по оси НАДО. То есть подчёркиваем, что общество дома, на курорте и работе не понесёт потерь от вашего осчастливливания.

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

Равновеликая мечта

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

Большое желание при малых возможностях

Увеличение возможностей равняет качели мечты

Обязательства скатывают мечту с горки

Когда объём желаемого и возможного совпадает, но невелики при огромной задолженности перед обществом, например, должников по алиментам не пускают за границу, то острый равнобедренный треугольник на первый взгляд выглядит ровно, но его острота предупреждает о высокой неустойчивости положения. То есть внутри страны может вы и поездите, но недалеко и недолго. А значит и полного удовлетворения получить не сможете.

Обильный долг не ширит мечту и силы

Встречается и ещё один вариант равнобедренного треугольника, когда ХОЧУ и МОГУ достигают максимума, а НАДО не растягивает фигуру в правильную (равносторонний треугольник - самая жёсткая фигура геометрии). Физик вам сразу напомнит, что малейшее приложение силы к одному из длинных плеч рычага начнёт качание. То есть при минимальных обязательствах перед обществом расширение мечты на один шаг сократит возможности чуть ли не вдвое, например, девицы лёгкого поведения автостопом не всегда попадают к морю, а чаще в подпол лесной избушки.

Так живут безалаберные люди

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

ЧугиноКоль-2021

Записки зрителя о фестивале любительских театров "ЧугиноКоль", никоим образом не претендующие на мнение театрального критика.

Дата:	12 февраля 2021г.
Время:	12:30
Где:	малый зал ДК г. Кольчугино
Кто:	Театральная студия "Теза" (г. Шуя, Ивановская область), режиссёр Пётр Лебедев
Что:	Владимир Маяковский "Вон самогон"

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

Дата:	12 февраля 2021г.
Время:	13:30
Где:	большой зал ДК г. Кольчугино
Кто:	Народный театр-студия "Закулисье" (СПб ГБУ "Александровский дом культуры" г. Санкт-Петербург), режиссёры Ирина Никитюк и Анатолий Трухин
Что:	Нил Саймон "Билокси блюз"

Спектакли на большой сцене ДК представляли "Пушкин" в исполнении Дмитрия Долгова и "Гоголь" в лице Александра Жулина. Меж ними скакал молодой то ли Алёша, то ли Костя, глотавший звонким голоском окончания слов.
Солдатушки-ребятушки
Сложили блюз у амер. речушки.
Поскольку коллектив "Закулисье" из культурной столицы, то оснащение (реквизит и костюмы) отдают натуральностью. Хоть обильные разнообразные бутылки и без жидкостей, но пистолет стреляющий и не только хлопками, но и огнём. Весьма деликатно была решена сцена "кувыркания" служащего с женщиной на час. А сколько романтики в обычном беге за ручку по кругу под весёлый смех!
Жюри оценило многогранность спектакля обилием дипломов:
* Диплом лауреата 2-ой степени - спектакль "Билокси блюз",
* Лучшая мужская роль первого плана - Денис Дмитриев за роль Юджина Джерома,
* Лучшая мужская роль второго плана - Константин Грицан за роль Арнольда Эпштейна.

Дата:	12 февраля 2021г.
Время:	16:30
Где:	малый зал ДК г. Кольчугино
Кто:	жюри С. Н. Коробков, Е. А. Дунаева, А. В. Карташов
Что:	интерактивный час "100 вопросов о театре"

Ученики кольчугинской ДШИ подготовили вопросы, на которые именитые члены жюри дали откровенные ответы. Зеркальная дата "12/02/2021" и мнение классика о театре, как о зеркале души, дали толчок к дискуссии о современном театре, всё больше уходящем от психологии к шоу и перфомансу, мюзиклам и пластике. Ещё раз театральные критики призвали молодёжь смотреть и слушать всё, что есть в афишах, но чувствовать и выбирать думая. Дунаева вскрыла правду тяги девочек в актёрскую профессию и рекомендовала работы учеников училища им. Б. Щукина по всей России, даже в далёкой Сибири. Коробков посоветовал ходить на фестивальные спектакли в регионах, поскольку сам заядлый член жюри таких мероприятий. Карташов выразил восхищение об актёре, завоевавшем "Золотую маску", но путешествующем по провинциальным театрам лишь с одним рукзачком. Современный театр, отражая сегодняшний мир, всё более становится технотичным и порою вообще обходится без человека - итог интерактива.

Дата:	12 февраля 2021г.
Время:	19:00
Где:	большой зал ДК г. Кольчугино
Кто:	Театральная мастерская "Грани" (г. Саратов), режиссёр Ия Воробьёва
Что:	Рэй Брэдбери "Лимонное мороженое с ванилью"

Белым-бело на сцене и за стенами.
Светлым-светло от Брэдбери в душе.
То ли автор неоднозначен, то ли режиссёры Рэя Брэдбери понимают по разному, но мастерская "Грани" представляет старух светлыми созданиями, а АКТ - грязными ведьмами в постановке "Всякое бывает". Февральский снегопад оказался в полном согласии с декорациями к "Лимонному мороженому", которые к сожалению не нашли оправдание ни текстом, ни действиями артистки. Но зато мощности света и кулис обновлённой кольчугинской сцены были использованы на полную. Как призналась актриса кому-то по телефону, ей удалось кайфануть, но строгое жюри ничем работу не отметили.

Дата:	12 февраля 2021г.
Время:	21:00
Где:	камерная сцена ДК г. Кольчугино
Кто:	Народный театр (ЦКМПиТ г. Кольчугино, Владимирская область), режиссёры Александр Рыжов и Александр Жулин
Что:	Николай Лесков "Чудотворец" история одной московской фамилии

Спектакль АКТ за год успел взять немало наград. И на этот раз отличился:
* Диплом лауреата 3-ей степени - спектакль "Чудотворец",
* Лучшая женская роль второго плана - Ольга Кириллова за роль Тётушки.

Дата:	13 февраля 2021г.
Время:	10:30
Где:	большой зал ДК г. Кольчугино
Кто:	"Думнов-ТЕАТР" (г. Владимир), режиссёры Яков Рубин и Евгений Думнов
Что:	Андрей Платонов "В прекрасном и яростном мире"

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

Дата:	13 февраля 2021г.
Время:	11:45
Где:	фойе ДК г. Кольчугино
Кто:	жюри Антон Вячеславович Карташов
Что:	тренинг по актёрскому мастерству

Час профессионализма заслуживает отдельной статьи. Здесь скажу лишь только, что пропустившие это мероприятие начинающие актёры сильно пожалели.

Дата:	13 февраля 2021г.
Время:	15:15
Где:	малый зал ДК г. Кольчугино
Кто:	Молодёжный театр "КРУГ-2" им. Е. П. Ступаковой (г. Краснознаменск, Московская область), режиссёры Станислав Дмитриев и Александр Ровенский
Что:	Эдвард Олби "Что случилось в зоопарке?"

Соцдистанция железная,
По-собачьи житиё...
Постоянные участники фестиваля из Краснознаменска привезли не какую-то новую постановку, а спектакль, который отточен за десять лет и мне удалось видеть его в рамках фестиваля "Взмах крыла - 2015" в Жаворонках. Но тем не менее актуальность соцдистанции прозвучала как нельзя кстати в этот год эпидемии. Наработанный профессионализм актёров заслужил диплом:
* Лучший актёрский дуэт - Андрей Ведмецкий и Алексей Коваленко.

Дата:	13 февраля 2021г.
Время:	17:30
Где:	большой зал ДК г. Кольчугино
Кто:	Народный коллектив театрального искусства "Любительский театр 'Атмосфера'" (МАУК ГОЩ "Центральный дворец культуры", г. Щёлково, Московская область), режиссёр Анастасия Гребенникова
Что:	Антон Чехов "Город N и его обитатели"

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

Дата:	13 февраля 2021г.
Время:	19:45
Где:	камерная сцена ДК г. Кольчугино
Кто:	Образцовый театр юного зрителя Ассоциации Кольчугинских Театров (г. Кольчугино, Владимирская область), режиссёр Александр Рыжов
Что:	Рэй Брэдбери "Всякое бывает" истории о любви

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

Дата:	14 февраля 2021г.
Время:	10:30
Где:	большой зал ДК г. Кольчугино
Кто:	Заслуженный коллектив народного творчества народный театр "Левый берег" (г. Тутаев, Ярославская область), режиссёр Светлана Асафьева
Что:	Олег Богаев "Марьино поле"

Левый берег,
Поле Марьи,
На троих старух один
Воин славный,
Рог обломан,
Патриоток полон двор.
Отличная постановка сказочных снов вызывала у зрителей и смех и слёзы, а получила от очень строго жюри только один диплом:
* Лучший актерский ансамбль - спектакль "Марьино поле".

Дата:	14 февраля 2021г.
Время:	12:30
Где:	малый зал ДК г. Кольчугино
Кто:	Театр "ЛУЧ" (ГОАУ ДО ЯО "Центр детей и юношества", г. Ярославль), режиссёр Наталия Баканова
Что:	Хуб Ульрих "У ковчега в восемь"

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

Дата:	14 февраля 2021г.
Время:	17:00
Где:	большой зал ДК г. Кольчугино
Кто:	"Учебный театр" Театрального института им. Б. Щукина при Государственном академическом театре им. Е. Вахтангова (г. Москва), курс В. П. Николаенко
Что:	триптих по классическим произведениям

Финал фестиваля от профессионалов - шикарное завершение театрального марафона. Спасибо будущим звёздам.