Предлагаю вашему вниманию краткую версию моего доклада "Testers and Developers. Как заставить их слушать друг друга" к сожалению не могу выложить видиоверсию, по сему будет в формате сказки с картинками.
Тестеры и девелы - многие считают, что конфликт заложен в самой основе их отношений - и я тоже так думал.
Но в условиях развития гибких методологий разработки, работы в стиле - одна команда, все тим мемберы, все равны (прям путь к коммунизму); коммуникации между этими якобы противоборствующими сторонами стали очень критичными.
Но может стоит проблемы решать, а не оставлять как есть?
Давайте попробуем разобраться в чем же суть конфликта?
• Каждый видит функциональность по своему
Скорее всего это происходит потому что нет точки сихронизации знаний между тестировщиком и разработчиком на понятном для них обоих языке
• Каждый договаривается с заказчиком о чем-то своем
Переписки и созвоны, а информация полученная или обговоренная на них не шарится между двумя сторонами. Как вы знаете тестировщики и разработчики мыслят немного по разному. То есть когда разработчик ставит вопрос «Должна ли быть отсылка нотификации по e-mail после регистрации?» и получает ответ «должна» это является достаточным для него ответом. (Немного утрирую для более драмматичного представления контента) Тестировщик же (хороший тестировщик) узнает, помимо того должна ли быть посылка, как это должно выглядеть и должен ли контент письма конфигурироваться в соответствии к каким-то бизнес нидс (как например рассылка банеров акций при регистрации), какие должны быть в письме ссылки и куда они должны вести, ну и наконец добавит что-то от себя, какое-то предложение, которое видел при получении подтверждения регистрации в гугле.
• ЭГО не позволяет признать свою неправоту
Мы все великие специалисты, и чего это нам кто-то, кого мы то и за людей не особо-то считаем будет указывать что делать? Мы всегда уверенны в своей непогрешимости. Это немного утрированная но в то же время довольно распространенная позиция в отношения тестеры-девелоперы. И она опять же в сторону недостатка информации – ни девелоперы не тестеры не козлы при этом (это правило, но как все знают из каждого правила есть и исключения) они просто не договорились и как следствие каждый стоит на своем (бараны да, но не козлы же)
• Взаимное недоверие
Ребята не доверяют друг-другу, ибо, почему-то думают что одни хотят выехать за счет других, Хотя по сути дело то одно делают
• Преследуют разные цели
Зачастую девелоперы не думают о том что в рамках итерации нужно еще время на тестирование, и делают то что должны сделать «аж до поки часу стане». Как результат идет на демо недотестированная функциональность при этом с далеко не нулевой вероятностью получить 500 прямо на глазах у заказчика.
• Девелоперы считают тестеров некомпетентными
Ну это уже как догма )
• Тестеры считают девелоперов лентяями
Это кстати тоже
И что же мы получаем в результате такого тим-ворка:
Почему же так получается, или какие проблемы нам надо решать?
• Дублировали работу
• Не обсудили друг с другом реализацию перед внедрением
• Усугубляли проблемы вместо того, чтоб решать их
Для того чтоб решать проблемы надо для начала понимать кто чего хочет, а потом начинать балансировать желания и возможности.
Вот, чего, по моему мнению хотят от работы разработчики:
У нас есть собранные желания обоих сторон, так же есть собранная проблематика, Теперь давайте решать каждую из проблем по очереди:
1. Для того чтоб добиться изначального понимания нужно понять кто за что отвечает на стадии анализа требований, еще перед тем как начали писать код или тесты. Обратимся к хотелкам обеих сторон:
Девелоперы хотят чтоб им сказали что делать, а они сказали как, то есть если дать ребятам описание + моки того как это должно выглядеть и работать для конечного пользователя, то как это реализовать они придумают.
Тестировщики хотят чтоб не было двойственного понимания того как это должно работать для конечного пользователя
Заказчик не хочет платить за одну работу дважды.
ИТОГО – тестировщики могут прояснять как должно работать для конечного пользователя, а девелоперы в свою очередь должны реализовывать это «как» при помощи своей великой инженерной мысли.
2. Более-менее четко распределять роли между друг другом – девелоперы инженеры, которые знают как сделать, тестировщики – инженеры которые знают что надо сделать. Если отбросить эго и синхронизировать эти два полюса по средствам распределения обязанностей, то результат превзойдет все ожидания.
3. Проблема не шарить знания между друг-другом, решается по средствам создания общего чата с заказчиком/requirement owner’ом , а так же приглашением на созвоны всех заинтересованных сторон. При переписке тоже очень не сложно ставить в копию все заинтересованные лица.
4. Последнее, но очень важное – не забывать про общие цели. Наша цель выпустить продукт приемлемого качества в приемлемые сроки. Это цель общая, но есть и личные, которые этому способствуют : задача девелоперов выпустить продукт в приемлемые сроки, а задача тестировщиков – выпустить продукт приемлемого качества, то есть по сути – ребята, мы друг без друга никуда.
Резюме. Сделать так чтоб тестировщики и девелоперы слушали друг-друга, задача общая – менеджмет должен организовать такую систему взаимодействия при которой задачи которые решают девелы и тестеры не дублируют друг друга, девелы должны прислушиваться и основываться на том, как это должно работать с точки зрения конечного пользователя, а тестеры, должны принимать экспертное техническое мнение девелов по поводу реализации.
Спасибо, за уделенное время,
Коменты как всегда велкам.
Артем
No comments:
Post a Comment