Пророчества

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

Tester's KPI

Product Manager (РМ) команды разработки в ConquestSS многие годы опирался на количество задач при оценке уровня специалиста. Поэтому, когда команда разрослась, поручил мне еженедельно публиковать в чате отчёт об обработанных задачах в разрезе продуктов (от трёх до шести приложений) и о переписке тех.поддержки (сколько получено писем, сколько отправлено ответов, сколько застряло в обработке). В те недели, когда у меня были отпуска, количество обработанных задач резко падало, и это первым заметил PM. Сделав выборку значений и подставив периоды моего отсутствия, у меня получился нижеследующий график.

Схождение отпусков и провалов задач

Скачки снижения количества задач (голубая и рыжая кривые) в точности совпали помесячно с периодами моих отпусков (коричневая кривая, где 100 - наличие отпуска, 0 - рабочий период). Что в точности подтвердило гипотезу РМ.
Но мне стали интересны и другие мои идеи.
1. Как часто стоит менять курируемый продукт? Ежедневно, как это делал РМ на стендапах, или закрепить один продукт за каждым тестировщиком на весь период спринта?
2. Зависит ли производительность тестировщика от его гендерности?
3. Кто эффективнее обучает новичка?
Для этого была собрана нижеследующая таблица.

Данные о сроках и количестве задач в разрезе тестировщиков

Имя (пол)		Tester_1 (F)	Tester_2 (F)	Tester_3 (F)	Tester_4 (F)	Tester_5 (M)	Tester_6 (F)	Tester_7 (M)
Через N дней оформлен "свой" баг		1	13	4	15	11	9	23
Через N дней оформлена первая задача из техподдержки		16	46	3	15	11	9	23
Срок в команде (месяцы)		165	26	16	26	6	5	2
Обработано всего задач за весь период		32457	4510	2181	1632	548	427	157
Скорость (обработано задач в месяц)		196,7	173,5	136,3	62,8	91,3	85,4	78,5
Количество оформленных задач (найденные баги самостоятельно и предложения из техподдержки)	всего	17204	1697	814	1362	188	148	51
	в т.ч. своих	12187	994	497	707	91	65	35
	%	71	59	61	52	48	44	69
Курируемый продукт		All	P_1, P_2, P_3	P_1, P_4	All	P_1, P_3, P_4	P_2	P_1, P_4
Количество обработанных задач по Product_1	всего	4981	3042	1116	926	288	16	147
	в т.ч. новые	3779	1136	260	798	101	10	44
	закрытые	1202	1906	856	128	187	6	103
Количество обработанных задач по Product_2	всего	5920	923	86	324	16	400	0
	в т.ч. новые	3701	328	16	292	12	128	0
	закрытые	2219	595	70	32	4	272	0
Количество обработанных задач по Product_3	всего	21016	336	31	163	164	11	0
	в т.ч. новые	11388	174	6	152	42	10	0
	закрытые	9628	162	25	11	122	1	0
Количество обработанных задач по Product_4	всего	540	209	948	219	80	0	10
	в т.ч. новые	444	59	532	120	33	0	7
	закрытые	96	150	416	99	47	0	3
Кто обучал внутренним правилам		самостоятельно	Tester_1	Tester_1	PM	Tester_3	PM	Tester_5

