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

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

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

Сначала давайте рассмотрим основные типы инструментов, которые вы будете использовать для тестирования. 

Инструменты для тестирования 

Удобно разделить инструменты, которые имеют отношение к тестированию, на три типа: 

  • Инструменты для совместной работы: они поддерживают сбор идей и требований, коммуникацию в команде с некоторой интеграцией с автоматизированными процессами, иногда с использованием ботов. 

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

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

База знаний "Tools" — это онлайн-реестр инструментов, который отличается от большинства онлайн-реестров тем, что его область применения охватывает совместную работу, тестирование и DevOps. В этих трех областях представлено более 1700 инструментов. Веб-страницы Tools индексируются и доступны для поиска. 

В базе объедены, проиндексированы и доступны для поиска более 300 блоггеров, более 52 000 блогов.  

Далее в этой статье мы рассмотрим основные проблемы, влияющие на управление тестированием и поддерживающие его. 

Архитектура инструментов 

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

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

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

Вам не обязательно быть приверженцем культуры DevOps, чтобы использовать инструменты “DevOps”. 

Управление тестированием 

Инструменты управления тестированием обязательны для всех масштабных проектов. В Agile проектах обычно используются инструменты для управления инцидентами, а в тестировании распространено использование бизнес-историй и сценариев для отслеживания ключевых примеров. Инструменты управления тестированием различаются по объему - от очень простых, например Microsoft Excel, до комплексных продуктов для управления жизненным циклом приложений (Application Lifecycle Management, ALM). 

В целом, инструменты управления тестированием охватывают несколько областей: 

  • Модель тестового покрытия: большинство инструментов управления тестированием позволяют определить набор требований, с помощью которых можно сопоставлять тест-кейсы и/или проверки в тестах. Иногда эти требования могут быть иерархическими, чтобы отражать содержание документа. Все чаще используются другие модели, например сценарии использования (Use Case, UC) или потоки бизнес-процессов. Обычно доступны план тестирования и отчеты по покрытию продукта запущенными тестами. 

  • Управление тестами: можно управлять тест-кейсами и их содержимым, чтобы обеспечить документированную запись выполнения тестов. Содержимое тестовых наборов может быть подготовлено перед тестированием или в виде записи о выполненных тестах. Тестовые наборы могут быть в свободном текстовом формате или структурированы по шагам с ожидаемыми результатами. Обычным делом является импорт документов и изображений для сохранения в соответствии с тестами или шагами. 

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

  • Выполнение тестов и фиксирование результатов: по мере того, как команда выполняет тесты, проставляется статус тестов. При выполнении всех тестов будет указан тестировщик, а также дата/время и продолжительность. Успешно пройденным тестам может быть присвоен статус "Passed". К результатам неудачных, заблокированных или аномальных тестов могут быть прикреплены скриншоты, результаты тестирования и отчеты об инциденте. Многие инструменты предоставляют возможности для запуска тестов. Эти инструменты управляют тестами и запускают их, регистрируют результаты и даже создают черновики отчетов об инцидентах. 

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

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

Самым популярным инструментом управления тестированием по-прежнему остается Microsoft Excel. 

Разработка тестов 

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

Во многих проектах модели используются для учета требований или высокоуровневых проектов. Когда они становятся доступными для тестировщиков, их можно использовать для отслеживания путей, по которым можно напрямую получать элементы покрытия из модели. Если такие модели недоступны, то команде тестировщиков часто бывает полезно составить, например, блок-схемы процессов или swim-lane diagrams (это визуальный элемент, который используется в технологических схемах для описания того, что или кто работает на определённой части процесса.). Это помогает тестировщикам вести более содержательные дискуссии с заинтересованными сторонами, особенно когда речь заходит о подходе к покрытию. 

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

Существуют также инструменты, позволяющие выполнять моделирование в test execution tools. Например, эти инструменты позволяют разработчику тестов отображать все поля на веб–странице, создавать ссылки для объединения полей и создавать модель навигации по странице — все это в графическом формате. 

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

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

Проприетарный или открытый исходный код? 

За последние двадцать лет широкое распространение получило использование продуктов свободного программного обеспечения с открытым исходным кодом (FOSS), особенно для управления инфраструктурой. Стоимость лицензий на операционную систему и сопутствующее программное обеспечение для веб-серверов от Microsoft, а также общее мнение о том, что Linux/Unix более надежен и безопасен, чем Windows, означают, что для многих сред Linux/Unix является предпочтительной операционной системой для серверов.  

Две таблицы ниже (обновляются ежедневно на w3techs.com) показывают относительную популярность операционных систем и продуктов для веб-серверов. Около 85% сайтов работают под управлением самых известных веб-серверных продуктов с открытым исходным кодом - Apache и Nginx. 

 

 

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

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

В таблице ниже приведены некоторые соображения, которые вы можете принять во внимание при выборе типа инструмента. 

 

Проприетарный 

FOSS 

Доступность 

Инструменты, доступные для каждой области 

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

Стоимость покупки   

Часто это дорого, особенно для корпоративных продуктов. 

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

Документация   

Обычно очень подробная. 

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

Техническая поддержка 

Очень хорошая, но за определенную плату. 

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

Другие инструменты поддерживаются слабо. 

Надежность/качество   

Обычно очень хорошее. 

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

Разнообразие функций 

Наборы функций, как правило, соответствуют опубликованным рекомендациям по продуктам и, как правило, являются всеобъемлющими.  

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

Периодичность выпуска/исправления 

Основные релизы, как правило, выходят с интервалом в месяцы, а иногда и годы. Регулярные выпуски исправлений. Предупреждения и release notes, как правило, очень хороши. 

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

 

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

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

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

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

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

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

Упражнение по выбору инструмента 

Если вы ищете инструмент управления тестированием для поддержки вашего текущего или недавно созданного проекта или приложения, с которым вы знакомы, вам необходимо, основываясь на функциональных возможностях, описанных выше в разделе "Инструменты управления тестированием", составить список из 15–20 функций, которые являются либо: 

  • Обязательными 

  • Желательными 

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

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

  • Каковы возможности инструментов, которые вы используете? 

  • Каких функций не хватает инструментам FOSS по сравнению с фирменными инструментами? 

  • Сколько существует инструментов, которые в целом соответствуют вашим требованиям? 

  • Как вы думаете, сколько времени вам потребуется на изучение инструментов, чтобы составить краткий список, скажем, из трех?