Свой велосипед

Был на Highload++, слушал доклады.

В нескольких докладах про изменение/развитие существующих систем заметил общий вполне понятный и разумный шаблон рассказа: встретили проблему - осмотрелись вокруг - решили делать что-то своё - разработали свой "велосипед".

* Здесь и далее буду называть "уникальные решения и разработки" велосипедами. Не потому, что в них есть что-то плохое (они, наоборот, как правило весьма достойны и хороши), а во-первых для краткости; во-вторых чтобы различать в тексте "решения", которые ментальное усилие выбора из нескольких вариантов, и "решения", которые программные системы и разработки; в-третьих сами докладчики их так называли.

Доклады были совсем не про механизм принятия решений, так что в них больше говорили про устройство велосипедов, а не о том, почему решили их строить. Вот несколько мельком озвученных причин (не дословно):

• Те, кто уже решил подобную задачу, не рассказывают подробности, так что приходится сочинять самим
• Можно было выбрать из вот таких инструментов, один из них неплохо подходил, но мы решили сделать по-своему
• Показалось, что людям будет трудно освоить новый инструмент, поэтому решили подпилить свои, всем уже знакомые

Некоторые вообще никаких причин не упоминали, а просто рассказывали про свой велосипед.

Но мне стало интересно, как/почему/в какой момент люди и компании решают, что лучшее возможное решение для вот этой конкретной проблемы - свой велосипед.

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

• Синдром not invented here
• Люди недоразобрались с уже существующими велосипедами
• Люди действительно столкнулись со специфической проблемой требующей своего специфического велосипеда

На самом деле, полагаю, чаще всего присутствуют все три причины в каких-то пропорциях.

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

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

Нужно потратить время и силы (вообще говоря - без гарантии успеха).

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

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

Есть старая шутка про написание научных статей: вывод это то место, где автор устал думать. Утрированно, но не лишено правды.

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

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

XPath в картинках

XPath - язык запросов, позволяющий обращаться к элементам XML-документа.
XPath активно используется в мире автотестов веб (ибо веб-страница - частный случай XML-документа).

В целом XPath штука несложная, если разобраться с двумя основными концепциями: осями и предикатами.

Качественный субъективизм

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

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

В общем, все молодцы, а на выходе какашка. Нормальный процесс переработки сырого продукта.

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

SUT с человеческим именем

Допустим я тестирую продукт, который работает [в том числе] с "человеческими данными".

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

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

Но с некоторых пор я стал чаще использовать данные похожие на настоящие имена, фамилии и адреса. Ибо не фиг. И это таки немножко помогает в тестировании.

Уважение к старшим

С легаси кодом не просто.

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

Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой - лучше к нему не прикасаться.

Так вот знаешь, что? Уважай его.

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

Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде - это следы древних багов. Будешь небрежен - и те же баги повторятся уже в новом коде.

Это легаси. Уважай его.

Сказка о неразобранных автотестах

Жил был проект, а в проекте делали продукт, а у продукта была веб-морда, и нужно было ту веб-морду тестировать, и были автотесты ("Selenium" - подумал Штирлиц) для всех и всяческих сценариев. Автотесты регулярно запускали на свежих билдах, они достаточно быстро выполнялись и радовали всех "зелёными" результатами. "Красные" результаты быстро исследовали, чинили проблему, и каждый следующий запуск был "зеленее" предыдущего. Скоро сказка сказывается, да не скоро дело делается.

У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?

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

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

Разработка и Продажи

Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи    (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи    (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи    (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь):  Вот  черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес

P.S. Основано на вымышленных событиях

Связанные многочисленными ниточками

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

Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.

Стоит потратить пять минут на чтение.

Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

100500 конфигураций.

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

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

Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).

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

4k+ знаков про ТО

Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.

Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).