Комментарии 7
Расскажите, пожалуйста, про форматы написания User-Story. Как потом технические писатели запускают тесты?
Для написания User-Story мы используем шаблон Given-When-Then. Он наиболее удачно походит для дальнейшего построения E2E теста. Вот как простой пример:
GIVEN the account activation page is open
WHEN
EITHER «Create new password», «Confirm password»
OR «I agree with the terms and conditions» checkbox isn't filled in
THEN the «Activate» button should be disabled
Он потом легко транслируется разработчиками в E2E тест.
Техническим писателям, мы делаем базовую настройку локальной среды — установка и подготавливаем специальные cmd файлы. Получается им нужно просто забрать последнюю версию тестов из GitHub например и запустить нужный файл. Так как приложение развернуто в облаке, настройка или сборка решения локально не нужна.
GIVEN the account activation page is open
WHEN
EITHER «Create new password», «Confirm password»
OR «I agree with the terms and conditions» checkbox isn't filled in
THEN the «Activate» button should be disabled
Он потом легко транслируется разработчиками в E2E тест.
Техническим писателям, мы делаем базовую настройку локальной среды — установка и подготавливаем специальные cmd файлы. Получается им нужно просто забрать последнюю версию тестов из GitHub например и запустить нужный файл. Так как приложение развернуто в облаке, настройка или сборка решения локально не нужна.
Все-таки объясните, у тех, у кого вместо AngularJS самописный фреймворк+React нре получится использовать Protractor вообще? Или будут какие-то сложности? Если да, то какие?
сразу извиняюсь, но я, как qa немного не согласен с тем, что разработчки должны писать тесты, так же не согласен с заголовком Вашим, сейчас постараюсь обьяснить почему.
Тестирование web интерфейсов: тут должна идти речь о UI тестировании. Все что делает ваш тест (допустим добавляет товар в корзину и делает заказ) это интеграционное тестирование (у qa и девелоперов немного разное понимание интеграционного тестирования). В тестах UI проверять сложно, но можно (1 раз сталкивался, но что-то больше не хочется)
Написание тестов: я всегда работал в классической связке, manual qa и автоматизатор. Ручной тестировщик пишет тест кейс, автоматизатор его автоматизирует.
Поддержка: не так уж и сложно, если вы редизайн не делаете часто.
Тестирование web интерфейсов: тут должна идти речь о UI тестировании. Все что делает ваш тест (допустим добавляет товар в корзину и делает заказ) это интеграционное тестирование (у qa и девелоперов немного разное понимание интеграционного тестирования). В тестах UI проверять сложно, но можно (1 раз сталкивался, но что-то больше не хочется)
Написание тестов: я всегда работал в классической связке, manual qa и автоматизатор. Ручной тестировщик пишет тест кейс, автоматизатор его автоматизирует.
Поддержка: не так уж и сложно, если вы редизайн не делаете часто.
У нас в компании написание в данном случае E2E теста — это процесс разработки.
BA закладывает в описание какие user-story должны быть покрыты E2E тестом и кто как не разработчик в момент реализации, может все это подготовить и реализовать по уже подготовленному сценарию.
Да согласен с вами, что проверять в UI сложно, так же наличие E2E — не исключает наличие других тестов, как вообще работы QA. Но из опыта, я вижу как E2E повышают качество проекта и не дают проскочить ошибкам в бизнес сценариях на продукцию.
Это нам позволяет делать обновление разных модулей быстрее и избегать ручной работы.
BA закладывает в описание какие user-story должны быть покрыты E2E тестом и кто как не разработчик в момент реализации, может все это подготовить и реализовать по уже подготовленному сценарию.
Да согласен с вами, что проверять в UI сложно, так же наличие E2E — не исключает наличие других тестов, как вообще работы QA. Но из опыта, я вижу как E2E повышают качество проекта и не дают проскочить ошибкам в бизнес сценариях на продукцию.
Это нам позволяет делать обновление разных модулей быстрее и избегать ручной работы.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматическое тестирование веб-интерфейсов в компании Virto Commerce