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

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

Удивляться я буду нескольким вещам. Во-первых, как так – программист не хочет, чтобы его код тестировали? Может он еще и код-ревью проходить не хочет?? (шутка).
На самом деле, конечно, программист в тестировании заинтересован. Ибо это – вариант спихнуть часть работы на кого-то. Ведь в противном случае код либо придётся тестировать самому, либо краснеть за глупые баги в релизе.
Тестировать самому для программиста – пытка. К тому же, программист, я считаю, просто неспособен нормально протестировать приложение. Во-первых, он уже просто подсознательно производит действия, которые являются правильными. Например, программисту не придёт в голову полезть в 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), в котором будет сказано: “Когда разработчики считают, что задача выполнена, устраивается код-ревью изменений, внесённых в ветку”.

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

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