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

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

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

Пророчества

Иностранная литература о профессии тестировщика называет то, о чём хочу сегодня поговорить, - 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 и иные подобные) очень быстро наступают на пятки и даже в каком-то смысле обгоняют, привлекая к участию более глубоко практикующих специалистов.
В рамках профориентации эта статья скорее сослужит недобрую службу, поскольку показывает нашу профессию с самой неприятной стороны. Тестировщик одновременно должен и предугадать конец, и предложить несколько путей по минимизации провала. Но в любом случае вину за неудачи скинут на того, кто их "пророчил". Психологически быть тестировщиком - очень сложная задача. Постоянный риск комплекса "носителя плохих вестей", если вы добросовестный и ответственный работник, на мой взгляд минимизировать можно лишь двумя путями. Либо программисты перестанут плодить баги, тогда вы прекратите грустно отчитываться на стендапах об увеличенном потоке возвратов и регрессов. Либо вы станете пофигистом, тогда рост багов вас никак не будет задевать, но в этом случае вероятна потеря интереса к профессии. А если вы приучите свою психику радоваться чужим ошибкам, то никакой социум вас не подпустит к себе, поэтому сначала вы перейдёте в разряд интровертов, потом мизантропов и аутистов. Но к этому моменту вас лишат рабочего места в группе разработки, да и на аутсорсе одиночки-фрилансеры - явление редкостное. Так что, вовремя контролируйте свой внутренний конфликт отношения к чужим промахам. Не бойтесь обрисовать во всех чёрных красках плохой конец, но при этом подготовьте и "рояль в кустах", и "туза в рукаве" в виде альтернативных путей по достижению цели постановщика задачи и в качестве отходных манёвров при приближении к пропасти. Не скрывайте свои способности пророка, развивайте интуицию, если в ваших планах восхождение по карьерной лестнице. Нет, мы - тестировщики - не прорицатели, но картину будущего продукта можем обрисовать в сочных (чаще тёмных) красках.

Вижу = понимаю

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

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

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

Но для иностранных произведений видео-книга стала бы лучшим решением, как сегодняшние аудио-книги и экрано-озвучки для слабовидящих. Как вы думаете, почему у японцев так сильно развилось такое творчество, как комиксы? Им некогда вчитываться в текст книг, потому что много работают. А пролистав картинки, они успевают отвлечься от производственных мыслей за несколько минут, вместо нас, отдающих от получаса перед сном грамотному тексту.

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

Взгляд назад