Если рассмотреть цифры в строке "Скорость (обработано задач в месяц)" в зависимости от строки "Курируемый продукт", то можно предположить, что тестировщик - универсальный солдат, легко перескакивающий с одной темы на другую. Но если учесть "Срок в команде (месяцы)", то гипотеза становится сомнительной. Особенно после отчёта на одном из стендапов, когда Tester_6 отчиталась об оформлении одного бага, а от Tester_1 за этот же день было добавлено в BTS более 20-ти задач.
На второй мой вопрос о половой принадлежности цифры мало что могут ответить. Поскольку не было возможности разбить задачи по их тематичности, которая в большей степени влияет на эффективность распределения работ. Более подробно об этом читайте в моей статье "Гендерность на страже качества или Вам Девочку или Мальчика?".
А вот на третий вопрос об обучении цифры вполне подтвердили мою гипотезу, что передавать знания должен единый лидер. Скорость учеников прямопропорциональна скорости учителя. Взгляните на строки "Скорость (обработано задач в месяц)" и "Кто обучал внутренним правилам" в купе со значениями "Курируемый продукт".
По таблице может у вас возникнуть вопрос о наличии данных в продуктовых деталях у тестировщиков, занимавшихся не всеми продуктами. Это последствия частой смены кураторов, которую так усердно лоббировал РМ, желая превратить нас в универсальных солдатов. Как следствие, одна из тестировщиц на указания шефа стала отвечать смайликом "Yes, Sir!", но он воспринял это лишь шуткой, не придав значения хлипкости командного духа подчинённых.
Количеством закрытых в спринте задач любил бахвалиться РМ и перед вышестоящим руководством, не вдаваясь в подробности того, что половина из них были элементарным откатом к функционалу прошлых версий. На каждое изменение в продукте "деды" тестирования всегда оформят, как минимум, две задачи. А если тестировщик более внимательно слышит пользователя, нежели сборщик бэклога РМ, то процесс его пополнения будет бесконечным: РМ навязывает свой взгляд на решение, а тестировщик инвертирует к пожеланиям пользователей.

Гипотезы

Прошедшая неделя заставила меня искать причины багов на порталах для ведения блогов.
Началось с того, что Blogger.COM перестал отображать некоторые картинки. Пройдясь по советам для решения аналогичных проблем, мне не помогло следующее:
- проверка на использование последней версии браузера;
- очистка памяти;
- кроссбраузерные тесты.
Эти все стандартные советы от техподдержки портала блоггеров были испробованы, о чём и было упомянуто в моей первой жалобе. Но золотые и платиновые советчики всё равно мурыжили меня первые дни всё теми же советами.
В первом же моём отчёте о проблеме был описан кейс со скриншотом, где конкретно описывалось место нестыковки back-end-а с front-end-ом. Но моя гипотеза о несоответствии лимитов на стороне пользователя и серверов была проигнорирована. Почему? Это прояснилось позже, когда техподдержка призналась в полном непонимании причин проблемы.
Суть проблемы в том, что картинки блоггер загружает через один интерфейс, который изначально благополучно фиксирует и отражает залитый на портал image, но в режиме просмотра картинка становится недоступной для некоторых пользователей и читателей блога. Из одного из разбирательств, а также проанализировав свои статьи с прикреплениями, выяснилось, что только с  1.bp.blogger.com  и  2.bp.blogger.com  доменов картинки не отображаются, а с  3.bp.blogger.com  и  4.bp.blogger.com  просмотр работает полноценно и в сжатом, и в галерейном режимах.
Поскольку мне известны принципы работы с partition, storage, rac, tns в Oracle DB, то одной из моих гипотез было то, что данные портал хранит разделяя на несколько серверов. И естесственным был вопрос к техподдержке для выяснения несоответствий лимитов при добавлении данных и при их считывании. По моей догадке владелец блога загружал картинки по одним условиям, не имея возможности выбрать сервер, а читатели блога получают данные только из лимитированных доменов. Поэтому мне, как пользователю, нужна настройка выбора места хранения images на момент их загрузки на портал. Но эта заявка, как и гипотеза, оказались излишними после того, как техподдержка разъяснила, что Blogger как бы хранит каждый мой аттач в четырёх экземплярах!
Такая структура данных мне очень импонирует, но всё же, как могло произойти такое, что в один (не-)прекрасный день часть картинок стала недоступна? Заливка всё также осталась автоматической с точки распределения доменов, но некоторым читателям после неизвестного апдейта портала был перекрыт доступ к  1.bp.blogger.com  и  2.bp.blogger.com  доменам. То есть мне, как владельцу блога, пришлось вручную в каждой статье для каждой картинки менять номера хранилищ с 1 и 2 на 3 или 4.
Здесь родилась вторая гипотеза о причине проблемы. Не могу похвастаться своими глубокими знаниями в серверных технологиях, но вполне понимаю, что ограничения на домен могут быть выставлены на обоих концах: как у моего провайдера, так и на исходном сервере. Далее мои рассуждения сводились только к стороне поставщика портала, потому что провайдер интернета обычно перекрывает домен верхнего уровня, а не третьего-четвёртого. К тому же сообщение в браузере о недоступности какого-то IP адреса по причине его внесения в чёрный список значительно отличается от предупреждения об отсутствии адреса.

