Тестирование в командах Agile — это процесс, а не конечный пункт. Эту идею, витавшую в наших мыслях, нам подсказала Элизабет Хендриксон (Hendrickson, 2006). В книге мы подчеркиваем: в процессе разработки софта тестирование должно учитываться на всех этапах.
Постоянно изучая лучшие техники Agile-тестирования, мы обнаружили, что подготовка специалистов широкого профиля с углубленными знаниями и навыками помогает справиться со сложными задачами. Опытные эксперты создали методы и шаблоны, которые позволяют членам команды из разных сфер сотрудничать и узнавать друг от друга ровно столько, сколько им необходимо.
Практикующие специалисты, такие как члены Agile-альянса инструментов функционального тестирования (Agile Alliance Functional Test Tools, AA-FTT), проложили путь к созданию более эффективных инструментов тестирования. Сегодня подход к написанию кода тестов так же важен, как и подход к написанию кода основного приложения. Мы научились определять, какой фреймворк, тестовая библиотека или драйвер подходят для конкретных нужд команды.
Выявляя потребности клиентов, бизнес-аналитики внесли свой вклад в развитие Agile. Тестирование и бизнес-аналитика обладают некоторыми взаимосвязанными качествами, которые помогают определить коммерческую ценность продукта. Таким же образом эксперты по пользовательскому интерфейсу (User Experience, UX) показали простой действенный способ вовлечения клиентов на этапах разработки новых элементов. DevOps-специалисты соединили разработку, функциональную часть и тестирование для улучшения качества в новых условиях (разработка и запуск). Их метод также позволяет сократить цикл запуска, снизить риски и повлиять на заказчика.
По сравнению с тем, что мы наблюдали несколько лет назад, сейчас Agile-команды понимают важность исследовательского тестирования. Хотя очевидно, что пользы от него может быть в несколько раз больше. Мы рады, что коллективы, использующие его в работе, делятся своим опытом.
Появились новые, творческие подходы к планированию тестирований и сотрудничеству. Сегодня у компаний куда больше возможностей визуализировать качество. Матрицы и пирамида тестирования адаптированы и расширены для применения в различных областях.
Все больше команд сталкиваются с тестированием мобильных приложений и встроенного ПО на расширяющемся поле устройств и платформ. Огромные объемы информации, содержащие новые технологии хранения, управления, анализа, поиска и визуализации, формируют новую категорию — большие данные (Big Data). И тестирование должно соответствовать новым реалиям.
Изначально Agile подразумевалась как методика для небольших коллективов, работающих в одном помещении. Сейчас мы видим, что Agile используют как крупные организации (нередко начинавшие как маленькие Agile-компании), так и распределенные команды. В организациях с общекорпоративным ПО тестирование сопряжено со строгими ограничениями. В то же время организации находят новые пути использования приложений с минимальным функционалом (Minimum Viable Products, MVPs), обеспечивающим итерационные релизы с быстрыми циклами обратной связи и доступное обучение.
В 2008 году некоторые компании были заняты тестированием в продакшн (на живой среде); мы не слышали об этой технике, если не считать случаев выпуска продукта без тестирования с одной только надеждой на успех. Сегодня выпуск обновлений для небольшого количества пользователей путем изучения логов на предмет ошибок и другие методы получения быстрой обратной связи могут стать важной и необходимой стратегией в определенных условиях.
Все эти изменения и инновации подвигли нас и других специалистов поделиться знаниями и опытом. Agile постоянно развивается, и многие из вас уже внедряют эту методологию, изменяя бизнес-процессы в обучении. Актуальные задачи, связанные с тестированием, во многом отличаются от тех, что вы решали, когда только начинали вникать в Agile. Надеемся, опыт, представленный в этой книге, породит идеи для экспериментов, чтобы можно было визуализировать качество вашего продукта, а затем изучить и адаптировать свои процессы.
РЕЗЮМЕ
С развитием программного обеспечения Agile мы постоянно изучаем и актуализируем методы тестирования. В этой главе мы рассмотрели, как именно менялось Agile-тестирование.
• Мы поняли, что тестирование — это процесс, невероятно важный для успешности продукта, и поэтому в нем должен быть заинтересован каждый член команды: от совета директоров до разработчиков и службы поддержки.
• Команды, работающие по Agile, четко осознают, как специалисты из разных областей (бизнес-аналитики, UX-дизайнеры и DevOps) расширили наши возможности, чтобы добиваться нужного для заказчика уровня качества.
• Инструменты для Agile-тестирования продолжают стремительно развиваться, позволяя Agile-командам внедрять инфраструктуру, необходимую для поддержки обучения и быстрой обратной связи.
• Agile-команды познают ценность исследовательского тестирования и других методов, которые помогают донести необходимую информацию до клиентов и разработчиков.
• Agile-тестирование должно идти в ногу с быстро меняющимися технологиями и новым контентом. Далее мы поговорим об этом.
Глава 2. О важности корпоративной культуры
Мы заметили схожие тенденции в организациях, переходящих на Agile. Команды разработчиков способны внедрить ценности, методы и практики Agile. Однако бизнес медленнее понимает преимущества Agile, и для изменений требуется больше времени. Для успешного перехода на Agile необходимо, чтобы между разработчиками и работниками коммерческих отделов существовало взаимопонимание и имелось представление о работе друг друга.
Если ваше руководство осознаёт, что через качество можно наилучшим образом донести коммерческую ценность до клиентов, скорее всего, и организация, и команда преуспеют. Регулярность и слаженность работы со временем совершенствуются. Наоборот, если компания отдает предпочтение скорости, качество часто страдает. Технические недоработки в хрупком, тяжелом коде и долгое время обратной связи снижают способность слаженно работать.
Если команды находятся под давлением нереальных сроков для выполнения определенных объемов, они не контролируют свою загруженность. С приближением дедлайна выбор у разработчиков сокращается, и они стремятся лишь управиться в срок, а не удовлетворить потребности клиента (Rogalsky, 2012). Скорее всего, они начнут торопиться и принимать решения, не думая о последствиях, и таким образом войдут в штопор постоянно увеличивающегося количества технических недоработок.
Командам необходимо обозначить опасность неразумных шагов, чтобы руководители компании знали о рисках и последствиях. Иногда нужно сбавить обороты, чтобы заняться техническими недоработками, или изучить новые концепции, или применить новые идеи. В своих презентациях Джанет использует рисунок с застрявшими в пробке суперкарами. Он показывает, как добавление новых элементов, не согласующихся с общей инфраструктурой, может парализовать работу. Зачем добавлять что-то, если система не будет работать, как ожидалось? Когда у вас накапливается слишком много технических недоработок, команда застревает.
НЕ ЖАЛЕЙТЕ ВРЕМЕНИ
Чтобы представить клиентам полезный софт, необходимо подойти к задаче творчески. Людям нужно время, чтобы все обдумать и применить свое мастерство. Мы также должны постоянно осваивать новые технические навыки, изучать новые инструменты. Это помогает проводить небольшие эксперименты, которые могут быть полезны при решении различных задач.
В статье «Медленные идеи» (Gawande, 2013) Атул Гаванде объяснил, почему некоторые инновации, такие как хирургическая анестезия, внедряются быстро, а другим, например антисептикам, требуются годы (а то и вообще этого не происходит). Вывод: изменения происходят только путем обучения, практики и личной заинтересованности. В программах, которые анализировал Гаванде, люди обучались лучше всего, когда сами выполняли новые действия, описывая их своими словами, под наблюдением преподавателя. Может показаться, что дешевле и быстрее нанять тренера, который покажет, как нужно делать, или заставить людей посмотреть обучающее видео, но практический подход обеспечивает реальные стабильные изменения.
В сфере программного обеспечения (как и во многих других) люди порой забывают, что для овладения новыми навыками требуется время и практика. Они часто отказываются от тренера, который бы обучал и направлял сотрудников.
...Тратьте время на то, что нужно
Дэвид Эванс, Agile-тренер по качеству, поделился метафорой, к которой прибегает, когда объясняет, что необходимо тратить время на то, что действительно нужно.
Иногда приходится сталкиваться с сопротивлением со стороны менеджмента, когда я предлагаю потратить время на совместное описание приемочного тестирования, прежде чем внедрять то или иное требование. Обычный аргумент: если команда потратит больше времени на приемочные тесты, это замедлит темпы разработки. В некотором смысле, конечно, замедлит, но ровно настолько, насколько замедляет движение автобус, чтобы забрать пассажиров с остановки. Попытки оптимизировать скорость автобуса ни к чему не ведут, если не согласуются с целью усовершенствовать работу общественного транспорта. Представьте, если бы водитель для улучшения показателей предложил не останавливаться для пожилых пассажиров, поскольку они медленнее заходят в двери. Если бы автобус вовсе не останавливался и не брал пассажиров, он бы двигался быстрее. По скоростному шоссе он мог бы даже вернуться в парк!
Это та же ошибочная логика, согласно которой работа над тестами замедляет темпы разработки. Это хорошо иллюстрирует утверждение Кента Бека (Beck, 2002): «Код, который не прошел тестирование, не работает. Это, кажется, самое благоразумное утверждение». Если создание приемочных тестов перед тем, как приступить к разработке кода, что-то и замедляет, то лишь нашу работу над кодом, который не будет функционировать.
Компании, работающие с концепциями бережливого производства, научили нас, что уважение способности каждого сотрудника вкладывать идеи или непрерывно работать над улучшением качества приводит к созданию новых продуктов, которые нравятся клиентам. Команды, имеющие время и поддержку на обучение и эксперименты, справляются с работой куда лучше. Во второй части «Обучение для улучшения тестирования» мы поговорим о некоторых достойных, на наш взгляд, методах.
Гойко Аджич (Adzic, 2013) заметил, что отличный результат получается, когда:
• люди знают, зачем они делают свою работу;
• организации сосредоточены на результате и влиянии, а не на отдельных элементах;
• команды решают, что делать дальше, основываясь на актуальной обратной связи от пользователей;
• никому не наплевать.
Некоторые компании попробовали разгрузить своих сотрудников, чтобы дать им время на обучение, позволяя посвящать свободные рабочие часы личным проектам или собственному профессиональному росту. Лайза работала с командами, практикующими этот метод, и они демонстрировали хорошие результаты, поддерживая низкий уровень технических недоработок и сохраняя объемы производства. Однако важно понимать принципы, стоящие за эффективным использованием и возможностями, иначе команде придется втискивать еще больше работы в жесткие сроки.
Загрузка производственных мощностей
Алексей Жеглов, консультант по бережливому производству и Kanban для организаций, использующих умственный труд, объясняет теорию использования производственных мощностей и учит, как избежать потери 20 % времени. Мы приводим часть его статьи.
Главная причина потери 20 % времени в том, что при неполной загруженности мощности используются на 80 %, а не на 100 %. Подумайте о компании, производящей ПО, как о системе, которая преобразует запрос на элемент в разработку этого элемента. Таким образом, мы можем смоделировать производство, используя теорию очередей.
Теория
Если запросы прибывают быстрее, чем система успевает их обрабатывать, они ставятся в очередь. Когда скорость поступления снижается, очередь уменьшается. Поскольку поступление новых запросов и их обработка происходят непоследовательно, длина очереди меняется.
J-кривая мощностей
