Текст книги "Agile-тестирование. Обучающий курс для всей команды"

Глава 5. Техническая подготовка

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

РАЗРАБОТКА НА ОСНОВЕ ПРИМЕРОВ

Мы часто говорим с клиентами о том, что они хотели бы и чего не хотели бы видеть в каждом проекте или элементе. Эти примеры можно использовать в автоматизированных бизнес-ориентированных тестах, которые сопровождают процесс разработки. Вот некоторые хорошо известные методы: спецификация на основе примеров (Specification by Example, SBE), разработка на основе приемочного тестирования (Acceptance-test-driven Development, ATDD), разработка через поведение. Если вы пока не знакомы с этими подходами, посмотрите список литературы ко второй части. Хорошо будет начать с «ATDD – разработка программного обеспечения через приемочные тесты» Маркуса Гэртнера (ATDD by Example, Gärtner, 2012), «Спецификация по примеру» Гойко Аджича (Specification by Example, Adzic, 2011), «Книга о Cucumber» Мэтта Уэйна и Аслака Хеллесоу (The Cucumber Book, Wynne and Hellesøy, 2012). Чтобы найти подходящий пример и использовать его в автоматизации тестов, требуется определенная техническая подготовка, которая необходима в работе с программистами. (Подробнее об этом мы поговорим в четвертой части.)

АВТОМАТИЗАЦИЯ И ПРОГРАММИРОВАНИЕ

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

Если тестировщики научатся использовать ту же интегрированную среду разработок (Integrated Development Environment, IDE), что и программисты, совместная работа над кодом станет проще, и, обсуждая приложения, специалисты будут говорить на одном языке.

Тесты могут проходить по-разному: с использованием языка, специфического для конкретной области (Domain-specific Language, DSL), ключевых слов или данных. Однако существует конкретный код, с помощью которого производятся тесты и получаются результаты. Кто-то должен его написать и проверить. Если вы как тестировщик не знаете, как писать код, очень важно хотя бы понимать, для чего он нужен.

Когда команда практикует разработку через тестирование (Test-driven Development, TDD), появляется возможность создать хороший код. С помощью тестов накапливается документация о постоянных характеристиках кода продукта. Если в дальнейшем потребуется внести в код изменения, тесты позволят сделать это быстрее и безопаснее. Поэтому к коду автоматизированных тестов следует относиться с таким же вниманием, как и к основному коду, он не менее важен.

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

Умение писать псевдокод может помочь в создании автоматизированных тестов. Вникните в основные понятия объектно-ориентированных принципов, таких как SOLID (Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion; см. Википедию, 2014m).

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

Если у вас нет опыта в программировании, изучите его основы самостоятельно. Посмотрите список литературы ко второй части, там вы найдете книги, которые помогут в изучении кода, в частности «Написание скриптов в Ruby каждый день» Брайана Марика (Every day Scripting with Ruby, Marick, 2007). Также существует множество онлайн-курсов, обучающих видео– и аудиороликов.

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

Пример структурной диаграммы для программного интерфейса (API)

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

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

На рисунке выше показан пример структурной диаграммы, которая помогает вникнуть в курс дела и понять взаимосвязь компонентов системы. Это структура программного интерфейса, разработанного командой Лайзы. Диаграмма визуализирует процесс обработки софтом пользовательской документации и выполнение запросов, а также таких команд, как «добавить», «изменить» или «удалить» источник информации.

ОСНОВНЫЕ ТЕХНИЧЕСКИЕ НАВЫКИ

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

Умение контролировать процессы, память и процессорные ресурсы (Central Processing Unit, CPU), изучать логи и разбираться в профильной статистике поможет выявить потенциальные ошибки в использовании источника. Следите и старайтесь понимать важные характеристики показателей, которые могут остаться незамеченными до выхода продукта. Контроль и изучение логов – еще одна область, в которой тестировщики, программисты и специалисты DevOps могут работать вместе для выявления скрытых проблем. Способность мониторить и создавать tail log необходима в работе с большинством софта. Свободное пользование командной строкой основной оболочки UNIX пригодится, например, для поддержки тестовой среды, контроля логов и тестирования API.

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