Ретроспективу тестировщики обычно проводят совместно со всей командой, но дата наших подведений итогов возможна намного позже выпуска, поскольку результат нашей работы виден лишь в долгосрочной перспективе. Отсутствие жалоб пользователей или благодарность за вовремя и в точности выполненные изменения - это положительный результат действий QA и его оценивают обычно на контрасте. Руководители проектов чаще не желают замечать тех ежедневных титанических усилий защитников качества, которые приводят к успеху продукта, а приписывают его только себе. Наши частые просьбы подправить мелкие баги в общей корзине изменений приводят к лоску всего продукта. Кто из ваших лидов отмечал эти капли на фоне моря бэклога во время ретроспективы? QA вполне могут приплюсовывать такие неприметные шажки к кампании по профилактике проблем.
Две-три недели изоляции достаточно для проведения первой ретроспективы. Но для полноценной оценки стоит учитывать не только предпринятые меры в учётный период. На примере современного общества можно увидеть, что государственное здравоохранение, организованное Н. Семашко, именно сейчас дало положительный эффект - спокойствие и государственную защищённость граждан. Страны, нацеленные на быстрый доход, не стремящиеся к долгосрочным перспективам (аналогия со стартаперами), только в текущей критичной ситуации заметили свою несостоятельность. Это яркий пример необходимости проводить регулярную профилактику вместо надежды на единственного супергероя, который в очередной раз вставит "костыль". Ещё одним положительным шагом, сыгравшим свою роль в условиях удалённой работы на дому, считаю проект Д. Медведева "Последняя миля". Как сто лет назад Ленин продвигал освещение по всей стране, так и в начале этого века нас покрыли RUNET-ом. Благодаря такому далеко-сведущему движению мы не только сейчас своевременно проинформированы обо всём, но можем продолжать обучение и трудовую деятельность. В рамках ретроспективы стоит сказать "спасибо" за столь важную предусмотрительность. А ваши тимлиды отмечают на подведении итогов роль примечаний и идей QA?
Наш соратник, бывший IT-шник, хотя врядли в наш инфо-век мы успеем стать "бывшими", М. Мишустин своевременно способствовал цифровизации налогообложения, а теперь, отменив в этом году перепись населения, надеюсь и её переведёт в режим фактов, не давая повода всяким фрикам хайпануть за государственный счёт. Хорошо помню свою волонтёрскую деятельность конца советского периода, когда летними вечерами приходилось обходить квартал за кварталом близлежащих к школе домов и переписывать всех детей, чтобы школа смогла вовремя составить расписание и подобрать пед.состав на одну или две-три смены. Тогда не было возможности обменяться базами данных ЗАГСу, паспортному столу и школам, даже тетрадку и ручку нам никто не выдавал. А сегодня тратятся немалые средства на оборудование (планшеты, канцелярия, удостоверения, реклама) и зарплату опрашивателей. Ведь эти все деньги и материалы вполне себе могли бы сослужить более выгодно: планшеты очень нужны школьникам для удалённого обучения, за меньшие деньги любое бюро разработки ПО быстро напишет связь всех нужных баз данных. Цифровизация переписи населения - это не только единоразовая экономия, это долгосрочное ПО, которым можно будет пользоваться хоть ежегодно, хоть ежедневно. Аналитики всех слоёв выгадают от этого, а у рядовых граждан не будет повода выдумывать всякую всячину взамен реальных имён, национальностей и прочих житейских параметров. Тут, как нельзя лучше, подходят обе поговорки "не было бы счастья, так несчастье помогло" и "всё, что не делается - к лучшему". Надеюсь, отменённая в этом году перепись населения перейдёт в разряд госзаказа на ПО, тем самым даст нам, тестировщикам-интеграторам, больше работы.
Ещё один правильный шаг делает правительство - повсеместно строит больничные комплексы. Это достаточно умно, если учесть, что сейчас семьи много времени проводят вместе, а государство объявило о поощрении роста демографии. Хочу натолкнуть вас на мысль, что эти больницы к концу года будут весьма востребованы в качестве перинатальных центров. QA, а вы умеете предложить такой костыль в критичных условиях, который лёгким движением превращается в солидное новшество? Помните, для плодотворной работы тестировщик обязан обладать многоходовым разумом шахматиста.
Ограничения на поездки переводят нас повсеместно в ранг пешеходов, многие из которых возможно спровоцируют очередной общегосударственный проект "Дорога к дому", в рамках которого главы поселений почувствуют на своих подошвах изношенность или отсутствие тротуаров, их затемнённость или узость. Надеюсь, местным властям, предпринимателям и жителям в рамках такой национальной программы удастся реставрировать устаревшие дорожки, проложить новые с полным соблюдением дистанции, обустроить зоны для велосипедистов, роллеров и иных мелко-колесящих участников движения. Хочется верить, что проект "Дорога к дому" на законодательном уровне закрепит героскутеры, скейтборды, самокаты и ролики, как средства передвижения по выделенным полосам тротуаров и пешеходных дорожек. Любое сужение рамок в творческом уме тестировщика порождает выгодные решения.
В рамках кризисного периода главы местного самоуправления получили больше полномочий, но почему-то не всюду торопятся ими воспользоваться на благо своих жителей. Например, каждый многоквартирный дом имеет придомовую территорию, но жители заперты в квартирах. А ведь старшие по дому и подъезду вполне могли бы составить плавающий график прогулок в пределах двора с предварительной санобработкой. Это же не так сложно - родителям части квартир за 10-15 минут пересменки до своей прогулки опрыскать детскую площадку антисептиками, а на последующие 45 минут вывести своих чад под присмотром и в соответствующем времени обмундировании (маска, перчатки).  Даже если в доме 100-200 квартир, то удлинившийся световой день вполне достаточен для того, чтоб на игровой площадке поочерёдно побывали хотя бы полчаса ежедневно все проживающие дети. Ребёнку нужен свежий воздух, физическая нагрузка, а не всякие жилые строения способны выдержать нагрузку прыгающих и бегающих непосед, да и стране более важны здоровые, а не хилые граждане. Если вам дали чуть больше воли, то используйте её на благо окружающих и тогда профит от неё подмигнёт звёздочкой на плече.
А. Рыжов хайпует постановками секс-шоу на старшеклассниках вместо воспитания в них культурного поколения. Запреты молодым актёрам на полное прочтение и просмотр оригинальных источников приводят к тому, что спектакли ТЮЗа из раза в раз отображают только комплексы режиссёра, а не истинные проблемы автора произведения и современного поколения. Театр - искусство массовое, несущее разум и воспитание. Также, как и при разработке ПО, постановка спектаклей вынуждена учитывать желания потребителей, изначально взятый курс стоит не только корректировать согласно современным течениям, но и забрасывать удочку на перспективу - развивать общество. А ваша команда на ретроспективе какие уроки пройденного периода усваивает и вырабатывает ли новые цели?
НТВ посылает московских репортёров в поля, не тронутые короновирусом, вместо расширения полномочий местных сотрудников и предотвращения распространения заразы, ведь привезти микробы они вполне могут на аппаратуре. Микрофоны как дезинфицируют? Концерт в Большом Театре показал отношение артистов к своему производственному предмету: клавиши рояля протирали перед каждым выступлением, О. Газманов держал микрофон в перчатках. Вещание круглосуточного новостного канала "Россия 24" перебазировалось в домашние условия, а НТВ по-прежнему собирает звёзд на тесных диванчиках, стратегически-важные каналы "Первый" и "Россия 1" в большинстве прямых эфиров и ток-шоу соблюдают социальную дистанцию, а НТВ зрителей и участников передач плотно набивает в зал без санитарных масок. Как представитель QA предупреждаю общественность, что телевещательный канал своим примером исключительности опасен в дни пандемии из-за несоблюдения санитарных правил. Не удивительно, что некоторые жители не соблюдают самоизоляцию, поскольку они берут пример со своих "любимых" телеканалов. История любых времён докажет вам, что в достижении успеха практика двойных стандартов никогда не являлась помощником, а только усугубляла процесс деградации.
За одну-две недели удалённой работы любой оценит важность соблюдения общепринятых правил и особенно распорядка дня, при чём не только средним звеном, но и высшим. Древняя наука - педагогика - практикует закон "пример заразителен", да и своё название взяла из фразы "веду за собой". Если руководитель желает сплотить коллектив и воспитать его в лучшем виде, то должен начать с себя, показать положительный пример на своём поведении и постоянно его придерживаться. Тайм-менеджмент нарушается начальником, считающим себя всегда исключением и не уважающим рабочее время своих сотрудников. В таких случаях я ратую за лозунг: "Чаты вместо звонков!" Профессионалы-тестировщики даже могут обучать искусству задавать краткие, конкретные, однозначные вопросы, которые способствуют эффективности в производстве и взаимоотношениях. Довольно многих раздражают голосовые сообщения из-за слов-паразитов, отнимающих драгоценное время. А при печатании текста ни их, ни мат уже не вставить. Боитесь, что затеряется ответ? Используйте напоминалки и цитирование в чатах. Любители поболтать, экономьте время ваших секретарш, которым всё-равно придётся переводить звук в печатный текст, ставьте задачи и вопросы сразу в письменном виде.

