Как тестировщикам преодолевать трудности?

Трудности, с которыми сталкиваются Agile-тестироващики

Каковы наиболее частые проблемы тестирования при тестировании программного обеспечения или QA в гибких проектах? Каково это - быть QA в Scrum-команде?

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

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

Трудности Agile-тестирования

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

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

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

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

Как преодолеть:

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

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

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

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

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

Как преодолеть:

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

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

В гибком тестировании нет фаз, это все одна деятельность. Тестирование начинается с самого начала работ, даже до начала разработки.

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

Как преодолеть:

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

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

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

Как преодолеть:

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

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

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

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

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

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

Как преодолеть:

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

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

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

Связь

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

Как преодолеть:

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