Так сообщается о сайте из чёрного списка

Edge предлагает несколько workaround

А вы дописываете в описании бага свои гипотезы о причинах проблемы? Конечно, программисты сильно обижаются, когда их как котят тыкают в место причины, но ведь это значительно сокращает время исправления.

К сожалению, мои гипотезы пока не подтвердились и не отверглись, поскольку техподдержка портала Blogger ещё не выяснила конкретные причины ограничения на просмотр картинок с   1.bp.blogger.com  и  2.bp.blogger.com  доменов.
А одним из моих обходных шагов было создание блога-спутника. На выбор альтернативного портала блоггеров ушёл день. В инете много советов по подбору места хранилища ваших мыслей:
12 лучших бесплатных блог-платформ
Какую платформу для блога выбрать
С чего начинается блог: 10 лучших бесплатных платформ
Выбираем платформу для ведения блога

Попытки создать новое пространство для моих записей с полноценным отображением картинок ни единожды заставило меня чертыхаться. Например, LiveJournal был отвергнут из-за малого пространства для прикреплений (до 500МБ), а Яндекс.Дзен и Инстаграм-подобные - из-за размера сообщений (для моих достоевско-толстовских широт никак не хватит нескольких строк). К сожалению, WordPress не оказался таким же простым и удобным, как Blogger.COM:
* наполнение контента страницы очень быстро начинает тормозить, то есть у портала есть серьёзные проблемы при обмене данными во время активности черновика, буквально после вставки 4-5 блоков. Blogger тормозить на черновике начинает намного позже, при объёме раз в 5-10 большем;
* нет возможности быстрого перехода от режима html-редактора к пред-просмотру, как это работает в Blogger. Точнее сказать, мне совсем не удалось найти в WordPress какой-то редактор текста html, чтоб не таскать "недвижимые" блоки и не удалять наугад пустые. Да, в Blogger в режиме просмотра тоже не видны границы пустых блоков и нет построителя таблиц, но их быстро можно переделать в html-режиме;
* те типы блоков, которые предлагаются для автоматической вставки, не могут удовлетворить все мои запросы: раскрасить часть текста, задать фонт отдельному слову и другие мелочи, либо интерфейс WordPress не столь интуитивен;
* дизайнерские штучки оказались совсем не юзабельными, поскольку обучающий режим не очищает за собой интерфейс и последняя плашка не пропадает даже после перезагрузки браузера;
* с большим трудом удалось вставить некоторые плагины для фильтрации, поиска и статистики;
* в WordPress при ведении блога обязательно наличие двух страниц (Home, Blog Feed), а в Blogger страницы можно вообще не показывать;
* Blogger нигде не ограничивает по объёму при бесплатности услуги, а WordPress даёт максимальное пространство (до 1ГБ) без оплаты среди альтернативных "дневников";
* из положительного: в WordPress есть структурированные рубрики и дополнительно метки, а в Blogger только метки.

На моё счастье техподдержка Blogger разродилась подсказкой для временного обхода проблемы (вручную поменять 1 и 2 на 3 или 4 в ссылках на картинки), поэтому дальнейшее сравнение функционала откладываю до следующей критичной проблемы на Blogger.COM.