Мелкие кремниевые полезности

Selenium - это бесплатное и очень удобное средство автоматизации веб приложений. Работает как библиотека на разных языках (Java, C#, Ruby, PHP, Perl, Python), подключаемая к вашему тестовому сьюту. Там большое количество атомарных методов, но для большего удобства постоянно приходится немного дорабатывать различными дополнительными методами.

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

Приведу пару примеров, а заодно сохраню их у себя :)

Быстро, не значит плохо

Вчерашняя встреча PM Zone с Томом Альберсом вдохновила меня на самоанализ и как следствие ряд мыслей.

Я представил сколько раз я за эти пару месяцев отложил всяких проблем только потому что не видел необходимого решения или еще зачем то. И что в итоге? Они остались. Т.е. они есть до сих пор и скапливаются, а срочных дел меньше не становится.
Простое и не оригинальное решение для такого рода несрочных и важных задач: первое что взбредает в голову.

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

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

P.S. Вот помнится на Agileee двое ребят очень забавно рассказывали о таком подходе. Жаль Видео нет

The sword and Other Tales

У 66666 дьяволят логины везде одинаковы

Цифры продолжают меня преследовать.

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

Рейс #666

Ничего не предвещало беды. Сидим вечером в офисе и готовим демо заказчику, которое должно было пройти 3 часа назад: как всегда в планируемых фичах начали обнаруживаться всякие блокеры.
И тут ко всему прочему падает билд. Что?! Как?! Оракл?! Где он?!
Вот так вот билд #666 лихо вырубил Оракл на тестовых средах и гордо смотрит на нас сквозь красную иконку "Build Failed"

P.S. Что было с билдом #13 я не знаю

Agileee 2010 accomplished!

Два дня Agileee 2010 прошли даже не как один, а даже быстрее. 4 потока, более 30 докладов и даже не знаю какое число участников. По моим ощущениям близкое к 400, но организаторы знают точно.
Началось все для меня в четверг, когда я все-таки решил поехать, и обнаружил для себя, что регистрация была закрыта. Да уж люблю я легкие пути :) Но где наша не пропадала. Я там побывал и не жалею.

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

Beyond Agile

View more presentations from Andrea Provaglio.

Она не техническая. Не касается ни методологий разработки, ни практик работы с Agile. Автор говорит о том, что важная составляющая Agile это команда, и Agile manifesto говорит нам "Individuals and interactions over processes and tools", но мы продалжаем говорить о процессах и инструментах, и на практике часто забываем о команде.
Следующее выступление я не буду коментировать. Скажу только, что автор Mary Poppendieck, вставлю тут анонс к выступлению и продолжу. Это надо просто просмотреть и подождать видео выступления.

"There is nothing so useless as doing efficiently that which should not be done at all." ~ Peter Drucker
If you look at the history of software failures, the vast majority can be attributed not to technical mistakes, but mistakes in understanding what should be built, what customers will buy, what the system needs to do in order to be successful. The bottom line is this - if we don't build the right thing, we may as not build anything at all. Because customers don't want software - they want a problem solved. And if they could get that problem solved without software - they would be delighted.

Mary Poppendieck “It’s Not About Software”

View more presentations from Agileee.

Еще принимал участие в игровом тренинге François Bachmann "The Art of the Retrospective".  Отметил про себя и для себя варианты визуального представления информации о проекте от Anda Abramovici “Making Feedback Visible” (ничего очень нового и революционного сказано не было, но при должном уровне абстракции восприятия, можно взять на вооружение). Послушал J.B. Rainsenberg'a и мне кажется, что меня скорее впечатлила его манера рассказывать, формат подачи материала и устройство рисования к iPad (или у него просто планшетник и Paint). Т.е. да он прямо по ходу рисовал свои слайды, как будто-бы рассказывал всей аудитории на бумажке как необходимо правильно писать интеграционные тесты. И не могу не отметить ребят из Англии, которые в конце представили свой подход к пониманию и использованию Agile-практик в виде небольшого театрализованного представления

Все на Agileee 2010!

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

Для затравочки вставлю ролик

Agileee is calling you! from Agile Eastern Europe on Vimeo.

 и дам просто ссылки на видеоролики с ключевыми спикерами

1. Мери Поппендик
2. Хенриком Книбергом
3. Робином Даймондом
4. Сергеем Дмитриевым
5. J.B.

Детали по регистрации можете прочитать на сайте или по ссылке.
Если не решили, то идите.

P.S. Спонсор поста магический пинок от Саши Орлова

Итеративный подход 2

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

