А сегодня Perfect Clock можно получить совершенно бесплатно.

На Software-Testing.ru опубликована новая статья Натальи Руколь «Управление тестированием: непрерывно совершенствуем процесс!». Меня заинтересовало уже по названию, поскольку почти год назад я уже писал о своём подходе к непрерывному улучшению процесса тестирования и всегда очень интересно посмотреть на другие мнения (не так уж много людей готовы об этом говорить). Наталья подходит к вопросу совершенствования по другому.

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

На мой взгляд, для такого подхода нужно иметь хотя бы небольшой опыт и понимание того, что проблемы при решении задачи — это самое обычное дело и какие бы они не были их надо решать, хочется или нет. На эту тему у Александра Орлова есть хорошая заметка.

Я люблю август. Во-первых, это наиболее комфортный по температуре и погоде, для меня, месяц. Во-вторых, это время затишья в работе, по всей Европе множество людей едут в отпуска. И в третьих, это время подготовки к началу бизнес сезона, много новостей о конференциях, помимо SWRUS Kiev и SQADays, о которых я писал чуть раньше, анонсированы AgileDays в Питере, IT Jam в Харькове, While Rider (странная у них какая то ценовая политика) и Patterns&Practices Summit Russia (Microsoft), так же тренеры представляют свои новые (не всегда) курсы и программы гастролей. Новые версии программ выходят аккурат перед августом, вероятно прицел на тех, кто работает даже на отдыхе — прочесть хотя бы документацию и заодно послушать вебинары (не у всех), а к выходу из отпуска уже принять решение о покупке новой версии или тренингах для персонала. Интересное время, много информации и многое можно успеть переварить.

На фоне этого торжества технологий и знаний – тихо, мирно и без непоправимых массовых последствий прошло резкое отключение электричества (почти половина Питера и существенная часть области). Меня это событие застало в электричке средне-дальнего следования (в Выборг, 140 километров от Питера), аккурат посередине. Сотовая связь продолжала работать, и даже мысли не было, что жахнула ЛАЭС проблемы могут быть масштабны и длительны. Уже только после того, как заработало радио стало спокойнее.

На следующий день для разрядки, да и просто из любопытства мы отправились на страусиную ферму (экзотика всё-таки в здешних местах). Маруся отказалась от поездки под предлогом, что ей всё-равно [хоть и не в зоопарке] жалко этих животных. Страусиная ферма оказалась на территории загородного подворья монастыря Оптина Пустынь. Нас это ничуть не смущало, но ехали мы всё-таки изначально на другую ферму (да, этой экзотики оказалось не так уж и мало). Территория подворья пересекается с базой отдыха в Сосновом Бору, и храм князя Александра Невского (1893, 1907) соседствует с развалинами корпусов санатория. Чуть дальше, на берегу Краснофлотского озера уже основная часть подворья и недостроенный храм Амвросия Оптинского (в общем людям верующим есть где разгуляться) с видом на двухэтажный коровник и озеро. На спуске к озеру как раз и располагается ферма, кроме страусов в ассортименте (которые, судя по рассказам дают жару остальным обитателям) там живут белки, олени, деревенская живность (коровы, козы, какие то странные бородатые бараны, похожие на козлов), карликовые кабаны бенгальские тигры и еноты отшельники, которые с нами общаться не захотели, но в целом жителям мегаполиса тоже есть где разгуляться. Есть яблоневый сад и пасека (но монахи что-то переборщили с ценами на мёд). Над всем этим возвышается 99 метровая вышка Теле2 с четырёх метровым крестом сверху. Говорят, особенно впечатляются вертолётчики (военная часть недалеко).

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

И снова, в конце сентября, мы отправляемся на конференцию независимых разработчиков в Киев. В этот раз она двухдневная и местом для проведения выбран пригород «Конча-Заспа» и база «Ярина», вроде как на берегах Днепра (любопытно посмотреть). Время проведения 25 и 26 сентября. Сама по себе конференция бесплатная, оплачивается только проживание, питание и две неформальные вечеринки, прости господи.

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

