Ёлка-самороска

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

Вариант 1
Из пластика или иного композитного материала (листы картона или ДВП из строительных магазинов не достаточно прочные и гибкие для нашего проекта, поэтому выгоднее склеить полотно из газет, офисной бумаги или тонкой ткани. Клей должен быть не силикатный, лучше ПВА, чтоб плоскость спирали не быстро ломалась, а имела пластичность и гибкость. Последующий ремонт сгибов тоже не будет дорогим. Поскольку папье-маше подразумевает сплошное проникновение склеиваемых материалов, то строительный ПВА-м вполне можно разбавить водой двойной или даже тройной пропорцией) толщиной не более 0.5см вырезаем спирали (сначала можно сделать спираль шириной ленты 1см и затем разрезать её вдоль ленты пополам). Исходный квадрат 100х100см даст две спирали с шириной ленты 5см.
Макет из бумаги в масштабе 1:10.

При растяжении плоской спирали в объёмный конус получится высота около 200см. Если оставить ширину ленты 10см, то высота ёлки уменьшится до 150 см. При необходимости нанесите краску на спирали. Спираль обвязываем крючком толстыми зелёными (или белыми для новогодней сказки) нитками либо хозяйственным шнуром. Объём материала для вязания зависит от плотности вязания. Обвязка начинается снизу, от верхушки через все слои сверху-вниз и наверх провязываются связующие рёбра. Верхушка ёлки поднимается за хвост ниток.
Макет из бутылочного пластика обвязан нитками Флокс. Исходный размер полотна: длина - 125мм, ширина - 90мм, толщина - 0.3мм.

Спираль нарезана шириной 5мм, получилось около 10 оборотов. Без направляющих в расправленном состоянии спираль искривляется и на 3-4 ступеньке снизу сбивается форма конуса. Достаточно двух направляющих, которые крепятся к готовой спирали в развёрнутом виде. Максимально оптимальная высота расправленной спирали получается около 270мм.
В сложенном состоянии на сцене такой бугорок может означать полянку, газон. Спираль обвязана ниткой толщиной 1мм и в сложенном состоянии получается высота 10-15мм, а высота бугорка на сцене зависит от толщины нити и полотна.

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

Вариант 2
Из такого же полотна вырезаем кольца шириной на ваше усмотрение. Минимальный (верхний) слой дерева будет кругом. Количество колец получается от 5 до 10, но все будут задействованы только в одном изделии. Красим и обвязываем каждое кольцо и верхний круг в зелёный или белый цвет. Как и в предыдущем варианте провязываем вертикальные сцепления через внешние (для полноты дерева можно и через внутренние) петли кольца.

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

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

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

Вариант 4

Для колец используем жёсткую проволоку. Для сценического реквизита хорошо подходит двужильный или трёхжильный алюминиевый провод в изоляции, либо медный толстый. Если изоляция подходящего цвета (белая для зимних ёлок, зелёная для летних), то просто сворачиваем отмеренную длину (расчёт основываем на формуле L=2пR) для каждого уровня дерева. На нижнюю окружность в 1 метр ширины потребуется 3 (+10см на сцепление) метра провода, для верхней в 10 см ширины - 30см (+5см на сцепление) провода. На все пять этажей: 3.5м + 2.75 + 2м + 1.25м + 0.5м = 10м провода. Отмеряем двойную высоту изделия вязальных ниток или хозяйственного шнура соответствующего цвета. Отступив 10-15см от края нити делаем узел на первом слое колец, потом с шагом 15-20см привязываем нить к каждому последующему этажу. От середины нити к её второму концу узлы вяжем с одинаковой пропорцией, но в обратном порядке этажей. Для крепости конструкции понадобится от двух до шести пар. Распределяем узлы на каждом этаже колец равномерно, симметрично центра окружностей. 

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

