Неужели Вы думаете, что ваш фреймворк лучше, чем мой?

design-patterns
architecture
framework
Теги: #<Tag:0x00007fedc12d1de0> #<Tag:0x00007fedc12d1610> #<Tag:0x00007fedc12d10e8>

(Mykhailo Poliarush) #1

Неужели Вы думаете, что ваш фреймворк лучше, чем мой?

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

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

 Лагерь 1: "Это никогда не работает так, как рекламируется и не стоит этому следовать "

 Лагерь 2: "Это будет работать, но с кучей программирования и ресурсов"

 Лагерь 3: "Неужели, вы думаете, что ваш фреймворк лучше, чем мой?"

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

 Лагерь 1: Это результат «записи и воспроизведения" – этапа, которой обычно используют как шаг продаж, чтобы продемонстрировать, как легко человек может производить тест кейс с использованием их продукции. Продавец может с помощью простого примера,закрыв глаза, простым нажатием клавиш и щелчком мыши автоматически записывать на языке программирования, а затем воспроизвести нажатием кнопки. Похоже, через несколько минут после покупки продукта, что утверждение этой замечательной техники превратилось в классический змею нефти.  Накапливаются часы, когда тест-команды изо всех сил пытаются поддержать бесконечное количество тест кейсов. Тест менеджеры относятся с недоверием к автоматизации и приходят к выводу, что все это не стоит затраченных усилий.

 Лагерь 2: Это результат этапа "структурного программирования" или тест менеджеров, которые не отказываются от обещаний выполнения автоматических тест кейсов. Определяя, что если они инвестируют больше, нанимая программистов, то это поможет контролировать изменения скриптов. Несмотря на улучшение записи и воспроизведения, стоимость, время потребления, а также возможность сотрудничать с другими разработчиками сценария, становится очевидным слабое место (недостаток). Тест менеджеры понимают, что ресурсы, необходимые для получения хорошей автоматизации, израсходуют весь бюджет и, возможно, будет лучше найти другие решения.

 Лагерь 3: Это результат этапа "фреймворк", или тех, кто расширяет структурное программирование для создания устойчивости в их программировании. Этот этап дает наилучшие результаты посредством разбиения кода на модули в переиспользуемые функции, компоненты и параметризированные тестовые данные. Удобство для пользователя является важной характеристикой, так что могут быть переданы системным аналитикам, чтобы уменьшить количество дорогостоящих программистов. Как недостаток, стандарт для достижения успеха в том, чтобы просто утверждать, что реализация достигла уровня фреймворка. Степень измерения повторного использования, технического обслуживания и удобства сильно варьируются и в лучшем случае носят субъективный характер. Страстные дебаты дизайн породили такие разговоры, как "Неужели вы думаете, что ваш фреймворк лучше, чем мой?" К сожалению, это понижает жизнеспособность хороших фреймворков.

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

 

Патрик Дж. Квилтер- младший, основатель ООО Quilmont