Полагаю, на этих нескольких примерах стали более очевидны принципы ретроспективы:
- выявить положительные и негативные действия как всей команды, так и отдельных её членов;
- дать оценку последствиям шагов обеих (+/-) сторон;
- выяснить причины успехов и провалов для выработки общих правил;
-  определить вектор развития.
Желаю, чтобы совещания в конце спринта стали более эффективными за счёт вышеизложенной памятки.

ТО о SD 5.1.1.239

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

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

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

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

Чудотворец

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

Высечено из под воска

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

Вот такие чудо-секреты мне удалось выявить за мои 15 театральных сезонов в АКТ.

Аналитики для тестировщиков

Список прямых ссылок и лично моё мнение о каждом докладе на конференции Analyst Days 10, проходившей 24-25 мая 2019 года в Санкт-Петербурге.
Зачем такой список? Мне лично не удобно долго смотреть доклады с сайта конференций или по плей-листу youtube. Поскольку мне часто хочется поделиться своими новыми знаниями, то потенциальным читателям облегчаю задачу поиска и запуска конкретного контента. А также мой список всегда имеет аннотации для конкретизации тематики.
Да, программа конфы красиво сгруппирована и есть инфа, по которой можно определить рекламные или заказные доклады, но для меня становятся лишними клики для открытия страницы с подробным контекстом каждого доклада. Составив себе список только из наименований докладов без имён компаний и рассказчиков моё внимание фокусируется лишь на смысле излагаемого материала. А плей-лист портала видеозаписей маловат при скроллинге, его нельзя отсортировать под себя и нет отметок об уже просмотренном. Некоторые откроешь, но для полного просмотра откладываешь, поэтому смена цвета линка в этом случае не помогает. Вот если бы указывался процент моего просмотра, то такой индикатор был бы более полезен.
Раньше площадкой для хранения видео был портал vimeo, но и его проигрыватель сильно перекрывался огромной плашкой куков.
К организаторам конфы, а точнее к тех.группе записи, сложились предложения:
* либо вообще не включать в запись блок вопросы-ответы, либо вопросы записывать в такой же микрофон, как и у докладчика. Потому что ответ без вопроса звучит глупо, непонятно, лишне и тому подобное;
* видео с докладчиком выводить в экран меньшего размера для улучшения восприятия. Нерационально использовать половину экрана на пустоту за телом докладчика, а слайды уменьшать до их нечитабельности;
* мастер-классы и доклады с досками, заполняемыми в режиме реального времени, сопроводить дополнительной видеокамерой, направленной на сам флипчарт для увеличения всем;
* звук из мастер-классов записывать через микрофоны, распараллеленные с ведущим.
Да, понимаю боль организатора - билеты на конференцию плохо покупают, а бесплатная публикация записей не несёт дохода. Но если записи станут удовлетворять вышеописанному, а также будут иметь лёгкую аннотацию от присутствовавших (=реклама из первых рук), то за просмотры можно будет брать ощутимую плату. 20-ю конференцию тестировщиков пытались продавать, но если бы вместо одного и того же ролика каждую запись предварял отзыв от побывавших (аннотация и отзыв бесплатно, а полная запись за плату), то организаторы собрали бы хороший куш.
Слабая наполненность залов и заверения (Никита Макаров про тестирование и конференции  с "01:05:52 - Про гайзенбаг" и далее) организаторов параллельной конференции Heisenbug  навело на мысль, что Analyst Days и SQA Days стоит объединить в одну, но расширить третьим течением - привлечь программистов, разработчиков, архитекторов. Тогда три потока (аналитик, программист и тестировщик) пересекутся в зоне BarCamp, их работодатель сэкономит на билетах, а конференция поднимется в статусе за счёт глобальности.

