Содержание
В сегодняшнем быстро меняющемся ландшафте разработки программного обеспечения методология Agile получила широкое распространение благодаря своей гибкости и итеративному подходу. Хотя Agile предлагает многочисленные преимущества, такие как быстрая доставка и сотрудничество с клиентами, обеспечение высокого качества остается важнейшей задачей. Именно здесь в игру вступает концепция продвижения качества вверх по течению. Сосредоточившись на качестве на ранних этапах жизненного цикла Agile, организации могут предотвратить дефекты, сократить количество доработок и повысить общую удовлетворенность клиентов. В этой статье мы рассмотрим важность продвижения качества вверх по течению, его влияние на проекты Agile и стратегии эффективной интеграции методов качества на начальных этапах разработки программного обеспечения.
С действительно короткими циклами релизов в мире разработки Agile команда QA всегда ограничена во времени, чтобы завершить свои тестовые проходы вовремя. В этой статье мы попытаемся охватить некоторые основные моменты, которые в случае успешной реализации дадут команде QA подтяжку лица, не только в плане тестирования продукта вовремя, но и в плане помощи в продвижении качества вверх по течению и внедрения фокуса на качество среди других дисциплин, таких как разработка, управление программами, команды управления продуктом.
Внедрение разработки через тестирование
Принятие Test Driven Development растет с каждым днем, учитывая ценность, которую он приносит, особенно в условиях сжатых сроков. Однако это нелегко реализовать, поскольку это требует сильной поддержки со стороны всей команды, включая поддержку руководства. Теоретически в TDD разработчики будут создавать автоматизированные тесты, но команда тестирования, безусловно, может сотрудничать с ними, чтобы понять требования клиентов/спецификации функций для создания тестов, которые затем станут основой для кодирования. Такое сотрудничество является ключевым в мире Agile, который повторяет основную мантру: «Качество — это ответственность всей команды». В ситуациях, когда TDD не может быть реализован из-за отсутствия поддержки, сообщество тестирования должно, по крайней мере, настаивать на следующем пункте, который звучит как «Улучшение качества сборки, доступной для тестирования».
Улучшить качество сборки, доступной для тестирования
Качество сборки, доступной для тестирования, во многом зависит от качества исходного кода, однако, как тестировщик, вы можете сделать кое-что, чтобы помочь улучшить качество заранее. Работайте с разработчиками, чтобы предоставить им набор основных тестов (например, тесты проверки сборки), которые они могут запустить до того, как сборка будет выпущена для тестирования. Это поможет вам сэкономить много времени, действительно сосредоточившись на тестировании продукта на стабильных сборках. Однако упростите этот процесс для разработчиков:
- автоматизация набора тестов, которые необходимо выполнить;
- тестирование такого кода автоматизации, чтобы убедиться в отсутствии проблем с тестированием;
- продемонстрировав им выполнение теста несколько раз и будучи доступным, если им понадобится помощь.
Хотя эта практика улучшит качество ваших тестовых усилий, если вы не сотрудничаете с разработчиками, они могут посчитать это накладными расходами. Заслужите их доверие, объяснив им, сколько времени это сэкономит как разработчикам, так и тестировщикам. Если у вас возникли трудности с реализацией этого, уделите время работе с разработчиками над итерациями. В то же время, по крайней мере, убедитесь, что вы проводите с ними обзоры тестовых случаев, чтобы убедиться, что их отзывы были учтены. Это также имеет дополнительное преимущество, поскольку разработчики имеют представление о вашем наборе тестовых случаев и могут проверить свой код на здравомыслие для некоторых сценариев, по крайней мере непреднамеренно.
Тщательно выбирайте задачи, включенные и выключенные в Sprint
Как мы все знаем, одной из основных характеристик Agile-разработки является предоставление наглядного кода в конце каждого спринта. Чтобы добиться этого, как команда тестирования, будьте внимательны на совещаниях по планированию спринта. Примерами тестовых задач, которые могут распространяться на спринты, являются тестирование производительности, тестирование безопасности, тестирование совместимости и т. д. Начните с этих тестовых задач заранее и распределите их по спринтам, чтобы они получили правильное тестовое покрытие и в то же время стали управляемыми для выделенных команд разработки и тестирования. Откладывание их на более поздний срок окажется рискованным как с точки зрения сроков выпуска продукта, так и качества, что повлияет на общие затраты на проект.
Создание фреймворков и утилит
Рассмотрите возможности создания фреймворков и утилит производительности, выходящих за рамки ваших основных усилий по автоматизации тестирования. Например, рассмотрите утилиты для создания тестовых данных, такие как создание учетных записей пользователей, поисковый робот для определения неработающих ссылок на веб-страницах, неконтролируемые установки продуктов и т. д. Такие фреймворки и утилиты сэкономят вам много времени и помогут сосредоточиться на областях, которые лучше всего тестировать вручную. Демонстрируйте такие тестовые IP остальной части команды по продукту, чтобы помочь им понять сценарии, когда они также могут извлечь из них пользу, помогая улучшить общее принятие усилий по тестированию.
Потенциально может быть еще несколько подобных вещей, которые команда тестирования может взять на себя, чтобы помочь продвинуть качество вверх по течению и охватить всех в своих усилиях по тестированию, однако вышеупомянутые области — это области, в которые команда тестирования может углубиться сразу, чтобы начать вносить изменения. Попробуйте их, если ваша команда пошла по пути Agile.