Поддержка IT-отрасли

Кто владеет информацией, тот владеет миром. Это аксиома современности. А технологии, собирающие и хранящие, анализирующие и обрабатывающие информацию, бессмысленны в случае ограниченности её потребителей.
Ну что толку в том, что вы один знаете таблицу умножения, если на рынке действует натуральный обмен без денежной прослойки? Зачем вам быстро считать монеты, если обмен происходит не в объёмном количестве, а по качественному признаку?
Или, например, зачем вам уметь читать или говорить на иностранном языке, если все закрылись у себя дома и не ездят в гости, не обмениваются новостями. Им всё равно, что происходит у вас, вам безразличны их достижения, потому что у вас всё по разному, уникально, точечно, логично и более приспособлено к собственной местности.
Развитие конкретики исходит из конкретных традиций. Да, по некоторым статьям в чём-то можно найти единообразие, допустим, появление радио. Но тот слой общества, который ставит превыше всего доходную составляющую, любую новинку стремится присвоить себе. С другой стороны, народы с широкой душой щедры не только хлебосольством, но и помыслами, мыслями, идеями. Россиянам не столь важен факт бюрократического подтверждения, сколь возможность поделиться способностями, возможностью помощи неимущим.
Одновременно общество, внедрившее юриспруденцию для защиты материальных интересов, к сегодняшнему дню устало соблюдать законы, которые они же сами и создали. Что это? Недальновидность в разработке законодательства? Ведь принятые к исполнению правила приходится соблюдать всем, даже тем, кто их придумал, а это вдруг стало невыгодно им самим. А может это психическая неуравновешенность? "Зачинатели демократии" вдруг перестали прислушиваться к мнению большинства, считая лишь себя исключением, элитой. Спешу напомнить исторические факты о тех, которые возомнив себя богом так и не добрались до солнца и заоблачных вершин.
И это тоже информация, которая была собрана историками для того, чтобы нашему поколению жилось легче, проще, а кому-то и выгоднее.
Какой-то век назвали "каменным", какой-то "железным". А текущий, наверно, назовут "информационным". Именно эти технологии сейчас правят миром. Начиная от газет и телевидения, учитывая базы данных всех горизонталей и вертикалей, присовокупить к этому списку фонды библиотек и архивов, а также не принижая значимость профсобраний, разговоров по душам в кафешке и подворотных слухов.
Информация сегодня - это дорогой продукт, особенно если он обёрнут в актуальную идею. Так к примеру слух, как сухой хворост для костра, разжигает ажиотаж вокруг какого-нибудь товара. Опечатка или оговорка в СМИ может исказить освещение события в точности наоборот. Искусственно подобранная статистика исказит стратегию и планирование. Киборги действительно поработят мир, если МОИРы (Мастера по Обучению Искусственного Разума) аккумулируют подобную задачу в автоматы.
Страшно. Но если предупреждён, то значит вооружён. А кто как ни радетель качества в состоянии предотвратить проблемы.
Да, я намекаю на нас - тестировщиков. Так нас называют в простонародье. Мы же себя именуем чаще инженерами по качеству. И государство в этом с 2014 года нас в этом поддерживает.
Но странны меры по поддержке отрасли. Они нацелены на молодых специалистов, которые не в состоянии поднять IT-производство на необходимый уровень из-за элементарного отсутствия опыта.
Не секрет, что в IT "войти" желают многие. Но не столько из-за интереса к профессии, сколько из низкого желания получать высокую оплату за кажущиеся на первый взгляд лёгкие работы. А сложностей в IT-профессиях предостаточно. Начиная от умения услышать заказчика и впоследствии убедить его, что он получил ровно то, что заказывал. На ком лежит ответственность за качество высокоточных приборов? Кто из создателей сложных систем спокойно спит, уверенный в работе их продукта без сбоев? Кто из кодировщиков хоть раз не отправлял программу заказчику с присказкой "авось пронесёт и юзер туда не полезет"? Разве что юниоры, не нюхавшие пороху. И на них надеется государство. Эти желторотики сделают прорыв? У меня за спиной несколько десятилетий стажа в IT-отрасли, глубокое знание внутренней "кухни" производства ПО, поэтому однозначно могу заявить, что эта молодая поросль скорее всего пойдёт по пути революций и сначала сотрёт, уничтожит всё до основания, а потом с нуля напишет ширпотреб, который моментально потеряет свою пригодность.
Полагаю, что предложения по господдержке формулировали эти самые юнцы, кто-то из депутатских сынков. Хочется спросить законодателей: почему у них не возникло мысли обратиться к тем, кто действительно знает все ступени создания и поддержки продуктов? Может они не знают, что мы есть? Почему "дедушка" российского качества молчит? Александр Александров, неужто ваша проактивность спит? Или вы не патриот?
Тем, кто действительно сейчас может принести пользу российским информационным технологиям, глубоко за 27 лет. И за счёт высокой оплаты у них нет жилищных проблем. А вот что действительно поможет поднять отрасль на должный уровень, так это ничего не стоит государству. О проблемах работы с госсектором говорено и обсуждено много в рамках конференций аналитиков и тестировщиков. Полный список докладов и капризов заказчиков доступен на сайтах "sqadays.com", "analystdays.ru" и в подборках Влада Орликова на портале "vimeo.com".
Почему российское ПО не пользуется спросом на мировом рынке? Сразу оговорю, альтернативы всем популярным порталам и мобильно-десктопным программам уже имеются. Их не надо создавать с нуля или придумывать нечто новое. Просто на международном рынке так заведено, что покупается ПО только с американским или европейским лицензированием. Запад приучил мир покупать только то, что юридически заверено.
К сожалению, приходится признать, что юридический сектор в России очень слаб. Нет, специалисты подкованы знаниями, но вот убеждать оппонента словом как-то не научились или не могут в силу широты души россейской. Наше добродушие и чистосердечность нас и губит. Бизнес и экономика никогда не будут добрыми, их прерогатива жёсткость, выгода, а порою и блеф до уровня лжи.
Чем действительно государство может помочь IT-сектору, так это прозрачностью и однозначностью законодательства. ПО и рацпредложения нуждаются в юридической поддержке, а не в обилии кодировщиков. Однозначность и единое понимание заказа и готового ПО, отсутствие несанкционированных запросов и изменений в техзадании являются источниками качественного продукта. Для этого нужны юридически подкованные специалисты каждой группе разработки. Дешевле снабдить компании юристами или обучить имеющихся аналитиков и внедренцев специализированным направлениям закона и права, чем раздавать всем айтишникам ипотеки и отсрочки от армии.
По-моему, если молодые специалисты пойдут в армию и там пройдут свои первые шаги в IT-отрасли, то это будет более эффективно для самого юниора и для всего производства в целом. Там его научат действительно работать, исполнять ровно то, что запрашивается, да и окружение уже служащих специалистов является наилучшей средой для передачи опыта.
В помощь информационным технологиям хорошо бы ускорить и упростить процедуру получения патента и лицензии. Но, чтобы они не стали фиктивными, их учёт должен быть прозрачным и доступным.
К сожалению, российский менталитет врядли когда-то допустит неукоснительное соблюдение всех законов и отстаивание прав через судебные инстанции вместо сегодняшнего землячества и родственных связей. Но всё равно, если Россия считается правовым государством, то всех жителей стоит приучать к этому с малолетства. Не знаю как это соединить с широкой душой, но в этом, думаю, помогут специалисты психологии. Может они сумеют без вреда нашему национальному менталитету, социально направленному, наложить на наши характеры неотвратимость соблюдения законов, нами же придуманных.
Нужна ли молодёжь в IT? С каждым годом всё меньше и меньше, потому что кодировщики и программисты скоро будут лишними, их заменят МОИРы. Даже тестировщиков можно будет отменить, если задания составлять так, чтобы все проверки проходили автоматически. А вот без аналитиков, постановщиков задач, внедренцев врядли когда-то сможем обойтись. Они как переводчики между людьми и машинами ещё долго будут нужны, как и яйцеклетки со сперматозоидами для продолжения и совершенствования рода человеческого.
Но вот вопрос: а что подразумевается под IT-отраслью? Только создание ПО или к информационным технологиям реально причисляют и СМИ, и всю электронную технику? Информацию распространяют Средства Массовой Информации: радио, телевидение, интернет каналы соцсетей и аудио-, видео-хостингов. Так значит господдержка должна распространяться и на блогеров, репортёров? А учителя и библиотекари разве не считаются распространителями информации? В их обязанности входит анализ и сортировка передаваемых в массы знаний. АСУТП-ишники, то есть электронщики, разве не считаются IT-ишниками? Абсолютно во всех сферах производства имеются должности так называемых "компьютерщиков", которые не создают, но поддерживают в рабочем состоянии уже внедрённые информационные технологии. Их тоже государство причисляет к тем, кому будет отсрочка от армии, ипотеки и низкие налоги? Не многовато ли категорий работников подпадает под IT-отрасль? Очевидно, что законодателям не хватает профессиональных тестировщиков документации, которые заранее выявят противоречивость, избыток и прочие недостатки требований. Ещё раз повторюсь, что всякому производству нужны профессионалы, а не дилетанты. Чтобы сразу после учебного заведения стать профессионалом нужна практика и передача ученикам актуальных знаний, либо максимально агрегированные базовые навыки.
Мой профессиональный взгляд на сегодняшнюю меру поддержки IT-отрасли однозначен: не эффективна для развития, а наоборот губительна. Покажу на примере. Допустим в какой-то группе разработки ПО возник форс-мажор - перед самым выпуском исчез (умер, уволился или ушёл в отпуск) работник, на котором держались основные задачи. Что в этом случае предпримет кадровик? Из любого безвыходного положения всегда есть три выхода, но тестировщик знает о трёх. Как QA предложу:
1) перепоручить работы имеющемуся персоналу, параллельно повышая его уровень курсами, то есть использовать внутренние резервы за счёт имеющихся, что является самым дешёвым вариантом (можно даже сэкономить на зарплатном фонде, добавив этому работнику лишь половину ставки ушедшего), но немного потратиться на дообучение, которое впоследствии принесёт ещё большую пользу. Никаких трат (денег и времени) в этом случае на введение стороннего члена команды не потребуется, стадия онбординга не замедлит разработку продукта и зарплатный фонд можно снизить, как и себестоимость продукта.
2) найти стороннего работника с аналогичным уровнем - задача для отдела кадров не только длительная, но и порой невыполнимая. Расходы на поиск и внедрение нового работника увеличат не только время разработки, но и себестоимость продукта. И ещё без какой-либо гарантии, что сотрудник подойдёт команде по уровню знаний, навыков и психологически.
3) взять на бирже труда пучок новичков, среди которых разделить все обязанности ушедшего. Новичков однозадачников набрать быстро, но каждому из них придётся выдавать полноценную зарплату, наше социальное государство не потерпит рабовладельчества. И не только поэтому считаю вариант наихудшим. Команда разработки страдает при добавлении одного новичка, а тут целая куча. Как бы это ни было странно, но любое дело замедляется по принципу геометрической прогрессии при добавлении рабочих рук и голов. Поговорка о двух головах, улучшающих одну, работает в противовес, потому что у каждого своя правда и каждая из рук, как лебедь, рак и щука тянут одеяло на себя, а не ровно в одну сторону к всеобщей цели. Если обязанности одного работника разделить на нескольких, то нет никакой гарантии, что один из этих новеньких в ответственный момент не станет тем же камнем преткновения, исчезнув из настроенного конвейера, и застопорит разработку.
Из этого примера вывод таков, что уже сейчас могу ответственно заявить, что выбранные меры поддержки IT-отрасли не помогут, а наоборот, скорее утопят её. Действенными же мерами были бы:
1) малограмотные дилетанты, не прошедшие опыт жизни в тесном коллективе, то есть отстранённые от службы в армии, никак не могут принести пользу. Это очевидно любому. Поэтому нужно повышать уровень знаний и приближать опыт на практических занятиях учебных заведений к актуальным реалиям. Для этого нужен прорыв в разрешённости и рекомендуемости учебных курсов и организаций. Для всех должностей в группе разработки в последние годы сформировалась предостаточная теоретическая база, это подтвердит наличие множества конференций и личных курсов, перешедших в высшие учебные заведения. Государству осталось помочь этим учебным заведениям формировать готовых специалистов, то есть обязать существующие производства стажировать студентов. А если задуматься о будущем, то нужно помочь составителям годичных планов этих курсов с актуализацией, то есть каждый год, а то и чаще, план обучения должен меняться. Технологии уходят вперёд, а абитуриентам приходится выбирать из курсов вчерашнего дня.
2) вместо налоговых и ипотечных льгот для весьма размытых по названию должностей повсеместная юридическая грамотность приведёт общество к привычке соблюдать законы. Если в обществе установлены и работают конкретные правила, то им просто управлять. Команды, строго придерживающиеся своих принятых правил, быстро достигают "бирюзового" уровня.
3) как одна из сторон юридической грамотности и для развития патриотизма уже имеющимся на рынке и только разрабатываемым продуктам нужна стабильная система лицензирования. Она поможет повысить доверие покупателей к продуктам и производителям, она защитит производителей от произвола пользователей.
Импортозамещение IT-отрасли в России, полагаю, должно пройти очень быстро, потому что наши создатели ПО по большей части составляли команды разработки всех популярных программ. При том, не только кодили (напомню: нашим программистам нет конкурентов на всех олимпиадах), но и знают изнутри эти системы, их связки и потенциальные уязвимости. Такая информация в головах теперь только наших специалистов недорого обойдётся государству, а прибыль может приносить обильную, когда начнёт конкурировать на мировом рынке.
И за это скажем спасибо санкциям. :) Русский мужик не перекрестится, пока гром не грянет. Но уж если возьмётся за дело, то супротив него некому выйти.

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

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

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