Вариант 5
Аналогично предыдущему варианту делаем две-три ёлки, но каждая по диаметру колец и количеству этажей на 10-20 см меньше. Вкладываем их друг в дружку, как матрёшку. Можно соединить кольца каждого уровня поперечными нитями. Декор крепить только на внешнюю окружность.

Преимущества вышеописанной декорации:

- мобильность и лёгкость при транспортировке, что часто требуется для участвующих во многих фестивалях театров;

- двойное предназначение реквизита (полянка-дерево);

- чудо происходит на глазах у зрителей;

- дешевизна материалов и производства.

Offside outsourcer

Бесправие голосового найма

(примеры обходных схем)

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

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

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

How to ask

Алгоритм тестировщика для задавания вопроса программисту

Шаг 1
Сформулируйте (на бумаге или в уме) вопрос так, чтобы ответ на него был однозначным: да/нет или пронумеруйте варианты.
Для практического закрепления возьмём "Пример 5" из статьи "Практикум корректности". Варианты главного вопроса:
- Надо ли учитывать размер всех вложенных папок и файлов при подсчёте размера отчёта?
- Что должно входить в размер отчёта:
a) размер файла "[НаименованиеОтчётаПроекта]_timestamp.html";
b) размер файла "[НаименованиеОтчётаПроекта]_timestamp.html" плюс объём файлов в иерархичных папках "[НаименованиеОтчётаПроекта]_timestamp";
c) раздельно две величины - размер головного файла и размер файлов в папке документа;
d) иной вариант (переименовать колонку).
Если самостоятельно не можете выбрать, то
Шаг 2
Там же (на бумаге или в уме) обрисуйте ситуацию в деталях: продукт, условия (система, настройки, данные), произведённые действия.
В рамках практики: продукт - "ClearSQL" последней версии, модуль - "Project Report Assistant", закладка - "Report History", колонка- "Report File Size".
Если собственные мысли не сложились в ответ, то
Шаг 3
Поищите подобные ситуации в литературе и публикациях по теме продукта. Изучайте буквари - это Ваше развитие, укрепление профессионального мнения и подтверждение трудоспособности.
Повысить свою компетентность можно заглянув в аналогичные списки иных продуктов. docuVIEWER на закладке со списком доступных для просмотра документов показывает общий объём файлов в колонке "Docu Size".
Если совокупность знаний всё ещё вызывает сомнения, то
Шаг 4
В списке сотрудников и их компетенций выбираем наиболее подходящего по Вашему мнению специалиста. Чаще всего им оказывается программист, на которого была возложена тестируемая задача для кодирования.
Если нет списка компетенций или в списке не нашлось подходящего соответствия по теме вопроса, то
Шаг 5
Выберите главного или старейшего программиста/начальника.
В команде Gitt для этого существует "ответственный за фичу".
Шаг 6
Запишитесь на приём или дождитесь, когда внимание программиста оторвётся от кода.
Из собственной практики:
- когда у меня был соседний/проходной с программистами кабинет (не видели друг друга, но всё слышали), то достаточно было дождаться момента, когда обсуждение кода перерастало в бытовые споры. Переключить болтовню с нерабочей темы на профессиональную - долг трудоголика, так что смело шагайте и вливайтесь в беседу;
- когда офис объединял в одном помещении и программистов и тестировщика, то разворот от своего монитора в сторону разработчика через несколько секунд давал положительную реакцию и готовность общаться;
- в случае раздельных помещений и распределённой команды в личном чате публиковался главный вопрос или из "Шага 7".
Шаг 7
Обратитесь  с первым вопросом так, чтобы ответ был только положительным. Это чистая практическая психология, налаживающая позитивное общение.
Пример вопроса, повышающего авторитет программиста: "Можете помочь тупому тестировщику?"
Шаг 8
Переключите мысли отвечающего на тему основного вопроса:
- Ты же работал с продуктом "Х"?
- Знаешь о существовании модуля "У"?
- У меня тест проходил при условиях "Z" и получилось "Бла-Бла-Бла".
Задайте основной свой вопрос (см. "Шаг 1"), например, "Это баговое поведение?".
Шаг 9
Получите однозначный ответ или уточняющие вопросы, для ответа на которые помогут "Шаг 2" и "Шаг 3".
На этом этапе у программиста есть возможность отыграться за все пятёрки "Зачем?", заданные вами ранее и упущенные на этапе планирования.
Шаг 10
Поблагодарите за потраченное на Вас время и упомяните консультанта в задаче (если ответ о новом баге был положительным, то в новооформленной, иначе в тестируемой). Ссылка в описании или комментариях бага на разработчика защитит Вас от разбирательств при выяснении корректности задачи. Во многих командах планирование новых задач основывается на залогированном времени выпущенных фич, поэтому обе стороны диалога должны добавить затраченные на обсуждение минуты в одну и ту же задачу.

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

