Показаны сообщения с ярлыком тест-менеджмент. Показать все сообщения
Показаны сообщения с ярлыком тест-менеджмент. Показать все сообщения

пятница, 12 декабря 2014 г.

Семь ступеней мастерства в разработке ПО


В книжке Эдварда Йордона "Путь камикадзе" наткнулась на интересную тему.

Новый софт (для разработки или для автоматизации) привлекает своими возможностями. И вот ситуация — выпросили мы у начальства новый клевый инструмент, оно дало добро. Оплатили инструмент, оплатили курсы по его изучению. Но вот беда, за неделю обучения ты экспертом не станешь. Казалось бы, это очевидно, но начальники могут начать задавать вопросы "Мы согласились на ваш инструмент, вложили кучу денег. И где результат?".

В своей книжке Йордон ссылается на статью Мейлир Пейдж-Джонс The Seven Stages of Expertise in Software Engineering и я хочу привести тут его перевод этих ступеней:
  1. Наивный новичок — никогда не слышал о технологии Х (очевидно, для этого не требуется никакого времени).
  2. Осведомленный разработчик — прочел статью о технологии Х (в большинстве случаев разработчику ПО достаточно одного часа, чтобы разобраться в общих чертах и высказать свое мнение о преимуществах и недостатках средства, даже если он никогда его не видел или не использовал.
  3. Начинающий разработчик — посетил пятидневный семинар. Неделя, возможно, сжатая до двух дней ввиду того прессинга, под которым находится проект. Следует отметить, что при этом разработчик, скорее всего, успел всего лишь поработать с компьютерными руководствами, предоставленными поставщиком, или пробежаться по небольшим примерам, иллюстрирующим возможности средства. Ему не пришлось столкнуться с какими-либо проблемами и недостатками средства, у него не было возможности масштабировать средство (если это вообще возможно) для больших и сложных проектов; он не пытался интегрировать средство с большинством остальных средств в данной среде.
  4. Практикующий разработчик — готов использовать технологию Х в реальном проекте. По-видимому, достаточно месяца, чтобы в основном постичь все нюансы использования средства и быть вполне готовым к его применению в "реальном" проекте.
  5. Квалифицированный разработчик — постоянно использует технологию Х в своей работе и очень недоволен. если по какой-то причине лишается этой возможности. Для достижения такого уровня обычно требуется 6-12 месяцев, и если средство действительно подобно "серебрянной пуле", то разработчик превращается в проповедника и пытается всеми способами убедить каждого, что это средство — самое замечательное в мире.
  6. Мастер — усвоил все детали технологии Х; знает, как обходить ее правила. На это требуется 2 или 3 года. Это также означает, что разработчик прошел две или три новые реализации продукта, познакомился со всеми пользовательскими сообществами в интернете, знает все отсутствующие в справочниках номера телефонов специалистов по технической поддержке в организации поставщика.
  7. Эксперт — пишет книги, выступает с докладами на конференциях, ищет способ распространить технологию Х на другие галактики (Пейдж-Джонс в своей статье говорит о методологиях, поэтому это не совсем применимо по отношению к средствам и технологии).
Статья написана давно, но до сих пор актуальна! Еще раз дам на нее ссылочку. чтобы не пришлось скролить вверх.

Я думаю, это применимо не только к разработчикам, но и к тестировщикам  Инструменты автоматизации точно проходят эти ступени. JMeter, Soap Ui, всему надо учиться.

Покажите эти ступени своему менеджеру, когда будете записываться на обучение. Или посматривайте на них сами, когда руки начнут опускаться на 3 этапе! (smile)

среда, 25 июня 2014 г.

Начинающие менеджеры. доверяйте! Не будьте надзирателем

Пост навеян прошедшими событиями...

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

Тема урока такая - не будьте надзирателем, давайте своим подчиненным свободу! В книжке Remote об этом хорошо написано. Там описывается, почему некоторым руководителям сложно отпускать сотрудников "на волю" - на удаленную работу. Ведь когда сотрудник работает из дома, ты не можешь за ним наблюдать, не можешь его контролировать! Ааааа, паника, паника! Они же тогда вообще работать не будут!! Нет, только через мой труп!!!

А со стороны сотрудника это выглядит примерно так:


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

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

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

Им просто сложно заниматься управлением, хочется бежать и делать все самому или хотя бы тщательно все проверять.

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

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

А ведь правильнее было бы как сделать? "Так, сегодня мы релизим этот модуль, как думаешь, что надо проверить? Правильно! Молодец! Когда сможешь?". Иногда твои указки уже не нужны, но остановится то уже сложно)))

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

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

