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

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

В результате мне приходится идти либо к автору, либо к менеджеру и допытываться, о чем тут речь. Человек, как правило, пару минут чешет затылок, пытаясь вспомнить, о чем тут шла речь. Потом его озаряет:
- А! Вспомнил! Это уже давно исправлено.
- Замечательно, только я не привык в таких вопросах верить на слово. Как это воспроизводилось?
- Э-э-э... а я не помню.

В результате тратилась куча времени (моего и собеседника) на то, чтобы вспомнить подробности. И, помимо всего прочего, примерно в каждом третьем случае оказывалось, что дефект либо не исправлен, либо исправлен не до конца - как правило, потому, что разработчик толком не знал, что именно надо исправлять.

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

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

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

Последней каплей стала следующая ситуация. Наткнулся на багу в состоянии "исправлено". Даже проставлена версия - как раз та, что у меня стоит на тестовой системе. Вроде даже вполне приличное описание, по крайней мере, понятно, что тестировать. Минут двадцать пытаюсь ее воспроизвести разными способами - не воспроизводится. Со спокойной совестью закрываю. Через пять минут приходит сообщение от разработчика, который над ней работал:
- Ты зачем ее закрыл?
- Я ее протестировал - на QA-билде она не воспроизводится.
- А у меня воспроизводится.
- Как? Расскажи шаги?
- Не знаю, я просто вижу, что в коде ошибка, а как воспроизвести - не знаю. Я как раз над ней работаю.
- Ладно, а почему ты ее пометил как "исправлено"?
- А я ее для себя пометил. Ты тестируй только те, что мы тебе в списке, прилагавшемся к билду выдали.
- А какого ж черта ты версию указал ту, которая уже в QA?
- А какая сейчас в QA?

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

К моему удивлению, особых препятствий эта мысль не встретила, и на следующий день была назначена встреча, посвященная обсуждению процесса. Я подготовился к встрече основательно, даже задержался на полтора часа на работе. В итоге на свет появилась черновая презентация, где я расписал основные преимущества использования формального процесса, предлагаемую схему самого процесса и распределение ответствености. Для красоты даже понадергал цитат из статьи давно мною любимого Джоэла Сполски. Утром мы с моим непосредственным руководителем QA-щиком еще немножко эту презентацию подкрутили и получилось вполне достойно.

Встреча прошла гладко. Были долгие споры - но все конструктивные. Правда, я допустил пару чисто дипломатических ляпов. Во-первых, чуть не оттер на задний план собственного руководителя (поскольку процессы - это мой конек, и я действительно неплохо в них разбираюсь), во-вторых - в запале заявил, что "худшее описание дефекта - это то, которое содержит copy-paste из поля Summary". Да, это действительно так, только я забыл, что самый большой любитель создавать такие описания - наш менеджер проекта. Надо было все-таки как-то помягче :-)

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

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

Я доволен :-)

Current Music: Dire Straits - Sultans Of Swing
Tags: testing, job

From: yusup Date: 02/20/2008 00:53:37   слушай, а как вообще можно работать без чёткого описания процесса?? как они до тебя там жили? :)

From: svalivshiysja Date: 02/20/2008 05:35:28   Юр, ты что, с луны? Не, это ж я оттуда:) Поверь мне - именно так и обстоят дела в большинстве софтверных контор, особенно на этапе бурной разработки и захвата рынка, т.е. тогда когда продано еще то что даже не придумано:)

From: _myx Date: 02/20/2008 07:14:42   Не, Толик, не совсем так. Во-первых, UBS явно не попадает в категорию конторы, которая находится на этапе бурной разработки и захвата рынка :-) А во-вторых, софтверной конторой назвать его можно с очень большой натяжкой (в отличие от той же CQG, хоть их сфера деятельности во многом и похожа). Ключевая разница в том, UBS пишет софт для себя, а CQG - на продажу. Но все равно, меня очень сильно удивило, что в банке такой бардак. Это, кстати, касается не только процессов разработки. Вспомни, как я плутал по зданию :-)

From: yusup Date: 02/20/2008 13:18:01   верю :) но поскольку я с самого начала попал в компанию с очень солидными заказчиками, мне трудно себе представить что такое бывает :))

From: _myx Date: 02/20/2008 07:09:21   Разбаловался ты в своем Майкрософте :-) Гм, а я - соответственно, в CQG :-)

From: yusup Date: 02/20/2008 13:17:06   да у нас не только Microsoft :) мы вот начинаем Linux тестировать с понедельника :) попробовали бы мы расслабиться и не следовать нашим процессам хоть на минуту :))

From: lansun Date: 02/20/2008 06:01:18   Да, непросто обстоят дела на чужбине. Начинаю понимать, что у нас процессы поставлены практически идеально =)

From: _myx Date: 02/20/2008 23:20:05   Кстати, а как вам удается сохранить целостность? Вроде же вы тоже аутсорсинговая компания?

From: lansun Date: 02/21/2008 07:59:43   Думаю, на этот вопрос тебе vittt ответит лучше, чем я =)

From: allucinazione Date: 02/20/2008 08:29:26   Построил всех? :)

From: _myx Date: 02/20/2008 23:11:34   Получается, что так :-)

From: ksch Date: 02/20/2008 15:47:05   Молодец, приедешь - будет тебе пирожок с картошкой :-)

From: vittt Date: 02/20/2008 18:45:23   по ощущениям от прочитанного - полный бардак. Но, Влад, я в тебя верю!

From: _myx Date: 02/20/2008 23:17:58   Спасибо :-) Думаю, все получится. Еще две недели назад я сказал себе: "либо меня выгонят нафиг, либо я всех построю - третьего не дано". Пока вроде бы получается второе :-)

From: aserofeev Date: 02/20/2008 20:21:51   ужас-то какой...((( ты меня прямо напугал... я теперь и не знаю чего от новой работы ждать...)) тут-то у меня весь Quality Control налажен уже по полной программе - и тебе багтрекинг полноценный (все всё везде заполняют - иначе ведь достану :)), и тебе письменные удоведомления о сборке билда и даже wiki проектная есть... программисты доступ к тестовым машинам вообще не имеют, кроме того, кто деплоит... и документация в соответствии со стандартами IEEE... но мне и этого мало :)) блин, а как подумаешь, что всё заново надо будет начинать и до крови биться за каждую мелочь... так и уходить можно расхотеть :))

From: _myx Date: 02/20/2008 23:16:26   Самая распространенная ошибка: считать, что все плюсы старой работы сохранятся и на новой, а все минусы - останутся в старой :-) А ты смотри на это с другой стороны: наладил, заработало - оставляй преемника и неси добро дальше.

From: aserofeev Date: 02/21/2008 06:26:30   Так и делаю... Больше всего меня в таких случаях challenge привлекает - смогу ли я донести добро в новый проект, и какого качества это добро будет ;-) Ибо когда все налажено, то скучно становится. "А он, мятежный, хочет бури..." и все такое ;-)

From: tan_chick Date: 02/26/2008 14:32:44   Дочитала "до была назначена встреча, посвященная обсуждению процесса." Чуть не разрыдалась, сдерживая приступ дежавю! :)

From: _myx Date: 02/26/2008 14:54:17   А ты его не сдерживай :-) Тем более, что, как мы все знаем по документальным фильмам, "дежавю - это сбой в Матрице" :-)