Agile-методология в тестировании ПО

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

Содержание

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Уровни тестирования

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

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

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

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

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

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

Юнит-тестирование

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

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

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

Интеграционное тестирование

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

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

Системное тестирование

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

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

Приемочное тестирование

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

В целом приемочное тестирование позволяет убедиться в том, что программа работает так, как должна, и с максимальной производительностью. Только после этого команда QA может быть уверена в том, что воплотит в жизнь точное видение клиента. Билд может перейти в фазу производства и релиза только после того, как этот этап будет отмечен как PASSED.

Жизненный цикл тестирования ПО

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

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

Agile-методология

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

Кроме того, сроки получения обратной связи и завершения проекта, значительно меньше, чем при использовании традиционного метода тестирования. Благодаря этому и многим другим преимуществам методология Agile прочно вошла в сердца большинства QA-команд и стала фаворитом в области разработки ПО.

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

1. Оценка требований

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

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

2. Планирование

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

3. Разработка тест-кейсов

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

4. Готовность к релизу

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

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

5. Выполнение

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

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

6. Закрытие цикла

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

Подход Shift Left

Agile-методология в тестировании ПО. Подход Shift Left

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

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

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

Как пишет Стивен Уоттс в блоге BMC: “Уже подтверждено, что более 55% всех ошибок в любом приложении возникает на этапе разработки требований. Более 25% возникает на этапе проектирования, а более 80% – на начальных этапах кодинга”.

Тестирование Shift Left дает огромные преимущества:

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

Чтобы приступить к Shift Left тестированию, организациям и командам необходимо соблюдать некоторые стандарты:

  • Все должны придерживаться единой позиции в отношении процедур и эталонов кодинга
  • Проведение раннего тестирования на каждом этапе, особенно в ситуациях, когда Agile-методология не подходит для проведения тестирования
  • Использование средств автоматизации, которые помогают в Shift Left тестировании, делает весь процесс менее обременительным.

Подведение итогов

Каждый этап тестирования очень важен и должен быть пройден. Хотите начать тестирование своего программного обеспечения уже сегодня? Убедитесь, что ваша команда QA или нанятая вами компания по тестированию ПО провела все эти этапы тестирования. Спасибо за прочтение!

Перевод статьи «Software Testing Stages of Agile and Traditional Methodologies».

2 комментария к “Agile-методология в тестировании ПО”

  1. Пингбэк: Полное руководство по регрессионному тестированию

  2. Пингбэк: Shift Happens: что такое shift-left тестирование на самом деле?

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *