Теоретически программы или инструменты автоматизации тестирования должны упростить работу тестировщиков, освободить время и предоставить нам дополнительное расслабляющее одеяло для нашей оценки.
И так много организаций не могут реализовать масштабируемую, сильную и хорошую инфраструктуру автоматизации тестирования, которая вернула бы вложенные ресурсы и могла бы их сэкономить. Некоторые «выбрасывают» письменные задания по автоматизации тестирования, а другие продолжают бороться за свои цели, чтобы заработать стабильный пакет автоматизации.
На протяжении многих лет я наблюдал, как многие компании пытаются реализовать свои усилия по автоматизации, я наблюдал, как письменные проекты выбрасываются, фреймворки меняются, а менеджеры увольняются из-за того, что они не смогли выполнить то, что было обещано или поставлено целью.
Есть много причин для неудач, хотя автоматизация имеет смысл в долгосрочной перспективе, мы должны понимать, что это намного сложнее, чем кажется.
Ниже приведены несколько причин, о которых вы должны знать, прежде чем прыгнуть вперед и начать создавать свой проект автоматизации тестирования:
Анализируйте и задавайте вопросы. Работа по автоматизации тестирования - это работа, как и любой другой проект приложений, и к ней следует относиться так же, как и к ней; Как бы вы отнеслись к планированию программного проекта? Позвольте этой идее направить вас, когда вы думаете о реализации проекта автоматизации тестирования. Кого бы вы выбрали на работу? Кто будет использовать произведенный продукт? Какой язык или фреймворк лучше всего подходят для работы? Вы бы поняли из проблем и их руководящих принципов и взглянули бы на них? Вы бы сами составили архитектуру, о которой ничего не знаете, или позвонили бы консультанту, чтобы он поделился с вами некоторыми мыслями?
Все эти вопросы - лишь верхушка айсберга того, что вы должны задать себе, прежде чем писать одну строчку кода или даже тестировать ситуацию.
Неадекватный набор навыков: позвольте мне задать вам вопрос. Вы бы позволили худшему или неопытному программисту, тому, кто не понимает, как составить отличный чистый код с возможностью поиска, - стилизовать дизайн вашего приложения и написать его с нуля? Думаю, ответ отрицательный. Так почему же так много компаний думают, что качество может быть реализовано кем-то из инфраструктуры автоматизации оценки без опыта и навыков? Если у преданных своему делу сотрудников нет опыта и знаний, и вы не планируете нанимать кого-то, кто есть, то вам нужно подумать об использовании инструментов автоматизации без кода.
Нереалистичные ожидания / подход: я разделю это на две части. Первый - это ошибочное понимание ROI (возврата инвестиций) автоматизации тестирования, а второй компонент - нереалистичные временные рамки. Есть Работа настолько же хороша, насколько она сделана вами, и вы не можете ожидать чего-то, не вкладывая времени, чтобы принести пользу. Я разговаривал с инженером по обеспечению качества, который сказал мне, что он выделил 6 часов в неделю на создание секретной инфраструктуры. Чего вы должны ожидать от него за 6 часов?
Чтобы выполнить эту работу, вам необходимо узнать:
- Каких именно целей вы хотите достичь с помощью автоматизации тестирования?
- Что можно считать фантастической ценой усилий / времени?
- Какие критерии для достижения?
- Сколько времени / денег вы готовы потратить, чтобы это произошло?
Автоматизация - это не задача «запустить и забыть» . Вы хотите признать, что это непрерывный процесс, требующий поддержки, групповых усилий и продвижения.
Я должен признать, что, к сожалению, судя по тому, что я увидел, некоторые компании воспринимают предоставление инженеру по обеспечению качества работы под прикрытием только как способ сохранить работника или внести некоторую « изюминку » в его еженедельный распорядок. Не поймите меня неправильно, я не говорю, что мы не должны сберегать наших сотрудников или предоставлять им время для обучения и развития, я просто говорю, что это должно соответствовать ожиданиям, которые являются реалистичными и прозрачными для сотрудников, что само по себе .
Недостаточное планирование: фантастический проект автоматизации должен начинаться с высокоуровневого плана и плана, который перерастет в всеобъемлющий технический стиль. Даже стратегия «Один размер подходит всем» может иметь катастрофические последствия для вашего успеха. То, что отлично сработало для одной компании, не обязательно означает, что это сработает за вас. Это заявление может относиться к выбору инструмента. Всякий раз, когда вам на самом деле не нужно использовать рассматриваемую технологию, это становится модным словом. Это очень важно отметить. Существует большое количество инструментов с открытым исходным кодом и коммерческих инструментов, которые могут обеспечить высокое соотношение цены и качества и даже без учета альтернатив и преимуществ / альтернатив, которые могут предложить эти инструменты. Выберите инструмент, который соответствует вашим потребностям. Вот мои два цента - гораздо лучше заплатить за решение, чем тратить много времени (это будет намного дороже, чем стоимость программы).
Теперь, когда мы продолжаем обсуждать способ планирования нашего дизайна, нам придется подумать о нашей комплексной технической архитектуре и бизнес-требованиях. Вот лишь некоторые из аспектов, которые следует учитывать:
- Представьте себе вакансии, модули, бизнес-потоки, которые будут изучать люди?
- Какова запланированная политика для каждого этапа выполнения? (Sanity, Regression, специальный пакет CI / CD?)
- Каковы основные общие / общие / повторяющиеся потоки / функции?
- Как мы планируем каждое испытание для небольшого автономного артефакта? (SetUp и TearDown, зависимость от внешних данных вместо сгенерированных оценочных данных, что нужно запускать перед каждым тестом, класс набора?)
- Как мы предотвратим "поломку" одной оценки другой, если они выполняются в параллельном режиме?
- Как создать хорошую масштабируемую, чистую и подходящую атмосферу? (Мок-серверы, варианты баз данных, сценарий очистки, настройки браузера, конфигурации сети / сервера, установка и очистка, виртуальное окружение или контейнеры докеров).
- Какие именно инструменты сборки мы используем?
- Как именно управлять нашими зависимостями?
- Где будет храниться наш проект?
- Сколько инженеров работает над проектом и как будет осуществляться управление вариантами?
- Какие инструменты CI лучше всего подходят для наших сборок?
- Будете ли вы внедрять рабочий процесс CI / CD?
- Где вы будете запускать свои тесты и ресурсы, которые вы можете использовать для разработки собственной платформы выполнения? (Есть ли у вас средства для покупки разрешений на облачные решения? Есть ли у вас инструменты или поддержка для создания собственной инфраструктуры Selenium Server?)
- Какие именно тесты скоро будут автоматическими? (API, визуальные концепции, серверные процессы, веб / автоматизация пользовательского интерфейса, мобильные устройства - Android / IOS).
- Существуют ли большие коллекции данных, длинные потоки, сложные процессы, интеграции, которые потребуют дополнительной оценки?
- Что мы должны тестировать через графический интерфейс, а что безопаснее проверять через API?
- Какие именно журналы, механизмы отчетности, обработчики и слушатели нам нужно будет реализовать, чтобы упростить оценку и отладку нашей основной причины? (Что такое одночасовая автоматизация, если вы посвятите день пониманию результата?)
- Какие показатели / отчет / выходные данные должны предоставлять прогоны?
- Какие именно интеграции мы действительно хотим? (Программы отчетности, ALM Tools, Bug Trackers, программы управления оценкой).
- Кто может составлять инфраструктуру и кто должен проводить тесты? (Может ли быть между ними ветвь?)
- Кто несет ответственность за то, чтобы предлагать инженерам по автоматизации бизнес-процессы / тестовые примеры / бизнес-логику, которая должна быть автоматической?
- Определены ли этапы проверки концепции (POC) для определения будущих целей?
Это лишь некоторые из вопросов вкратце, и что вы должны вынести из этого, так это то, что
Подходящий вариант инструмента, превосходное планирование / дизайн, вероятно, повлияют на неудачу и успех.
Автоматизация всего : важно отметить, что то, что не может и не должно быть автоматическим. Иногда при восприятии или неправильных управленческих решениях мы автоматизируем все, что приходит в голову тестировщику, или слепо конвертируем тестовые случаи в сценарии. Во-первых, не все оценки целесообразно автоматизировать. Во-вторых, сами тест-кейсы неприемлемы для работы. Это заканчивается неудержимым набором автоматических тестов, которые невозможно сохранить, и, к сожалению, в большинстве случаев это приводит к выделению большого количества нашей письменной работы. Нет никакой дополнительной ценности в автоматизации, если у вашей компании нет средств для поддержки групп автоматизации десятков тысяч тестовых экземпляров, которые время от времени проверяют одну и ту же бизнес-логику.
Нам также нужно будет составить четкий план того, что необходимо поддерживать для каждой сборки автоматизации. Что входит в нашу регрессию? Что называется нашим рассудком? Что является достаточно безопасным и надежным, чтобы войти в наш конвейер CI / CD?
Test-Automation требует твердого планирования, понимания, приверженности и преданности делу, чтобы обеспечить надлежащую ценность.
Отсутствие навыков / надлежащего обучения, неправильный выбор инструментов, недостаточные ресурсы, отсутствие надлежащей подготовки, нереалистичное ожидание, все это может привести к провалу проекта.
Я надеюсь, что этот отчет окажет положительное влияние и поможет некоторым из вас выработать продуктивный образ мышления.