Доверяйте своим коллегам! В конце концов, нам же не нужны работники, которые будут бить баклуши, если у них не стоять над душой каждую минуту, правда ведь? Smile :)

понедельник, 28 октября 2013 г.

Я могу поставить идею (IDEA) !!!

Хочется поделиться небольшой тестерской радостью, пусть и не совсем своей Smile :)


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

И вот есть у нас девочка, назовем ее Яна. По некоторым причинам она раньше появлялась редко, сейчас уже часто. Но ближе к вечеру. И, так как она старожил, то и компьютер у нее, прямо скажем... Всего 4 Гб оперативки.

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

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

- Ну как там тесты, поправила?
- Да какое там, 15 минут (потрясает кулаками) ждала, пока машина отвиснет.
- Ого, как же так.
- Да в ней же всего 4 Гб оперативки...
- Так попроси админа дать тебе нормальную станцию, поставь задачку в JIRA!
- Ну-у-у-у, я с ним разговаривала уже (скромно потупив глазки).
- И что?
- Он сказал, что когда Вася (другой коллега) пересядет на ноутбук, мне отдадут его компьютер. Только (тяжкий вздох) уже пара месяцев, как он пересаживается...
- И что, тебе ждать теперь чтоли? Это же необходимость, а не прихоть! Ставь задачку!
- Ну-у-у-у... Я даже не знаю, наверное, попробую с ним еще поговорить, а может, пока вообще не стоит (опять же по некоторым своим причинам).

Ладно. Проходит еще минут 15-20, мне надоедает работать, да и время уже 11 часов, собираюсь домой. Иду мимо Яны, а она раздраженно машет рукой на свою железяку и говорит "А, ладно, я с тобой. Лучше завтра все сделаю, а то надоело ждать, пока все отлагает".

А я иду и думаю, ну как же так? Ведь Яна же одна из моих ребят, и так страдает. Да и не только она, весь проект страдает! У нее сегодня в планах было эти тесты добить и другую задачку сделать, а что в итоге? Из-за ограниченности компа она ничего не сделала...

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

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

- Видел задачку?
- Ага. У меня как раз свободная станция завалялась...
- о_О Где ж ты раньше то был?!
- А ко мне последнее время никто с просьбами не обращался!

Потом были еще танцы с бубнами вокруг установки машины. Но вот, наконец, у Яны стоит нормальный комп!

Сегодня ухожу с работы, прохожу мимо нее. А она сидит и таким счастливым голосом говорит:

- Я теперь могу поставить идею!!!
(IntelliJ IDEA - среда разработки для Java-приложений)

Раньше идея бы даже не стартанула. А теперь - ВАУ, можно спокойно работать! И, главное, столько счастья Smile :)

А я даже где-то горжусь. Тем, что ускорила процесс получения этой радости Smile :)

вторник, 22 октября 2013 г.

ШТМ. Школа тест-менеджеров Натальи Руколь


Хочу поделиться впечатлением от прохождения онлайн-курса по ШТМ!

Чисто случайно школа была для меня бесплатной, я выиграла участие в ней в конкурсе нашей группы вконтакте, TEST IT. Да-да, иногда там бывают очень полезные конкурсы с оч-чень ценными призами!

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

четверг, 26 сентября 2013 г.

Отчет о Выездной Школе тест-менеджеров (c) Юля Свистунова

Сначала немножко от себя. Я уже писала о том, как здорово мы и отдохнули и поучились. А сегодня я бы хотела опубликовать отчет другой участницы школы, которая тоже хотела поделиться своими впечатлениями. И ого-ого как поделилась!!! Столько написала, явно эмоций много набралась Smile :) Я, например, с огромным интересом прочитала, хотя сама в этой школе была!

Итак, Вашему внимаю предоставляется отчет участницы школы Юлии Свистуновой!!!


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

Впереди у меня была Выездная школа тест-менеджеров, а это значит предстоял еще путь за пределы столицы, в Подмосковье, в плейс с оригинальным названием “Агроусадьба “Ранчо”.
Поскольку опыт выездных школ у меня уже был - в прошлом году имела возможность быть в Крыму на Школе тест-дизайна, то примерное представление о том, что предстоит имелось. И это прибавляло позитива изрядно!


Где-то ближе к 14 часам я добралась на Савёловский вокзал, откуда должна была отъезжать нужная нам электричка до города Яхрома. Там уже ожидал нас Леша. Буквально в течении часа наша компашка дополнилась Игорем, затем подошли Катерина и Руслан. Оставалось дождаться Олю Киселеву - как договаривались. Однако Оля в этот раз отличилась - вместо того, чтобы добраться в точку сбора - зал ожидания вокзала, она обнаружила и исследовала новый путь (в обход всем турникетам, между прочим ;)))) и уже ждала нас на перроне!!


