Читая Мишины отзывы и ссылки, думал тут про тестеров.
Там кто-то говорит про "плохих" и "хороших" программистов и тестеров, кто-то объясняет, что программисты делают "тяп-ляп" потому, что "типа тестер всё равно проверит", а тестеры типа относятся к программерам как к "багоделам".

Это показалось мне странным, я думал-думал и пришёл к такому вот выводу: что-то тут не так :)

Потому, что лично я, как программист, пишу код не для тестеров. И не с расчётом на тестирование. И для меня никаким критерием не является то, нашли тестеры баг, или не нашли, и если нашли, то сколько. Я об этом не думаю, когда пишу код. Я не думаю о тестировании, когда пишу код. Я не думаю о тестерах, понимаете?
Да, имеет значение, есть баги в коде или нет. Но я не думаю о тестерах как о некой страховке! Предполагая, что в коде может быть баг, я подсознательно предполагаю (и прямо вижу, так сказать), как этот баг находит кастомер, не тестер.
Я делаю задачу, и для меня, когда я сдаю эту задачу, эта задача закончена. То есть, с моей точки зрения задача выполнена полностью. Я сделал, я написал юнит-тесты на всё, что хотел и что имело смысл проверить, я проверил, как оно работает...
Такой мысли, что "если чё - тестеры найдут" просто не возникает.

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

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

Когда программист начинает думать про тестеров как о страховке, когда он начинает думать "сейчас я зачекиню, они проверят, и, если чё - я пофиксю", то он начинает думать о незаконченной задаче как о законченной, то появляется сама возможность, там, в голове, сдать полузаконченную задачу.
Когда программист думает о тестерах как о неком фильтре, который за него разберётся что он сделал “так”, а что “не так” и выдаст назад результат в виде “вот тут ещё доделай и вот тут подкрути”, начинается такая фигня, и потом эта фигня вырастает в “ну чё он придирается”.

Тестер для программиста никогда не должен быть некой сущностью, которая проверяет домашнее задание непоседливого школьника, указывая на недостатки и недоработки. А школьник этот вертится на стуле и стремится поскорее “ответреться”. А если тут ещё ПиЭм неправильный, который типа контроллирует и типа требует результата – то и вообще атас (это я всё о том же).

Так кто же такие тестеры получаются?
Тестеры “располагаются” уровнем выше, так сказать. Они располагаются на уровне продукта. Они не являются фильтром ляпов программиста, они отвечают за конечное качество продукта. За то, чтобы фичи, которые идут в релиз, работали так, как им допустимо работать. Поэтому, насколько я вижу тестеров, у них точно так же нет мыслей о том, что кто-то там наделал багов. Они просто не размышляют в категориях конкретных программистов, они мыслят на уровне “эту фичу я пропускаю к релизу, а вот эта не вполне соответствует спецификации + для релиза необходимо иметь вон ту штуку готовой”.

Такой подход + отсутствие персонального владения кодом (я не помню, писал про таковое, или посчитал очевидным, но это – Изначальное Зло, если оно есть в команде – срочно искоренять, а тех, кто это устроил – линчевать) ведут к естественному и правильному взаимодействию тестеров и программистов, которое выражается… в отсутствие персонального взаимодействия

То есть, я не имею в виду, что тестеры с программистами не общаются, вовсе нет. Общаются, и ещё как! Но это общение вида: я делаю фичу, или чиню баг, у меня есть вопрос, я пошёл к тестеру и попросил объяснить, как это должно работать, или как это воспроизвести, или что-то ещё.
Но это не взаимодействие типа “я напишу, а я проверь там” и “я проверил, ты там доделай”.

Поэтому есть команда программистов и команда тестеров. Которые просто выполняют разные задачи, на разных уровнях, а вовсе не “фехтуют” друг с другом.
И описанных проблем не возникает.

Писать по программированию особо нечего: не втянулся ещё после недельного перерыва, затеял большой рефакторинг, который позволит добавлять кучу интересного в  будущем, словом, рутина.

Поэтому напишу то, что навеяло “Я встречал такую ситуацию, когда программисты не хотят чтобы их код тестировали!”. Последние четыре года с тестированием в тех местах, где я работал, всё, можно сказать, нормально, поэтому немного поудивляюсь и опишу процесс.

Удивляться я буду нескольким вещам. Во-первых, как так – программист не хочет, чтобы его код тестировали? Может он еще и код-ревью проходить не хочет?? (шутка).
На самом деле, конечно, программист в тестировании заинтересован. Ибо это – вариант спихнуть часть работы на кого-то. Ведь в противном случае код либо придётся тестировать самому, либо краснеть за глупые баги в релизе.
Тестировать самому для программиста – пытка. К тому же, программист, я считаю, просто неспособен нормально протестировать приложение. Во-первых, он уже просто подсознательно производит действия, которые являются правильными. Например, программисту не придёт в голову полезть в XML-файл с данными, руками поправить там что-то, а потом попытаться с ним работать. Или заполнить весь жёсткий диск и посмотреть, как будет вести себя приложение при попытке автоматического сохранения состояния. А тестеры это делают (реальные примеры, это нас в Алкателе тест-команда такими вещами удивляла).
А во-вторых, он в основном не является конечным пользователем продукта и поэтому не в состоянии оценить и отработать нормальное пользовательское поведение, с чем тоже выходят иногда курьёзы.
Ладно, расскажу один – и пойдём дальше :)