Ось ХОЧУ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

теле2-портация

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

Входные данные.
В телефоне-звонилке работает симка с тарифом только для звонков и сообщений (назовём её ТЗС=ТарифЗвонковСообщений), все услуги по выходу в Интернет отключены, да и сам аппарат не поддерживает выход в Сеть. Фирменный модем-свисток со специальным тарифом (назовём его ТИ=ТарифИнтернета) подключает к Интернету компьютер.
Проблема.
Рано утром меня разбудили пришедшие на ТЗС два сообщения: о подключенной услуге развлечений и тутже факт самой забавы. Это кто ж меня подключил во время сна? Подозревая неладное, открываю через ТИ личный кабинет ТЗС-а и обнаруживаю в блоке Расходы, что с меня сняли 15 рублей за выход в Интернет и 10 рублей за подписку развлечений. 

Провайдерские кражи

Как так? Без моего ведома кто-то распоряжается моими счетами? Да ещё в то время пока сплю! Какой-то нонсенс. При том, что аппарат лежит в соседней комнате, то есть довольно далеко от кровати спящего владельца.

Разбирательство и устранение проблем.
В блоке Услуг личного кабинета ТЗС-а обнаружена подключенная услуга развлечений, которую немедленно отключаю. Для поиска подробностей о том, кто и когда мог мне её подключить, а также о якобы выходе в Интернет делаю запрос Деталей Расходов. Но поскольку в такой отчёт включаются данные только с четырёхчасовой задержкой, то обнаруживаю лишь запись об Интернете. Какого же было моё удивление от времени якобы-связи: 00 часов 52 минуты текущих суток. Припоминаю, что примерно в это время был окончен сеанс Интернета, но не по ТЗС-у, а совсем по иной симке - ТИ. Да, вчера пользование телефонным аппаратом с ТЗС-а было завершено в 21:00, да и то, не связью, а лишь прослушиванием записей с карты памяти. В общем, к аппарату никто не прикасался более, никаких входящих или исходящих контактов не осуществлялось. Далее, то есть с 21:00, был включен комп для просмотра видео через связь по ТИ.

Кстати, если видеопроигрыватели на порталах поддерживают настройку "Качество=Низкое", а тариф интернета мерный, то за 10-14 часов просмотра видео без сторонних скачиваний (реклама, обновления системы и приложений) потратите лишь около двух гигабайт. Соглашусь, что перед сном лучше книжку почитать, а не в монитор глазеть, но наше поколение экран быстрее приводит в сонное состояние.

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

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

Ответы чат-бота

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

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

Льстивый возврат

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

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

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

Бесплатное подключение и использование, но не на всех тарифах

Решение задачи завершено. Ответ.

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

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

СУТ

