Домой » Теория автоматизации » 7 грехов автоматизированного тестирования

7 грехов автоматизированного тестирования

7 grehov avtomatizirovannogo testirovaniya
Автоматизированное тестирование очень мощная вещь. Вы можете запускать тысячи тестов с одним нажатием кнопки и получить быстрый отчёт о состоянии продукта. Вы можете быстро найти баги в регрессии. По незнанию или неопытности автоматизированное тестирование рассматривают в качестве панацеи от всех бед и как альтернативу ручному тестированию. Но не всё так просто в автоматизации. Сейчас рассмотрим 7 “грехов” автоматизированного тестирования.

  1. Зависть (Некорректное сравнение ручного тестирования и автоматизации)

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

  1. Обжорство (Потакание коммерческим инструментам тестирования)

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

  1. Похоть (Любить UI так сильно, что все тесты выполняются с помощью пользовательского интерфейса)

Тестирование через UI происходит более медленно, чем через API. Также оно и сложнее, так как данные приходится вносить поочерёдно в каждую форму (или выбирать из меню). В таких ситуациях лучший способ – тестирование с использованием API. В таком случае вы просто бэкэнду отправляете данные пачкой и анализируете поведение системы. Тестирование с использованием UI незаменимо, если на странице присутствует валидация данных или результат их обработки невозможно проанализировать без графической оболочки.

  1. Гордость (Слишком горд, чтобы участвовать в процессе тестирования)

Test Driven Development, несомненно, является хорошей практикой, но и это не выход. У разработчиков и тестировщиков должно быть понимание общей задачи и общее виденье процесса тестирования. Автоматизаторы тестируют общее поведение системы, где модули взаимодействуют между собой. И девелоперы должны принимать результаты тестов как данное.

  1. Лень (Слишком ленивы, чтобы поддерживать автоматизированные тесты)

Чтобы оправдать стоимость создания автоматизированных тестов и воспользоваться всеми преимуществами этих тестов необходимо прогонять тесты на регулярной основе. Только тогда мы сможем получить всегда актуальное состояние продукта. Для этого тесты надо запускать не вручную, а с помощью системы непрерывной интеграции (CI). Настройка этой системы не представляет какой-то сложности, зато вы можете настроить расписание запуска тестов.

  1. Ярость (Разочарование в медленных или ненадёжных тестах)

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

  1. Алчность (Попытка сократить издержки за счет автоматизации)

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

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*
*