За разговорами и фотками моих котиков дорога прошла незаметно.



Видео см тут (охотник) и тут (буклированные шторы из органзы).

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

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

Нас впустили в коттедж, но расселяться и занимать комнаты как-то не ломился никто - видимо, альтенатива в поиграть в Алиас привлекала больше Smile :)


Через некоторое время подъехала Наталья, с АРБУЗОМ (26 кг вроде ….), Андреем, другие участники также постепенно доезжали. Вот тогда-то нас и просветили, что есть и еще один коттедж для нас )). Как уже было сказано - коттеджи обозначили как тихий и шумный, волей судеб - да-да-да, оно само так получилось - я обитала в шумном, хотя лично мне это как-то не помешало и высыпаться и даже не замерзать в промозглой осенней погоде.


Заранее прошу прощения, но я не могу не подлить ложку (даже 2) дёгтя - ну, плохо себя буду ощущать тогда, привыкла уж я быть честной Smile :)
Итак, первая ложка - это Wi-Fi!! Точнее его отсутствие - Wi-Fi был обещан, на сайте “Ранчо” гордо значился, что он есть, но …. он был ТОЛЬКО в ресторане!! Ну, да, он же ЕСТЬ, нельзя же сказать, что его нет, это не бага, а маленький сюпризик …
Второй момент, который не обрадовал многих, это завтраки ….. во-первых, как оказалось, в стоимость проживания они не входят, а во-вторых, даже если мы все решим их заказать утром, время на их приготовление уйдет больше часа!! Это яичницу пожарить-то … А нас всего-то 24 человека! Короче, момент неприятный, что говорить.


Приключения с завтраками послужило толчком к принятию решения, чтобы утром совершить поход в макдак!
На утро субботы у меня был ответственный квест: “разбудить Наташу с 8 до 8.30”. Честно скажу - делать это не пришлось, то ли мои методы побудки, описанные в красках накануне в пятницу подействовали, то ли еще что, но в 8:23, когда полная решимости я распахнула дверь комнаты Наташи и Оли, Наташа уже была на ногах! Smile :)

Пока осваивался (модное слово ;)) утренний кофе возле входа в шумный коттедж, мне посчастливилось познакомиться с одной из местных агроусадебных обитательниц - умница и красавица Пёса (как ее звать мне неведомо было, но на Пёсу она вполне соглашалась пообщаться Smile :)
Кофе был освоен и к нам примкнули Катя, Маша и Леша. Таким составом мы отправились в славный город Димитров. Даааа, макдак они спрятали там серьезно - аж за Кремлём!! Но это не помешало нам его найти! Smile :)


Закупив примерно необходимое число булок с яйцом, а также заглянув в магазин, где нам не продали пиво и шампанское потому как 11:00 еще нет, тронулись обратно. Но переезд нас не пустил - пришлось ждать поезд, всё-таки он побольше нас будет. Да, этот риск с переездом мы не учли, потому он нам стоит 20 минут опоздания. Но не могу не заметить, что даже с этим риском, мы явились на “Ранчо” раньше тех, кто-таки рискнул отведать скоростную местную кухню!!


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


На обеде я осталась на агроусадьбе. Не знаю почему - но скорее всего, нужно было перехватить тот пласт инфы, который получила, ну а может мне было некомфортно от того, что прошли сутки, а я до сих пор на необследованной мной территории :)))) В общем, совместить брожение по округе, общение с местным зверьем и Пёсой и переваривание полученных знаний получилось успешно! К слову, местная фауна лично меня порадовала: были там чернобурая лиса, обычна лисичка, 2 енота-полоскуна, пара золотых и серебряных фазанов, серая неясыть - только она спала постоянно :(, ну и традиционные - петушки, курочки, гуси и утки. Петюней по утрам было хорошо слышно как раз из наших окон, хотя вот мою соседку по комнате, Вику, эти песнопения не очень радовали и только при мне она 2 раза обещала сварить из него суп! ))
По возвращению народа с обеда, подпитка знаниями и фаном продолжилась: нас разбили на команды и задачу поставили - собрать “баги”, заботливо рассованные Андреем Smile :) Незадолго до того, как начали играть, на улице пошел холодный дождь и как бы мы не старались, но промокли практически все. По итогам как-то само собой получилось, что наша команда, действуя не сговариваясь и по наитию, но оказалась не самой худшей Smile :) Особенно меня поразило, как мы всей толпой, командой, не договариваясь заранее, в одном и том же месте собирались и обсуждали результаты, чтобы построить задачи на дальнейший поиск - это на самом деле было совершенно спонтанно, но у всех и одновременно! Что называется чувствовали друг друга )))


