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

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

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

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

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

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

Подумаем?

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

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

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

КОНФЛИКТНЫЙ ПРОЦЕСС 

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

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

Я перешел в другой проект. О тестировщиках там только слышали. 

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

У тестировщиков нашего департамента принята структура хранения тестов, при которой
1. Тесты разделяются на функциональные и регрессионные и, соответственно, хранятся в разных каталогах "известной системы".
2. Функциональные тесты структурированы по релизам, а регрессионные - в соответствии с компонентной моделью (как правило). Понятно, что компонентная модель регрессиии отличается от новой функциональной.
3. После тестирования релиза определенный набор тестов (согласно проставленным приоритетам и здравому смыслу) копируется в каталог регрессионных тестов. Остальные забываются.

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

01. Function testing
---- Release 01
---- Release 02
------ SecProd + Certificate Dicsount
-------- Server side components
-------- GUI implementions


02. Regression testing
----Options 
----Swaps
------ Interaste Rate Swap
------ Variance Swap
---- Exotics

В новой команде подобную логику менеджер проекта понять не смог.

Зачем создавать сценарии, чтобы потом их не использовать?

Почему мы должны разделять функциональное и регрессионное тестирование, если нам все равно нужно тестировать все компоненты?


Зачем хранить тесты в двух разных каталогах?

Со стороны менеджера поступило предложение:
1. Хранить все тесты в одной папке.
2. Прогонять все тесты или просто их приоритезировать (благо разработчики знали и могли это делать).

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

И это удачный кейс, когда тестировщики не спорили о процессах с менеджером.

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

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

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

Я определил эту проблему как риск и к концу релиза накопил статистику (кстати я ее показывал ежедневно - в отчете). Потери составили 30% ровно.

С тех пор 30% постоянно включались в оценку, как устранение риска "Время потраченное на исследование багов и ретестирование". И это история о том, что идею порой приходится продавать несколько раз.

Хуже всего, когда менеджер пытается сам строить процесс тестирования и активно лезет руками проверять функционал. Все с тем же "молодым" менеджером связана еще одна история.

Я пришел в проект, в котором тестированием занимались вендоры индусы. О том, чтобы получить отчет, что именно они протестировали было сложно. Тем не менее они отчитывались в конце дня о проделанной работе словами и "молодой" к ним уже привык.

Но я же не индус. Первым делом я захотел отчитаться о том, что я сделал формально. Менеджеру было все равно (хорошо, что не запретил), но мне согревало душу, что я смогу ответить на вопрос "Как было протестировано так, что баг нашли пользователи?". В конце концов индусы "худо-бедно" начали также добавлять комментарии - что они тестировали. Настоял сам мененеджер - небольшая победа.

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

Нужно отдать должное "регионалам" они понимали с кем общались. Поэтому на фразу "он тестирует медленно" прозвучали вопросы "Как вы сравнивали?" и "А качество повысилось?". Поскольку учета времени индусов не велось, а качество оценить мог только я (улыбаюсь на все свои кривые зубы), то я таки доказал, что качество повысилось (и это кстати правда!)

Отношения несколько обострились.

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

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

В итоге менеджер "сдался". Мы стали тестировать медленно, но верно.

КОНФЛИКТНЫЙ РЕЛИЗ

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

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

Люди привыкают ко всему.  Даже к плохому пользовательскому интерфейсу. Даже к текстовому редактору vim.  Даже к тому, что релиз для последнего цикла тестирования попадает за  несколько часов до релиза.  И особенно люди привыкают, к трудностям других людей. Менеджеры проектов сами не программируют и не тестируют (за некоторым исключением) и поэтому в некоторых клинических случаях ИХ даже приходится убеждать что мы устали так работать.  Что делать в этом случае?

Как вы определяете что релиз готов?

Такой вопрос мы часто задаем на собеседовании.  Самый желаемый ответ:

У нас есть стандартное/задокументированное определение готовности  (definition of done) релиза.

Чтобы не было путаницы. У разработчиков и тестировщиков может быть разное определение готовности (ровно потому, что у нас разные задачи). Более того может быть совсем отдельное определение готовности релиза.

Пример определения готовности разработки:

1. Все требования запрограммированы.

2. Код размешен в системе хранения версий.

3. Написаны unit-тесты с определенным уровнем покрытия.

4. Задача в системе управления работ переведена на тестировщиков.

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

6. Код-ревью выполнен и замечания устранены.

7. Все настройки/конфигурирование специально для данной фичи добавлены в Release Notes.

Пример готовности после тестирования:

1. Созданы тесты для покрытия всех требований или 100% требований покрыты тестами.

2. Все тесты с приоритетом critical/high проверены и дефектов нет.

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

4. Для каждого элемента тестирования (фичи, бага) существует формальный sign off от тестировщиков.

5. Все задачи в систему управления работ переведены в Testing completed.

6. Отчет с результатами тестирования разослан всем заинтересованным лицам с решением: тестировщиков: продукт готов к релизу/продукт к релизу не готов.

Пример определения готовности:
1. Все критические баги исправлены.
2. Нет ни одного не успешного регрессионного теста.
3. От пользователей получено подтверждение на каждое изменение (проведено приемочное испытание и есть письменный sign-off - все по взрослому).
4. Release notes есть и описано как настраивать систему для нового функционала для установки на проде.

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

Но защитить свои мягкотелые окружность нужно.

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

Ничего личного - только бизнес.

ЗАКЛЮЧЕНИЕ

Пора подводить итоги. Из всех этих процессуальных и релизных несогласий с менеджерами я вынес несколько уроков.

Урок первый. Люди ошибаются

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

Урок второй. Нужно уметь продавать идеи

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

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

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

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

Урок четвертый (последний и основной). Нужно постоянно поддерживать и улучшать отношения с менеджером

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

Качество или Время? - Вечная борьба.  

И кто знает, что у нас в настоящий момент - нимб или рожки?