Home

Оригинальная публикация: http://qablog.practitest.com/leading-by-example/

Перевод: Анна Радионова

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

На заре времен разработки тестирование считалось незыблемым/неприкосновенным.

Тестировщики были закреплены за отдельными командами, они были изолированными единицами в организационной иерархии для того, чтобы они не попадали под влияние разработчиков. Взгляд  тестировщиков на продукт был беспристрастным. Тестируемые системы являлись “черными ящиками”, в которые тестировщики подавали данные на вход и делали выводы о состоянии продукта на основании полученных в результате данных.

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

С появлением и распространением agile методологий убежденные “отщепенцы” стали понемногу замещаться фидбеком и тестированием пользователей.

Тестирование в рамках традиционных больших команд было заменено на закрепление специалиста по тестированию за небольшой командой разработки.

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

Ценность тестировщика определяется тем, насколько по-другому он мыслит в сравнении с другими членами команды.

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

Методологии и фреймворки

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

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

Но, с другой стороны, не существует единой структуры внедрения тестирования в команды.

Влияние через отождествление

Если люди не понимают ЧТО вы делаете, КАК вы это делаете и как обсудить то, что вы делаете, то как в этом случае ваша команда может считать вас полноправным ее членом?

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

Проблема заключается в том, что у тестирования нет достаточного влияния, которое необходимо для принятия командой целого набора новых процессов и терминологии.   Тестирование не является ключевым процессом в разработке.

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

Понимание

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

Принятие

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

Коммуникация

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

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

Давайте рассмотрим несколько примеров:

Автоматизация тестирования

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

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

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

Планирование спринта

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

Совершенно не так дело обстоит с тестированием при таком подходе - оно больше похоже на задачу вида “протестируй это”.   Более подробный отчет о трудозатратах тестирования нужно отслеживать в отдельных системах или тест-планах.

Почему нужно отслеживать тестирование отдельно от реализации?

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

Относительно недавно разработка считалась черным ящиком, каким и сейчас является тестирование. В то время разработчикам выдавался проект и некоторые требования  и их не беспокоили до момента сдачи проекта.

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

Тестовое планирование

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

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

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

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

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

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

Код-ревью

Код-ревью является довольно прямолинейной концепцией: до интеграции кода в продукт он передается на рассмотрение одному из членов команды или группе людей для получения фидбека.

Как можно понять, этот процесс не универсален и не существует явно описанного стандарта по которому оценивается код. Если качество кода является субъективным, то что же команды ожидают от проведения процедуры код-ревью?

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

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

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

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

Тест-ревью

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

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

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

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

Тест-планы и тест-кейсы можно использовать как обучающий инструмент. Вместо подсчета тест-кейсов и создания отчетов вида pass/fail, пусть тестировщики кратко описывают свои действия и мысли, возникающие у них, во время проведения тестирования. Можно проводить ревью этих заметок и сохранять  в качестве справочной информации, как хранится код.

Коммуникационное управление

В приведенных примерах первый шаг - это понимание.

Чем глубже понимание - тем лучше наше представление о продукте и процессе.

Чем лучше представление - тем более эффективной становится коммуникация.

Чем эффективнее коммуникация - тем большее влияние может оказывать тестировщик.

Это позволяет тестировщику стать полноценной функциональной единицей в команде.

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

Можно также использовать практику “тестировщик разработчику”. Вы можете оказывать содействие в планировании спринта или проведении код-ревью с точки зрения тестировщика. Трудно спорить с уже существующим рабочим построением процесса на примере вашей команды.

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

Обсудить в форуме