Стратегия утилизационного тестирования ("сут" в переводе с казахского - молоко, если нет попаданий в цель, то это синоним аутов) в период кризиса выходит на первый план. Текущее время - самое подходящее для разворота направления работ отдела тестирования в сторону сворачивания бизнеса, помогая руководителю проекта оставить продукт пользователям в наилучшем состоянии для очистки совести ответственных за качество.
По результатам моих исследований нижеследующий чит-лист ни единожды спасал компанию от излишних расходов на поддержку производства после расторжения договоров.
1.  Изучить лицензионное соглашение юзера и выделить параметры:
1.1. период действия купленного продукта. Опираться на него при планировании фиксов;
1.2. период техподдержки. Выполнять работы только для оплаченных сервисов и пользователей;
1.3. объём работ по тех.поддержке: править баги, искать обходные пути, предоставлять обновления билдов и версий. Ограничить план тестирования только теми задачами, которые имеют юридическую силу
2. Вычленить из BTS мега-критичные баги (регрессия, нагрузка, обновление внешних систем) для срочной правки. Предоставить по ним отчёт руководителю проекта для согласования тест-плана.
3. Закрыть магазин и продажи для новых покупателей без остановки форумов, сообществ, мест обратной связи:
3.1. уведомить весь список дилеров об ограничении продаж;
3.2. личный кабинет пользователя ограничить доступной версией;
3.3. фильтровать рассылку писем пользователям по доступности продаж.
4. Контролировать публикацию инфы в открытых источниках о возможностях продукта (сайты компании и дилеров, хелп продукта).
5. При приёме заявок от актуальных пользователей критичность и важность входящих багов определять по массовости использования модуля.
6. Прекратить приём и оформление предложений по усовершенствованию продукта.
7. Работа тестировщика продолжается вплоть до завершения периода техподдержки, если лицензионным соглашением определено исправление критичных багов и поставка обновлений.

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

Cheat-sheet доступности

На днях предложили протестировать рекламу, а перед этим довелось посмотреть доклад на SQADays-24 "Manual and Automated Accessibility Implementation". Индиец, конечно, в своём духе перескакивал с темы на тему, но из множества его мыслей скомпоновался нижеследующий cheat-sheet для тестирования доступности. Начинать, изучать и закреплять тестирование доступности лучше всего на рекламных проспектах и роликах. Мы все её потребители, а вдобавок ещё и имеем профессиональный взгляд тестировщика.  Цель любой рекламы - доступно донести до потенциального потребителя продукта много важной информации, то есть тест на доступность - первоочередной для рекламы. Доступная реклама = польза информации производителю и потребителю.
Доступность программного обеспечения тестируют для того, чтобы:
- любой пользователь смог полноценно работать в вашем десктопной программе, на вашем сайте, в ваших web- и мобильном приложениях;
- к вашему продукту не было судебных исков из-за несоблюдения законодательств;
- расширялся круг пользователей за счёт людей с ограниченными физическими возможностями;
- пользователи, привыкшие к определённым действиям, не отвергали ваш продукт по причине несоответствия общепринятым стандартам, их привычкам и приоритетам;
- в гонке за хайпом и новомодным интерфейсом не затерялся основной функционал, предназначение продукта;
- вовремя проводить профилактику багов, предотвращая невозможность ввода и просмотра данных, как обычными пользователями, так и людьми с физическими ограничениями.
Большинство пунктов cheat-sheet accessibility основано на WSAG принципах:
 
Да, тест доступности - часть юзабилити и интерфейсного тестов, местами похож на негативный, но, если заглянуть в руководство WCAG и проанализировать статистику экранов пользователей, он превращается во вполне положительный.
В своём списке мне хотелось бы ограничиться такими пунктами, которые были бы адекватны для всех типов приложений и не претендовали на стандарты для особых пользователей. Это скорее смоук-тест доступности, а не обязательные проверки для получения сертификата. К слову сказать, с 2002 года мной был собран список того, что подлежит обязательной проверке перед передачей продукта на тестирование. В нём были многие пункты из ниже перечисленных, а каждый добавлялся после случая на стороне конечного пользователя. Так что, это не утопия, а реальные вещи, которые надо проверять в рамках позитивных тестов, несмотря на то, что эти параметры не включены в системные требования конкретно вашего продукта. Если начальство начнёт сопротивляться: "Негативные тесты - это излишество. Стартапу не по-карману!", то вашим аргументом будет фраза: "Наш продукт, по Вашему требованию, соответствует общепринятым мировым стандартам после прохождения теста доступности."

