Проблемы с автоматизацией тестирования и современным QA
Какие общие проблемы с автоматизацией тестирования в Agile и DevOps?
Современная разработка программного обеспечения и контроль качества слишком много внимания уделяют автоматизации тестирования и недостаточно - исследовательскому тестированию.
Выпускаем ли мы более качественное программное обеспечение с большим количеством автоматизированных тестов? Думаю, нет!
Недавно я наткнулся на сообщение в социальной сети, в котором говорилось
Сегодня я вижу в большинстве мероприятий по тестированию и контролю качества в основном DevOps, непрерывную интеграцию и автоматизацию тестирования.
Хотя все это очень хорошо, я вижу, что автоматизируется множество дерьмовых тестовых примеров.
Я вижу несколько ошибок, сообщаемых во время интеграционных и функциональных тестов, хотя все они автоматизированы.
В UAT пользователи находят все больше и больше ошибок, потому что команды тестирования не смогли идентифицировать их на предыдущих этапах.
Если мы не научим людей писать хорошие тестовые примеры, мы получим полностью автоматизированные…
И моя интерпретация… - «дерьмо». :-)
В любом случае, давайте посмотрим, что действительно происходит в мире современного контроля качества и автоматизации тестирования.
Проблемы с современным QA
Большая часть «автоматизации тестирования» в рамках гибкой разработки находится в ужасном состоянии. Индустрия программного обеспечения вкладывает огромные суммы денег в найм «Экспертов по автоматизации тестирования» в основном для того, чтобы получить уверенность в том, что программное обеспечение, которое они создают, имеет высокое качество. Тем не менее, заметные ошибки и / или другие проблемы обнаруживаются во время UAT или проскальзывают в производственную среду. Итак, что происходит?
Примечание:Под автоматизацией тестирования я в основном имею в виду ЛУК Автоматизация тестирования.Автоматизированное тестирование сейчас лежит в основе любого современного процесса разработки программного обеспечения. Его цель - помощь поставлять высококачественное программное обеспечение на постоянной основе, но так ли это на самом деле?
Тестировщики все еще тестируют?
Дело в том, что в большинстве гибких команд тестировщики больше не занимаются тестированием.
Ручное тестирование утратило свою ценность благодаря таким методам разработки и культуре, как Agile и DevOps , которые создали разрыв в пространстве QA - тех, кто умеет писать код, и тех, кто не умеет.
Вы часто слышите что-то вроде: «Я на 100% инженер по автоматизации», «80% автоматизация, 20% ручное управление» или, что еще хуже, «Я ненавижу ручное тестирование». Шокирует!
В DevOps нас убеждают в том, что все должно быть автоматизировано. Здесь нет места ручному вмешательству, например ручное тестирование.
В настоящее время большинство тестировщиков в гибкой команде изо всех сил стараются удовлетворить спрос на «автоматизацию тестирования». Есть необходимость автоматизировать каждую историю в спринте, а времени на тщательное исследовательское тестирование не хватает.
Проблема, особенно в гибкой разработке, заключается в том, что QA берут пользовательскую историю и автоматизируют ее критерии приемки. При этом их основная и единственная цель - бороться со своими ограниченными навыками программирования, просто чтобы пройти тест.
Естественно, это создает узкую направленность, когда вы заинтересованы только в автоматизации теста и видите его прохождение в конвейере сборки. Это только доказывает, что то, что было в критериях приемлемости - правильно или неправильно - работает, и вы, как правило, забываете об общей картине.
Снижение ручного тестирования
Все больше и больше «традиционных тестировщиков» переходят к «гибкому тестированию», беря уроки кодирования и становясь более техничными.
Не поймите меня неправильно; это все хорошо. Я считаю, что как тестировщики, мы всегда должны стремиться изучать новые и появляющиеся технологии, чтобы оставаться находчивыми. Мы должны понимать технический стек, если мы хотим протестировать систему с высоким уровнем качества.
Однако настоящая причина, по которой большинство ручных тестировщиков берут на себя эти инициативы, заключается в том, что существует общее убеждение, что «автоматическое тестирование» лучше ручного тестирования, и, эй, программирование - это весело, верно?
Примечание:Путем ручного тестирования я НЕТ ссылаясь на старый школьный способ следования сценарию и выполнения шагов. Я имею в виду так называемых «исследовательских тестировщиков» - тех, кто проводит настоящее тестирование и которым любопытно изучить поведение системы, реализуя интересные и продуманные сценарии.К сожалению, рынок исследовательских тестировщиков, похоже, сильно упал. Это совершенно очевидно. Просто введите несколько поисковых запросов для «ручного тестировщика» и «автоматического тестировщика» на любом сайте вакансий в сфере ИТ, и вы сами увидите результат.
Проблемы с автоматизацией тестирования
Теперь давайте посмотрим, почему большая часть усилий по автоматизации тестирования не приносит никакой пользы.
Типичные ошибки, которые я наблюдаю неоднократно:
- Неправильное ожидание автоматических тестов
- Автоматизация тестов на неправильном уровне, в неподходящее время и с использованием неправильных инструментов
- Автоматизация бесполезных тестов
- Пренебрежение важными областями
- Отсутствуют ключевые сценарии
Неправильные ожидания
Некоторое время назад я написал сообщение в блоге на зачем вам автоматизировать тест ? Если вы еще не читали, ее стоит прочитать.
Резюме этой статьи состоит в том, что вы автоматизируете тесты, которые хотите запускать на регулярной основе. По определению, это ваши регрессионные тесты, которые подтверждают, что система все еще работает.
Однако, если автоматические проверки действительно обнаруживают много проблем с регрессией, я бы поставил под сомнение навыки разработчиков и процесс разработки. Автоматизированные тесты пользовательского интерфейса не должны [проводиться за счет] или [компенсироваться] за плохое кодирование.
Не тот слой, неправильные инструменты и неправильное время
Большинство инженеров по автоматизации тестирования в гибких командах изучают пользовательскую историю и автоматизируют ее критерии приемки. В большинстве случаев это делается с помощью комбинации селена и огурца.
Современные веб-приложения теперь четко разделены на серверную часть и интерфейсную часть. Бэкэнд в основном состоит из ряда веб-сервисов или API REST с легкодоступными конечными точками.
Логику приложения можно протестировать на уровне API. Однако большинство инженеров по автоматизации тестирования прибегают к проверке функциональности на уровне пользовательского интерфейса, что в лучшем случае является громоздким.
Существуют инструменты для тестирования, такие как Каратэ и Rest-Assured, которые упрощают тестирование API. Мы должны использовать эти инструменты во время разработки. К сожалению, некоторые инженеры по автоматизации тестирования даже не знают основы HTTP , не говоря уже о возможности писать сценарии тестирования API.
Что касается автоматизации UI-тестов, Кипарис отличный инструмент. Это больше похоже на инструмент TDD для интерфейсных разработчиков. Разработчики очень быстро получают отзывы о поведении новых компонентов пользовательского интерфейса.
И Karate, и Cypress служат «инструментами тестирования разработки», то есть инструментами, которые направляют и поддерживают разработку. Оба они легкие, легко интегрируются и могут обеспечить уверенность в развитии .
Затем мы можем использовать Selenium или Cypress для разработки только нескольких сценариев, которые проверяют систему на всех этапах. Эти сценарии составляют наш легкий регрессионный пакет и обеспечивают уверенность в непрерывности бизнеса .
Довольно часто я слышу что-то вроде: «мы ждем, пока функция полностью не разовьется и не станет стабильной, прежде чем автоматизировать тесты». Любой сознательный тестировщик знает, что ошибок в новой функции больше, чем ошибок регрессии. Вероятность обнаружения проблем с текущей развивающейся функцией выше, чем со стабильной функцией.
Если вы собираетесь тратить время на автоматизацию тестов, делайте их параллельно с разработкой, когда они могут принести больше пользы.
Автоматизация бесполезных тестов
Не автоматизируйте каждый «тест» только ради него. Включите в игру некоторый мыслительный процесс. Изучите архитектурные схемы верхнего и нижнего уровня. Спросите, что может пойти не так. Изучите точки интеграции и найдите потенциальные точки отказа.
Используйте риск-ориентированный подход к автоматизации, как если бы вы (надеюсь) поступили бы со своим общим подходом к тестированию. Какова вероятность того, что что-то выйдет из строя, и каковы последствия отказа? Если ответ высокий, то эти сценарии следует автоматизировать и выполнять при каждой сборке.
В каждом спринте мы часто пишем автоматические тесты на основе пользовательских историй для этого спринта и забываем об интеграции с другими функциями. Есть либо слабые интеграционные тесты, либо их нет.
Помните, что автоматизация «тестов» требует времени. Также имейте в виду, что, автоматизируя тест, вы на самом деле не тестируете, а просто проверяете, удовлетворяет ли рассматриваемая функция некоторым критериям приемлемости.
Ты не могу автоматизировать тестирование, но можно автоматизировать проверку известных фактов.
Поэтому каждый раз, проводя автоматизацию «теста», думайте о времени, которое вы тратите, не тестируя!
Пренебрежение важными областями
Я вижу все больше и больше такой халатности с момента зарождения культуры DevOps.
В DevOps конвейер доставки вместе со сценариями развертывания составляет основу разработки и доставки программного обеспечения, но они почти никогда не проходят тестирование.
За последние несколько лет я легко могу сказать, что видел гораздо больше «экологических проблем», чем функциональных ошибок. Проблемы среды, такие как проблемы с сервером CI, сценариями развертывания, средами тестирования и т. Д.
Проблемы с окружающей средой серьезно влияют на разработку и тестирование. Они отнимают много времени разработчиков и DevOps и значительно замедляют процесс развертывания, но при этом не учитываются возможности тестирования и предотвращения этих проблем.
Мы просто принимаем их как часть поставки современного программного обеспечения.
Мы тратим много усилий на автоматизацию функционального поведения и полностью игнорируем самые важные «вещи». Еще хуже то, что приходится полагаться на тесты Selenium, чтобы указать, работают ли развертывания или нет!
Отсутствуют ключевые сценарии
Сценарии - король! В конце концов, именно сценарии выявляют ошибки.
Довольно часто серьезная проблема просачивается в производственную среду, потому что никто не думал об этом конкретном сценарии. Количество выполненных автоматических тестов значения не имеет. Если сценарий не был продуман или протестирован, закон говорит нам, что в нем есть ошибка.
К сожалению, в большинстве сред гибкой разработки этому важному мероприятию «Мастерская сценариев» уделяется недостаточно внимания.
Проблемы с процессом
Давайте посмотрим, как указанные выше проблемы проявляются в типичном сценарии разработки:
- Владелец продукта пишет пользовательские истории без критериев приемлемости или с минимальными критериями приемлемости.
- Недостаточно времени, посвященного сеансам уточнения историй, чтобы обсудить различные сценарии пользовательской истории.
- Критерии приемки интерпретируются как приемочные испытания - Да, есть разница между двумя !
- Тестировщики только автоматизируют критерии приема в пользовательских историях, в основном используя Selenium и / или Cucumber.
- За автоматизированное тестирование почти всегда отвечают «тестировщики автоматизации».
- Разработчики понятия не имеют, что входит в состав тестовых пакетов, или даже не знают, как выполнять автоматические тесты.
- Автоматические тесты добавляются к постоянно расширяющемуся «пакету регрессии», поэтому каждый раз запускается все дольше и дольше.
- Автоматические функциональные тесты пользовательского интерфейса интегрированы в конвейер сборки, что хорошо, но ...
Разработчик вносит простое изменение и должен подождать 30 минут, пока автоматические тесты не станут зеленого цвета, прежде чем новую функцию или исправление ошибки можно будет развернуть в производственной среде. Ожидание 30 минут возможно только в том случае, если тесты пройдут с первого раза. Если они потерпят неудачу из-за каких-либо проблем с тестированием или средой, это может занять больше времени.
Поскольку автоматизированные тесты выполняются, а QA исследует случайные сбои, разработчик и / или владелец продукта проверили новую реализацию и с радостью выпустят ее, но они не могут этого сделать, потому что сборка не зеленая.
Через некоторое время либо сборка становится зеленой, либо руководство разочаровывается в неудачных тестах и все равно принимает решение о выпуске. Затем, BOOM, после нескольких минут работы в производственной среде, наблюдается всплеск 500 ошибок сервера.
Сбои инфраструктуры
Неудачи, кажется, показывают похожую картину
- Сбой в точках интеграции.
- Сбой связи со сторонними приложениями.
- Веб-службы не работают и запросы к конечным точкам API не работают.
- Неправильная конфигурация на одной из виртуальных машин или узлов, что приводит к периодическим проблемам.
И все же не существует процесса проверки этих проблем в рамках процесса разработки или доставки.
Инженеры по автоматизации тестирования фокусируются на автоматизации функциональных тестов. Не делается акцента на производительности, безопасности или отказоустойчивости. Да и тестирования инфраструктуры точно нет!
Резюме
Пришло время сместить наше внимание с автоматизации функциональных тестов, у которых мало шансов выявить функциональные проблемы, на более серьезные и распространенные экологические проблемы, мешающие разработке.
Автоматизация тестирования, если сделано неправильно или без мыслительного процесса , это пустая трата времени и никому не представляет ценности. Плохие автоматизированные тесты могут повлечь за собой огромные расходы на обслуживание и затруднить разработку. В конце концов, единственное решение - отбросить тесты.
В современной разработке программного обеспечения большая часть усилий «инженеров по автоматизации тестирования» тратится на борьбу с кодом автоматизации и обеспечение работы «тестов», а не на правильное тестирование и исследование системы.
На написание кода автоматизации буквально не хватает времени а также провести исследовательское тестирование. Мы автоматизируем историю за историей и забываем об интеграционных тестах, забываем об общей картине.
Часто мы выполняем множество автоматических тестов, но исследовательское тестирование обнаруживает большинство ошибок. Затем ретроспективно мы пишем автоматический тест для ошибок, обнаруженных в ходе исследовательского тестирования, чтобы выявить ошибки регрессии.
Мы должны выбирать, что автоматизировать, и судить о своем решении, исходя из рисков. Что может пойти не так, какова вероятность того, что что-то пойдет не так и как повлияет на пользователя или бизнес, если что-то пойдет не так?
Если вы занимаетесь «Автоматизацией тестирования», пожалуйста, не используйте Selenium для тестирования функциональности API или компонентов пользовательского интерфейса. Вместо этого используйте Selenium для автоматизации лишь нескольких полезных и критически важных для бизнеса сценариев, чтобы обеспечить непрерывность бизнеса перед каждым выпуском.
И, наконец, каждый раз, когда вы проводите автоматизацию «теста», думайте о времени, которое вы тратите, не тестируя!
Дальнейшее чтение:
