11 способов улучшить процесс тестирования ПО

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

Хороший пример важности QA – Flud, приложение для чтения социальных новостей для iPad, iPhone, Android и Windows Phone. Flud был известен как “первый настоящий социальный новостной ридер”. Но, к сожалению, стартап потерпел неудачу из-за плохой работы службы контроля качества. Главным приоритетом команды Flud был процесс разработки и создание кода – практически исключая всё остальное. Когда продукт, наконец, был выпущен, он был перегружен ошибками и несоответствиями. Несмотря на то, что все было исправлено, плохая репутация и ужасный пользовательский опыт помешали его успеху. Поэтому Flud был снят с производства.

БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"

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

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

Контроль качества программного обеспечения (SQC) – это часть управления качеством, которая включает в себя комплекс мероприятий, направленных на выполнение требований к качеству. Контроль качества представляет собой ориентированную на продукт деятельность, которая сертифицирует ПО перед его выпуском. Этот процесс регулируется гарантией качества программного обеспечения.

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

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

Содержание:

• 1. Планируйте процессы тестирования и QA
• 2. Применяйте тест-ориентированное управление разработкой ПО
• 3. Используйте подход “сдвиг влево”
• 4. Проводите формальные технические обзоры
• 5. Обеспечьте подходящую рабочую среду для команды QA
• 6. Внедряйте приемочное пользовательское тестирование
• 7. Оптимизируйте использование автоматизированных тестов
• 8. Внедряйте исследовательское и ad-hoc тестирование
• 9. Используйте измерения качества кода
• 10. Эффективно сообщайте об ошибках
• 11. Получайте максимальную отдачу от инструмента управления тестированием
• Заключение

1. Планируйте процессы тестирования и QA

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

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

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

Стандартного подхода к созданию политики тестирования не существует, но обычно она включает в себя следующее:

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

План управления качеством

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

Основные компоненты плана управления качеством:

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

Стратегия тестирования

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

Основными компонентами стратегии тестирования являются:

• Объем тестирования.
• Цели тестирования.
• Бюджетные ограничения.
• Коммуникация и отчет о состоянии.
• Отраслевые стандарты.
• Измерения и метрики тестирования.
• Отчетность и отслеживание дефектов.
• Управление конфигурацией.
• Сроки.
• График выполнения тестов.
• Выявление рисков.

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

Хороший документ о стратегии тестирования отвечает на следующие вопросы:

• Что представляет собой продукт?
• Какую его часть (части) следует тестировать?
• Как они должны быть протестированы?
• Когда должно начаться тестирование?
• Каковы критерии начала/окончания?

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

План тестирования – это документ, который описывает, что, когда и как тестировать, и кто будет проводить тестирование. В нем также описывается объем тестирования и все действия. Этот документ включает в себя цели тестов, которые необходимо выполнить, и помогает контролировать риски. Рекомендуется иметь план тестирования, написанный опытным человеком, например руководителем отдела контроля качества или менеджером.

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

• Идентификатор.
• Введение.
• Ссылки (список связанных документов).
• Объекты тестирования (продукт и его версии).
• Вопросы риска программного обеспечения.
• Функции, подлежащие тестированию.
• Функции, не подлежащие тестированию.
• Подход (стратегия).
• Критерии прохождения или отказа элемента.
• Критерии приостановки.
• Результаты (документ плана тестирования, тестовые случаи, инструменты, журналы ошибок, отчеты о проблемах и т.д.).
• Тестовая среда (оборудование, программное обеспечение, инструменты).
• График.
• Потребности в персонале и обучении.
• Ответственность.
• Риски.
• Утверждения.

Вот несколько основных рекомендаций по повышению эффективности плана тестирования:

Сделайте план кратким. Избегайте повторений и неактуальности. Он должен содержать только релевантную информацию.

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

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

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

Тестовые случаи

Подготовка эффективных тест-кейсов является неотъемлемой частью совершенствования тестирования программного обеспечения. Согласно определению, данному ISTQB (International Software Testing Qualifications Board, мировой лидер в сертификации компетенций в области тестирования программного обеспечения), “тест-кейс – это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части.” Это один из ключевых инструментов, используемых тестировщиками. Стандартный тест-кейс включает в себя следующую информацию:

• Идентификатор.
• Описание.
• Предусловия.
• Шаги.
• Тестовые данные.
• Ожидаемый результат.
• Фактический результат.
• Статус.
• Кем создан.
• Дата создания.
• Выполнен или нет.
• Дата выполнения.

Ниже приведен пример стандартного тест-кейса.

Для написания эффективных тест-кейсов используйте следующие методы:

Определите тестируемые требования. Определите объем и цель тестирования до начала самого процесса.

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