• есть такое понятие "окно срочности". Я слышал о таком и раньше из психологии. Но понятно для менеджеров описано у Орлова на его happy-pm.ru. Cуть: человек начинает работать над чем-то усерднее и ставит приоритеты выше, если это что-то попадает в это самое окно.
• процесс по которому сейчас работает команда похож на то, что можно назвать Event Driven Development. Релиз обычно раз в месяц, но может и полтора. Т.е. 5-6-7 недель. Но это не правило, а скорее статистическое среднее. Такие итерации обусловлены это тем, что система уже оченьбольшая. Очень-очень большая. Каждая докручиваемая фича как дополнительный отсек на авианосце, котрый надо встроить по всей вертикали. И чтобы сынтегрировать такое необходимо немалое количество времени. Вот и получается что зависим не от сроков, а от объемов, а сроки большие. Изредка ряд мелких изменений может занимать и пару недель. Но окно срочности у людей обычно горааздо меньше месяца-полутора. Неделя в лучшем слуае. И само собой сложностей по ходу возникает много
• малыми итерациями, которые все советуют при использовании scrum мы позволяем команде работать в одном ритме и находится в постоянном тонусе. Естесственно, если все расчитано правильно и мы делаем работу, а не совершаем подвиги каждую итерацию.

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

Жду пока мы это внедрим в ближайшем будущем и на опыте будет видно. Потом отдельно напишу

"Все мое, мое!"

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

Мотивация собственников и эгоистов.
Необходимо заставить человека думать, что работа, которую он делает относится непосредственно к нему, это его.
Например, не сказать человеку что необходимо сделать, а объяснить что хочется получить (не конечный ожидаемый результат, а цель), зачем это необходимо и какие могут быть последствия. А главное делегировать ему ответственность за то, что он будет делать. И это не означает только обязанности, но и права и полномочия, т.е. всю полноту власти, необходимую для выполнения порученной работы. Естественно, только в том случае, если мы уверены, что человек сможет этим воспользоваться ;)
По-моему это нормально и очевидно. Важно сделать это не со словами "не мог бы ты" или "я тебя попросил бы". А "я отдам тебе", "твоя часть .... это нужно затем-то и потому-то". Это будет его(ее).

Реальность субоптимизации

Помнится мне что-то такое еще с университетских времен. А тут посмотрел и понял конкретное применение в управлении проектами и командами в ИТ. И это точно надо "заложить" себе и тому кто прочтет.

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

А считаем мы эффективность из отношения суммы сколько на каждом этапе работали над нашим  вопросом (подразумеваем: тикетом/ишью/задачей/требованием/баг-репортом) к общему времени работы над ним. Т.е. сколько суммарно записал каждый человек, что работал с багом ко времени сколько баг находился в активном состоянии. Считать можно в чем угодно, но единицы измерения должны быть одни и теже: дни, недели, story points, мартышки, папугаи, -- но одинаковые в числителе и знаминателе. Если выш процесс более специфический, то просто исходите из классики:

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

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

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

Гармония важна в любом аспекте жизни. :)

Как мотивировать наших людей

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

А лучше всего вести нашего человека в обозримое светлое будущее, с морковкой внутри и стимулом (тем самым) сзади. Человек всегда должен быть чем-то недоволен немного, в лени люди теряют форму

SQA Days 7, Харьков. Часть первая

На этих выходных прошли первые украинские SQA Days. Был на этой конференции первый раз. И первый же раз на ней выступал с докладом. Если коротко про доклад, то говорил я на тему обеспечения качества локализованных продуктов. Несмотря на простуду, то выступление свое считаю удовлетворительным. Есть над чем задуматься. Потому материалы отдельными статьями выложу позднее.

Началось все утром в пятницу, 14 мая. Проводили в Радмир Экспохолле, хотя где еще можно это проводить в Харькове пока придумать не могу.
Пока народ прибывал и регистрировался, я немного поправил здоровье горячим чаем и уточнил программу конференции. Очень приятно, что программа конференции была отдельно в раздатках, потому что в последний день произошли изменения и было бы неприятно бегать в поисках нужного доклада. Хоть рецензий на изменения и не было в распечатаном сборнике тезисов. Также в раздаточных материалах был диск с материалами конференции. Приятно порадовал бонус в виде материалом по SQA Days 4 и 5.

Организаторы, как и положено, обратились ко всем со вступительным словом, рассказали про планируемые плюшки. и все устремились.

В начале слушал "Сокращение времени выполнения регрессионного тестирования", Павел Моцарь. Как человек выступал понравилось. Суть в том, что в их компании начиная с момента, когда еще не было ни Hudson, ни СruiseControl развернули систему управления версиями и, самый важный момент, добились установки системы на тестовую конфигурацию одним кликом.
Далее автоматизация тестирования. Она как раз и используется для регрессионного тестирования. Да, также запуск скриптов в одно касание :). Но тесты, хотя на данный момент идея не так уж и нова, из-за огромного их количества и большого времени прогона, разбиты на suites и каждый suite запускается на отдельной тестовой конфигурации.
Интересный момент, что клиент этой системы автоматизированного тестирования запущены на большинстве рабочих машин работников. И система может запросить хардварные ресурсы рабочей машины работника, чтобы обеспечить свою производительность. :) Мне, правда, сразу вспомнился LoadRunner.