Учтите, что отвлекая сотрудника на две минуты подготовленного разговора Вы крадёте у него от четверти до получаса мыслительной деятельности. Поэтому предпочитаю пользоваться отложенными сообщениями в чате, а не созвонами или болтовнёй вживую.
Из личного опыта:
- диалог в одной комнате затягивается до получаса и перескакивает на отвлечённые темы;
- через Skype, TeamViewer вопрос решается за 20-50 минут, включая время установления стабильного соединения (слышимость, видимость монитора, запуск приложения для воспроизведения проблемы);
- через личные каналы чата решается от трёх до пяти вопросов за 20 минут переписки, поскольку алгоритм сокращается на шагах 1-8. Но такой вариант совсем не нравится заядлым стартаперам, которые собираются в команду не для производства продукта, а лишь пообсуждать новые гаджеты, автомобили или цветочки.

Старпёры стартаперства

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

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

Uncorrectly correction

Практикум корректности

Есть ряд слов и фраз, употребление которых в описании багов, в том числе и исправленных, не уместно. Эти слова могут быть восприняты пользователем продукта двояко. Сегодня покажу на конкретных примерах неоднозначность слова "корректно".
Для тестирования возьмём Release Notes для продукта ClearSQL 7.1.2.181.

Пример 1

Окно "Select Code Review Rules to Suppress Violations" можно открыть из области редактора кода через одноимённый пункт контекстного меню. Оно является дочерним только для редактора кода, но модальным для основного окна приложения. С точки зрения usability возможность сдвига вспомогательного окна и последующее его переоткрытие на том же самом месте - это удобство и очевидное ожидание пользователя. Но с программистской стороны имеется просчёт - позиция и размер дочернего окна не зависит от координат родительского. Если пользователь работает на нескольких мониторах, то рабочее пространство продукта не ограничивается координатами основного окна приложения, что часто приводит к проблемам при открытии приложения после отключения одного из мониторов: окно фактически открывается, но не доступно в видимой области активных экранов.
В предыдущей версии окно переоткрывалось центрировано по активному монитору, а размер устанавливался ни последний пользовательский, ни минимальный стандартный (интерфейсные приложения компании Conquest Software Solutions разрабатываются в Delphi и используют настройки по-умолчанию в среде разработки от Embarcadero), к тому же уменьшение размеров окна не имело предела.
Ошибками тех-писателя, составлявшего Release Notes, считаются:
- отнесение данного пункта к модулю "Code Analyzer Options", поскольку окно "Select Code Review Rules to Suppress Violations" является самостоятельным и всего лишь клоном части окна "Code Analyzer Options";
- употребление слова "restart" вместо "reopening", поскольку имеется ввиду переоткрытие окна, а не перезапуск приложения.
Таким образом пользователь остаётся в недоумении о "корректности" правки:
- впервые появившись в продукте окно открывалось каждый раз центрировано по основному окну приложения, поэтому новое позиционирование по координатам монитора может исказить ожидания пользователя;
- впервые появившись в продукте окно открывалось каждый раз одного и того же размера, установленного программистом, поэтому восстановление "пользовательского" размера при каждом переоткрытии окна может быть воспринято и как удобство, и как неожиданность;
- не уточнённое "restart" относительно переоткрытия окна или приложения вводит в заблуждение пользователя.
Если программист не счёл нужным ориентироваться в разработке новой фичи на чит-лист, то это действительно баг. А если первоначальное поведение было задумано разработчиком, то подобный пункт в Release Notes стоит оформлять улучшением интерфейса, а не багом.

