Дело касается не только 8-ми часового рабочего дня. "Положено" также касается обязанностей тестировщика. Он с удовольствием покопается в базе данных, порыщет в логах, потыкается в приложении, проведет исследование функционала (даже если ему уже дать готовые сценарии). Но проработав тестировщиком большую часть своей сознательной жизни он искренне считает, что тестировщик должен только тестировать.
Жизненный кейс таков, что на утренней "пятиминутке" PM высказал сомнение: ему было непонятно почему напарник не интересуется состоянием найденных им багов.
Напарник тестировал отдельный функционал и каждый день отчитывался формальным отчетом, но PM "иногда" не читает писем и задает вопросы на "пятиминутке". На вопрос "Сколько осталось времени чтобы закончить тестирование?" напарник ответил, что все зависит от того, когда разработчиками будут исправлены баги.
На вопрос "Когда же баги будут исправлены?", напарник неосторожно ответил, что не знает и не спрашивал у разработчика. Менеджер мягко пожурил и перешел к следующему вопросу.
Наша беседа после совещания выглядела так:
Жизненный кейс таков, что на утренней "пятиминутке" PM высказал сомнение: ему было непонятно почему напарник не интересуется состоянием найденных им багов.
Напарник тестировал отдельный функционал и каждый день отчитывался формальным отчетом, но PM "иногда" не читает писем и задает вопросы на "пятиминутке". На вопрос "Сколько осталось времени чтобы закончить тестирование?" напарник ответил, что все зависит от того, когда разработчиками будут исправлены баги.
На вопрос "Когда же баги будут исправлены?", напарник неосторожно ответил, что не знает и не спрашивал у разработчика. Менеджер мягко пожурил и перешел к следующему вопросу.
Наша беседа после совещания выглядела так:
Н: (обиженно) Я тестирую. Я нахожу баги. Я их описываю. И что я еще должен следить за разработчиком, когда он их исправит?
Я: (кивая головой и улыбаясь улыбкой-а-ты-как-думал) Да!
Толстый канал общения
В тот самый момент, когда разработчики отвечают "ДА! У нас кое что есть для вас" инициатива переходит к нам и начинается наш крестовый поход. Общаться, общаться, общаться и постоянно задавать вопросы - я не знаю другого "королевского" пути, чтобы понять, что у нас будет завтра/послезавтра готово к тестированию. Этот путь также единственный, чтобы правильно спланировать работу и сказать менеджеру (как только он спросит или если даже сам не спросит) "Завтра баги будут исправлены и готовы на тестовой лаборатории, я планирую проверить их к вечеру и именно поэтому мы пока укладываемся в сроки". А в нашем статус отчете пишем так, чтобы он и не спрашивал:
Проблема:
Когда будет решена:
Кто проинформирован и кто решает проблему:
Или если у проблемы нет владельца и не известно когда решат, то меняем проблему на риск
Риск:
Какое влияние на проект (сколько времени продолбаем):
Кто владелец:
И уж если вы не можете влиять на пользователя или разработчика, то менеджер как раз для этого и предназначен, в конце то концов.
Цепь взаимоотношений
Когда то я работал на предприятии сохранившем многое от советского образа жизни. Я сумел (очень надеюсь на это) впитать все хорошее и понять все плохое. Одним из "хороших" понятий было "цепь передачи полномочий".Кратко. Каждое звено в цепи связано с двумя другими. Если мы говорим в терминах продукта, то после того, как звено сотрудников (или даже один сотрудник) №1 заканчивает работу и передает звену №2 готовый продукт и полномочия, то следующей задачей звена №1 является помочь звену №2 передать продукт и полномочия звену №3 - и это обязанность, а не опция!
В нашем случае это замкнутая цепь разработчик - тестировщик - разработчик.
Нам передают функционал - Мы тестируем и находим баги - Разработчик исправляет баги - Мы тестируем и находим баги ... И по кругу, по кругу - до тех пор, пока не решаем прекратить тестирование. И в течение этого процесса мы помогаем разработчикам передать нам обратно исправленый продукт и полномочия его проверять.
Ведь мы связаны одной цепью и должны помогать друг другу. А также уметь друг друга готовить ;)
думаю это акутально только если цепочка прямая - тестер->разработчик. то есть тестер сам ассайнит баги, сам назначает билд, когда баг доложен быть пофикшен. ну, либо последнее они решают вместе или еще как.
ОтветитьУдалитьесли же баги тестера сначала попадают к человеку, который их ассайнит, а также решает - быть им пофикшеным в ближайшем билде или нет - то обязанность следить за тем, когда разработчик их исправит, с тестера снимается.
мммммммммм....
ОтветитьУдалитьА кто это такой человек вне команды разработки, который принимает решение - фиксить или нет? Для чего тогда ПМ, команда разработки и тестировщики (и еще не названные роли)?
Решение об исправлении бага принимается командой, а поскольку идет тестирование и именно тестировщик репортит о состоянии стадии тестирования, он должен предоставлять информацию о всех проблемах.
То, что не решено - будется исправлять баг или нет - это риск, что мы можем не уложиться в сроки.
Если принято решение что баг будет исправляться, тестировщик должен "спросить с пристрастием" разработчика - когда он его исправит.
Если разработчик не может предоставить сроки - тестировщик должен об этом сообщить менеджеру.
Ровно так я и имел ввиду )))
Кстати, Ваш напарник во многом прав) Если баги висят на разработчике, то PM, если хочет знать реальную картину, должен спрашивать у разработчика, когда он их исправит и в чем загвоздка. На то он и менеджер, чтобы координировать группы разработчиков и тестировщиков, на то ему и полномочия - спрашивать и требовать.
ОтветитьУдалитьТестировщик, конечно, может спросить, но он не может и не должен требовать - это не его компетенция. По-хорошему, разработчик должен сам написать, еще до вопроса от тестировщика, когда ожидать исправления и сколько это займет. То есть, разработчик должен быть в курсе того , что "одно дело делаем" и информировать о сроках, задержках и проблемах.
В идеале, чтобы люди друг другу горло не перегрызли необходимо выработать единый workflow с учетом особенностей данного конкретного коллектива. Участвовать в процессе согласования этого workflow должны все заинтересованные. После того, как описание процесса всех устроит, оно должно быть принято всеми на вооружение. Несоблюдение должно "караться". Тогда не будет вопросов кто кому , что должен - порядок будет один для всех. Подписался? Будь добр , исполняй.
Еще раз по порядку))):
ОтветитьУдалитьТестировщик не только тестирует и работает только 8 часов - он часть команды, которая помогает менеджеру принимать решение.
Тестировщик (или лид - если тестировщиков несколько) это единственный правдивый источник информации на любой момент времени о состоянии тестирования продукта.
Тестировщик отвечает за предоставление информации на стадии тестирования: прогресс (скорее сроки окончания) и все, что может повлиять на сроки окончания тестирования и следовательно сроки передачи продукта клиенту.
Отсутствие информации от разработчика - риск, который может повлиять на сроки.
Если разработчик по какой либо причине (не знает, выше его компетенции, он занят и т.п.) не способен ответить на вопрос - об этом нужно сообщить (не пожаловаться, а сообщить).
Если тестировщик не потрудился спросить - это плохо.
Если тестировщик не потрудился определить риски - это плохо.
Если тестировщик не потрудился пересчитать сроки - это плохо.
Теперь относительно комментариев:
ОтветитьУдалить>На то он и менеджер, чтобы координировать группы разработчиков и тестировщиков
Менеджер не должен координировать группы разработчиков и тестировщиков - для них посредник не нужен, это замедляет работу. Т и Р должны работать и решать внутренние проблемы сами.
>Тестировщик, конечно, может спросить, но он не может и не должен требовать - это не его компетенци
Согласен на 100%, но не МОЖЕТ а ДОЛЖЕН спрашивать
>По-хорошему, разработчик должен сам написать, еще до вопроса от тестировщика, когда ожидать исправления и сколько это займет.
Как я вам завидую - у вас такие хорошие разработчики в команде )))
>В идеале, чтобы люди друг другу горло не перегрызли необходимо выработать единый workflow с учетом особенностей данного конкретного коллектива....После того, как описание процесса всех устроит....
Как бы я хотел жить в идеальном мире! - ЧЕСТНО! Но реалии таковы, что приходиться работать с теми, кто есть и строить отношения так, как наиболее выгодно (но с оглядков в перспективу). Тут просто болото для бесед. У нас пока нет набора единых процессов. Команда молодая, мы движемся вперед. Но ей богу идеального процесса нет - нет процесса, который всех устроит. Ну, не верю я.
>Несоблюдение должно "караться"
Вы очевидно поклоник карательных мер. Исправляйтесь!!! )))
Интересная беседа получается, честно..) Продолжу пожалуй ее )
ОтветитьУдалить>>Тестировщик, конечно, может спросить, но он не может и не должен требовать - это не его компетенци
>Согласен на 100%, но не МОЖЕТ а ДОЛЖЕН спрашивать
Хорошо, допустим , он спросил. А разработчик ему в ответ "Отвали, я тут занят и мне не до твоего бага". Что дальше делать тестировщику?
>Как бы я хотел жить в идеальном мире! - ЧЕСТНО! Но
Вот например как у нас (далеко не в самой идеальной конторе): обсужден и принят единый workflow разработки софта. Начиная от получения "хотелки" от заказчика, и заканчивая внедрением этому же заказчику.. Каждый знает , что от него требуется в данный момент времени по данному вопросу и старается соблюдать этот workflow. Понятно, что люди могу забыть , запить, забить - для этого обязанностью руководителей групп является контроль за соблюдением процесса. Не тотальный, а выборочный. В результате в целом можно сказать, что мы работаем по единым правилам. И эти правила разработаны коллегиально, все понимают , что эти правила служат общей цели. В общем, это работает. Конфликтов минимум.
Да, кстати, этот самый workflow со временем эволюционирует, оптимизируется.
>о ей богу идеального процесса нет - нет процесса, который всех устроит
ОтветитьУдалитьТо есть, вы отрицаете способность людей договариваться ? А я верю (и практика это подтверждает), что при грамотном менеджменте компромисс возможен. Главное до человека донести, что он приходит на работу не только для отстаивания своих принципов и потакания своим "хочу" и "не хочу", а для того чтобы достигать КОМАНДНО общего результата. Поверьте, это действует и помогает договариваться.
>Хорошо, допустим , он спросил. А разработчик ему в ответ "Отвали, я тут занят и мне не до твоего бага". Что дальше делать тестировщику?
ОтветитьУдалитьЯ именно в этом вопросе выделил бы две задачи:
1. Наладить именно с этим конкретным разработчиком такие отношения, чтобы он не грубил.
2. Определить приоритеты бага. Поскольку решать фиксить-не фиксить может либо команда (Т+ Р), лимо ПМ (зависит от команды) неплохо бы определиться как с ним (багом) работать.
Проблем с ответом разработчика не вижу (правильно замечено, мы на их работу не влияем). Но мы можем сообщить, что разработчика спросили, но он не может предоставить ответить (почему - вопрос не к нам)
>Вот например как у нас...
Рад, что у кого-то все замечательно... Нет честно рад. но "Конфликтов минимум" - конфликты то все таки есть ;).
В команде всегда присутствует противостояние время-качество, на одной стороне (с самого края) команда разработки + ПМ, на другой - тестировщики. Истина где то на пересечении интересов.
Именно потому, что достичь 100% качества при 100% производстве продукта в срок невозможно (по моему скромному мнению и опыту), я считаю, что идеального процесса нет.
Хороший процесс построить можно. Удовлетворить всех членов команды нельзя.
>То есть, вы отрицаете способность людей договариваться ?
Нет конечно же!
Я обожаю книгу "Программируем командный дух", и прежде всего я пытаюсь построить отношения и только потом начинаю строить процесс.
Договоренности по крайней мере в России влияют больше, чем стандарты, законы и прочие процессы.
Люди могут и должны договариваться )))
Да, и мы с Вами это доказали ))
ОтветитьУдалить+1
ОтветитьУдалитьтоже плюсану, что "Люди могут и должны договариваться"
ОтветитьУдалитьНо по сути поста полностью согласен с вашим напарником - тестировщик НЕ должен тратить своё время на получение у разработчика информации "когда будет исправлен баг". Пинговать манагера (лид-проекта) на предмет "когда вы планируете предоставить билд в тестирование" или "не забудьте с билдом прислать описание что добавили/что починили" - это ок.
Конечно, совсем другое дело проходя мимо конкретного разработчика, обсудить рабочие моменты. Например "не стоит ставить багу 474 wont fix, потому что билд с таким багом гарантированно вернётся обратно".
Хотя конечно уместность подобных активностей зависит исключительно от компании. Точнее от практик и процедур, принятых в компании. Например, является ли тестировщик одним из участников проекта или отдел тестирования является внешним сервисом для проекта.
ОтветитьУдалитьДа, согласен. Тестировщики как сервис это другое.
ОтветитьУдалить>тестировщик НЕ должен тратить своё время на получение у разработчика информации "когда будет исправлен баг"
ОтветитьУдалитьТестировщик многое "не должен" делать:
Не должен писать юнит тесты, потому что программист это сделает лучше.
Не должен поднимать и управлять тестовой лабораторией, потому что это обязанности суппорта.
Не должен планировать, поскольку это дело менеджера.
Не должен писать документацию, потому что на это есть бизнес аналитики.
Не должен общаться с программистами, потому что тратит драгоценное время.
Не должен вообще разговарить, потому что он должен только тестировать! ))))
Я уже согласился, что "тестировщкик как сервис" это другой подход, но не могу согласиться, что тестировщик не должен тратить свое время на получение информации, ровно потому что информация это кровь, плоть, кости - все для тестировщика. В мире нулей и единиц ничего означает смерть.
Я уже высказался, что на этапе тестирования тестировщик должен быть единственным источником информации.
Как тестировщик получает информацию это вопрос технологии:
- это может быть письмо,
- это может быть телефонный/личный разговор,
- это может быть комментарий в Jira или иной системе.
Но если информации нет, тестировщик ее должен получить. Без вариантов. Если не может получить - определить риски.
Я исхожу из предположения, что команда должна решать проблемы быстро, дещево и умно. Тестировщик должен быть на порядок организованее и решительнее, чем разработчики, по крайней мере в вопросах коммуникации.
Так и осталось непонятным, что мешает менеджеру узнать напрямую у разработчика,когда будут исправлены дефекты и зачем использовать тестировщика как посредника в получении этой информации?
ОтветитьУдалитьКак мне кажется координация работы команд и получении информации из первоисточника несколько разные вещи, это номер раз.
Номер два, своевременное исправление дефектов, скорее головная боль менеджера, т.к., чаще всего, именно он полностью ответственный за проект и поэтому у него больше возможностей воздействовать на разработчиков. Тестировщик, как правило, кроме влияния никаких других возможностей для воздействия не имеет.
Если тестировщик занимает активную позицию и старается получить от разработчиков как можно больше информации и договориться о датах исправления дефектов и сроках поставки билдов, это несомненно хорошо, но на мой взгляд не является обязательным.
Все же, основная задача, предоставить информацию о времени необходимом для тестирования и рисках связанных с несвоевременным исправлением дефектов и поставкой билдов на тестирование.
>Так и осталось непонятным, что мешает менеджеру узнать напрямую у разработчика,когда будут исправлены дефекты и зачем использовать тестировщика как посредника в получении этой информации?
ОтветитьУдалитьТестировщик ведет финальный этап разработки приложения и предоставляет общую информацию по одному из 10 стримов.
15 разработчиков+3 тестировщика+10 разрабатываемых приложений/сервисов - Менеджеру некогда быть нянькой для каждого сотрудника по каждому багу.
>Номер два, своевременное исправление дефектов, скорее головная боль менеджера
Не согласен - это головная боль всей команды.
>Как мне кажется координация работы команд и получении информации из первоисточника несколько разные вещи
>Если тестировщик занимает активную позицию
Коллеги, мы с вами взрослые люди, наверное, кто то даже считает себя профессионалом. Если вас нужно "координировать" на работу с командой, возможно просто настало время пересмотреть свое отношение к работе либо поменять работу. Без обид.
Мое мнение такое: каждый человек должен относиться к своей задаче как к своему личному делу, от постановки до завершения.
ОтветитьУдалитьТестировщики должны интересоваться, что происходит с их багами, они должны интересоваться, в каком состоянии фича и почему её задерживают на час, они должны понимать, какое значение эта фича имеет для пользователя.
Для меня ситуация, когда тестировщик "просто ждет, пока ему подадут задачу на тестирование", а потом "просто ждет, когда пофиксят баги" - неприемлема!
Такой подход должен быть у всей команды. Аналогично неприемлемо, если разработчик отдал задачу на тестирование и не интересуется её статусом.
В Вашем, Саша, примере, на мой взгляд, менеджер мог задать тот же самый вопрос и тестировщику, и разработчику. И ни от одного из них он не должен был услышать: "Я не знаю, я свою часть выполнил, у них спрашивайте."
Еще раз, и по пунктам:
ОтветитьУдалить-чем больше тестировщик и разработчик общаются и обмениваются информацией, тем лучше.
-если разработчик и тестировщик согласовывают график поставки билдов для тестирования и помогают друг другу в решении задач, это хорошо, я бы сказал очень близко к идеальному.
Но, если доступны разработчики, например тим-лид, считаю, лучше информацию получать у разработчиков, т.к., в общем случае, они могут предоставить более актуальную информацию.
>Коллеги, мы с вами взрослые люди, наверное,...
Александр Орлов аплодировал бы стоя, да.
Читайте, пожалуйста, более внимательно, в данном предложении была высказана совсем другая мысль.
Ilya, согласна я вами, что разработчики предоставят менеджеру более актуальную информацию.
ОтветитьУдалитьНо только на этапе активной разработки. Когда же проект переходит в тестирование, то актуальной информацией обладают уже тестировщики. И разработчики (хорошие) интересуются у тестировщиков "как там наш код?". И при обнаружении багов тестировщики (хорошие) не просто выписывают их в Jira, а лично обсуждают проблему с разработчиком и, действительно, знают сроки на ее исправление.
Так что менеджер вполне себе вправе задать вопрос о состоянии бага тестировщику. Заодно и состояние коммуникаций в команде узнает))
>В Вашем, Саша, примере, на мой взгляд, менеджер мог задать тот же самый вопрос и тестировщику, и разработчику. И ни от одного из них он не должен был услышать: "Я не знаю, я свою часть выполнил, у них спрашивайте."
ОтветитьУдалитьЧеловек работает в Гонконге - спал наверное уже в это время )))
>Еще раз, и по пунктам:
ОтветитьУдалить>Читайте, пожалуйста, более внимательно
Коллега извините, как говориться, что хотел то и прочитал ))
>Но, если доступны разработчики, например тим-лид, считаю, лучше информацию получать у разработчиков, т.к., в общем случае, они могут предоставить более актуальную информацию.
Татьяна верно подметила то, что я слабо выразил - следует разделить два этапа: программирование и тестирование.
Команде дается задача и сроки, далее идет "командная" работа. На этапе разработки программист лучше знает, что и когда он закончит (и в идеале он даже угадывает))) ). На этапе тестирования тестировщик собирает информацию, чтобы ответить на главный вопрос менеджера - "Сколько осталось времени чтобы закончить тестирование?" или его аналог .
Человек, который отвечает перед пользователями за сроки поставки продукта, не должен тратить время на "координацию" команды и выяснение "когда будет пофикшен баг", он вправе ожидать, что команда с внутренним задачами разработки справится сама и предоставит ему адекватную информацию или ответ на вопрос:"Мы успеваем?". На этапе тестирования это должен делать тестировщик. Без вариантов.