Пишите вовремя. Лучшее время для написания тест-кейсов – ранние фазы анализа требований и проектирования. Так QA инженеры смогут понять, все ли требования могут быть протестированы или нет.

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

Уникальность. Все тест-кейсы должны иметь уникальное название. Это поможет классифицировать, отслеживать и анализировать их на последующих этапах.

Внесение изменений. Если требования изменятся, тестировщик должен иметь возможность скорректировать тест-кейс.

2. Применяйте тест-ориентированное управление разработкой ПО

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

• Разработка, управляемая тестированием
• Парное программирование

Разработка, управляемая тестами

Разработка, управляемая тестами (TDD – Test-driven development) – это процесс разработки программного обеспечения, в котором тесты пишутся до реализации кода. В TDD используется подход «сначала тестирование», основанный на повторении очень короткого цикла разработки. Согласно ему, каждая новая функция начинается с написания теста. Разработчик пишет автоматизированный тест-кейс до того, как он напишет достаточно производственного кода для выполнения этого теста. Изначально этот тест будет неудачным. Следующим шагом будет написание кода, сфокусированного на функциональности, чтобы тест был пройден. После завершения этих шагов разработчик рефакторит код, чтобы пройти все тесты.

Преимущества использования подхода TDD:

Высокое качество. Качество продуктов, основанных на TDD, обычно намного выше, чем при использовании других методов.

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

Упрощение кода. Инженеры тратят больше усилий на согласование требований кода с конкретными тестами.

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

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

Парное программирование

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

Преимущества парного программирования:

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

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

Понятный код. Более короткий и гораздо более четкий код.

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

3. Используйте подход “сдвиг влево”

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

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

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

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

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

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

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

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

4. Проводите формальные технические обзоры

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

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

• Что было рассмотрено?
• Кто проводил обзор?
• Какие выводы и решения были сделаны?

FTR – это своего рода класс обзоров, который включает следующие типы:

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

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

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

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

5. Обеспечьте подходящую рабочую среду для QA команды

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

Определите роли QA

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

• инженер по тестированию программного обеспечения;
• аналитик по тестированию;
• инженер по автоматизации тестирования;
• инженер по разработке программного обеспечения в области тестирования;
• архитектор тестирования;
• менеджер по тестированию.

У каждой роли есть свой собственный набор навыков, обязанностей и инструментов для работы. Чтобы наладить правильное взаимодействие с командой QA и понять специфику каждой позиции, нужно больше узнать о ролях QA и их особенностях.

Уважайте своих тестировщиков

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

Руководитель команды QA должен отмечать её прогресс и индивидуальные достижения ее членов на командных встречах. Это будет стимулировать других специалистов работать лучше в будущем.

Проводите бизнес-тренинги для вашей команды QA

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

Поощряйте общение

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

Также важно давать тестировщикам возможность поговорить о чем-то наедине, вне групповых собраний. Руководители QA должны быть гибкими и открытыми для новых стратегий, чтобы наилучшим образом вести свои команды.

6. Внедряйте приемочное пользовательское тестирование

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

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

Типы приемочного тестирования

Приемочное тестирование (UAT) может проводиться различными способами. Согласно данным Usersnap, существует 5 типов UAT:

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

Приемочное тестирование контракта – это тип UAT, проводится для проверки соответствия разработанного программного обеспечения требованиям контракта.

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

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

Тестирование “черного ящика” изучает функциональность программного обеспечения, не затрагивая код. Это означает, что QA инженеры знают только то, что должно делать приложение, но не зная, как именно. Этот тип тестирования позволяет командам тестировщиков получить наиболее релевантные результаты, сравнимые с тестированием конечных пользователей.

Как организовать приемочное пользовательское тестирование?

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

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

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

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

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

Тестируйте пользовательскую документацию

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

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

7. Оптимизируйте использование автоматизированных тестов

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

• кросс-девайсное и кросс-браузерное тестирование;
• регрессионное и smoke тестирование;
• нагрузочное тестирование;
• тестирование производительности.

Чтобы достичь идеального сочетания в тестировании, важно найти баланс между ручным и автоматизированным тестированием.

Существует большое разнообразие инструментов для автоматизации тестирования. Они могут быть как с открытым исходным кодом, так и коммерческими. Selenium, Katalon Studio, Unified Functional Testing, Test Complete, Watir – самые популярные из них, с которыми стоит ознакомиться в первую очередь.

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

Непрерывная интеграция и непрерывная доставка

Непрерывная интеграция (CI) – это практика разработки, которая требует от инженеров интегрировать изменения в продукт несколько раз в день. Каждый фрагмент кода запускает “интеграционные тесты” при каждом изменении кода, чтобы быстрее обнаружить ошибки. Хорошей практикой является сочетание CI с автоматизированным тестированием, что сделает ваш код надежнее. Bamboo, Hudson и Cruise Control – это инструменты с открытым исходным кодом, которые позволяют внедрить непрерывную интеграцию в вашу среду.

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