По cheat-sheet accessibility можно идти турами, поскольку группировка отлична от WCAG принципов. В пояснениях даны примерные места проверок, куда заглянуть во время очередного "путешествия". А также перечислены пункты и уровни из положения о доступности. По-моему, некоторым пунктам в положении явно завысили уровень, так как поведение программы в этих случаях более чем очевидное и ожидаемое.
1. ТЕКСТ
1.1. размер шрифта и межстрочный интервал (слипшийся мелкий текст во всю ширину экрана 9х16 вряд ли кто-то дочитает до конца, огромные заголовки принижают значимость основного текста или вынуждают много прокручивать экран, все символы и интервалы зуммируются пропорционально) - п.1.4.4(АА), 2.4.10(ААА), 1.4.12(АА);
1.2. цвет основного текста и подложки, контрастность (рекламные объявления для консистентности с логотипом могут быть в старославянском коричневом шрифте на "а-ля папирусе" бежевого цвета, либо детский сайт использует розовенькие буковки на жёлтенком коврике)- п.1.4.3(АА), 1.4.5(АА), 1.4.6(ААА), 1.4.8(ААА);
1.3. перевод на региональный язык (полное переключение и дублирование в титрах, быстрое и точное осознание содержимого может быть только на родном языке) - п.1.3, 1.3.1(А), 1.3.2(А), 1.4, 3, 3.1.1(А), 3.1.2(АА);
1.4. восприятие смысла (краткость и однозначность терминов всегда способствовали взаимопониманию, расшифровки аббревиатур, глоссарий, контекстная помощь) - п.1, 1.3.1(А), 3, 3.1, 3.1.3(ААА), 3.1.4(ААА), 3.1.6(ААА), 3.3, 3.3.5(ААА), 4.1.2(А);
1.5. восприятие синтаксиса, лингвистики (в инструкциях пользователя строго не рекомендуется использовать сложно-подчинённые предложения, язык Достоевского уместен только в классической литературе) - п.1, 3, 3.1, 3.1.5(ААА), 3.1.6(ААА), 4.1.2(А);
1.6. пропорциональное масштабирование надписей (изменение DPI, разрешения экрана, использование зуммирования не должны существенно искажать пропорции интерфейсных элементов и их подписей) - п.1.4.4(АА);
1.7. наличие видимых подписей всех элементов интерфейса (новомодная фича сайтов - перекинуть название окон ввода данных в сами редакторы до момента начала набора символов, оставляя пользователя только догадываться о полноценности вводимых данных) - п.1.4.5(АА), 1.4.9(ААА), 3.2.2(А), 3.2.4(АА), 3.3, 3.3.2(А), 4.1.2(А), 2.5.3(А);
1.8. изменение пользователем цвета текста и фона, размера шрифта пропорционально зуму - п.1.4.8(ААА).
2. КУРСОР, КООРДИНАТЫ, МАСШТАБИРОВАНИЕ
2.1. расположение элементов сверху-вниз, слева-направо или регионально справа-налево, снизу-вверх, ландшафтно или портретно, совпадение точек верх-низ экрана с положением монитора - п.1.3.2(А), 1.4, 2.4.3(А), 3.2, 3.2.3(АА);
2.2. пометка обязательных к заполнению полей, подсказка формата поля (шаблон даты, звёздочки замены, разделитель e-mail) - п.3.2.2(А), 3.3, 3.3.2(А), 1.3.4(АА), 1.3.5(АА), 2.5.6(ААА);
2.3. вместимость всех важных, сгруппированных элементов в единый кадр, прокрутку - п.1.3.2(А), 1.4, 1.4.8(ААА), 2.4, 3.2.4(АА), 3.3;
2.4. удержание подсказки курсором (окно хинта не исчезает пока в его области активен курсор) - п.2.1.3(ААА);
2.5. управление курсором - клавиатура реальная и остальные инструменты (вспомогательная клавиатура, мышь, сенсорная панель или сам экран, джойстик, видеорегистратор, шлем телепатии) взаимозаменяемы - п.2, 2.1, 2.1.1(А), 2.1.2(А), 2.1.3(ААА), 2.4, 2.4.3(А), 2.5.1(А), 2.5.4(А), 2.5.6(ААА);
2.6. подсветка текущего курсора не пересекается с иными пометками и выборками (визуализация фильтрации и изменения данных, навигация в деревьях и схлопывающихся окошках опций, действия между нажатым и отжатым курсором обратимы) - п.2.4.7(АА), 2.4.8(ААА), 3.2.1(А), 3.2.2(А), 1.4.13(АА), 2.5.2(А), 2.5.6(ААА);
2.7. встроенные лупа, зуммер или глобальная смена DPI масштабирует весь контент пропорционально (жёстко-заданный, а не пропорциональный, размер шрифта может не среагировать на изменения пользователя) - п.1.4.4(АА), 1.4.8(ААА);
2.8. прокрутка вертикальная, горизонтальная, диагональная (мышью, клавиатурой, сенсорным устройством, джойстиком) - п.1.4.10(АА);
2.9. минимальные размеры окон и размещаемых на них элементов (полноценная видимость при DPI-100%, наличие скроллеров при увеличении DPI до 200% и разрешении 600*800 пикселей) - п.2.5.5(ААА).
3. ИЗОБРАЖЕНИЕ
3.1. ассоциативность ряда картинок и всего остального содержимого страницы (кнопка выхода с картинкой двери или крестика - логично, перемешанный порядок изображений путает восприятие) - п.1.3.2(А), 1.4, 3, 3.2;
3.2. наличие подписей, хинтов у кнопок с картинками (мелкие детали требуют пояснений, нестандартные и непривычные изображения слабо ассоциируются с предлагаемыми действиями, программы-ассистенты распознают элемент экрана по имени, браузер с выключенным показом картинок) - п.1.1.1(А), 1.3.1(А), 1.4.9(ААА), 3, 3.2.4(АА), 3.3, 3.3.2(А), 3.3.5(ААА), 1.3.6(ААА), 2.3.3(ААА);
3.3. пикселизация, размытость, нечёткость ухудшают понимание - п.1.4.3(АА), 1.4.5(АА), 1.4.6(ААА), 1.4.11(АА).
4. ЦВЕТ
4.1. привычные многим: красный цвет - ошибок, жёлтый - предупреждений, зелёный - разрешение продолжать, синий - рабочая норма (частичная подсветка объектов для ассоциативного привлечения внимания) - п.1.4.1(А), 3, 3.2;
4.2. недопустимость цвета без подписи (дальтонизмом страдают 20% мужчин) - п.1.3.3(А), 1.4.1 (А), 3;
4.3. контрастность (тема ОС или монохромный монитор не ухудшают функционал продукта) - п.1.4.3(АА), 1.4.11(АА).
5. ТАЙМЕР
5.1. системная обработка удержания клавиш (длительное нажатие считается повторным в играх на строго определённых этапах) - п.2.1.3(ААА), 3.2;
5.2. подсказка, хинт элемента не исчезает пока на ней курсор - п.2.1.3(ААА), 2.2.3(ААА), 2.2.4(ААА), 3.3, 2.2.6(ААА);
5.3. для прочтения или просмотра анимации отведено достаточно времени (текст может быть иностранным или объёмным, процентная шкала ведёт обратный отсчёт) - п.2.2, 2.2.3(ААА), 2.2.4(ААА), 3.3;
5.4. секундомер работы с базой (транзакции в БД обязательно настраиваются админом) - п.2.2.4(ААА), 2.2.5(ААА), 3.3, 2.2.6(ААА).
6. ЗВУК
6.1. подпись объекта (воспроизведения аудио-ролика может начинаться по клику на всю картинку плейера или только на одну маленькую кнопку-иконку - неожиданное поведение) - п.1.3.3(А), 2.4.4(А), 2.4.9(ААА), 3, 3.2, 3.2.4(АА), 1.3.6(ААА);
6.2. краткое описание или содержание аудио-ролика (прослушивание всего ролика отнимает время, упоминание в тексте основных моментов привлекает внимание) - п.1.2.1(А), 1.2.3(А), 1.3.1(А), 3;
6.3. пауза, возврат, перемотка, повтор, длительность ролика, громкость звука (управление всеми параметрами повышает степень восприятия содержимого) - п.1.4.2(А), 2.2.1(А), 2.2.3(ААА), 2.2.4(ААА), 2.2.6(ААА);
6.4. плейер (имеется встроенный, указан формат файла для выбора альтернативного плейера) - п.1.2.3(А), 2.4.4(А);
6.5. аудио-фон отсутствует или выключается (часто аудио-фон применяют в играх или на страницах сайтов с множеством объявлений - это мешает или раздражает) - п.1.4.7(ААА);
6.6. нет заглушки системных звуков (залипание или долгое удержание клавиш, окна с сообщениями системы сопровождаются аналогичными звуковыми эффектами или перенастраиваются на пользовательские) - п.3.2.
7. АНИМАЦИЯ
7.1. "переливающийся курсор" в движении во всё время длительного процесса (длительная загрузка данных не означает зависание программы) - п.2.2.2(А), 2.2.3(ААА), 2.2.4(ААА), 2.2.5(ААА);
7.2. затянувшуюся загрузку можно прервать (окно с "градусником" процесса имеет кнопки остановки и отмены, либо перевода в фоновый режим для продолжения иной работы) - п.2.2.2(А), 2.2.3(ААА), 2.2.4(ААА);
7.3. всплывающие окна имеют достаточный период (более 5сек) до исчезания (обратный отсчёт, задать большой интервал программно) - п.2.2.1(А), 2.2.2(А), 2.2.4(ААА), 3.3;
7.4. всплывающие окна закрываются по временному интервалу или нажатию функциональной кнопки в зоне окна, клавиши ESC - п.2.2.1(А), 2.2.4(ААА);
7.5. всплывающие окна не перекрывают друг друга, занимают только рабочую область экрана (хороший пример - появления alarms поочерёдно в ICQ Miranda, хинт за пределами экрана или наложенный на предыдущий -  нечитаемый) - п.1.3.2(А), 2.2.2(А), 3.3;
7.6. мерцание не более 24 кадров или 3 вспышек в секунду (слишком частые изменения экрана ведут к глазным и нервным заболеваниям) - п.2.3.1(А), 2.3.2(ААА);
7.7. предсказуемость изменений (обновление страницы браузера по F5, автозаполнение полей ввода, смена экрана по запросу пользователя) - п.3.2.5(ААА);
7.8. браузер с выключенным показом картинок не ограничивает функционал - п.2.3.3(ААА).
8. ВИДЕО
8.1. подпись объекта (воспроизведения видео-ролика может начинаться по клику на всю картинку плейера или только на одну маленькую кнопку-иконку - неожиданное поведение) - п.1.3.3(А), 2.4.4(А), 2.4.9(ААА), 3, 3.2, 3.2.4(АА), 1.3.6(ААА);
8.2. краткое описание или содержание видео-ролика (просмотр всего ролика отнимает время, упоминание в тексте основных моментов привлекает внимание, браузер с выключенным показом картинок) - п.1.2.1(А), 1.2.3(А), 3, 2.3.3(ААА);
8.3. пауза, возврат, перемотка, повтор, длительность ролика, громкость звука (управление всеми параметрами повышает степень восприятия содержимого) - п.1.4.2(А), 2.2.1(А), 2.2.3(ААА), 2.2.4(ААА), 2.2.6(ААА);
8.4. плейер (имеется встроенный, указан формат файла для выбора альтернативного плейера) - п.1.2.3(А), 2.4.4(А).
9. ТЕХ-ПОДДЕРЖКА
9.1. поддержка встроенных в ОС средств (лупа, зуммер, секундомер, смена разрешения экрана в ОС, смена региональных параметров ОС, плагины-помощники для браузеров) - 3.2, 4, 4.1;
9.2. полноценность кода для распознавания программами-ассистентами (закрытые тэги, имена и параметры, тех.подписи элементов) - п.2.4, 2.4.1(А), 2.4.2(А), 2.4.4(А), 2.4.5(АА), 2.4.6(АА), 2.4.9(ААА), 2.4.10(ААА), 3.2.4(АА), 4.1, 4.1.1(А), 4.1.2(А), 1.3.6(ААА), 2.5.3(А), 4.1.3(АА);
9.3. горячие клавиши (стандартные наборы работают только в своей области, можно переназначать или отключать, имеется достаточно предупреждений об использовании) - п.2.1.3(ААА), 3.2, 3.2.4(АА), 2.1.4(А);
9.4. проверка, отмена, подтверждение, шифрование значимых действий (скрытый ввод пароля, ограничения на обмен персональной инфой, финансовые операции с предпросмотром и подтверждением, пред-просмотр вместо печати больших объёмов) - п.2.2.4(ААА), 2.2.5(ААА), 3.2, 3.3, 3.3.4(А), 3.3.6(ААА);
9.5. конкретизация ошибок подсветкой и поясняющим сообщением (нет заглушек для ошибок ОС или базы, внутренние ошибки продукта имеют инструкцию дальнейших действий, неверные данные локализуются цветом или позицией курсора) - п.3.2, 3.3, 3.3.1(А), 3.3.2(А), 3.3.3(АА), 3.3.4(А), 3.3.5(ААА), 3.3.6(ААА).

