Пророчества

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

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

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

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

Offside outsourcer

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

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

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

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

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

Призвание тестировщика

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

Для развития качества тестирования читайте статьи этого блога из рубрик "Нюх на баги", "ТТ = Тестирование и Театр", "ГКЧП".

Решение проблем

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