Мой список сгруппирован по приоритету для тестировщика (по-жизни я из числа критиков и оценщиков качества), но не отсортирован по порядку важности (мой просмотр получился в такой очереди, обусловленной наименованием каждого доклада).


полезное:
Байки из Банка. Как нам помогли пользовательские истории - о влиянии метода на весь процесс разработки
Единый язык проекта - два документа, которые должны быть изначально, словарь терминов (продуктовый, внутрикомандный) и диаграмма сущностей продукта
Погружение в новую предметную область, чек-лист аналитика - универсальный список дел для любой должности (аналитик, программист, тестировщик) + пункт о % выполненности + причины задержки
«Пиши-упрощай»: как сделать требования легкими для восприятия? - в помощь issue review
Трассировка: лучшие практики - реальные советы-напоминалки к шагам issue review
4 правила археолога: как «раскопать» систему - легаси, зачем первейший документ - структура проги, визуализация кода = карта (плохо слышно)
Фасилитация рабочих встреч: творчески и результативно - не подготовленное совещание не обеспечивает комфортного обсуждения (неожиданное прерывание текущей работы, недостаточность информации о материале дискуссии)
Все лгут. Живите с этим - техники практической психологии применимы тестировщиком на стадии планирования
Сценарии неэффективного использования ресурсов аналитика - что на кого спихнуть и когда
Игра в разработку. Опыт оценки профессиональных качеств аналитика - аттестация для доверия, статуса, планирования (не используемых в CSS), можно подменить покер-разработкой
Роль бизнес аналитика в решении нестандартных задач на сложных проектах - алгоритм решения проблем
Система мониторинга: продвинутый набор технических метрик или панорама успеха? - приятно слушать понятную речь о собственно изобретённом методе сбора и обработки информации
Самопредставление - мастеркласс от актёра в год театра для работников с первоочередной надобностью - общение и написание текстов (правильных, интересных, читабельных = по законам драмматургии)
Антикризисный аналитик: как подхватить проект и не надорваться - не так весело, как у Дорофеева про прокрастинацию, но также полезно и разложено по полочкам
Как мы оцениваем и развиваем больше сотни аналитиков - больше о том, как выбрать область развития в конкретной компании, есть подсказки надобности по ролям
Ценность ясности цели - про типы оппонентов и как их раскручивать
Кто и как на самом деле пользуется системой: от догадок к цифрам - как собрать и применять стат.данные о пользователях web-приложения
UX дашборда мечты. Как превратить хаотичные данные в один красивый динамичный экран - о правилах построения отчётов для верхнего звена
Учимся играть в бизнес-анализ - коротко о необходимости игры, но забыта обучающая роль
Учимся играть в бизнес-анализ (мастер-класс) - визуализация с подробными пояснениями, обучение от хорошо подготовленной лекторши; более пол-записи - самостоятельная работа в группах - не попал звук в ролик = бесполезный просмотр записи
Тактические приемы при работе с субподрядчиками - об одном успехе одной команды (что помогло, без перечисления помех)
Проверка гипотез требований к функциям и UX/UI с помощью Customer Journey Map. Рабочий кейс - альтернатива сочетанию методик демка+ретро
Свой DSL на проекте: когда и как - шаги по созданию своего и под себя не фреймворка, а намного глубже - целого языка, который ускорил написание кода и выявление багов (на уровне аналитика и кода)
Чек-лист для описания требований к интеграции - в помощь при тест-дизайне интеграции
TM Forum API: что, зачем и почему - телеменеджмент правила про стандарты
Ограниченность как источник вдохновения. Проектирование систем на базе идей инклюзивного дизайна - составление данных для тестов доступности
Дневник аналитика или как не стоит писать на gherkin - забавно о соблюдении правил
Заповедная зона – где продукт живет в мире с госзаказом - эмоционально о подводных камнях приоритетности качества в том числе
Работа аналитика в медицинской компании - тестировщику, идущему в мед.сферу, есть из чего дизайнить тесты


