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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Между роботом и обезьяной

Есть две точки зрения на тестирование, с которыми в свое время сталкивался практически каждый тестировщик. Первая - что тестировать может любой, ума тут не надо: сел и прокликал. Вторая - что вообще не надо тестировать людьми, надо просто автоматизировать все тесты и жить счастливо. Эти подходы, пожалуй, несколько, гм, наивные (кто-то все равно должен эти тесты придумать и описать; кто-то должен приглядывать за автотестами и анализировать результаты их работы, и так далее), но я сейчас не об этом. На деле, мне кажется, это одна и та же точка зрения. В обоих случаях как минимум предполагается, что можно описать тесты таким образом, что их успешно выполнит любой - хоть студент, хоть скрипт. Или в других терминах - хоть обезьянка, хоть робот. Года полтора назад Макс cartmendum Дорофеев устраивал доклад-состязание "Обезьянки против Роботов"; если вдруг кто не видел - рекомендую к просмотру. В докладе отлично сформулирована разница между этими "крайностями": "Обезьянки умеют немножко смотреть по сторонам. Роботы не могут смотреть по сторонам. Они могут смотреть в точку, но быстро и долго". Это существенное различие, которое позволяет в разных ситуациях выигрывать то Обезьянкам, то Роботам. 

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

Коротко говоря - они не умеют думать. Роботы - совсем, Обезьянки - почти. И в этом смысле тестировщик круче и Обезьянки, и Робота в равной степени. Ну разве что Робот быстрее кликает. Зато тестировщик способен понять, что тут кликать вообще незачем. 

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

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

Удачи вам, верных Роботов, смышленых Обезьянок и ясного взгляда.