Не ройте колодцы в тестировании

Любой человек должен уметь менять пеленки, 
планировать вторжения, резать свиней, 

конструировать здания, управлять кораблями, писать сонеты, 

вести бухгалтерию, возводить стены, вправлять кости, 

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

сотрудничать, действовать самостоятельно, решать уравнения, 

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

Специализация — удел насекомых.

Роберт Хайнлайн 
Достаточно времени для любви

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

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

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

Считайте данную заметку, своего рода антисилосным (silos = колодец) манифестом в тестировании. Только без лозунгов и транспарантов.

Передача знаний: о зрелости, врагах и жертвах

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

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

Наивная конфликтология в картонках

Сидели с коллегам за рюмкой чая. Кроме всего прочего затронули конфликты и споры в команде. Делились опытом. От коллеги по цеху прозвучал слегка наивный (мое глубокое ИМХО), но интересный способ делегирования своей команде разрешение споров.

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

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

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

Картинка номер три - нолик. Эта картонка означает, что человек просит руководителя принять решение. Т.е. человек самоустроняется и готов подчиниться воле начальства.

Картинка номер четыре - две стрелки указывают в одну сторону. Это самое приятное - коллеги приняли одно решение.

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

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

Если команда новая или в споре участвуют новички, то чаще случаются первые (спорим дальше) варианты.

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

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

Интересный способ учить команду общению. Слегка наивный, но интересный.

В копилку менеджеру: 10 главных факторов, мотивирующих на работу

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

Ричард Флорида опросил двадцать тысяч творческих профессионалов, предложив им на выбор тридцать восемь факторов, которые мотивируют их на лучшее выполнение работы. Вот десять главных факторов:

1. Задача и ответственность.

2. Гибкость.

3. Стабильное рабочее окружение.

4. Деньги.

5. Профессиональное развитие.

6. Признание коллег.

7. Стимулирование коллег и начальников.

8. Захватывающее содержание работы.

9. Культура организации. 

10. Местность и сообщество. 

Только один из этих стимулов является внешним (№ 4 — деньги). Все остальное — это либо то,что мы делаем сами для себя, либо то, что мы ценим само по себе. 

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

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

Моете ли вы руки до и после?

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

Человек жаловался на свою команду, которая не может точно выполнять "простые" правила описанные на вики. Рядом стоял и поддакивал другой наш коллега. Разговор шел в неформальной обстановке (как водится выпивали). И меня зацепило то, с каким пылом  Коллега №1 клял разработчиков за то, что его простые правила либо игнорируются, либо выполняются не до конца.

Небольшая предыстория. Пришел в команду Коллега №1 недавно. Полгода назад. Все, вроде бы, было неплохо. Знания получил. Процесс передачи из разработки в тестирование поставил. Начал требовать от разработчиков соблюдения Definition Of Done. Стал его расширять и в какой-то момент столкнулся с тем, что ребята не до конца выполняют все дефенишины. Причем разработчики честно признаются: правила правильные, они согласны... Но вот выполнять их целиком или постоянно то ли сложно, то ли забывают. А сами правила действительно достаточно простые  и правильные (насколько я мог судить по словам коллеги).


Коллега №2 поддакивал и говорил, что разработчики очень  не любят правила. Вообще мы, как Дартаньяны, должны за ними следить. 


Тут я уже не выдержал и решил вмешаться (если честно еще и пиво в голову ударило, захотелось платоновских диалогов, но не начинать же сразу с "Ты меня уважаешь?").


Я: Говорите правила правильные и обязательные?


К1: Да


Я:  Без них проекту прям смерть?


К1: Ну чо передергиваешь. Они нужные и их легко выполнять. Просто все. Достаточно один раз понять и использовать. И все. Ну умные же люди. Могли бы уж запомнить. И делать.


Я: Ммм. Ты в курсе что руки нужно после туалета мыть?


К1: Ну в курсе.


Я: Моешь?


К1: Мою


Я: Всегда?


К1: Ну практически.


Я: А перед туалетом мыть руки нужно?


К1: Нужно. ..


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


Долго молча пили пиво...

Начальники с Марса. Подчиненные с Венеры.

Закончил читать книгу "Мужчины с Марса. Женщины с Венеры" Джона Грея. 

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

Очередной поток мыслей переформулированных цитат показался занятным.

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

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

Люди испытывают душевный подъем и прилив сил когда чувствуют себя нужными.

Процесс с нуля. Первые шажки 3: Отчетность и Визибилити

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

Нет более неблагодарной работы, чем подготовка отчетов и постоянное подтверждение, что ты тот самый, в то самое время, на том самом месте.

Люди с небес

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

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

C прочтением книги "Дети с небес" у меня осталось стойкое убеждение, что многие советы из книги подходят и для обычных взрослых - как менеджеров, так и подчиненных.  В книге несколько раз встречалась фраза "советы для детей всех возрастов". Дети бывают всех возрастов - бывают малых, а бывают - и взрослых ))))

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

Список рефразированных цитат, который, как мне кажется, будет полезен как менеджерам так и подчиненым - детям всех возрастов. 

Трудности перевода

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

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

Целая тетрадь.

Записная книжка отзаборовдообедов.

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


Товарищи курсанты, принято решение начать лекции сегодня в декабре... Не важно, что завтра еще ноябрь...

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

Процесс с нуля. Первые шажки 2: Планирование и Знания

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

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

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

Процесс с нуля. Первые шажки - 1: Взаимоотношения и Тестовая лаборатория

За последние 2 года мне удалось "поосваивать" - в хорошем смысле слова - несколько разных по сложности о составу команды проектов. Каждый проект уникальный. А задачи с созданием группы тестирования - вроде бы одни и те же...

Новый проект. Новые люди. Новые традиции и новые горизонты в тестировании.

Знакомиться с новыми людьми.

Изучить новый продукт.

Построить свою работу с нуля.

Как не утонуть в новом хаосе?

Я бы хотел сегодня покопаться в этой нелегкой куче.

Полезные вопросы

Продолжаю собирать полезные вопросы для развития себя любимого.

Где мое узкое место, ликвидация которого позволит перейти на другой уровень?

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

Почему я это  опять продолбал?


Почему я этого раньше этого не сделал?


Почему так получилось?

Вариант про узкое место предлагает предугадать, а не анализировать по факту.

Если к начальнику/разработчику/сослуживцу придут и спросят в чем я силен  - что он ответит?
Правда немного пугает  - тем более будет интереснее ее услышать раньше других.

Что еще можно сделать?

Акцент смещен  с "нужно", на "можно". Перенос зависимости от "начальника"/"окружения"/обстоятельств на инициативность.

Хотя, вполне возможно, я в очередной раз - цепляюсь к словам.

Работа над ошибками: Почему мы не согласны с менеджером.

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

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

Одним из таких вопросов стал "Если вы не согласны с менеджером, как бы вы поступили?".

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

Но сам вопрос очень интересен для будущей практической пользы.

Подумаем?

Кто виноват?

Кто виноват в том, что баг пропустили?

Риторический вопрос.


Наверное разработчики, потому что они баг посадили.


Или, быть может, тестировщики, потому что они баг пропустили.


А может быть менеджер? - он су..а, времени не дал, чтобы нормально запрограммировать , а потом протестировать.


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

"Доска портвейна" - как способ самоорганизации команды.

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

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

Сплотить или поощрить сплотиться - чувствуете разницу?