ну, послушайте...:
Зачем вам ПО. Драма в трех частях - нет 3 частей, нет драмы, но множество пунктов для общения с заказчиком
10 советов по организации удалённой работы аналитика - не затронуты технические и экономические стороны
Управление временем для аналитика - балабол
Управление требованиями в работе с удаленной командой - не столько специфичность управления требованиями, сколько общие подсказки по удалённой работе в области инструментов
Выбираем качество требований - забыто время доставки, как часть качества
IT Дирижер - слишком заумно и книжно
Единым махом семерых побивахом! или почему нельзя создать единственный понятный документ для всех - не 7, а только 3 типа доков; коучер, а голос дрожит как у дебютантки; чит-лист параметров для ума писателя доки
Эволюция процесса разработки продукта: роль аналитика - от аналитика к владельцу продукта
Путь из Бизнес-заказчиков во Владельцы продукта - как нашли или переименовали "козлов отпущения"
Визуализация данных - просто и наглядно - мисс-очевидность про место uml в техзадании
Нестандартный подход к разработке через тестирование. Практический кейс - реклама своего продукта, написанного для внутренних нужд
Как управлять аналитиками? - сплошная теория от любительницы поболтать бессвязно
Аналитическая орда. Как захватить "Козельск" стейкхолдера без потерь! - о необходимости распределить роли, планировании и строгом соблюдении правил в резко выросшей команде для идеального agile
Передача знаний: быстро, весело, полезно - на примере эстафеты, при смене сотрудника, структуризация подготовки и самого трансфера по законам педагогики
Аналитик 2.0. Как информация, которой владеет аналитик, влияет на мотивацию в команде - куда бежать, когда уже и так всё хорошо
УПРАВЛЕНИЕ. ЛИДЕРСТВО. ПАРТНЕРСТВО - о результатах опроса
Оценка соответствия модели основных бизнес-процессов стратегии компании - теория экономики стартапа
Влияние аналитиков на развитие компании - аналитики отвоевали своё место
Нерешенные вопросы в бизнес-анализе - нудный искатель серебряной пули
Сторителлинг в бизнес коммуникациях (командостроение, продвижение, переговоры, продажи). Сторибанки - неподготовленный лектор постоянно мычит и скачет с темы на тему, попытки отвечать на неслышимые вопросы
Сторителлинг (мастер-класс) - разговоры участников еле-слышны, поэтому сложно уловить смысл и важные моменты мастер-класса, сплошные недомолвки
Use Case VS User Story. Выбираем подход к специфицированию требований - скучно, нудный "учитель"
Мы строили, строили и наконец построили или краткая история эволюции интеграционного сервиса - весьма специфичен для аналитиков
Декомпозиция системы или "ну пусть это будет подсистема интеграции..." - весьма специфичен для аналитиков, теоритезировано
Практика архитектурного проектирования ИТ решений - яркий пример спешившего на конфу "учителя" - избыточность инфы на слайдах, опечатки, нудность голоса
Интеграция и пустота. Заглядываем внутрь моков - более для тестировщиков, но сказка не к месту
Опыт управления изменениями с помощью формирования концепции - специфичная хеппи-стори отдела аналитиков
Особенности сбора требований в Data Science-проектах - теоритезировано сугубо для аналитиков
Роль аналитика в Data Governance - специфично для сообществ аналитиков
Общебанковский модельный репозиторий - прикручивание графического приложения к нуждам архитектора
Автоматизация бизнес-процессов в строительстве - реклама собственного продукта
Archimate — швейцарский нож аналитика - об инструменте для рисования диаграмм


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