ЧАСТЬ ПЕРВАЯ. ВВЕДЕНИЕ

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

ЧАСТЬ ВТОРАЯ. ОБУЧЕНИЕ ДЛЯ УЛУЧШЕНИЯ ТЕСТИРОВАНИЯ

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

ЧАСТЬ ТРЕТЬЯ. ПЛАНИРОВАНИЕ РАДИ ЦЕЛОСТНОЙ КАРТИНЫ

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

ЧАСТЬ ЧЕТВЕРТАЯ. ТЕСТИРОВАНИЕ БИЗНЕС-ЦЕННОСТИ

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

ЧАСТЬ ПЯТАЯ. ИССЛЕДОВАТЕЛЬСКОЕ ТЕСТИРОВАНИЕ

Программисты прислали вам некий код для тестирования. С чего начать? Если вы или ваша команда испытываете трудности с исследовательским тестированием, то в этой части вы найдете много полезного. Мы выделили несколько техник исследовательского тестирования: использование искусственных образов (персон) и туров (маршрутов) для генерации новых идей и тестов, сессионное тестирование (SBTM) и тестирование вокруг различных направлений («цепочек») работы (TBTM).

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

ЧАСТЬ ШЕСТАЯ. АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ

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

ЧАСТЬ СЕДЬМАЯ. РАЗНЫЕ СФЕРЫ ДЕЯТЕЛЬНОСТИ

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

ЧАСТЬ ВОСЬМАЯ. AGILE-ТЕСТИРОВАНИЕ НА ПРАКТИКЕ

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

В книге есть также два приложения:

• Приложение А. Page Object на практике: примеры.

• Приложение Б. С чего начать.

ДРУГИЕ СОСТАВЛЯЮЩИЕ

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

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

ЭКСПЕРИМЕНТ

Линда Райзинг много лет назад уговорила нас провести несколько маленьких экспериментов, изучить их результаты и продолжить решать задачи по частям, постепенно добиваясь поставленных целей. Если что-то в этой книге покажется полезным для вас и вашей команды, попробуйте внедрить это хотя бы пару раз. Оглядываясь назад, посмотрите, сработали ли нововведения, и при необходимости измените что-то. Если ничего не сработало, не огорчайтесь: вы получили опыт и сможете попробовать что-то другое.

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

Часть 1. Введение

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

• Глава 1. Как изменилось Agile-тестирование.

• Глава 2. Важность корпоративной культуры.

Глава 1. Как изменилось Agile-тестирование

Каждый из нас начинал карьеру в области 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-тестирование в разных сферах.