Программы выступлений пока нет (рано), но в целом понятно, что приедут представители регистраторов, кто то от больших спонсоров, наверняка будет выступать Карполан. Мне лично очень интересно, что в этом году будут рассказывать про развитие рынка веб-приложений и тестирование. В прошлом выступил только Александр Балабанов из TestLab². Тогда мне его рассказ показался очень уж поверхностным, но его сервис живёт и это означает, что знает он тестирование на достаточном уровне. Было бы интересно послушать о развитии самого сервиса, хотя в целом понятно, что эта информация скорее всего не будет доступна. Общее расписание обещает довольно насыщенное общение. Фактически 12 часов только официальных докладов и судя по времени столько же отводится на неформальное общение.

Поедем мы, как и раньше, на машине и за день преодолеем расстояние чуть более 1200 километров. Поскольку поедем утром, то я предчувствую необычайно интереснейшие виды. Там по дороге есть несколько мест, где деревья полностью накрывают дорогу, образуя подобие арок. Ночью мы только очертания увидели и только из рассказов Гриши узнали о том, как это выглядит днём. Нельзя забывать и об осенней Белоруссии и Украине, лишь бы опять не было непонятных проволочек на границе с Украиной.

Зарегистрироваться на конференцию SWRUS Kiev 2010 можно здесь.

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

Сообщество тестировщиков Петербурга, обзавелось свои сайтом и обособленной от начального сообщества жизнью. Благодаря усилиям Алексей Лянгузова и Романа Твердохлебова развитие сообщества поражает — кроме сборов началось проведение семинаров по тестированию на площадках Yota и Bercut.

Сообщество под эгидой Software-Testing.ru напротив опустело, хотя вполне возможно, что это только из-за по-настоящему южного лета, а может потому что наиболее активные участники перетекли в свои локальные сообщества. Если это так, то возможно это шаг назад в создании общего информационного пространства на территории СНГ.

Алексей Баранцев продолжает вести тренинги, которые реально могут помочь желающим улучшить свои познания в QA. Он знает о чем говорит и излагает всё очень доходчиво. Ближайшие тренинги пройдут в cентябре в Питере:

• 09 сентября, Тест-дизайн от А до Я
• 10 сентября, Автоматизация тестирования веб-приложений: Selenium
• 11 сентября, Тестирование методом свободного поиска
• 12 сентября, Быстрый старт в тестировании ПО

Льготный период оплаты участия на SQA Days 8 продлён до конца августа. Выглядит так, как будто никому событие неинтересно, но я думаю, что опять виновато лето и наиболее отпускной месяц август. Программа конференции еще не сформирована, так что риск в какой то мере есть, хотя о прошедших конференциях SQA Days значимых плохих отзывов не наблюдается (хотя про недостатки пишут).

Прошлые выпуски: 2, 1

Мне показалось это наиболее подходящей метафорой к такому стилю работы с задачами.

Если задача есть, значит её нужно сделать самому, либо передать тому, кто может сделать, либо закрыть, но не задерживать у себя. Сделав свою часть оставить комментарий и передать задачу коллегам.

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

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

Один из моих любимых примеров стоимости отношения к трекингу работы.

Я долго работал с разработчиком, который о фиксах писал так «Fixed in b.1.1». Проблем с этим не было никаких, пока на вполне тривиальный фикс в комментария не появилось «Fixed in Prod A b.1.2 & Prod B b.4.4». В CVS изменения были сделаны в более чем сорока файлах. На следующий день, после комита, разработчик ушёл в отпуск.

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

Кстати баг можно было и не исправлять, он не был виден пользователям и в целом они бы о нём никогда бы и не узнали и через несколько месяцев часть, на которую было потрачено столько сил, была полностью переписана. Но ни информация о планах разработки, ни видимость ошибки не попала в комментарии к задаче. Стоимость этого не трудно посчитать приблизительно вычислив финансовые затраты на двух разработчиков ($100x2 в день) и одного тестировщика ($60 в день) за всё время потраченное на исправление ошибки, анализ исправлений и переписывание кода ($260 долларов  в день в пустую, не считая косвенных убытков и того, что время могло быть потрачено на более ценные задачи).

Это кстати ещё одна вариация неявного саботажа работы (по недомыслию). Но здесь практика работы с задачами могла бы предотвратить трату времени.