Дальше вечер заполнился уже чистым фаном и в тепле: Алиас, Шляпа, крокодил, данетки, интеллект-бар “BeerMind” - всё просто супер!


Утро воскресенья также началось рано, но на этот раз подвиг в макдаке Наташа совершила сама!! К слову, тогда же обнаружилось, что закончился кофе и решив, что время пока соберутся все, есть мы съездили в Яхрому, где пополнили запасы напитка прямо из станционного магазина. На этот раз риски не сработали! Smile :)


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


После конфеток была пицца, суши и лапша, Аллиас, а уже ближе к 6 вечера - Наташа и такси доставили нас оставшихся на станцию Яхрома.


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

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


Но не могу не сказать, что ощущения от мероприятия остались только положительные!! За что огромное СПАСИБО как организаторам - отдельно, Наташе Баранцевой, я чувствую, что это всё ее идея :)) и Наташе Руколь, на голову которой было повешено такое число тест-манагеров )))!!! Кроме того, спасибо всем участникам - ребята, коллеги, без вас бы такого экшена просто не получилось бы!! :)))


Вот, пожалуй кратенько и всё Smile :). До новых встреч в эфире, всегда ваша Ю.С. Smile :)

понедельник, 23 сентября 2013 г.

Выездная школа тест-менеджеров

Только что вернулась с замечательного мероприятия - выездной школы тест-менеджеров.
И хочу сказать, что было очень здорово! Мы и поучились, и поиграли в тематические игры, и поиграли в простые игры Smile :)

Это если кратко. Но я же кратко не умею, так что дальше подробно.
Место проведения - Подмосковная агроусадьба Ранчо. Начало в 6 часов вечера в пятницу. Большой плюс, что можно спокойно за 1,5 часика добраться с Савеловского вокзала. Правда, на вокзал тоже надо доехать и что-то как-то я поздно с работы вышла, добралась до поезда - целый квест был (указатели, блин, надо точнее делать), но мы успели сесть в него за 2 минуты до отправления!

В поезде мы ехали с моей уже хорошей знакомой Юлей Свистуновой, которая, кстати, обещала предоставить собственный отчет не позже, чем во вторник (24.09.2013) вечером Smile :)

Потрещали, немного познакомились с юношами, которые ехали с нами. От станции за 200 рублей на такси - меньше, чем по 100р с носа, отлично! Приехали раньше организаторов, но нас заселили, что огромный плюс! А то бы уперлись "в 6 и точка" и все...

Заселились и стали играть. Так немного и познакомились. И ребятам "Алиас" показали. А потом приехала Наташа Руколь, рассказала о правилах и мы окончательно расселились. В нашей комнате ноутбуки размножались делением Smile :) Или почкованием?


Ну, неважно. Вскоре началось самое интересное - лекция!



Что хорошо в оффлайн версии?

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

Ах да, кстати, лекция то была вчера, в субботу утром. Ну а в пятницу вечером ребята пока собрались, пока расселились, в общем, вскоре уже все играли в шляпу и алиас. Так и познакомились. А утром Наташа Руколь встала в 8 утра (!!!), чтобы съездить в город и привезти нам завтрак. Это вообще очень круто, тем более что для Наташи это почти подвиг, так рано встать. Очень приятно, что ради нас она на это готова Smile :)

А я, кстати, прохожу еще онлайн курс по ШТМ, перед отпуском он заканчивался, но я попросила себе отсрочку. Так что в субботу утром, проводив Наташу, я не легла обратно спать, а включила ноутбук (моя прелесть!) и посмотрела 7 лекцию, последнюю лекцию с домашним заданием. Вот так продуктивно прошло мое утро.

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

Тема затрагивала планирование и постановку задач. А среди нас были и простые тест-менеджеры, и удаленно работающие. Так что вопросы были интересные, касающиеся разного спектра задач.

Ну а потом был обед и тематические игры вечером! Секреты игр полностью раскрывать не буду, хотя вторая мне не очень понравилась. Но я просто с этим сталкиваюсь не первый тренинг уже, вот у Бескова была, также было - собрали незнакомых людей в команду и дали 10 минут требования записать (условно). Люди в команде спорят, повторяют работу итд итп.

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