СРЕДА РАЗРАБОТКИ

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

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

Чтобы делать эту работу, тестировщики должны быть в курсе, какие инструменты контроля версий программного кода используют в их команде, и в идеале иметь представление о свободной интегрированной среде разработки (Integrated Development Environment, IDE). Этого легко достичь, если позволить тестировщикам и программистам работать вместе. Когда Лайза занимается кодом в паре с кем-то, она постоянно делает заметки о методах, которые могут пригодиться в будущем, и выгружает их в корпоративную вики-энциклопедию, таким образом позволяя другим членам команды пользоваться информацией.

ТЕСТОВАЯ СРЕДА

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

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

Простая схема программной версии продукта

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

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

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

НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ И СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ ПРОГРАММНОГО КОДА

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

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

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

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

Разветвление усложняет CI. Если вы всегда работаете на главной (иногда называемой основной) версии, все гораздо проще. Давайте представим, что ваша команда работает над перепроектированием основной версии, в то время как необходимо исправить ошибки на стадии производства. Вы должны быть уверены, что проверяете то, что нужно, и развертываете верную версию продукта в подходящей тестовой среде. Это еще одна область, где необходимо сотрудничество с программистами и, возможно, со специалистами DevOps. На рисунке показано исправление ошибок либо в рамках основного кода разработки, либо путем двойного прогона (и то и другое завершается одинаковым устранением багов).

Возможная стратегия разветвления

Простая стратегия разветвления

Августо Евангелисти, явный сторонник Agile-тестирования из Ирландии, рассказывает, как в его компании простейшим способом реализуется стратегия разветвления.

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

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

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

Более сложная стратегия разветвления

Адам Найт, директор по QA и поддержке из Великобритании, делится опытом разветвления в своей команде, который в корне отличается от того, о котором рассказал Августо.

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

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

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

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

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

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

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

КАЧЕСТВЕННЫЕ СВОЙСТВА ТЕСТИРОВАНИЯ

Agile-квадраты используются для проверки соответствия планов коллектива типу требуемого тестирования.

В главе 8 подробно рассказывается о планировании всех четырех квадратов. Сейчас мы рассмотрим некоторые технические возможности.

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

Не всегда в компании работают все необходимые специалисты. Например, у вас может не быть специалиста по тестированию безопасности. В таком случае для обеспечения этой функции вы сами можете изучить некоторые основные техники тестирования безопасности. Знания внедрения SQL и перекрестных скриптов позволят выявлять некоторые основные уязвимые места. Недавно Джанет работала с сайтом, который принимал оплату посредством банковской карты. Джанет заметила, что это был не HTTPS-протокол, и протестировала кое-что. Сайт даже не скрывал информацию на странице, и любой view source после подтверждения позволял увидеть абсолютно все введенные данные. Однако повысить безопасность вашего продукта не такая простая задача. Возможно, самое ценное, что вы можете сделать, – это рассказать о важности проверки безопасности.

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

Мы поместили исследовательское тестирование в квадрат 3 и посвятили ему главу 12. Однако мы хотели бы поговорить об этом и здесь, потому что это необходимые навыки, которые нужно наращивать и совершенствовать непрерывно. Обучение программистов исследовательскому тестированию поможет им в создании кодов. В книге «Исследуй это!» Элизабет Хендриксон приводит примеры того, как программисты могут применять исследовательское тестирование, в том числе на уровне кода. Иногда мысль об «эффекте ряби» маленьких кусочков кода может предотвратить разбор других частей приложения на составляющие или внесение изменений в существующий код. Работая совместно с тестировщиками, программисты больше узнают о сути тестирования.

ТЕХНИКИ ТЕСТ-ДИЗАЙНА

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

РЕЗЮМЕ

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

• ведение разработки на основе примеров;

• техническую осведомленность о создании структуры и кода;

• навыки автоматизации и программирования;

• поддержка тестовой среды;

• понимание контроля версий программного кода и процесса непрерывной интеграции;

• качественные свойства тестирования на основе квадратов Agile;

• техники тест-дизайна.