Для подтверждения WCAG уровня, конечно же надо будет ужесточить и увеличить количество проверок.
Инструменты для автоматической проверки сайтов:
 
Больше примеров можете подчерпнуть из доклада Екатерины Шепелевой "О тестировании доступности" на QA-Fest-2017.

Полезные ссылки:
Изучайте оригинал самостоятельно и расширяйте список тестов - "Web Content Accessibility Guidelines"
На русском - "Web Content Accessibility Guidelines (WCAG) 2.0"
Дополнения за 2018 год - "WCAG 2.1 на русском" (в 2007 г. появился Национальный стандарт ГОСТ Р 52872 и его актуализированная редакция от 2012 г., авторизованный перевод международного стандарта WCAG 2.0 в 2013 г.)
Первая версия содержала 14 принципов - "WCAG — рекомендации, которые никто не слушал"
Практические рекомендации программистам - "Приведение сайта в соответствие со стандартом WAI-WCAG"
Мобильные приложения не отделяют от web-app - "Mobile Accessibility at W3C"

ПэйджСэйвер

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

P.S.: о необходимости таких кнопок для тестировщиков и говорить излишне.
Интерфейс в большинстве случаев проверяется по скрин-шотам. А тут - готовое решение:
- неизменное содержимое;
- полнота данных за счёт авто-скроллирования;
- данные актуальны на момент действия и полностью соответствуют текущим условиям;
- дата и автор проведения теста в свойствах файла.
И всё это лишь в один клик.

Балловая связь

Чиновники для народа

Общественность постоянно сетует на работу чиновников: и не слышат они народ, и взятки берут. Уж и законы об обращениях граждан на них насылали, и штрафы взяточникам взвинтили, а они всё равно рвутся занять должность "слуги народа", чтобы жить по-царски. А может сами подчинённые и избиратели виноваты в том, что продвигаются не те проекты, которые нужны? Как повысить активность граждан? А может подношения вышестоящие воспринимают как необходимую благодарность, которую не получают после окончания дела? Как воспитать всех отзывчивыми? Почему же власть портит людей? Даже мелкую сошку, бригадира или начальника подотдела не узнать через несколько месяцев верховенства. Может они всё время ждут благодарности за свой труд и грустят от неблагодарности "свиты"? Или гордыня затмеваем им основную идею лидерства - вести за собой и опекать подчинённых от неприятностей? А ведь даже родители взращивают своих детей, чтобы в старости было кому поднести стакан воды. Значит и руководитель всегда ждёт своей доли благодарности, и не в виде зарплаты, а чисто по-человечески.
Можете ли вы представить себе, что цифровая экономика и демократия способны воспитывать общество в целом и каждого в частности? При этом можно искоренить кумовство и взяточничество, снизив до нуля человеческий фактор ошибок. И решается проблема довольно просто: небольшое дополнение к закону об обращениях граждан и введение автоматической аттестации для всех уровней руководящего состава.
Техническая реализация заключается в следующем. Дополняем закон об обращениях граждан обязательным завершающим пунктом для выставления отметки об исполнении запроса обратившегося. Для этого предварительно дублируем (переводим) весь оборот обращений и ответов в электронный вид. К сожалению, на этом этапе нет полной автоматизации, так как кроме электронных писем и специализированных форм обратной связи на сайтах существуют очные письменные и устные способы общения, телефонные звонки и смс, посты в соц.сетях и публикации в СМИ.  Но любой разговор всегда можно записать и оцифровать, а бумажные формы отсканировать в цифровой вид. Поэтому будем считать, что все входящие реально регистрировать в электронной базе. Объём обращений можно лимитировать, автоматически рассчитывая пропорцию рабочего времени руководителя и количества подопечных. Например, при 40-часовой рабочей неделе и минимуме в 15 минут на визит мэр города с 5 тысячами полноправных жителей сможет максимально обработать около полутора (4*40*52/5000=1,664) обращений в год от каждого, но не более 8320 (=4*40*52, где 4 - количество обращений в час, 40 рабочих часов в неделе, 52 недели в году без отпуска) всего в год. Соблюдать уникальность обращений и их инициаторов объективно может только электронная база данных. Она же станет и беспристрастным оценщиком исполнительности. Обязав заявителей отправлять электронно отзыв о выполненности или отказе, можно собирать статистику по каждому начальнику и автоматически выставлять им рейтинг. Эта же система самостоятельно будет контролировать исполнение. Например, гражданин подал срочную заявку, которую зарегистрировали в базе (присвоили уникальный идентификатор, завели данные гражданина - паспортные и телефон, суть обращения, дату обращения и высчитан крайний срок исполнения). Если исполнитель уложился в срок, то система отправляет заявителю СМС (исполнена ли заявка, удовлетворены ли ответом/отказом) с обязательным ответом (0 - нет, 1 - да), или автоматическое электронное письмо, или телеграмму обычной почтой. Если исполнитель не уложился в срок, то система автоматически добавит заявку в отрицательный список рейтинга начальника. Если исполнитель всё исполнил, но заявитель не удовлетворён исходом дела, то отвечает "0" и он влияет на негативный рейтинг начальника. Если дело исполнено благополучно, то заявитель улучшает рейтинг начальника. На этом этапе сами исполнители будут бегать за заявителями с просьбой положительного отзыва. И здесь заявителю придётся проявить собственную гражданскую ответственность и объективность. Такой переворот отношений между заявителем и исполнителем поднимет активность граждан, наладит диалог, будет воспитывать отзывчивость, сблизит общение чиновников и общества, приучит говорить "спасибо" даже столь неприятным до селе чиновникам. Поскольку рейтинг конкретного исполнителя будет зависеть от каждого обращения, то чиновники реже станут перенаправлять заявки на иные инстанции и реализовывать собственными силами в положеный срок. Но поскольку менталитет у всех таков, что "не подмажешь, не поедешь", то вполне возможно исполнители начнут предлагать взятки заявителям за положительные отзывы. Поэтому наказания взяточников неизбежны, если каждый гражданин не перестанет контролировать самого себя, хотя подачки поменяют размер и направление. Таким образом чиновника по факту превратятся в слуг народа.
Современные технологи позволяют разделить базы заявок и отзывов, а агрегированные данные вполне можно опубликовывать. Процент выполненных заявок можно раскрасить их объёмом, как это подсчитывается в спорте (кмс, чемпион, чёрный пояс и т.д.), взяв процент от максимального объёма. И в этом случае объективность будет соблюдена за счёт лимита уникальных обращений от каждого заявителя.
Рейтинг руководителей, опубликованный в общем доступе, регулярно и независимо обновляемый, станет не только мерилом ответственности, но и гарантом доверия. Результаты ежечасной работы сложатся в профиль кандидата на вышестоящий пост, либо вовремя покажут причину снятия с должности или необходимость дотаций, внешней помощи.
Аналогичную систему предлагаю и для аттестации руководителей всех уровней. Очень много в стране компаний, на руководящие должности в которых поставлены работники без знаний КЗоТ или с недостатком навыков управления персоналом. В советские времена профсоюзы повышали такой уровень в спец.школах и на курсах. Но сейчас организациям приходится тратить собственные средства на обучение. И поскольку это дорого, то компании экономят на развитии трудовых ресурсов. Если же руководителей всех уровней можно было бы сертифицировать и регулярно аттестовывать, то такой контроль заставил бы начальников знать законы и уметь применять техники руководства. Аттестацию вполне логично возложить на комиссии по трудовым спорам и центры занятости населения. Комиссии по трудовым спорам могут составлять независимые рейтинги на основе обращений работников, количестве увольнений и предотвращённых сокращений штата. А центры занятости могут проводить экзамены на знание КЗоТ и умение применять техники управления персоналом. Сертификацию руководителей можно сравнить с техосмотром автомобилей - отсутствие грозит штрафами, а наличие гарантирует спокойствие подчинённых. Если в этой системе обращения работников в комиссии по трудовым спорам будут бесплатны, а расходы на рассмотрение споров будут оплачивать начальники, то задержки зарплат, сокращение штата и беспричинные увольнения уйдут в небытие. А значит у центров занятости уменьшится объём работ по подбору вакансий и это время распределится на аттестации, организацию курсов. Главным плюсом сертификатов воспользуются кандидаты на замещение вакансий.