А когда собираются незнакомые люди, начинается хаос. И ты или берешь на себя функции менеджера или делаешь, как скажут. Я вот НЕ ХОЧУ брать на себя в такой ситуации функции менеджера, но такая работа с команде меня убивает. Я вроде смотрю на это и внутри понимаю, что нам сейчас надо делать не так, но тут я больше интроверт. Мне хочется пойти в темный уголочек и сделать задачу самой. А не пытаться что-то кому-то доказать.

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

Но и тут можно вынести полезные идеи. Я, например, не просто играла в подобную игру, я уже тестировала это приложение. И все равно, пару умных вопросов мы "аналитику" задали, а про пару забыли. Вот просто забыли. Казалось бы, они элементарные + на тренинге о них уже слышал, да и вообще, привет капитану очевидности. А вот ведь, на деле то не задаешь, нет такой привычки. Уже очень полезный вывод, я считаю.

Тем не менее, после тематических игр мы снова вернулись к алиасу и вечер прошел на ура!

А наутро снова в строй и ручку в зубы Smile :)




На этот раз тема была про мотивацию. И делегирование. И проекции! Очень интересная и спорная тема. На этот раз было много вопросов из зала. И не только вопросов, но и комментариев и даже споров.

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



Вопросы и примеры были самые разные. Вот, например, один:

Жил-был один автоматизатор. И так ему нравилось то, что он делает! И все видели, что нравится, и что делает он это хорошо. И даже решили его повысить за это.

А ему это было не надо!!! Менеджер спроецировал себя "я хочу повышения, и все хотят, и он хочет". И целый год пытался этот автоматизатор их убедить, что они не правы, а потом пришел к Наташе на собеседование:

- Ого, ты работал начальником автоматизаторов, а к нам простым просишься... Почему?
- Да не хочу я быть начальником!
- Погоди... А до начальства пытался донести мысль?
- Да.
- А, может, вам грамотные автоматизаторы не нужны?
- Нужны!!

Ну и смысл тогда держать человека на нелюбимой должности?

И опять же, кто-то с чем-то не согласен, начинаются споры, примеры из практики и т.д. и т.п. В общем, очень классно!

А потом снова тематические игры, которые повернулись очень внезапно)) Один из коллег решил показать нам отличие краткосрочных результатов от долгосрочных. Дали задание делиться конфетками. И вот он подходил (ко мне, например), "а давай меняться, все мои на все твои, всем будет по + в карму". Я даю и вижу, что он мне только одну свою протягивает. И как-то так подозрительно, прямо чуяла подвох, но доверие победило. А Вася забрал мои конфетки, улыбнулся и сказал "Ну, а остальное я отдам тебе потом, о сроках мы не договаривались". И все, ушел.

Потом выяснилось, что он так еще парочку одурачил и больше с ним уже никто не менялся. Причем ладно бы он это сделал, именно чтобы краткосрочность от долгосрочности отличить. Но он очень хотел высказаться "а почему я это сделал" и, когда ему дали такую возможность, сказал "А все хотели смухлевать, дать мне 3 и получить 3, получить +3 за обмен, а не за само задание. Я просто на этом сыграл".

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

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

Фуф... В принципе, потом было еще немножко алиаса и все поехали по домам.
Ну что я могу сказать? Было интересно послушать чужой опыт. Снова послушать интересные темы и обсудить их. Ну и фан, конечно же, фан.

А еще я в школе успела посмотреть одну запись по ШТМ и обсудить с тренером 2 домашки, что тоже очень даже здорово! Ну и весело провела выходные. что немаловажно.

Большое спасибо организаторам за то, что дали возможность все это сделать!!! И отдельно Наташе Руколь за ранние завтраки, почти что кофе в постель Smile :)

вторник, 13 августа 2013 г.

Светлана Иванова. Мотивация на 100%



Ссылка на книгу (издательство "Альпина Паблишер")

Прочитала книжку по рекомендации Натальи Руколь. Очень любопытная!

Написана довольно простым языком, интересная. А главное - в конце каждой главы идет задание для самостоятельной работы. Это самый эффективный тип книжек, книга-тренинг. Тут главное - не лениться и выполнять задания.

Книжка нужна в первую очередь для менеджеров, в нашем с вами случае - для тест-менеджеров. Она рассказывает о том, что суждение "мотивировать можно только повышением зарплаты" - ложно. Она рассказывает о том, какие еще бывают мотиваторы, как их выявить и что с ними делать дальше.

