Читать книгу Agile-тестирование. Обучающий курс для всей команды - Лайза Криспин - Страница 7

Каждый из нас начинал карьеру в области Agile как одиночка на поприще экстремального программирования (Extreme Programming, XP) во времена, когда даже не упоминалось о том, что в каждой команде могут быть свои тестировщики. Было всего два игрока: программист и заказчик. Клиенты определяли необходимые приемочные тесты, программисты автоматизировали их: раз, два и готово. На конференциях по экстремальному тестированию мы были единственными, кто определял себя как тестировщиков, хотя и понимали, что они могут внести значительный вклад в работу коллектива. Мы экспериментировали, обсуждали тестирование с первопроходцами XP, обменивались мыслями.

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

Уорд Каннингем создал Fit (фреймворк для комплексного тестирования) – инструмент, помогающий выявить такие примеры. Дэн Норт представил BDD, которая проложила путь новым популярным инструментам (North, 2006). Agile-команды осознали ценность исследовательского тестирования, и оно стало для них не просто функциональным. Как показал Брайан Марик в своей матрице, которую мы адаптировали для квадратов Agile, тестирование охватывает теперь множество областей (Marick, 2003).

Конечно, все еще оставались трудности, препятствующие успеху Agile-тестирования. Мы, тестировщики, завидовали всем тем инструментам, которые имелись у программистов в свободной интегрированной среде разработок (Integrated Development Environments, IDEs). Нам хотелось, чтобы для нас все было так же просто. Мы начали эффективно использовать «силу трех», или «трех друзей», как говорит Джордж Динвидди. Когда заказчик, программист и тестировщик работают вместе, всегда возникают вопросы, как должен функционировать тот или иной элемент (Dinwiddie, 2010). Тем не менее было непросто учесть все запросы клиентов: дизайн, юзабилити, данные и другие составляющие качественного продукта. О некоторых из них мы поговорим в этой книге.

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

Тестирование в командах 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-тестирование должно идти в ногу с быстро меняющимися технологиями и новым контентом. Далее мы поговорим об этом.