Готовый перевод Agile-Friendly Test Automation Tools/Frameworks / Несколько причин задуматься над тем, как делать автоматизированное тестирование в agile.: Agile-Friendly Test Automation Tools/Frameworks

Некоторые спрашивают, почему я не фанат традиционных инструментов автоматизированного тестирования в agile проектах. Почему мне нужно использовать какие-то хипстерские инструменты", - спрашивают они. - "Мы уже нашли тулу, которая может все! Больше ничего не надо."

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

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

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

Почему же традиционное автоматизированное тестирование с использованием тяжеловесных фреймворков не для аджайл?

Вот три причины:

принцип напиши-тест-после-разработки неправилен для аджайл команд.

Трудноподдерживаемые скрипты созданные с использованием таких инструментов - это неподдерживаемые скрипты, и их трудно изменить.

Такие специализированные инструменты для Специалистов Автоматизированного Тестирования воспитывают разрозненность.

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

Автоматизируй-после-написания.

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

Тест аналитики дизайнят и документируют тесты.

Тестировщики вручную тестируют и репортят баги.

Девелоперы фиксят баги

field("item_1").enter_value("12345")

button("lookup_item_1").click

field("price_1").verify_value("$7.00")

field("qty_1").enter_value("6")

button("total_next").click

active_window.verify_title("Checkout")

field("purchase_total").verify_value("$42.00")

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

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

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

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

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

Отделите сущность тестов от деталей имплементации!

Поддержите и поощрите хорошие практики программирования в автоматизированном тестировании.

Делайте все вместе.

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/53921/233804

Переводчики: isitrita