Home

Автор: Энди Найт (Andy Knight)

Оригинал статьи: https://automationpanda.com/2017/11/29/the-airing-of-grievances-test-automation-process/

Перевод: Ольга Алифанова

Тест-автоматизация очень много для меня значит. Я выбрал эту специальность из множества доступных в поле разработки ПО. Когда я вижу, что она неверно применяется, или когда люди просто не понимают, что это такое – меня это бесит. У меня много вопросов к плохим процессам автоматизации, и сейчас вы узнаете об этом все!

Говорить «Это просто тест-сценарии»

Автоматизация тестирования – это не просто набор тест-сценариев. Это целый арсенал технологий, требующий дизайна, интеграции, и опыта. Разработка тест-автоматизации – это отдельная область. Когда вы говорите, что это всего лишь набор тест-сценариев – вы унижаете и оскорбляете ее. Это обесценивает те усилия, которых требует автоматизация, ведет к плохому масштабированию работы и отношениям «они против нас» между разработкой и QA.

Не применять лучшие практики разработки ПО к автоматизации

Тест-автоматизация – это разработка ПО, и к ней применимы все соответствующие практики. Пишите чистый, хорошо спроектированный код. Используйте контроль версий и код-ревью. Добавляйте комментарии и документируйте. Не ленитесь потому, что «это же просто тест-сценарии» - это неправильный подход!

Болтать впустую

Не говорите, как важна автоматизация, если вы затем не уделяете ей ни времени, ни ресурсов. Не бросайте ее, как задачу, которую нужно выполнять только тогда, когда у вас осталось время после тестирования вручную. Сделайте ее приоритетом, иначе вы никогда ее не внедрите! Однажды я работал в Agile-команде, в которой стори, относящиеся к фреймворку автоматизации, никогда не включались в спринт, потому что были «недостаточно значимы, чтобы возиться». В результате, хотя компания наняла меня именно для автоматизации тестирования, я каждый спринт пытался урвать на нее время у ручного тестирования.

Путать автоматизацию тестирования с автоматизацией деплоя

Автоматизация тестирования – это автоматизация сценариев тестирования для функциональных тестов или тестов производительности. Автоматизация деплоя – это автоматизация распределения и установки билдов продукта. это разные вещи. Cucumber – это не Ansible.

Навязывать 100% автоматизацию

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

Снижать размеры отдела QA или вовсе его устранять

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

Говорить, что код продукта и код тестов должны писаться на одном и том же языке

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

Не классифицировать типы тестов

Не все тесты одинаковы. Вы можете жонглировать кучей модных словечек: юнит, интеграционные, end-to-end, функциональные, тесты производительности, системные тесты, контрактные тесты, исследовательские, стресс-тесты, тесты границ, тесты долговечности, тесты «чтобы сломать», … Разным тестам нужны разные инструменты/фреймворки. Тесты также должны писаться на соответствующем уровне тест-пирамиды.

Предполагать, что все тесты равнозначны

Повторяю, не все тесты одинаковы, даже внутри одного и того же типа тестов. Тесты различаются по времени разработки, прогона и поддержки. Сравнивать людей или команды по количеству тестов неправильно.

Не приоритезировать тесты для автоматизации

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

Не запускать тесты регулярно

Автоматизированные тесты должны прогоняться как минимум раз в день, а в непрерывной интеграции – постоянно. В противном случае их полезность слишком низка, чтобы оправдать работу автоматизаторов. Однажды я работал в QA-команде, которая запускала автотесты максимум пару раз в течение двухлетнего релиза! Что за бессмысленная трата времени!

Пользоваться HP Quality Center / ALM

Этот инструмент просто отстой, мать вашу. Не используйте его для автотестов. Приберегите деньги для разработки хорошей базы кода с грамотной документацией, и воспользуйтесь другими дашбордами (вроде Jenkins/Kibana) для отчетов о тестировании.

Обсудить в форуме