Человек оркестр: тестировщик и журналист

Как часто мы (тестировщики) общаемся с коллегами?

Часто - хотелось бы побольше тестировать.

А как часто мы на работе задаем вопросы?

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

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

Я опять новичок в команде. Проект распахнул объятия новому единственному тестировщику. Отсутствие плана обучения новичков усугубляет ситуацию. Но мы же качки!

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

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

Как - вот главный вопрос на сегодня?

ИНСТРУМЕНТЫ НА ВООРУЖЕНИЕ

АНКЕТЫ

Опрос мнений разных людей по одному и тому же вопросу. Где же мы можем их применять? Хм.. А вот пожалуйста -  kick off meeting.

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

В качестве небольшого примера полученного результата:

Что в скопе релиза?  Что нужно тестировать?  Что тестировать не нужно?	Для релиза 2011.1 есть фильтр задач … Задачи, которые требуют тестирования имеют значение поля «Требуют тестирования» = Yes Залачи не предназначенные для тестирования (технические, аналитика пр) имеют значение поля «Требуют тестирования» = Yes
Какие приоритеты?  Какой порядок пересмотра приоритетов.	Приоритеты расставлены в системе управления задачами.  Пересмотр приоритетов возможен на утренних митингах с обязательным участием проект менеджера, руководителя программистов, руководителя тестировшиков
Когда планируется релиз?	Дата релиза: 19 июня (воскресенье)
Каковы критерии выхода из разработки в тестирование?	Код помещен в систему хранения версий В задаче поставлен статус «Готово к тестированию» Все затронутые компоненты помечены (для определения скопа регрессии) В задачу добавлен комментарий, как можно проверить или описаны основные шаги воспроизведения
Как будет передаваться код в тестирование?  Когда планируется код-фриз?	Планируется что еженедельно во вторник и четверг будут передаваться билды в тестирование. Код фриз (остановка разработки новых фич и только фикс критичных багов) будет за 2 недели до релиза.
С кем из пользователей можно общаться во время тестирования?	Для фич 1-3 — Вася Пупкин (телефон, мыло) Для фич 4-10 — Проект менеджер Для фич 11-13 — Руководитель разработчиков
Кто отвечает за развертывание тестовой лаборатории?	Тестировщики отвечают за развертывание нового релиза в тестовой лаборатории
Кому можно жаловаться эскалировать, в случае рисков и блокеров?	Проект менеджер, руководитель тестировщиков, тест менеджер
Формат (ежедневной, еженедельной) отчетности.	Шаблон отчета размещен на wiki по адресу...

Другой пример.

Post Mortem/Lesson Learned. Я пытался внедрить подобную практику в двух проектах. Очень и очень сложно сломить скептицизм пессимистов:

Если нам что-то не нравиться, мы это сразу устраняем... А еще мы устраняем надоедливых тестировщиков.

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

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

Один из прошлых "освоенных" проектов:

Проблема	Решение
Нет четкого понимания что тестируется автоматизированными тестами. - Разработчики вендоры более не доступны - Отсутствует четкое понимание ожидаемых результатов - Нет понимания почему использован Jmeter - Отсутствует спланированное иследование сценариев (даты релизов существенно влияют и не позволяют тестировщикам изучать продукт)	После релиза 10.8 включать в оценку тестирования время на исследование и доработку автоматизированных сценариев – но не более 10% от времени на ручное+автоматизированное тестирование.
Отсутсвуют тесты для ручного регрессионного тестирования - Присутствуют  чек листы (не известно покрытие) - Вендоры тестирующие продукт более не доступны	После релиза 10.8 включать в оценку тестирования время на исследование и доработку регрессионных сценариев – но не более 10% от времени на ручное+автоматизированное тестирование.
Автоматические тесты производительности созданы без учета нагрузки на проде.	Проанализировать логи прода и разработать модель для тестирования производительности
Во время выкатывания релиза на тестовую лабораторию приемочного тестирования возникли сбои. Потребовалось дополнительые затраты времени на создание нового билда	Процесс создания билда и развертывание на тестовой лаборатории описан и размещен в wiki
Большие затраты из-за сбоев в тестовой лаборатории: --Тестирование сервиса 1: 37 m/h (2 QA) --Тестирование сервиса 2: 42.5 m/h (1 QA)	1. Продолжить собирать статистику по простоям тестировщиков 2. Во время простоев заниматься анализом и доработкой регрессионных и автоматизированных тестов.

ДИСКУССИИ

О, эти нескончаемые ожидаемые результаты.

О, эти отсутствующие-неполные-неясные-противоречивые требования.

О, этот хаос в головах и разруха в процессах...

Королевской дороги к уменьшению хаоса нет. Но есть допросы дискуссии.

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

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

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

ТРЮКИ, LIFE HACKS, BEST PRACTICES

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

30-60-60

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

Журнал интервью

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

Анализировать - Формулировать - Получать ответ - Записывать

Это постоянный цикл. Если есть что почитать - почитай и подумай. Если есть вопросы - запиши. Если нет ответов - спроси. Если есть ответы - запиши. Если записал - не поленись просмотреть и подумать: чего еще не знаешь.

Короткие сессии

Устанавливайте границы даже если у вас весь свободен весь день. Для интервью нужно постоянно чувствовать цейтнот. 30-60 минут. Тул для отсчета времени - http://e.ggtimer.com/. 

Во-первых люди устают, даже от умных разговоров о вечном. 

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

Перефразируйте, перефразируйте, перефразируйте.

Правильно ли я понял...Поправьте меня если я не прав...Т.е. вы хотите сказать... 

Меня это "спасало" не один раз. В условиях постоянной неопределенности очень легко понять по другому.  А если человек говорит на нерусском языке - включаются дополнительные культурные и фразеологические риски.

"Ко встрече со звездой нужно готовиться"

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

Minutes of Meeting

Всегда подводите итоги. Даже если кроме вас никто этих самых итогов не увидит. Если говорить о формальных митингах (kick off, post mortem) то Minutes of Meeting (старый добрый протокол совещания) это то, что спасает нас в больших компаниях.

Психологически благоприятная обстановка

Где это место? Для меня - всегда возле моего компьютера. Но это не всегда возможно. Чужой компьютер тоже подойдет. Для разработчиков - примерно та же схема. 

Но. 

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

Шаг за шагом меняем понимание на формализм: лично - веб камера - телефон - письмо

С каждым шагом мы все дальше от человека и более сложно получить ответ в пересчете системы вопрос-ответ. Более формально = менее информативно.

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

Большое количество информации передается при помощи жестов, интонации, гримас и даже молчания. Передать многозначительное молчание в официальном письме... Хм... Нужно попытаться в следующий раз.

Интервью != Допрос

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

Улыбаемся и сохраняем чувство юмора

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

И напоследок - самое основное правило.

Уходя, не забудьте поблагодарить.

Вам еще предстоит вернуться ;)