Практики CI и CD требуют непрерывного тестирования, которое выводит автоматизацию тестирования на новый уровень. Они организуют отдельные автотесты в единую систему, делая ее частью конвейера CI/CD.

8. Внедряйте исследовательское и ad-hoc тестирование

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

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

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

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

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

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

Такая хаотичная проверка может помочь обнаружить дефекты, которые непросто найти с помощью формальных тестов и которые трудно воспроизвести. Однако результаты аd-hoc тестирования непредсказуемы и случайны.

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

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

Лучшей стратегией станет дополнение автоматизированного тестирования исследовательским и аd-hoc тестированием. Так вы сможете увеличить тестовое покрытие, улучшить пользовательский опыт и придумать дополнительные идеи для тестирования.

9. Используйте измерения качества кода

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

Модель качества программного обеспечения CISQ определяет следующие важные аспекты: надежность, эффективность производительности, безопасность, сопровождаемость и скорость доставки. Кроме того, модель можно расширить, включив в нее оценку тестируемости и удобства использования продукта.

Рассмотрим каждый из основных пяти аспектов качества программного обеспечения и изучим, как их можно измерить:

Надежность. Этот показатель определяет, как долго система может работать без сбоев. Цель проверки надежности – сократить время простоя приложения.

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

Эффективность производительности означает скорость реакции системы на выполнение любого действия в течение заданного промежутка времени. Её можно измерить с помощью следующих показателей:

• Стресс-тестирование обеспечивает понимание верхнего предела возможностей системы.
• Soak-тестирование проверяет, как долго система может выдерживать определенную нагрузку и когда производительность начинает снижаться.
• Мониторинг производительности приложений – это подробные метрики производительности с точки зрения пользователя, предоставляемые специальным программным обеспечением.

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

• Развертывание обновлений безопасности – это процент пользователей, которые действительно установили патч или обновление безопасности.
• Время устранения – это количество времени, необходимое для устранения уязвимости.

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

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

10. Эффективно сообщайте об ошибках

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

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

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

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

Аттачи. Добавьте скриншот или видеозапись, подтверждающие наличие ошибки. Это упрощает работу инженера, устраняющего проблему.

Рассмотрите возможность добавления краткого описания ошибки. Точное описание ошибки помогает гораздо быстрее определить ее природу, сокращая время на исправление. Это также полезно в случае поиска ошибки в реестре, поскольку идентификаторы ошибок трудно запомнить.

Пример баг-репорта:

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

11. Получите максимальную отдачу от инструмента управления тестированием

Инструменты или системы управления тестированием – это программные продукты, которые помогают QA командам структурировать процесс тестирования и управлять им. Такие платформы могут быть интегрированы с вашими системами автоматизации тестирования, инструментами CI/CD, инструментами отслеживания ошибок и другими программными решениями. Они могут:

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

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

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

1. Zephyr – ведущий мировой поставщик решений для управления тестированием, поддерживающий Agile и DevOps фреймворки. Он предлагает несколько редакций: Zephyr for Jira – гибкий, однопроектный инструмент, работающий внутри программного обеспечения Atlassian Jira; Zephyr Scale – масштабируемая, межпроектная платформа, также работающая внутри Jira; и Zephyr Enterprise – надежное автономное решение для синхронизации нескольких команд.
2. SpiraTest – мощный пакет для обеспечения качества ПО, который помогает планировать и управлять дефектами и требованиями. Он предлагает полную отслеживаемость, поддержку различных типов тестов и множество вариантов отчетов.
3. TestRail – комплексное решение, которое обеспечивает многочисленные возможности интеграции с системами отслеживания ошибок и инструментами автоматизации тестирования. Оно также обладает мощными возможностями отчетности с настраиваемыми панелями для эффективного отслеживания результатов тестирования и важных показателей, а также для получения практических выводов.
4. Kualitee – гибкий продукт, позволяющий эффективно управлять дефектами, тест-кейсами и отчетностью. Он интегрируется с различными системами тестирования и имеет мобильную версию.
5. Testpad – простой инструмент, который легко использовать как профессиональным тестировщикам, так и другим специалистам, т.е. клиентам, менеджерам и т.д. Он позволяет создавать планы тестирования на основе контрольных списков, легко добавлять новые тесты и адаптироваться к различным стилям тестирования (BDD, TCM, exploratory и др.).

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

Заключение

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

Перевод статьи  «11 Ways to Improve Software Testing through Planning, Work Environment, Automated Testing, and Reporting».