На прошлой работе делали мы вторую версию некого существующего инструмента, в котором была интегрирована *nix-консоль. Консоль эта использовалась там для отображения прогресса того, что происходит на удалённой машине. Цветная вся такая.
И вот в один прекрасный день приходит нам толи от одного из пользователей, толи от тестеров пожелание: дескать, консоль эта работает нестабильно в такой-то ситуации, внимание, если вводить там команды. Типа, поправить бы в новой версии.
Упс, подумали мы и спросили тимлида. Он удивился и сказал: консоль точно не предназначалась для того, чтобы что-то в ней ещё вводить! Даже непонятно, как это можно сделать: она ж read only!. Решили узнать в другой команде, которая занималась написанием самой платформы. Тимлид ушёл, через пару минут вернулся с круглыми глазами. Рассказывает: подхожу к тамошнему инженеру, спрашиваю – команды вводишь в консоль? Ага, ввожу, говорит! Очень удобно – если что-то свалилось – тут же подправил, не надо логиниться, окружение поднимать! Только, говорит, я думал, что я один это знаю. И да, говорит, а можно подправить заодно, чтобы оно не падало? :)
Оказывается, в случае ошибки, когда вывод в консоль останавливался, она толи переключалась в том инструменте из режима read only, толи какую-то комбинацию клавиш нужно было нажать… Сейчас не помню, а исходников первой версии никто не видел, да и смотреть не хотел :) Но каким-то образом это сокральное знание расползлось по всему зданию (а может и дальше) и достаточно много чуваков пользовались такой фичей, считая, что они одни знают как это делать. И никто не жаловался на баги, потому, что знали, что это типа хак.
Вот так хак стал требованием :)

Помимо же явной заинтересованности я не вижу, как программист вообще может повлиять на процесс тестирования. Ну, разве что там существует какой-нибудь “руководитель”, с которым можно договориться, и который “волею, данною мне…” прикажет тестерам не тестировать определённый функционал ;) Другого пути я не вижу…

Расскажу про жизненный цикл разработки и место тестирования в нём на примере нашего веб-проекта.

Что мы имеем:

1. Основную ветку (Trunk) в системе контроля версий (про ветки я уже писал: Про бранчи);
2. Main Build с Main Build Agent – определение автоматического билда для интеграции и проверки кода;
3. UAT Build с UAT Build Agent – определение автоматического билда для UAT;
4. UAT Environment – неполный комплект серверов + база данных UAT (неполный потому, что всех типов серверов по одному);
5. Staging Environment – полный комплект серверов + staging база данных (полный потому, что зеркалирует следующую конфигурацию);
6. Production Environment – полный набор;

Что происходит:

1. В соответствии с принятым в команде соглашением, любой новый функционал разработчики делают в отдельных ветках. Забавно: ветки обычно называют шуточным именем своей sub-команды или названием фичи, которую делают. Например, у нас была ветка “Team3G”, ветка “Old Skool” и ветки типа “FormPropsRefactoring”, etc.
2. Когда новая функциональность готова, делается merge в Trunk.
3. Каждый check-in в Trunk автоматически запускает Main Build, который забирает код из системы контроля версий, собирает его в релизной конфигурации и прогоняет юнит-тесты. Если что-то пошло не так, то он (Main Build) начинает паниковать и слать письма о том, что в результате такого-то check-in таким-то пользователем код перестал собираться и тесты не проходят.
4. Ночью, а конкретно в 3:30AM, по расписанию срабатывает UAT Build. Этот зверь суровее: он тоже берёт последнюю версию, собирает и запускает юнит-тесты. Если всё прошло успешно, то он минифицирует и комбинирует javascript/css, автоматически заливает новую версию продукта на все UAT-серверы, синхронизирует базу данных (об этом тоже писал: Синхронизация баз данных), выполняет ряд служебных функций. После этого UAT готов к работе.
   В случае невозможности обновления UAT паники больше: письма идут и разработчикам, и тестерам, и менеджерам, которые используют UAT для “а! они это сделали! хочу посмотреть!”, и специалистам по требованиям (не буду называть их ПиЭмами, чтобы не было путаницы: они программистами не руководят).
   UAT Build может быть так же запущен руками любым членом команды в случае какого-то срочного багфикса или просто по договорённости с тестерами.
5. У тестеров есть какая-то своя тулза или планировщик, который, насколько мне известно, запускает ночью автоматизированные веб-тесты. Они хвастались, что у них уже в районе 400 веб-тестов есть. Ну, это которые умеют работать с продуктом в браузере, извне. Логинятся, делают там чего-то.
6. Утром приходят тестеры. Хитро ухмыляясь они смотрят на то, как прошли веб-тесты. Потирая ладошки они смотрят на ряд задач, которые были программистами помечены как законченные (Done). Закончен – значит ночью попал в UAT, думают они, щас мы его… И приступают к своей работе.
   Здесь я должен отметить: хочет программист, или не хочет программист, статус Closed задаче может поставить только тестер. И сделает он это только тогда, когда лично убедится, что штука работает. Ведь под статусом будет стоять его фамилия ;) Шучу. Но фамилия стоять будет. Если же штука не работает, то тестером в системе регистрируется баг, которому присваивается приоритет – и пошёл в работу. А задачу обратно в статус невыполненных.
7. Когда тестеры довольны тем, что происходит на UAT и когда пришло время по мнению специалистов по требованиям, протестированный продукт заливается из UAT на Staging. Там – копия реальной конфигурации. Там работают маркетинговые ребята, там проводятся демонстрации. Там же работают бета-пользователи. Там же продукт тестируется снова для того, чтобы убедиться, что всё будет работать в production. Разработчики туда доступа уже не имеют.
8. Когда все довольны тем, как работает staging, код из него переносится в production.

Вот и всё. В идеале перед пунктом 2) должен идти пункт 1.5), в котором будет сказано: “Когда разработчики считают, что задача выполнена, устраивается код-ревью изменений, внесённых в ветку”.

Отсюда видим:

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

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

Не люблю багфикс, никому не пожелаю. Так и хочется сказать: люди, не бойтесь делать нормально поддерживаемый код! Не бойтесь рефакторить! Душите все эти “нафигааа мне два класса, я лучше по-быстрому в одном методе напишууу”, лупите по рукам клавиатурами тех, кто делает такие подлянки :)

Вообще, на мой взгляд, основными допущенные изначально командой ошибками были:

1. “Сделаем это просто и быстро”. Любая задача решается “в лоб” без оглядки на какую-либо общую инфраструктуру, архитектуру, что бы то ни было. Проще написать спагетти-метод на две страницы, чем изобретать какую-то декомпозицию, API и т.д. Он будет работать здесь и сейчас – это нам и нужно.
2. “Будем думать только о реализации текущей задачи”. Программист получает таск (задачу) и делает её так, чтобы в максимально короткий срок выдать её решение. При этом человек не думает о том, насколько это решение укладывается в общую архитектуру, укладывается ли вообще и насколько просто/сложно будет потом это решение поддерживать. Сколько нужно усилий будет приложить потом, когда требования изменятся или расширятся. Как потом строить что-то поверх, имея в основе данное решение. Всё это приносится в жертву тому, чтобы поскорее поставить задаче статус “done” и объясняется тем, что “сделано быстро и просто, надо будет – просто переделаем этот кусок”.
3. “Решим конкретную задачу”. При этом такое “решение” совершенно не является решением. Оно является костылём. Как-то что-то подпёрли – вроде пошло дело. Что-то помешало – подопрём и это немножко с другой стороны. Работает же! О! очень не люблю фразу “работает – не трожь”. Есть основания.
4. “Кто делал эту часть?”. Люди, которые делают какую-то часть проекта. Другие люди не знают этой части, не знают, как оно сделано, почему оно сделано так, насколько оно вообще сделано (несмотря на статус “done”). Когда возникают какие-то проблемы или появляются новые требования, в команде возникает вопрос “Кто у нас делал эту подсистему?” и ответ “А это не я, это XXX” и задача автоматически делегируется этому человеку.
5. “Поставим костыль”. Очень похоже на номер 3, но поскольку это оооочень плохо и мы ооооочень много на этом накалывались, напишу ещё раз :) Внося исправление, программист видит, что там, в коде, не решение задачи, а какой-то бред написан (утрирую). Даже если задача попала ему в соответствие с пунктом 4. А уж если нет… При этом он, в соответствие с 2 и 3 думает: “А ну его нафиг! Щас вот тут подправлю, подфиксю – и будет работать”. И подфиксивает. И оно работает. До следующего раза. Потому, что решение так и не было предложено. Потому, что для того, чтобы получить решение, нужно много отрефакторить и много переписать. В результате, как показывает практика, хотя кода становится в полтора раза меньше, но времени-то тратится куда больше на то, чтобы написать это решение плюс повыкидывать те костыли, которые уже успели понаставить.

Сейчас эти проблемы в нашей команде можно сказать решены. Поздновато они были решены, но такова жизнь. За это заплачено достаточно большой потерей времени (можно было сделать раньше) и достаточно большими переработками всей команды (отчего и устал и ушёл в отпуск, и многие сейчас уходят).
И всё это вылилось, как я сказал, в несколькомесячный трудный, унылый, утомительный багфикс. Наша команда ошибки осознала и исправила (хоть и не осталось практически никого из “первого состава”).
Всем остальным от всей души советую этих ошибок не допускать, а если они есть – вырывать с корнем прямо с понедельника :)

Cебе желаю, чтобы багфикс к понедельнику благополучно закончился :)