Но я, например, не тест-менеджер. Более того, проходя сейчас школу успешных тест-менеджеров и читая всякие такие интересные книжки, я понимаю, что мне просто нельзя руководить людьми. В силу присутствия у меня некоторых талантов ))

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

Но все равно книжка была для меня очень интересной и я даже, сделав все упражнения из самой книжки, запланировала себе сделать упражнение на примере своей команды. Ну и что, что я ими не руковожу? Это все равно интересный опыт! Опять же, учитывая то, что писательство помогает мне структурировать информацию, я, возможно, получу даже больше выгоды от задания, чем ожидаю.

Кстати, у меня пока не получается посидеть и помедитировать над данным упражнением, но я придумала скрестить его с книжкой "Сначала нарушьте все правила" и поискать таланты, начав с себя. Так что начало положено! Посмотрим, что мне это все принесет, но я вас уверяю - это как минимум интересный опыт. Всем рекомендую Smile :)

PS - Добавила книгу в общий список прочитанных мною книг.

суббота, 22 сентября 2012 г.

ConfetQA. Общение с коллегами

Немного приоткрою завесу тайны, о чем пойдет речь на осенней Chief ConfetQA в моем докладе.

Один из наиважнейших принципов "сделать все хорошо" - общение! Общаясь с коллегами, вы не только получаете feed-back, не только слышите разные точки зрения, что помогает посмотреть на ситуацию по-новому, но и можете сами сделать какие-то выводы, сами прийти к какому-то решению...

Как говорится, "Поделись своей радостью - и она удвоится. Поделись горем - и оно станет вдвое меньше" (с) Адам Джексон.


Хочу рассказать реальную user-story о том, как данный метод работает.

Проверяю систему руками, замечаю ошибку. Иду к коллеге (пусть будет К) - так и так, посмотри, плиз, есть ли уже что-то подобное? Приходим, изучаем. Странное поведение, нужны тесты.

Конкректно таких тестов нет. Иду, ищу похожие, копирую в свою папку файлы с тестовыми данными, а также TestRunner. Тестовые данные исправляю на те, что меня смущают. Запускаю - тесты прошли о_О

Хорошо, включаем debug-режим, узнаем точные тестовые данные. Записываем в файл теста. Запускаем - проходят о_О

Так, блин! Ну тогда изменим-ка ожидаемый ответ на тот, что приходит в реальности. Запускаем - ну вы поняли...

Как так? Два разных ответа пройти не могли. Получается, тесты заскипаны. Но ведь они не заскипаны! Пишу К - "посмотри, пожалуйста, как время будет". Сама ухожу прогуляться. Стою у окна, смотрю на пока еще зеленые листочки на деревьях. А мысленно жалуюсь К.

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

- Ну К, ну что не так? Ну ведь тесты исправила. Ну они не заскипаны!!! Там не стоит "#". Ну как так? И в TeamCity подключены, я проверила. Ну где еще может быть ошибка? Я же всего 3 файла и добавила...

Внезапно приходит озарение. TestRunner! Скопирован! Он берет данные из той папки, откуда был копипаст, а не из новых данных!

Быстренько возвращаюсь на свое рабочее место, надеясь, что за прошедшие 5 минут у К. не нашлось времени посмотреть, что я там понаписала. Ну да, так и есть! Вот она - ошибка! А ведь так бы и ушла, не зная...

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

А когда начинаешь говорить - то ты сам "проговариваешь" ситуацию. Сам можешь увидеть ее под другим углом. И сам же найти ответ Smile :)

А что, у вас в школе никогда такого не было? "Ну маааааам, ну неполучается!!!! Вот смотри, я делаю так и так... Блииииин... Понятно :("

А уж если разговор был реальный... То можно услышать и полезную идею, о которой ты раньше даже не думал. Всего-то и надо - поговорить )

четверг, 23 августа 2012 г.

Приоритеты проекта

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

А правильного ответа то и нет! Удивлены?

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

Пригласить специалистов по контракту? Да, вот Рекс Блэк об этом хорошо писал в своей книге. Там тест-менеджер очень удачно нашел применение простаивавшему оборудованию. Просто нанял контрактников. Довольно дешевая рабочая сила, работает во вторую смену, помогает основной команде выполнять нудную работу, чем плохо?)

Только вот стоят ли переплаты того?

И вот тут всплывает оно - решение задачи... А решение может быть разным! И зависит оно от приоритетов проекта. Волшебной палочки в виде единственно правильного ответа не существует :)

PS - пример был взят из книги Карла Вигерса "Разработка требований к ПО". Все статьи по книге:

[1] [2] [3] [4]

вторник, 17 июля 2012 г.