Далее был "Метод Всех пар, или как не убиться тестируя комбинации", Александра Барановского. Кстати по манере изложения один из самых качественных докладов был. И идея полезная, хотя тоже не новая. Суть в том, чтобы сократить число тестов при тестировании взаимодействующих параметров, таких как настройки системы. Метод рассмотрели еще и на конкретном примере. И специальную тулзовину посоветовал.
Почитать можно и в интеренете, но суть в том. Чтобы вычленить все имеющиеся параметры (контролы формы настроек), их значения. А потом можно загрузить в предложенную тулзовину (PICT от Microsoft) и получить упрощенный вариант тестов. В двух словах описать математическую составляющую метода мне тяжело.
Этот метод не дает замену полному перебору. Но предлагает оптимальное количество тестов, при котором можно выловить большую часть ошибок.

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

Перед обедом пошел на доклад, "Организация процесса тестирования в Agile команде на основе матрицы квадрантов тестирования", Игорь Бондаренко. Инженерам, на плечи которых только упала ноша управления командой тестирования он бы несомненно помог систематизировать свои знания. Все сорок минут человек рассказывал о тестовых активностях и том, как их разбили на четыре группы, эти самые квадранты. К концу, правда, так и не стало понятно зачем такое разбиения, но после того как был задан этот повисший в воздухе вопрос все стало ясно. Разбиение активностей по группам помогает команде по тестированию при работе на спринте. На этапе планирования все новые фичи и планируемые таски расклеивают по этим группам на тестерском scrumboard и дальше уже проще распределять их внутри по статусам.

Потом был обед и я пока прервусь :)

"Лучше давайте побыстрее закончим"

Последнее время я очень часто слышу эту фразу: "Давайте лучше сделаем это побыстрее".
Да, все хотят успеть сделать вовремя, или как можно быстрее, если это самое "вовремя" прошло.
Причины? Различные. В моем конкретном случае я все отношу к различным "окнам бессрочности" (вот тут прочитал) всех членов команды.

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

Если все же хочется это получить поскорее, то придется поступиться остальными углами треугольника менеджмента проектов. А QA помнят, что углов в треугольнике 4: время, ресурсы, деньги и качество :)

Design your desk to give a good impression

Design your desk to give a good impression: "

"

 Что-то мне этот комикс напомнил :)

Отношение команды к работе

Есть пара интересных идей (идеи не мои, но комментарии и мысли все же мои :)), но хотелось бы о ней в свет сказать - может когда-нибудь пригодится

Настроение людей влияет на прямую на их работу ибо напрямую от этого зависит интерес к работе.

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

Вторая: Вместе с занесением времени по задачам отмечать отношение к ним: интересно; не интересно; было, но перестало. И соответственно можно получить картину об отношении сотрудника к его работе. Это можно использовать при периодической оценке сотрудника.
Но внедрять лучше только, если действительно отношение человека к его работе имеет смысл и представляет интерес

О пользе коммуникаций

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

Информация должна быть постоянно в движении. Т.е. двигаться и шириться внутри команды, не только от вас ккоманде, но и должно быть наоборот.

Информация должна дублироваться. Это такжестоит принять заправило. У каждого разное мировосприятие. Кому-то проще устно, кому-то письменно, кому-то и так, и так, и еще нарисовать было бынагляднее. Вот и пишите, собирайтесь на митинги, наглядно доносите свою мясль. Так дойдет лучше. Останется и в твердой копии, и на серверах, и в головах черезразличные органы чувств. Не надо считать, что это избыточно. В этом вопросе ее нет, поверьте. Со временемсо стабильной командой вы так или иначе придете к какому-то состоянию оптимума: что, где, как хранить и предоставлять

Главное: делитесь всем что вам становится известным, просите того же от своихсотрудников, поддерживайте процесс движения информации внутри команды, храните ее и подавайте в разных видах.

Enjoy :)

Как узнать человека за 13 мин?

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

Вариант 2
Просто ставьте ему вопросы, ответы на которые вы хотите получить. Важно самое первое мнение. После этого сразу задавайте следующий. Вопросов не должно быть много, чтобы человек не успел войти в игру. Они должны требовать которких и развернутых ответов

Необходимая мотивация

Уже какое-то время с небольшим перерывом волновал меня вопрос мотивации персонала. Основной мотиватор это деньги скажете вы (естесственно не конкретно Вас я имею в виду). Что тут думать - деньги! Собственно, да. Идею пирамиды Маслоу опровергнуть тяжело и деньги обеспечивают основные уровни. Но у меня не было этого рычага сначала напрямую, а затем и косвенно. Приходилось выкручиваться как получалось, но я не был долго готов, чтобы озвучить что-либо вслух (тяжело это дается, когда не можешь не просто сформулировать, а просто или сложно объяснить).
Естесственно при отсутствии материальной мотивации надо придумывать нематериальную.
Сегодня просмотрел одно видео Дена Пинка (Daniel Pink) и перед тем как я постараюсь в двух словах описать как можно сделать мне кажется его стоит послушать. Он и рассказал ту базу, которую я интуитивно попытался достичь, и на чем пытался строить свои идеи. И даже больше :)

Автоматизировать можно быстрее

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

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

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

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