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

Слайдшоу.

Подробно

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

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

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

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

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

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

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

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

ШАГ 1

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

Часто случается, что программист с тех. лидом уже сделали какую-то фичу. Фича переходит в тестирование в сокращенном варианте.
На примере ниже — это заголовок с небольшим указанием, что может пригодиться для тестирования 🙂

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

Решая эту задачу и основываясь на своем жизненном опыте, я нашла вот такие решения:
Внедрение новых практик — одной из которых, будет, к примеру, ежедневный синк программистов и тестировщиков( личная встреча или звонок)  на 30 минут -1 час для того, чтобы задать все имеющиеся вопросы и получить на них ответы.  В том числе такие синки позволяют создать дополнительные action items или подзадачи и мини-собрания для того, чтобы глубже уточнить некоторые другие вопросы и не занимать время всех присутствующих.

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

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

Немного о Team rules
Вот например памятка о том,  какого алгоритма было бы хорошо придерживаться, высылая предложения клиенту.

Proposal emails
All our proposal e-mails should correspond to the following structure:
1)Business case. How the fix/feature affects business logic.
2)Technical description of the fix/feature: What a cause of the issue? How the feature should work from technical point of view?
3)Ways to fix/implement. Analyze merits and demerits of every suggested method.
4)Conclusion: what we would prefer and why.

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

2.  тестировщик-программист.
Когда и как решать вопросы по новым фичам. Переводить неясную задачу на программиста или организовать несколько кратких синков в течение дня в удобное для всех время и т.д.

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

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

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

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

ШАГ 2

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

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

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

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

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

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

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

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

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

ШАГ 3

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

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

ШАГ 4

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

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

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

ШАГ 5

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

В случае, когда нужно подстраиваться под сложившиеся  шаблоны, я предлагаю свои решения, но если они не устраивают лида, или не подходят под проект, предпочитаю пересмотреть свои убеждения в сторону согласованности.
Желательно договариваться о едином стиле написания тестов, чтобы потом можно было проходить чужие тесты как свои. Это даже можно вынести в блок своей внутренней вики Team rules.
Ниже я представила свои заметки по написанию тестов:

ШАГ 6

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

А еще есть человеческая высокомерность, чувство всесильности, когда один человек что-то знает, а другой нет. Иногда люди, которые владеют информацией, этим пользуются и пытаются таким образом показать свою значимость. Что тут говорить, — незнающим коллегам в такой ситуации нелегко.
На новом проекте ситуация может доходить до того, что коллеги объединяются и начинают жаловаться на то, что человек ничего не знает, с ним невозможно работать, потому что он задает много вопросов. Тут хочется задать вопрос: может быть, дело не в том, что человек глупый, а в том, как организован процесс, и как сам человек понял свое место в этом процессе? На эту ситуацию  у каждого будет свое видение.

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

Как получить нужную информацию в короткие сроки?
На слайде несколько примеров того, что помогало мне.

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

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

ШАГ 7

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

ИТОГ