Подробное описание того, что значит быть тестировщиком в гибкой проектной команде.

Я читал Agile Testing: Практическое руководство для тестировщиков и Agile-команд Лизы Криспин и Джанет Грегори, когда нашел небольшую часть, в которой обсуждалось существование Билля о правах. для программистов и заказчиков. Лиза Криспин отметила, что Билль о правах тестировщика отсутствовал, поэтому они с Джанет приступили к его созданию¹.

«Билль о правах тестировщика» содержит шесть статей, каждая из которых описывает основные права или обязанности тестировщика в agile-команде. К сожалению, не хватает подробностей по каждой статье. Новые тестировщики могут задавать вопросы по этим статьям, в частности:

  1. Что значит предоставить оценки для истории спринта?
  2. Почему я должен выступать за подход «всей команды» к качеству?
  3. Как мне обратиться к моей команде по поводу внедрения новых инструментов?

В этой статье мы попытаемся ответить на поставленные выше вопросы, а также дать представление о статьях, изначально написанных Джанет Грегори и Лизой Криспин.

Статья 1

«Вы имеете право поднимать вопросы, связанные с тестированием, качеством и процессом в любое время».

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

Будучи инженером по автоматизации QA в TransLoc, я заметил, что процесс подготовки моей команды был больше сосредоточен на конкретизации историй, а не на доработке невыполненной работы. Из-за этого команда тратила больше времени на обсуждение историй, что в конечном итоге закончилось «обработкой» одной истории за сессию, тогда как мы должны были сделать как минимум пять. В результате мы проводили две подготовительные сессии в неделю, что сокращало время разработки и тестирования.

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

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

Статья 2

«Вы имеете право задавать вопросы клиентам, программистам и другим членам команды и получать своевременные ответы».

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

Задавайте вопросы не только вашей команде разработчиков, но и заинтересованным сторонам продукта и клиентам.

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

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

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

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

Статья 3

«Вы имеете право просить и получать помощь от любого члена команды проекта, включая программистов, менеджеров и клиентов».

Недавно я столкнулся с ситуацией, когда я был натянут и не мог самостоятельно провести регрессионное тестирование всех своих релизных билетов. У меня было два варианта:

  1. Рискните отложить релиз, тестируя все в одиночку
  2. Попросите мою команду помочь мне в тестировании

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

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

Делайте все возможное, чтобы помочь своей команде. При необходимости обращайтесь за помощью, будь то проверка заявки, уточнение реализации функции или понимание процесса.

Статья 4

«Вы имеете право оценивать задачи тестирования и включать их в оценки историй».

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

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

Например, у вас есть тикет, который оценивается в 5 стори поинтов, на разработку которого должно уйти примерно 2–3 дня работы. Тестирование тикета на основе истории с продуктом займет примерно полдня. Автоматизация создается параллельно с разработкой и, вероятно, займет около дня, когда все будет сказано и сделано.

По моему опыту, я бы оценил эту историю как 8. Я лично добавил бы 0,5 балла для тестирования и от 1 до 1,5 балла для автоматизации, в результате чего получается 7, которое округляется до 8 как следующее число Фибоначчи в последовательности.

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

Статья 5

«Вы имеете право на инструменты, необходимые для своевременного выполнения задач тестирования».

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

Когда я начинал в Vodori, Inc., команды разработчиков использовали бесплатную версию Hiptest (теперь Cucumber Studio), которая в то время позволяла одновременно работать только 10 пользователям. Наша команда постоянно добавляла и удаляла пользователей, так как разработчики принимали участие в написании и выполнении тестовых сценариев. Это был довольно громоздкий и трудоемкий процесс.

Примерно через шесть месяцев борьбы с бесплатной версией я предложил Vodori рассмотреть корпоративную версию. Пытаясь изложить свое дело, я обратился к Hiptest и попросил провести судебное разбирательство. Нам дали корпоративную версию на один месяц с условием, что по истечении месяца нам нужно будет либо заплатить, либо перейти на бесплатную версию.

Я сопоставил количество времени, которое мы потратили на удаление и добавление лицензий, по сравнению со стоимостью корпоративной версии. Я также отметил преимущества использования предприятия, такие как доступ к «Живой документации».² Затем я представил эти данные моему менеджеру по обеспечению качества и техническому директору компании, утверждая, что мы сэкономим время и усилия, используя предприятие.

Мое дело было отклонено. Проще говоря, в то время Vodori не мог полагаться на корпоративное программное обеспечение. У нас просто не было средств, чтобы оправдать расходы.

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

Статья 6

«Вы имеете право ожидать, что вся ваша команда, а не только вы, будет нести ответственность за качество и тестирование».

Вполне возможно, что это самая важная из статей «Билля о правах тестировщика». Ваша команда должна понимать, что качество — это работа, над которой должна работать вся команда, а не только те, кто отвечает за тестирование продукта.

Моя команда в Pendo.io усердно работала над тем, чтобы перенести качество из правой дорожки в левые столбцы. Вместо того, чтобы сосредотачиваться на качестве в конце спринта, как каскадная команда, мы стараемся обсудить проблемы с качеством как можно раньше. В настоящее время мы предприняли следующие шаги для обеспечения того, чтобы качество было делом всей команды:

  1. Регулярные обсуждения качества и дизайна приложений в Slack
  2. Приглашение тестировщиков на встречи по составлению чертежей, подготовке и планированию
  3. Отмечая влияние качества во время масштабного проектирования, подготовки и планирования
  4. Разработчики, участвующие в ручном и автоматизированном тестировании
  5. Командные форумы о том, как тестировать и на что обращать внимание при тестировании

Как много раз подчеркивали Лиза Криспин и Джанет Грегори в Agile Testing, качество — это инициатива всей команды, а не исключительная ответственность тестирующей стороны.³

Резюме

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

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

Ресурсы

  1. Гибкое тестирование: практическое руководство для тестировщиков и гибких команд, Лиза Криспин и Джанет Грегори, Addison-Wesley, 2014, с. 50.
  2. Живая документация. Живая документация | Документация по CucumberStudio, support.smartbear.com/cucumberstudio/docs/bdd/living-doc.html.
  3. Гибкое тестирование: практическое руководство для тестировщиков и гибких групп, стр. 15.