Пример 2
 
Сразу в трёх пунктах блока Call Tree диаграмм использовано слово "корректно". Но, как и в предыдущем примере, правильность исправлений не может быть единственно объективной как для заказчика, так и для исполнителя, поскольку продукты в Conquest Software Solutions разрабатываются по методу Research&Develop, а общепринятых стандартов для отображения Call Tree никто не вводил.
Экспорт диаграмм не изменился по сравнению с предыдущей версией продукта, кроме излишнего формирования map-файла. Но об этом имеется отдельный пункт в Release Notes. Так что пункт об имени экспортируемого файла можно считать очковтирательством в списке исправленных багов. Но не будем столь строго относится к некомпетентному тех-писателю, а попросим разработчиков уточнить исправления. Возможно, что-то было подправлено для особых типов объектов или только в одном из множества типов экспорта. Ещё возможный вариант правки - иной тип диаграмм, а тех-писатель опечатался в имени блока Release Notes. Либо правка на самом деле была в пред-предыдущей версии, а про баг написали только в этот раз.
Во втором и третьем пунктах говорится о Call Tree диаграммах, автоматически открываемых из CRUD матриц по клику на имена связанных объектов. Согласно чит-листу для тестирования новой фичи приоритетными параметрами статуса, размера и позиции окна считаются пользовательские. То есть наиболее ожидаемое поведение - это когда окно открывается на том же месте и того же размера, каким оно было закрыто в текущей сессии приложения и после перезапуска приложения. А центрирование дочернего окна основывается на координатах родительского. Поэтому, если фикс о центрировании актуален лишь в случае показа всех объектов на одной лишь закладке CRUD2, то фикс статуса окна легенд слишком сомнителен. Дело в том, что CRUD1 матрицы формируются в разрезе скрипта и для Call Tree диаграмм разворачивается дополнительная панель, а не модальное окно. При этом о центрировании панели не может быть и речи, а легенда диаграммы Call Tree скорее всего переформировывается из-за включенной опции "Preferences / Project Analysis / Keep diagram/matrix local settings".

Пример 3
 
В предыдущих выпусках копирование диаграмм в память вообще не происходило, если Flowchart или Call Tree были сформированы в формате GIF. Поэтому приписка "correctly" в данном случае просто излишняя, ведь никаких стандартов по копированию картинок в память у ConquestSS нет, а дополнительные индикаторы операционной системы и оперативной памяти в приложение не встроены. 

Пример 4
 
