Страница 8 из 11
Мы видим значительный прогресс в том, что касается важности компетенций внутри команд, а не ролей или должностей. Когда происходят такие изменения, чаще вместо «Это не моя работа» можно услышать «Как я могу помочь?». Сотрудники по-прежнему имеют ключевые навыки в каких-то вопросах, но уже не так сильно привязаны к определенным ролям. Например, фраза «Я тестировщик» означает: «В основном я занимаюсь тестированием, потому что люблю это занятие и разбираюсь в нем. Я могу руководить и направлять остальных, а могу помочь и в других областях».
Однажды на конференции Пит Волен из Мичигана раздавал свои визитки. Джанет с радостью приняла одну из них. Однако ее привлекла указанная на ней должность. Она спросила об этом, и вот что Пит ответил.
На моей визитке, кроме имени и контактов, есть еще три вещи.
Самое очевидное – «тестировщик ПО». Это то, чем я занимаюсь. Я тестирую софт и помогаю коллегам улучшить показатели в этой области.
«Антрополог ПО» было добавлено после долгих раздумий на Conference of the Association for Software Testing (CAST) в 2011 году. Майкл Болтон выступал с докладом о развитии программного обеспечения, в частности тестирования как социальной науки. Это зацепило меня и заставило о многом задуматься. Главным образом мои мысли касались отношений между людьми и приложениями. При оценке принципов работы ПО эти взаимоотношения весьма важны и составляют существенную часть сути тестирования.
Это подводит нас к третьему и самому важному пункту – «постановщик вопросов». Это похоже на QA, и часто термин путают с тестированием. Сколько помню себя в сфере разработки ПО, так и было. Это раздражало меня некоторое время. В 2009 году я разговаривал с Майклом Болтоном, Фионой Чарльз, Линн МакКи, Нэнси Кельн и другими. В этой беседе постоянно использовалась формулировка: «Тестировщики задают вопросы, чтобы узнать, как реагирует или должно реагировать ПО». Постановка вопросов ведет к получению информации о софте, о том, как мы взаимодействуем с ним, и, определенно, к еще большему количеству вопросов. По крайней мере, до тех пор, пока на большинство вопросов не будут найдены ответы, удовлетворяющие заинтересованные стороны.
А это вновь возвращает нас к «тестировщику ПО».
Нам нравится термин «постановщик вопросов», который можно использовать и в планировании совещаний. Более подробно на этом остановимся в четвертой части.
В командах, с которыми работала Лайза, границы между ролями размылись. Некоторые программисты еще и опытные тестировщики. Иногда именно тестировщик находит простое решение для сложной задачи в написании кода. К тому же люди с широким кругом компетенций могут соответствовать более чем одной роли в коллективе. Например, в команде, где сейчас работает Лайза, есть программисты – системные администраторы с обязанностями DevOps-менеджеров.
В последние несколько лет термины типа DevOps стали широко использоваться, подчеркивая взаимосвязь между разработчиками ПО и сетевым оборудованием и операциями. Хотя термины и могут казаться новыми, отличительной особенностью Agile-команд всегда было то, что здесь выполняют работу, которую раньше обычно делал человек, занимающий другую должность. (Мы поговорим о взаимовыгодном сотрудничестве между специалистами DevOps и тестировщиками в главе 23.)
Триша Кху, инженер по тестированию из Австралии, делится опытом и говорит о том, что происходит, когда вся команда думает о тестировании.
В прошлом году я устроилась в небольшую команду, где разработчики действительно ценили тестирование и рассматривали его как неотъемлемую часть всего цикла создания продукта. Я никогда не забуду одну из первых планерок, где мы обсуждали новый элемент. Один из разработчиков насупился и сказал: «Да уж, но как мы собираемся его тестировать?». В результате весь проект изменили.
Я едва не упала в обморок, потому что не слышала о подобном за всю свою карьеру. Важным было то, что не команда спрашивала меня, тестировщика, как я собираюсь тестировать это. Вопрос задавался всей команде: «Как мы вместе собираемся это тестировать? Как нам сделать так, чтобы быть уверенными, что это будет работать так, как задумано?».
По ходу создания элементов разработчики всегда писали тесты: от модульных до браузерных. Кто-то из разработчиков всегда вручную проводил тестирование перед тем, как передать продукт мне. Именно благодаря этому я редко обнаруживала баги, вызванные невнимательностью. Большинство были связаны с пользовательскими или системными сценариями, которые не проявлялись раньше.
Вы можете подумать, что мне как тестировщику в таком случае не приходилось слишком много работать. Мой самый ценный вклад в процесс заключался в том, что я анализировала продукт с точки зрения тестировщика и пользователя. Я поняла, что тестирование было не так важно в конце процесса, но невероятно важно в его начале.
Чем больше внимания я уделяла тестированию на начальной стадии, тем меньше усилий требовалось в ручном тестировании в конце, потому что в результате возникало гораздо меньше багов. Я бы хотела выделить последнюю мысль в умную цитату, потому что, на мой взгляд, это важно.
Но основной частью этого было то, что я знала: разработчики тестировали продукт качественно, вдумчиво писали тесты, тестировали их вручную по мере разработки. Я точно знала, что, если на встрече планирования мы говорили о сценарии, он будет качественно разработан и к концу процесса протестирован с помощью автоматизированных регрессионных тестов.
В этом году мне часто приходилось обсуждать роль тестировщика. Давайте оставим это сейчас и подумаем о роли разработчика софта. Этот человек должен быть уверен, что его продукт будет функционировать так, как задумано. Знания о том, как делать это на элементарном уровне, – важное качество для хорошего разработчика. Именно поэтому требуется больше тестирований на стадии разработки. И они должны проводиться именно теми, кто создает продукт.
Иметь в команде тестировщика ценно, но не стоит возлагать всю ответственность за тестирование на одного человека. У вас может быть отдельный специалист по базам данных, но это не значит, что он единственный, кто работает над этим. То же самое справедливо и для тестирований. Специалист может помочь в действительно сложных вопросах, зная, что все остальные члены команды в состоянии справиться с более простыми задачами.
Это заметно сокращает время обратной связи, повышает уверенность и ускоряет процессы QA. Кому такое может не понравиться?
Во многих Agile-командах появились специалисты с различными компетенциями. Например, сейчас часто можно встретить как бизнес-аналитиков, так и тестировщиков, плотно занимающихся различными вопросами бизнес-анализа. Границы между ролями и обязанностями размываются. В то же время такое пересечение обязанностей внутри команды не означает, что можно совсем обойтись без определенных специалистов. По нашему опыту, коллективы заходят в тупик из-за отсутствия у них специалистов с конкретными навыками. Порой решение простое: нанять человека, обладающего этими навыками, или обучить уже имеющихся сотрудников.
Команда, с которой я недавно работала, находилась в растерянности из-за того, что мы взялись за несколько проектов, которые не были достаточно оценены бизнес-экспертами головного офиса. В результате мы постоянно обращались к заказчику за разъяснениями требований или показывали готовые разработки только для того, чтобы в ответ услышать, что мы все сделали неверно.
Мы, тестировщики, предложили нанять бизнес-аналитика, который бы помог клиенту прояснить, что именно ему нужно. Наш руководитель продукта не был знаком с новой головной компанией, и хотя он встретился с заинтересованными лицами, тем не менее не знал, какие вопросы задавать, чтобы добраться до сути того, что нужно. Опытный бизнес-аналитик знал бы, как вести переговоры с заказчиком, и задавал бы правильные вопросы.
К сожалению, менеджер не захотел нанимать бизнес-аналитика, так что мы создали свое сообщество по методам бизнес-анализа. Тестировщики, руководители продуктов, Scrum-мастера, менеджер-разработчик и заинтересованные программисты собрались вместе, чтобы прокачать свои аналитические навыки. Мы читали книги и статьи, посещали конференции, мастер-классы и участвовали в семинарах, чтобы разобраться в бизнес-аналитике. Мы постоянно встречались, делились информацией и записывали все в собственную вики-энциклопедию.
Возможно, лучше было бы нанять эксперта, но наши старания принесли плоды. Руководитель продукта обучился методам и техникам общения, которые мог использовать на встрече с представителями головной компании. В итоге он лучше стал понимать нюансы. Нам и теперь порой не хватает информации, какие именно задачи хочет решить клиент, но мы больше не тратим так много времени на то, чтобы ходить туда-сюда и спрашивать про каждую мелочь.