Support Request - "Прежде всего сядь и ПОДУМАЙ!"

Как обычно происходит support, или поддержка пользователей?

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

Кто же общается с Заказчиком?

1. Аналитики

Ну, казалось бы, а кто еще? Аналитики пишут ТЗ, согласовывают его с Заказчиком, рассказывают разработчикам, что им надо сделать... Дают ответы на бесконечные вопросы тестировщиков, утрясают проблемы со сроками и многое, многое другое...

Но бывают и другие варианты...

2. Тестировщики

Ну а кто еще так знает продукт, как тестировщик? :) Логика опять налицо. Тестировщик - последняя стадия продукта, его последний этап. Он знал его на этапе требований, а теперь он докапывается до сути реализации. Ну кому еще отвечать на вопросы "а какие параметры можно отправлять через soap-запрос в этом методе?"...

Разумеется, бывают и другие варианты. Особенно в agile - командах, где нет четко выраженных аналитиков или тестировщиков. Но нас то интересует именно второй вариант, правда ведь?

Чем хорош такой подход?
  • Разнообразие - ты не ограничиваешься рамками "сел и потыкал", ты порой сам пишешь и согласовываешь ТЗ (ну а что делать, если оно непонятно написано?). Спектр твоих обязанностей расширяется и разнообразия в работе хватает с головой.
  • Быстрый feedback - обратная связь всем нужна, всем важна. Как иначе узнать, понятное у вас описание в википедии или не очень? У Заказчика нет Аналитиков/разработчиков под рукой, ему похуже будет...
  • Рука на пульсе - ты всегда знаешь, какие баги есть на предпродукционной платформе, удачно ли прошел релиз? Ведь кто "яйца на бочку" кладет ((c)Андрей Мясников), подтверждая, что ошибок в релизе нет, он - готов? Тестировщик! Кому, как не ему, первому узнать о проблемах пользователя?
  • Быстрый ответ - Заказчик тоже хочет быстрой обратной связи. И если у него есть проблема, он хочет знать, откуда она и когда ее поправят. Уверена, что тестировщик тоже очень хочет это знать, тут их интересы совпадают.
  • Соответствие ожиданиям - вы сталкивались с ситуацией "сломанного телефона"? Когда реализовали одно, а выяснилось, что нужно было совсем другое? Ситуация была очень ярко показана в ролевой игре в летней школе тестировщиков. А, чтобы такой ситуации не было, тестировщику надо знать, что нужно Заказчику. Какие у него возникают вопросы и пожелания. Как он пользуется системой...
В общем, сплошные плюсы. Назначаем тестировщика ответственным за customer@support и радуемся жизни. У менеджеров появляется время на более важные дела, а тестировщики держат руку на пульсе.

Казалось бы, все хорошо? НО! Подумайте сами о минусах такой почты...

1. Как обрабатывается заявка? Чтобы она не потерялась "где-то в почте у коллег", создается task в баг-трекере. В который аттачатся письма, в котором идет обсуждение, что ответить, что сделать итд.

Теперь представьте себе длинную переписку. И ее отображение в комментариях... Тут, как говорится, "лучше один раз увидеть".

2. А если тестировщик забыл приаатачить письмо? Дел много, главное - ответил, остальное ерунда. По прошествии времени сидит, смотрит на задачу - "блин, что-то же делал,а что?". Лезет в почту, ищет, аттачит... Время - деньги!

3. Тестировщик заболел / ушел в отпуск. Его Заказчика радостно передают другому. У этого другого информации - все, что в джире было. А ведь половины и не было (чтобы не раздувать комменты). Что делать? Куда бежать?

В общем, так подумаешь, подумаешь... И поймешь - надо Заказчиков в баг-трекер переводить!

Создать специальный тип задач - Support Request. И пусть пишут вопросы туда. А ответственные (читай - тестировщики) будут отвечать. Но одно дело - ответить на 2 строчки, а другое дело, переслать письмо, где эти самые две строчки окаймляют "Кто? Кому? Кто в копии? Тема письма", а также подписи.

Всем хорошо! Все плюшки подхода остались, а минусы решились! Добавилась информативность - теперь вы всегда в курсе, что происходит на проекте, даже если не входите в почту его support-a. И легко можете заменить коллегу.

Но! Опять это "но", будь оно неладно.

Ребята! Подумайте заранее. Ну если у вас уже есть такая почта. И в джире (возьмем как пример баг-трекера) уже есть куча тасков, созданных по этим письмам. Подумайте заранее о возможном переходе Заказчика в джиру!

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