В блоке Отчёта Проекта нашлось сразу два пункта с запрещённым словом.
Для подтверждения, а вернее доказательства от противного первого пункта сформируем проект с диаграммами в предыдущем билде и текущем. На основе диаграмм всех форматов сформируем отчёты аналогичных проектов в обеих версиях. Проверяя кликабельность из диаграмм в код в рамках отчётов, получаем возможность позиционирования кода из GIF, JPEG, PNG диаграмм в текст кода в рамках проекта из предыдущей версии продукта. А в текущей версии позиционирование перестало выполняться для перечисленных форматов, но стало благополучно выполняться для SVG формата. Так сказать "за уши притянуть" корректность к описанной правке фактически невозможно. Поэтому употребление недопустимого слова не только искажает смысл, а просто напросто противоречит элементарной логике как пользователя, так и разработчика.
Для второго пункта аналогично генерим отчёты, выбирая одинаковые параметры фильтров и группировки для данных на Summary страницах отчётов. Отметим, что параметры касаются только двух таблиц на Summary страницах отчёта всех уровней (проект/папка/скрипт). После сравнения отчётов получается, что раньше данные в таблице "Top Violated Code Review Rules" фильтровались по условию из интерфейса закладки "Project Analyzer Results / Summary", а в новой версии приложения группировка применяется из настроек Project Report Assistant, но никаких пометок в самом отчёте о применённой группировке нет. Так в чём же "корректность" правки? С таблицей "Code Metrics" дела обстоят немного лучше, так как в заголовке таблицы и ранее имелась информация о фактически применённых группировке и фильтрации. Но о корректности правки стоило говорить намного раньше, когда переименовали опцию "Project Report Assistant / New Report / Summary Options / Panels Size and Position / As in the Analyzer View Summary Page". Стоит напомнить, что группировка и фильтрация двух таблиц устанавливаются в трёх-пяти местах - в уже упомянутом окне Project Report Assistant и его аналоге для Job and Schedule Manager, на закладке "Project Analyzer Results / Summary" и дублируются в Preferences, на "Preferences (Job) / Export" странице настроек для автоматического экспорта. Какие из этих настроек стоит считать эталонными, какова территория их применения и отображения - ответы  на перечисленные вопросы не очевидны и их невозможно найти в Online Help продукта. Значит очередной пример подтверждает запрет на использование слова "correctly" в описании фиксов.

Пример 5
 
Хотя в примере и видны два пункта, но на самом деле они об одном и том же. Пользователю заметно лишь изменение в подсчёте объёма отчёта, но не одного файла, как это сказано, а всех составляющих html-документ. Вероятно программист изменил структуру хранения информации об отчётах, а тех-писатель не смог пояснить внутренних процессов. На самом деле вместо приписывания одного слова "correctly" необходимо было перефразировать баг в улучшение или хотя бы переименовать file в document для большей правдивости. Отсутствие достаточной коммуникации между тех-писателем и разработчиками, низкая квалификация и нежелание повышать уровень знаний замещаются шаблонной отпиской, которая оборачивается для пользователя непониманием и последующим недоверием к поставщику продукта.

Пример 6
 
Обновление дерева файловой системы после импорта визуально ничем не изменилось в новой версии. Возможно что-то было оптимизировано в алгоритме или коде. И чтобы скрыть отсутствие обмена информацией в команде разработки тех-писатель вынужден заполнять свои пробелы в знаниях пустословием.

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

Пример 8
 
Элементарный smoke-test не может показать произведённых изменений. Поэтому можно заключить, что фикс касается некоторого частного случая, для описания которого у специалистов не хватило профессионализма. В результате пользователь вполне имеет право считать, что никакого исправления не было.

Пример 9
 
Данный случай вполне обошёлся бы просто без слова "correctly". Поскольку активация окна не подразумевает вариаций. Или же разработчики компании Conquest Software Solutions ввели стандарт активации окна без предупреждений или подтверждений? Не очень похоже на них, так как в ClearSQL и других их продуктах очень много мест с излишними подтверждениями. Так почему же по их меркам в этом случае смена рабочей области происходит автоматически и без пользовательского согласия?

Пример 10
 
В этом примере к одному запрещённому слову добавили ещё и always, забыв постулат тестировщиков о порождении двух новых багов на основе одного фикса. Но это не удивительно, поскольку шеф группы разработки любит добавлять к описанию задачи фразу "исправить везде". Это следствие неумения и нежелания применять декомпозицию и конкретизировать планирование.
По существу правки. Можно ли считать правильным обрезание имени подпрограммы? В предыдущем билде имелась приставка из имени объектного типа, которая позволяла не теряться в списке подпрограмм таблицы Code Metrics, особенно на закладке Summary. Но половинчато всё же фикс был - overloaded подпрограммы теперь показываются с цифровым индексом, но без перечисления параметров. В чём корректность правки? Вопрос весьма не риторический.

Надеюсь, вышеописанные исследования доказали неуместность использования слова "correctly" в описании исправленных багов.