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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всего лишь пара изменений

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

Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в GUI. Или поменялась очередность шагов визарда. Или изменилась давно привычная логика работы. Да мало ли что. А чтоб такие изменения планировались, он и не слышал. Баг писать? Или так и должно быть теперь?

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

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

И вопрос - как эти изменения контролировать?

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

Правильный багрепорт для всех и каждого.

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

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

Проблема
Проблема в том, что среди тестировщиков людей умеющих говорить кратко, точно и по делу не больше, чем среди любого другого множества людей. Таких людей вообще не так уж много к сожалению.

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