Как преодолеть вызовы гибкого тестирования

С какими проблемами чаще всего сталкиваются тестировщики программного обеспечения или специалисты по обеспечению качества в гибких проектах? Каково быть QA в agile-команде?

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

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

Проблемы гибкого тестирования

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

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

Изменение требований / изменения в последнюю минуту

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



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

Как побороть:

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

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

Недостаточно информации об истории

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

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

Как побороть:

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

Непрерывное тестирование

В Agile тестирование - это не этап, это действие. Тестирование начинается с самого начала, еще до начала разработки.

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

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

Как побороть:

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

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

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

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

Технические навыки / Автоматизация тестирования

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

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

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

Как побороть:

Начните с изучения нескольких языков сценариев или программирования, таких как Ruby и Java - это самые популярные языки в сообществе технического тестирования.

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

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

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

Несколько браузеров / несколько устройств

В настоящее время архитектура многих веб-сайтов состоит из «back-end» и «front-end». Интерфейсная часть в значительной степени основана на JavaScript и CSS, которые потенциально могут вести себя по-разному при просмотре из разных браузеров или устройств.

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

Как побороть:

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

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

Еще один отличный инструмент для тестирования нескольких браузеров - это BrowserSync .

Коммуникация

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

Как побороть:

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

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