Основная проблема при организации работы в QA — нужно помнить всё и даже то, что было давно. Чем больше задач на входе, тем быстрее всё уходит в лёгкий хаос и таски начинают подвисать, и время на переключение между задачами начинает стремительно расти. Вместе с этим растет уровень стресса, а эффекстивность стремится к нулю. Прокрастинация довершает дело и приоретизация задач начинает строится на «хочу» вместо «надо». И вроде бы задачи делаются, но дело стоит.

В Agile и Lean, для организации используется доска задач и бумажки с тасками, которые на неё крепятся. Доска разбивается на несколько колонок или секторов, упрощая — «входящие», «в процессе», «сделано» и «завершено». Во «входящие» ставятся все задачи, приходящие из вне. Дальше задачи с учетом приоритетов и загруженности команды переносятся в колонку «в процессе» и закрепляются за кем то. В зависимости от команды задачи могут идти в общем пуле, либо раскидываться по конретным людям сразу, что довольно рискованно. Когда задача сделана — она переносится либо в «сделано», либо в «завершено» в зависимости от того требуется ли подтверждение или нет. Например, при успешной проверке, дополнительное подтверждение не требуется, мы ведь доверяем тестировщику? Но при разработке тестового сценария неплохо бы посмотреть нескольким людям на результат. После этого на следующий день, после релиза или любой другой выбранной точки бумажка с таской выбрасывается.

Использование доски и бумажек позволяет физически видеть загрузку, что в целом может мотивировать команду, до тех пор пока на доске не окажется вся пачка офисной бумаги. А в QA это очень быстро происходит, если учитывать задачи на тестирование, тест кейсы и внутреннюю разработку. Использование Jira и вообще трекеров задачу не решает. Там происходит точно такая же свалка задач за которой перестают следить, только намного проще и быстрее.

Для того, чтобы этого не происходило все участники команды должны уметь работать с задачами. Тут есть несколько моментов, которые этому мешают – отсутствие такой практики вообще, отсутствие системы для трекинга, нежелание тратить время на написание комментариев (в открытую объясняемое нелюбовью к бюрократии, а в подсознании боязнью наказаний за обнаруженные недочеты), неумение выражать свои мысли, непонимание смысла и ценности такой работы.

Технические проблемы легко решить – установить любую систему – dotProject, Eventum, Jira. В целом не имеет значения, но с психологическими стопорами так легко может и не получится. Что же тогда делать?

Контроль — это решение. Логично, есть люди как ресурс, которые что то делают. Что, как и когда делать им говорят. Зачем разбираться в первопричинах отказа говорить о своей работе? Процесс регистрируется в задачах, записи контролируются. Но в результате время будет тратиться только на контроль, да и психологически это будет только давить, в худшем случае работа будет незаметно саботироваться, в обычном выполняться формально. Требовать от наемных рабочих горячей любви к компании за зарплату бесполезно (корреляции между деньгами и лояльностью чаще всего нет), программы мотивации работают, но они не нацелены на конкретного работника и в среднем по больнице температура то нормальная, но…

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

• «прозрачность работы», «контролируемость» является пустым звуком в большинстве случаев. Ведь это ничего не приносит тому, кто описывает свою работу. И лучшим аргументом становится часто то, что от того, как описана задача зависит работа всех участников. Потому что в случае отпуска (неприятные события лучше не упоминать, мне кажется). Описание в задаче будет единственной помощью для остальных.
• Показать на своём примере как можно работать с задачами, и пример должен быть не один. Кому то может не понравится писать много текста о работе, кому то напротив захочется записать много данных. Разные вариации описания своей работы позволяют остальным выбрать наиболее близкий, понятный и приятный стиль.

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

В остальном, листы рассылок (меил листы) используются внутри компаний чаще чем что-либо другое, но из того что я видел листы имеют общее предназначение, например all@,office-all@,news@. Бывают и совсем неживые вариации, когда одних и техже людей помещают во взаимоисключающие списки (only-managers@:vasya@, not-managers@:vasya@). Но нечасто их начинают использовать как инструмент эффективной организации, скорее как необходимое зло.

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

qa@:vasya@,masha@,dasha@,sveta@,misha@,vova@
server-side@:vasya@,masha@,bigdev@
client-side@:masha@,dasha@,guiguru@

так и по географическому положению (распределённые команды оценят), либо по должностным обязанностям:

qa@:vasya@,masha@,dasha@,sveta@,misha@,vova@
qa-leads@:sveta@,vova@,dasha@

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

Что же до почтового сервера, то в условиях одной компании мейл листы нагрузки не создают.

Работа с мейл листами вместо прямых адресов позволяет:

• уменьшить риск отправки письма неправильному адресату (либо забыть кого-нибудь);
• уменьшить время на поиск нужных адресов. Особенно актуально, если в одной адресной книге собраны все адреса, без разбиения, хотя бы на группы, либо если есть полные тёски.
• Эффективнее вести обсуждения по почте. Большинство почтовых клиентов позволяют организовать письма в треды, но справляются с этим лучше, когда есть только один адресат.

Главное, это не засветить адрес листа в сети.

Сегодня мне 29 и во мне 92 килограмма, кому то это показалось символичным. В целом жизнь остаётся замечательной штукой, которая продолжает преподносить приятные сюрпризы. Мысли в этот день рождения стали логичным продолжением предновогодних размышлений. Сейчас то время, когда необходимо сфокусироваться на области работы, которая наиболее близка, понятна и любима и не распыляться на то, что уводит в сторону. Потерю знаний от неиспользования невозможно компенсировать – это всегда потеря личного времени, финансов и в наихудшем варианте потенциала.

Последние полгода, проведённые в условиях стартапа показали много. Отличие стартапа от многих компаний в том, что здесь изначально есть определённая культура и стремление людей к работе, к тому чтобы стать лучшими. Всё поддерживается тем импульсом, который дали ему основатели. Это захватывает. Нет никаких всевдо командных проявлений, люди просто работают друг с другом, а не проводят время на работе. Более того мне посчастливилось работать с прекрасной командой профессионалов, с большой любовью и ответственностью относящихся к своему делу от которых я узнал множество интереснейших вещей. Но работа в стартапе имеет свои прогназируемые риски. Один из них — это завершение конракта с заказчиком. В такой момент приходится решать, переходить на новый контракт или двигаться дальше. Поскольку я по-прежнему вижу себя больше в тестировании, то для меня решение было только одно.

За всё то время, которое я провел в этом стартапе я получил невероятно полезный опыт работы в клиентской поддержке (и еще раз убедился в особенности работы Европейских фирм). Как я уже писал в марте — QA и CS (Client Services) содержат огромный потенциал друг для друга. Для CS, помимо коммуникационных способностей, быстрой реакции и смекалки, требуются навыки тестирования и интуитивного поиска проблем. QA же от CS получает огромный поток информации о том, как продукт используется клиентами и из неё уже можно выделить полезную информацию для развития тестирования и в немалой степени самого продукта. В нашей стране направление технической поддержки развито не хуже, чем тестирование, однако обе службы существуют отдельно друг от друга, тем самым снижая потенциальную эффективность обоих направлений.

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

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

Прошла третья по счёту встреча тестировщиков Санкт-Петербурга. На этот раз формат проведения больше походил на неформальную конференцию. Пока еще не очень гладко – Лёша Лянгузов сильно затянул свой рассказ, хотя говорил он правильно и о правильных проблемах. Приехал так же Александр Орлов. На предстоящей встрече ожидается, что придет Алексей Баранцев и Вячеслав Панкратов. Интересно о чем они будут рассказывать.

Я сменил работу и неплохо отдохнул. И о первом и о втором давно уже задумывался. Неожиданностей в этом нет, разве что, в какой то мере я сменил профиль и теперь занимаюсь Client Services, что в общем то является технической поддержкой пользователей. Очень интересная область, которой в VTS я занимался не столь плотно и уже сейчас вижу, что в ней заложен огромный потенциал для QA. Но не в каждой компании этот потенциал даже теоретически можно использовать.

В очередной раз мы, в ALSEDI, столкнулись с вопросами интеллектуального права. В очередной раз убедились, что разумные люди решают такие вопросы достаточно спокойно и без фанатизма.

Прошлые заметки: 1