На каком этапе Agile (SCRUM) мы должны начать создавать тесты автоматизации?

Немного предыстории меня - я работаю тестером в течение почти 2 лет в Agile-среде с использованием SCRUM (спринты 1-2 недели). Поэтому я хочу представить автоматизированное тестирование в моей работе с использованием Selenium WebDriver (с Java).

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

Я читал и получил другой подход, такой как:

1. Когда начинается новый спринт, преобразуйте пользовательские истории в автоматизированные сценарии из предыдущего спринта, ИЛИ;
2. Преобразуйте пользовательские истории в одном спринте.

Любые советы будут очень признательны. Заранее спасибо.

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

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

Автоматизация тестирования так важна в Agile, потому что:

Организационная Ловкость ограничена Технической Ловкостью

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

https://less.works/less/technical-excellence/index.html

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

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

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

Итак, 1, кажется, отсутствует, поскольку вы пишете тесты для задачи, выполненной в предыдущем спринте. Что делать, если тесты не пройдены?

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

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

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

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

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

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

В действительно гибкой среде каждый может сделать все. Не было бы кого-то на 100% посвятившего себя тестированию, вы бы также развили навыки, чтобы помочь с какой-то базовой работой с пользовательским интерфейсом или чем-то еще. Однако мы редко живем в идеальном мире.

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