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

9

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

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

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

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

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

сойка
источник
4
Пожалуйста, не размещайте один и тот же вопрос на двух разных сайтах обмена стека. Пожалуйста, удалите один из них.
Р Саху
2
Крест размещен на sqa.stackexchange.com/questions/27017/… .
Р Саху

Ответы:

13

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

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

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

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

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

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

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

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

Нильс ван Реймерсдал
источник
Я не согласен с первым «должен». Определение done - это то, что команда Scrum должна разработать для себя. Если группа считает автоматическое тестирование важным, то оно включит его в свое определение. Однако сам процесс не говорит, что они должны или даже должны. Это то, что полностью зависит от команды, и нет правильного, неправильного или предпочтительного ответа.
aroth
@aroth Я согласен с вами, но почти во всех случаях вы создаете более крупный программный продукт, который вы хотите добавить в DoD для тестирования. Поэтому я думаю, что хорошо говорить людям, что вы должны хотя бы серьезно подумать об этом. Как тестер, я считаю, что в конце тестирование отдельной командой - это первые шаги к Wagile. Но да, есть ситуации и / или случаи, когда тестирование может даже не понадобиться.
Нильс ван Реймерсдал
2

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

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

Ewan
источник
Так что, если на первой неделе нового спринта ни одна пользовательская история этого спринта не находится в состоянии, которое может быть проверено регрессом, вы предлагаете, чтобы ОП пошел домой и ничего не делал? Звучит не очень эффективно для меня ;-)
Док Браун
Тестер должен использовать эту первую неделю, чтобы задаться вопросом о спецификации «хммммм, как пользователю, которого я ожидал бы фоновой музыкой на моей веб-странице ...», находить ошибки в неполных историях и вообще создавать проблемы. Разработчикам разрешается говорить, что они не могут начать, пока не написаны планы испытаний
Ewan
@DocBrown: на первой неделе нового спринта тестер проделал невероятную работу. Они должны понимать, что строят разработчики, работая с владельцем продукта и разработчиками. Им нужно работать с разработчиком, чтобы убедиться, что они делают код тестируемым. Они могут начать работать над автоматизированным планом тестирования. Они могут даже начать писать некоторые тесты. Если у вас есть подходящая среда тестирования, где ваши тесты написаны на высоком уровне абстракции, вы можете написать их до того, как код будет готов.
Брайан Оукли
1

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

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

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

Брайан Оукли
источник
0

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

Мартин Маат
источник
1
Это не работает с инструментами тестирования пользовательского интерфейса, такими как Selenium. Вам нужен рабочий и стабильный пользовательский интерфейс, чтобы создавать тесты.
Док Браун
@DocBrown: я не думаю, что это обязательно так. Если вы дадите мне спецификацию для новой веб-страницы, я могу начать (и, возможно, закончить!) Писать автоматические тесты до того, как страница будет написана. Вам просто нужно сотрудничать с разработчиком, чтобы вы оба договорились о структуре страницы, идентификаторах элементов и т. Д.
Брайан Оукли
0

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

остолоп
источник
0

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

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

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

krillgar
источник
Я никогда не видел спринта, в котором уже не хватало места для текущих целей спринта в первый день. Написание автоматических тестов требует совместной работы и планирования, и это должно начаться в первый час первого дня спринта.
Брайан Оукли