Offside outsourcer

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

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

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

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

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

GDPR - доверяй и проверяй

Возврат к бюрократии или Сотрудник на доверии
(рубрика - Нюх на баги)

Европейское сообщество решилось на усовершенствование охраны данных. Теперь тестировщикам и сотрудникам отделов тех-поддержки необходимо в срочном порядке совершенствовать свои знания в области юриспруденции.
Начать обучение следует с самого документа - "General Data Protection Regulation (GDPR)".
В большей мере вопрос касается персональных, конфиденциальных данных. А есть ли в них различие? Что об этом думают эксперты? Читайте "Experts on the GDPR #3: What is personal data under the GDPR?".
С технической точки зрения эксперты определили облачные сервисы для защиты данных - "Experts on the GDPR #4. Storing encrypted personal data in the cloud: What is the most secure option?", "EU GDPR: соблюдение требований регуляторов в сфере облачных вычислений".
Какая же ответственность теперь будет у сотрудников техподдержки первого уровня и тестировщиков? Для техподдержки объектом пристального внимания становится информация о кастомерах, которую необходимо дифференцировать по территориальному признаку - индивидуальные данные от покупателей и поставщиков следует хранить и обновлять в рамках GDPR, компаньонов из других стран позволено обслуживать в прежнем режиме, только если они не связаны с европейцами. Было бы проще ко всем применить политику GDPR, но Вы уверены, что иные страны не имеют более жёстких условий? Поэтому техподдержка первого уровня - одно из самых важных звеньев в процессе фильтрации данных. Например, баг от пользователя должен храниться во внутренней системе компании разработки, а все контакты пользователя в независимой базе, вплоть до отдельного сервера. Получается, связующее звено "техподдержка" при этом несёт полную ответственность за линковку данных об исправляемом баге и пересылаемом отчёте пользователю. Тестировщику, оформляющему баг в базу при этом придётся унифицировать проблему, применяя переименование и аггрегацию для сокрытия данных от сторонних глаз. А Ваши базы контрагентов и задач готовы к такой конфиденциальности?
Создавая и тестируя базы данных в программном продукте, выпускаемом Вашей компанией, следует более тщательно контролировать простоту наименований таблиц и полей, связей реляционных баз и доступность их описания. В этом плане хороший пример в OEBS, где таблицы и поля имеют нелогичные наименования, в основном состоящие из цифр, что хорошо запутывает взломщиков. Также должны быть усилены тесты по способам и местам хранения данных - физические носители, облачные сервисы, удалённое управление с ограничением прав доступа и функций. При пересылке данных должны использоваться высоко-защищённые от несанкционированного доступа способы, а пересылаемые данные защифрованы в обязательном порядке. Также не менее важно проверять объём информации, присылаемой с отчётом о баге, чтобы в ней не хранилось что-либо, идентифицирующее пользователя продукта. Объём и содержимое пересылаемых данных необходимо проверять на актуальность, необходимость и достаточность, предотвращать скрытые пересылки (без ведома пользователя) паролей, IP-адресов, списков баз и прав доступа, прочих идентификаторов.
Список ответственных за сохранность данных не ограничивается техподдержкой. Компания, выпускающая десктопный продукт и продающая его через свой сайт, вполне может быть распределённой: например, зарегистрирована компания в США, разработчики и тестировщики фактически раскиданы по России и Украине, маркетологи разъезжают по всему миру, сервера с исходниками и данными пользователей могут быть распределены  по всему миру. Удобнее иметь сервера с исходным кодом и задачами поближе к группе разработки, а сервис продаж в Европе. Но при этом копия базы данных покупателей обязана быть у разработчика в оригинале, а не переименованная, поскольку могут быть проблемы, напрямую зависящие от комбинации исходных данных. Такие моменты прописаны в GDPR как доступ к данным по запросу "Art. 15 GDPR  Right of access by the data subject". О предварительных действиях компании разработки рассказано в "How to prepare for Data Access Requests under GDPR", "GDPR data access portal: Logging into the GDPR data access portal, Making a data access request, The data access request excel template, Making a data deletion request, Making a data change request, Making a consent change request".

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

ТнаТ

Тестировщик на техподдержке (ТнаТ) или Слуга на все четыре стороны

Кто есть тестировщик на техподдержке? Сотрудники техподдержки первого, второго уровня (бывшие аналитики, бета-тестеры) обязаны досконально знать продукт, чтобы максимально быстро дать ответ пользователю. Третий уровень техподдержки - программисты - знают код продукта, то есть его внутренности. Тестировщики знакомы с продуктом как со стороны пользователя, так и со стороны кодеров. К тому же у тестировщиков выше уровень грамотности, что является важным фактором при оформлении ответов пользователям и задач в баг-трекинговую систему. Поэтому на первый уровень техподдержки обычно ставят тестировщиков, иногда аналитиков. Но поскольку у тестировщиков есть ещё и знания кодирования, то тестировщик на должности техподдержки получается более дешёвым сотрудником.
Общепринято считать, что тестировщик и сотрудник техподдержки должны в первую очередь защищать сторону пользователя, то есть быть адвокатом юзера. ТнаТ должен уметь общаться с пользователем наравне - грамотно, но не заумно; на доступном для обеих сторон языке; о пользовательских нуждах, воплощённых в коде. Любой отчёт пользователя приходится рассматривать как критичный баг, убеждать кодеров и руководство в необходимости правки. Программисты, как всегда, ведут разъяснительные беседы о новшествах, которые плохо описаны в аннотации к билду, поэтому юзер считает фичи багами.
Соглашусь, что напору проггеров сложно противостоять, и вскоре мнение тестировщика склоняется в сторону фичи, а не бага. Но при этом техподдержке приходится вуалировать или откровенно врать пользователю о явном баге, который по мнению аналитиков и программистов тянет на фичу. Выясняя подробности отчёта юзера, сотрудник техподдержки оказывает неоценимую услугу аналитику и программисту, облегчая им работу, или, попросту говоря, работает вместо них: переформулирует вопросы с кодерского языка на юзерский и ответы обратно, уговаривает пользователя принять ошибку за новшество. Вот и первая ступень борьбы ТнаТ с совестью. В моей практике было не мало примеров, когда программист заменял логичное "два плюс два" по задаче от аналитика "два и два" в более быстрое по мнению кодера "дважды два". При этом результат в большинстве случаев не менялся, но никакое предупреждение пользователя в продукт или аннотацию к билду не включали сотрудники, выпускавшие билд. Когда пользователь обнаруживал такое несовпадение, то непременно репортил его как баг, а то и отказывался от продукта с заявлением о возврате потраченных им средств. Баг ли это или рефакторинг, промах  разработчиков или выпускавших билд - решение принимал всегда шеф не в пользу тестировщиков и техподдержки.
Но как ни печально, далее ещё сложнее, поскольку врать приходится ради денег фирмы. Ложь для собственной единоличной наживы совесть позволяет оправдать. А групповой обман подпадает под уголовную статью второй-третьей частей, то есть более сильную. Отдел маркетинга проводит опросы, собирает статистику, распространяет рекламу. Вся информация в оба конца проходит через руки ТнаТ, который группирует её по контрагентам, анализирует при исследовании проблемы, передаёт часть маркетологу, часть аналитику и программисту, часть руководству. Конечно, из настроек продукта ТнаТ может вычленить много полезного для локализации бага, но вместе с этим приходится пропускать (с 25 мая 2018 года шифровать, маскировать и фильтровать в рамках GDPR) индивидуальную инфу. Некоторые ошибки тесно связаны с персональными данными, но у ТнаТ не всегда есть право распространять инфу третьим лицам, которыми вполне можно считать кодировщиков. Итого, сначала ТнаТ шлёт рекламу пользователю с обещаниями всяческих плюшек, а чуть позже ему же приходится оправдываться в их отсутствии или иной реализации, при этом быть политкорректным настолько, чтобы фирма не потеряла свои финансы. Но виноватыми в этой ситуации остаются сами же ТнаТ, как в глазах пользователя (ТнаТ - лицо компании), так и по мнению руководства, для которого за успех продукта поощряются программисты, а за провал наказываются тестировщики. Для избежания подобных проблем ТнаТ должно быть позволительно влиять продукт: участвовать в планировании спринта (особенно если реклама обещает новшества к определённому сроку), проверять аннотацию (Release Notes) к выпуску, тесно сотрудничать с финансовым отделом для ограничения распространения спама о скидках или регулярных платежах за техподдержку. Тогда ТнаТ может проявить всю свою политкорректность в переписке с пользователем не споря с собственной совестью.
Ну, и самый тёмный угол - это соблюдение законов, которые подчас могут противоречить друг другу. Например, корпоративная этика, минимизирующая бюрократизм, и закон о сохранности персональных данных, обязывающий логировать передачу индивидуальной информации. ТнаТ тяжело удерживаться на своём месте и не противоречить сотрудникам фирмы, поскольку маркетолог, программист и пользователь как лебедь, рак и щука тянут продукт в свои стороны. А ТнаТ вынужден меж этих огней ещё и соблюдать законность, политкорректность и дружелюбность в общении пользователя и фирмы. Сотруднику техподдержки бывает очень сложно убедить руководство не обманывать пользователя для соблюдения законности: предупреждать об объёме собираемой и пересылаемой в фирму индивидуальной информации пользователя; отвечать за обещанное рекламой и фактически поставленное продуктом в рамках лицензионного соглашения; скрывать от пользователя конкретику работы фирмы в рамках соглашения о нераспространении внутрикорпоративной информации и подробно описывать шаги группы разработки для спокойствия пользователя.
Миссия ТнаТ не легка. При переходе на должность сотрудника техподдержки непременно подтяните свои знания в области юриспруденции, психологии, грамотности (русский или английский язык переписки с пользователями) и дикции (для случаев аудио-связи), наряду с отличным знанием продукта.