Так вот. Все Заказчику видеть явно не надо. Только свой проект и только такие запросы. Но старые запросы ему видеть интересно. А иначе какой смысл? Часть переписки - в джире, а часть - в почте.

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

Ура? Агащаз. Сначала багу открой и почитай комменты.
А что мы пишем в комментах?

"Хихи, наконец-то они поняли, что это неудобно"
"Да вы что? Это нереализуемо! Нафик всех!"
"Ма-а-а-а-аш, посмотри, плиз, тут можно что-то сделать?"
"По-моему, они нас динамят..."
...

Ну и всякие мелочи аля "Закрывающему потестить то-то" или "пофиксил тут-то", которые Заказчику, опять же, не нужны.

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

PS - Начитавшись Демарко, вдохновившись мистером Томпсоном, я решила если не каждый день, то хоть иногда находить умные и/или полезные идеи в течение рабочего дня и записывать их...

PPS - А пряча в джире флуд 6 часов подряд, я не могла промолчать... 

суббота, 30 июня 2012 г.

Точное описание доработки и ревью тест-кейсов

Когда ставится доработка, ее описание не всегда блещет краткостью, которая - сестра таланта.
Или не всегда новое. Например, захотел Заказчик фичу. Ставим доработку, а все последующие уточнения по ней просто добавляем в комментарии.

Что из этого может получится? Да ничего хорошего! Люди вообще ленивые создания, читать километровую переписку в комментах... Ну разве что от скуки или из любопытства. А если на тебе и так 10 задач, надо быстро все проверить? Будете читать? Не, ну пяткой бить себя в грудь на словах мы все умеем... А на деле?

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

В релизе была доработка. Написать DB View. Доработку делала я, закрывающий - Никита.
В описании задачи - лаконичные первоначальные требования. И дли-и-и-и-инный шлейф переписки в комментах.

Сделали, даже закрыли. Потом обсудили на митинге - как-то быстро закрыли, ай-яй-яй, давайте еще посмотрим. Хотя зачем смотреть - давайте сразу автотесты напишем! Ну ок.

Так как по бизнес-логике Никита мог что-то забыть, то он попросил меня помочь ему с написанием тест-кейсов:

- Давай обсудим, чтобы я ничего не забыл?
- Ок, напиши в вики свой вариант и приходи.

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

Ок. Прошлись по основным шагам, но терзают, терзают меня сомнения. Ведь что-то было такое... Недавно... В соседнем проекте... Покопалась в джире, стали вместе изучать проблемы "соседа". Обсуждаем, обсуждаем, и тут Никита говорит "

- Нет, подожди, Заказчик вроде не то хотел...
- Да ладно о_О

Фишка в том, что, совершая некие действия, мы получаем некий результат. И во вьющке, соответственно, можно показывать или одно, или другое, или все вместе. Я сделала - все вместе.

Смотрим багу - в описании только требования к полям. Открываем почту, находим переписку - ой :) А ведь изначально планировалось отображать только результат!

Но как оно бывает?

- Если забываете - записывайте.
- Я записываю! Но забываю, где...

Это ведь было записано, но! В комментах. Которые никто при быстром ревью задачи не читает. Смотрят куда? В условие... Ну и на последний коммент, так и быть.

И главное - я то все записала. Причем специально, чтобы, если что, можно было переписку в багтрекере найти. А не лазить по почте. Но вот ведь... Согласовала же! А то, что это слегка противоречит первоначальным требованиям... Ну не мешает же :) Просто лишнее значение вытащено "на свет божий", вдруг пригодится?

Вот к чему приводит нежелание подкорректировать описание задачи...

А если бы решили не писать автотесты? Махнули бы рукой - руками проверил и ладно?
Ну и что, что слишком быстро, "а мы пальцы скрестим и понадеемся, что ошибок не будет"...
А если бы мы махнули рукой на ревью - "взрослые же люди, сам напиши то, что считаешь нужным и достаточным"?

Закрывающие задачу нужны не просто так. Это как программист, который пишет код. Ему сложно оценить его, протестировать - сам же написал! Нет там багов!!

Блин, я чувствую себя программистом :)))

Не забывайте - задачи/доработки в багтрекере ставятся не просто так! Если вам когда-нибудь понадобится вспомнить, "а с чего все начиналось" и вы полезете искать закрытую полгода назад задачу, первое (иногда и единственное), что вы будете изучать - это описание. Поэтому его надо держать актуальным.

И не пытайтесь быть гением, за которым не надо проверять. Все мы люди, все мы человеки. Все ошибаются. Это не страшно. Страшно считать, что тебя это не касается :)