Качество кода одним числом

Maintainability Index – величина качества кода

Качество продукта, согласно ISO-9126, состоит из 6 частей (см. Рис.1 "ISO-9126").

Рис.1 "ISO-9126"

Из этих же шести пунктов (см. Рис.1 "ISO-9126") строится и качество кода, которое можно измерить для любого языка программирования. К сожалению, идеального кода не существует и добиться невозможно, как и КПД-100%.
Одна из простейших метрик – количество параметров, которое рекомендуют не более 7: 5 входящих, 2 на выход. Особое место занимают глобальные переменные, наличие которых усложняет код.
Более сложно качество кода вычисляется по формулам, только одна из которых "цикломатическая сложность" пока принята институтом стандартов. Когда научному миру удастся доказать полезность и значимость остальных формул, тестировщики смогут официально ориентироваться на эти лимиты.
Формула расчёта Maintainability Index была выведена достаточно давно Доном Колеманом, Паулем Оманом и Джеком Хегмейстером. Она имеет несколько вариаций для различных языков программирования. Фактически, польза индекса "ремонтопригодности" не только в оценке готового кода, но по этой величине вполне можно спрогнозировать устойчивость кода с учётом будущих исправлений.
Согласно формулам (см. Рис.2 "Две формулы подсчёта количества багов в юните", где TNOpr – общее количество операторов, TNOpd – общее количество операндов, DNOpr – количество уникальных операторов, DNOpd  – количество уникальных операндов) Мариуса Халстеда, если код состоит хотя бы из одного оператора и операнда, то величина багов в этом коде уже не нулевая.

Рис.2 "Две формулы подсчёта количества багов в юните"

Если оценить обе формулы (см. Рис.2 "Две формулы подсчёта количества багов в юните") через их графики, то очевидно, что количество багов в новом и исправленном коде будет нулевым только в "пустой" подпрограмме.

 

Рис.3 "График и формула подсчёта новых багов"

На рисунке 3 "График и формула подсчёта новых багов" верхняя формула для расчёта прогнозируемых багов минимизирована по количеству операторов (1 шт) и операндов (2 шт). Количество багов смотрим по оси Y, количество операторов и операндов (только целые числа) смотрим по оси X. Поскольку рабочей подпрограммы без операторов и операндов не существует, то по графику убеждаемся, что количество багов резко уходит в бесконечность только при нулевых значениях операторов и операндов [0..1], количество багов растёт плавно (y>0 при x>1). 

 

 Рис.4 "График и формула подсчёта недавних багов"

Минимизировав вторую формулу (см. Рис.2 "Две формулы подсчёта количества багов в юните") для расчёта недавних багов и приняв один оператор на пару операторов, получаем по-сути аналогичный график (см. Рис.4 "График и формула подсчёта недавних багов"), когда количество багов равномерно растёт по оси Y и не может быть отрицательным, так как в рабочем коде должен быть хотя бы один оператор и операнд, то есть значения по оси X рассматриваются только целочисленные, начиная с 1.
Итак, мы убедились, что в любом коде всегда есть баги. А об их серьёзности можно судить по величине Maintainability Index (MI).

Из чего же складывается величина качества кода?
Максимальная формула учитывает значения Сложности Халстеда, Цикломатической Сложности, значимые Строки кода и объём Комментариев:
MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln (LOC) + 50 * sin(sqrt(2.4 * COM)), где HV – сложность Халстеда, CC – цикломатическая сложность, LOC – количество строк кода, COM – объём комментариев в коде.
Укороченная формула не учитывает объём комментариев:
MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln (LOC)
Компилируемые языки программирования "не отвлекаются" на комментарии, поэтому для них (например, Си) вполне очевидно использование укороченной формулы. А языки-интерпретаторы (например, SQL) корректнее оценивать по полной формуле, так как комментарии внутри цикла в некоторых языках могут замедлять исполнение программы, поскольку на вычленение незначимых строк тоже нужно время.
Пределы индекса принято рассматривать по следующей таблице (см. Рис.5 "Лимиты Maintainability Index"):
- подпрограмма требует немедленного исправления, если MI упал меньше 65;
- подпрограмму желательно исправить, если MI больше или равен 65, но меньше 85;
- подпрограмма не нуждается в исправлении, если MI равен или больше 85.
Исходя из формулы абсолютное максимальное значение Maintainability Index равно 221 (171-0-0-0+50), но оно не достижимо ни при каком содержимом сорсника.

Рис.5 "Лимиты Maintainability Index"

Об истории лимитов MI можно почитать в статье.

Итак, чем больше индекс, тем лучше код. Рассмотрим способы повышения индекса важности кода.

Более скорый способ увеличения индекса исходя из формулы первой модели "MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln (LOC) + 50 * sin(sqrt(2.4 * COM))" возможен за счёт увеличения объёма комментариев, так как индекс в формуле – наибольшее положительное число "50". Объём комментариев зависит от функции синуса, которая колеблется в пределах [-1..1]. Но поскольку объём комментариев можно исчислять двумя способами – как процент или долю, а значение синуса может быть и отрицательным, то необходимо выяснить оптимальные пределы комментариев. Для этого рассмотрим график функции "y(x)= 50 * sin(sqrt(2.4 * x))" на отрезках [0..100] (при исчислении комментариев в процентах) и [0..1] (при исчислении комментариев в долях от общего кода).

Рис.6 "График комментариев в процентах"

На графике (см. Рис.6 "График комментариев в процентах"), построенном по формуле "y(x)= 50 * sin(sqrt(2.4 * x))", по оси X имеем процентное соотношение комментариев к строкам кода, а по оси Y – величину для расчёта Maintainability Index. 1-2% или 25-26% или 83-84% комментариев дадут желаемый максимум (y=50), 0% или 4% или 17% или 37% или 66% комментариев абсолютно не влияют на Maintainability Index (y=0), 9% или 50-51% комментариев самым сильным образом (y=-50) отрицательно влияют на индекс ремонтопригодности. При этом MI может стать и отрицательной величиной. 

Рис.7 "График комментариев в долях"

На графике (см. Рис.7 "График комментариев в долях"), построенном по формуле "y(x)= 50 * sin(sqrt(2.4 * x))", по оси X имеем долевое соотношение комментариев к строкам кода, а по оси Y – величину для расчёта Maintainability Index. График показывает, что 3-4 комментированные строки кода из 10 рассматриваемых (или каждая третья) максимально помогают увеличить MI, то есть являются самым полезным соотношением.

Итак, если MI упал ниже 65, то по-быстрому его поднять можно вставкой комментариев в каждую третью строку.
Примечания:
- полезность/качество комментариев не рассчитывается формулой, поэтому не стоит забывать, что просто закомментированный код – это не полезные примечания;
- при добавлении комментариев соответственно увеличится и общее количество строк кода.

Шаг второй по повышению индекса устойчивости подпрограммы – снизить количество строк кода, потому что в формуле "MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln (LOC)" наибольший отрицательный индекс "16.2" у величины строк. На графике (см. Рис.8 "График и формула строк кода") видно, например, что 4500 строк уменьшат индекс на 136 пунктов из 171 возможного по формуле. Количество строк в подпрограмме определяется по спецсимволам текста, поэтому парсер обмануть не получится обычным размещением команд в одну строку файла. Единственный вариант – оптимизация кода за счёт объединения и выноса идентичных блоков кода в самостоятельные функции, которые будут рассматриваться как отдельные подпрограммы.

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

 

 Рис.8 "График и формула строк кода"

Если пойти от обратного и принять в формуле MI(<=65) максимальные значения HV(=1000), CC(=10) и комментариев (sin[X]=1), то в одном юните желательно иметь не более 1500 строк (см. Рис.9 "График максимального количества строк кода и формула с учётом комментариев").

 Рис.9 "График максимального количества строк кода и формула с учётом комментариев"

То есть по формуле Maintainability Index с учётом комментариев мы вывели лимит для оптимального количества строк в подпрограмме: LOC<1500 mi="">=65.
Для формулы второй модели (без учёта комментариев) смотрите рисунок 10 "График максимального количества строк кода и формула без учёта комментариев".

 Рис.10 "График максимального количества строк кода и формула без учёта комментариев"

График по оси Y показывает MI, а LOC по оси X. Из чего следует, что в юните без комментариев для стабильно-устойчивого кода нужно иметь менее 50 строк (см. Рис.11 "Увеличенный график максимального количества строк кода для формулы без учёта комментариев").

 

 Рис.11 "Увеличенный график максимального количества строк кода для формулы без учёта комментариев"

Об иных подробностях строк кода читайте в статье "Source lines of code".

Третий шаг по повышению MI – это снижение сложности Халстеда из части "5.2 * ln(HV)". Максимальная величина Халстеда – 1000. Исходя из этого на графике (см. Рис.12 "График и формула Halstead Volume в рамках MI") видно, что сложность Халстеда максимально может уменьшить индекс ремонтопригодности на 36 пунктов.

 

 Рис.12 "График и формула Halstead Volume в рамках MI"

Все величины Халстеда рассчитываются по операторам и операндам. Напомню, что в выражении "a+b" оператором является плюс, а операндами – переменные "a" и "b". Длина программы по Халстеду – это сумма всех операторов и всех операндов. Словарь юнита он определил как сумму уникальных операторов и операндов. А помножив длину программы на логарифм словаря, Халстед получил объём подпрограммы (или ещё эту величину называют сложностью Халстеда):

HV = ( TNOpr + TNOpd ) * log2 ( DNOpr + DNOpd ),

где TNOpr – общее количество операторов, TNOpd – общее количество операндов, DNOpr – количество уникальных операторов, DNOpd  – количество уникальных операндов. Более подробно о величинах Халстеда читайте в статье "Halstead complexity measures".
Если принять, что на один оператор приходится два операнда, то график функции HV будет приблизительно, как на рисунке 13 "График и функция сложности Халстеда".

 Рис.13 "График и функция сложности Халстеда"

По оси Y смотрим значение HV, а по оси X выбираем количество операторов. Максимальному значению HV=1000 соответствует 45 операторов, и соответственно около 90 операндов (~ два операнда на один оператор).
Для увеличения MI до 65 и выше надо уменьшать HV, то есть количество операторов и операндов. В коде (см. пример на рисунке 14 "Пример сложных и простых вычислений") можно множество простых операций объединить в одну сложную. Это как в начальной школе по арифметике при имеющемся решении задачи в три-четыре действия выполнить расчёт одним действием.

 Рис.14 "Пример сложных и простых вычислений"

На скриншоте из ClearSQL (см. Рис.15 "Пример упрощения кода по HV, MI") показана разница в значениях HV для сложной "hv_1" и простой "hv_2" подпрограмм.

 Рис.15 "Пример упрощения кода по HV, MI"

Уменьшая количество операторов и операндов в коде снижается сложность Халстеда (HV), и как следствие увеличивается (улучшается) индекс ремонтопригодности (MI).

Четвёртый шаг по улучшению MI – снижение цикломатической сложности.
Томас Дж.Маккейб вывел формулу цикломатической сложности юнита как разность рёбер (edges) и узлов (junctions) с добавлением удвоенного количества компонент связности (coherences):

CC = Edges – Junctions + 2*Coherences

Максимальное значение величины Маккейба утверждено Американским Национальным Институтом Стандартов и Технологий (NIST), равно 10, но последнее время расширяют до 15. Нам тестировщикам это значение говорит о необходимом количестве юнит-тестов. Более подробно о цикломатической сложности читайте в статье "Cyclomatic complexity". Цикломатическая сложность снижает индекс ремонтопригодности максимально на 2-3 пункта, поэтому её рассматриваем в последнюю очередь. График (см. Рис.16 "График и формула цикломатической сложности в рамках MI") показывает часть "0.23 * CC" из формулы MI.

 

 Рис.16 "График и формула цикломатической сложности в рамках MI"

По оси X берём целочисленное значение Cyclomatic Complexity (max=10 or 15), по оси Y видим объём снижения (коэффициент – отрицательная величина "-0.23") MI.
Для улучшения MI нужно уменьшать CC, то есть "выпрямлять" ход программы. Но учтите, что иногда сложные условия (композиция нескольких AND и OR) рассчитывается как одно, то есть уменьшается количество узлов и рёбер, следовательно и само значение CC будет меньше.

Рис.17 "Пример кода цикломатической сложности"

В примере (см. Рис.17 "Пример кода цикломатической сложности") процедура threeinone имеет одно сложное условие (CC=4 или CC=2), а процедура oneinthree – три простых условия (СС=4 всегда).

Итак, для оценки качества кода достаточно вычислить только одну величину – Maintainability Index. В слабом юните исправления следует применять по очереди к комментариям кода, количеству строк, операторов и операндов, узлов и связей хода программы. Элементарных знаний математического анализа и школьного курса информатики достаточно специалисту, решившему тестировать код на любом языке программирования, при этом не углубляясь в синтаксис языка.

Полезные ссылки:
* Качественный анализ программного модуля на основе метрик кода
* Don M. Coleman, Dan Ash, Bruce Lowther, Paul W. Oman. Using Metrics to Evaluate Software System Maintainability. IEEE Computer 27(8), 1994, pp. 44-49.
* Paul Omand and Jack Hagemeister. “Metrics for assessing a software system’s maintainability”. Proceedings International Conference on Software Mainatenance (ICSM), 1992, pp 337-344.
* Paul W. Oman, Jack R. Hagemeister: Construction and testing of polynomials predicting software maintainability. Journal of Systems and Software 24(3), 1994, pp. 251-266.
* The Maintainability Index was introduced at the International Conference on Software Maintenance in 1992
* To date, MI is included in Visual Studio (since 2007), in the recent (2012) JSComplexity and Radon metrics reporters for Javascript and Python, and in older metric tool suites such as verifysoft.
* Think Twice Before Using the Maintainability Index
* P. Oman
* J. Hagemeister