Название говорит само за себя. Некоторые сотрудники нашей компании считают, что автоматизированные тесты «просты» и что «на их создание уходит« один день », чтобы написать наборы тестов COM и UI». Что можно сделать, чтобы противостоять этому?
Примечание: я не спрашиваю о том, как продвигать автоматизацию. Это не проблема. Автоматизированное тестирование и процессы продвигаются и запрашиваются здесь все время. Проблема в том, что некоторые люди не понимают, что автоматизация не «легка» и не «быстра».
project-management
quality
automation
joshin4colours
источник
источник
Ответы:
В следующий раз, когда вы получите запрос, постарайтесь разбить как можно большую часть процесса автоматизации на куски времени. Я думаю, когда они понимают, что для каждого текстового поля или нажатия кнопки требуется 5 минут, они начинают понимать, сколько времени это занимает.
Например, возможно, почему это занимает так много времени, потому что они начинают вводить взаимозависимость между полями: например, позволяют им продолжать, только если это заполнено, но не, если это не так, за исключением случаев, когда ....
Постарайтесь объяснить им, ПОЧЕМУ это занимает так много времени, но не так много, как вы теряете их в процессе «обучения».
источник
В своих ролях я сталкивался со многими людьми «х легко», особенно в проектах разработки. На мой взгляд, есть три причины для этого:
1) Они действительно не понимают, о чем говорят, но очень любят звучать так, как они.
2) Они прочитали пару книг и думают, что знают, о чем говорят
3) Наконец, люди предполагают, что компьютер проводит тестирование быстро, потому что компьютеры работают быстро.
Единственный верный способ борьбы с этим - вовлекать пользователей на регулярной основе, стратегии коммуникации для проектов являются ключевыми, конечно, объяснять все тонкости автоматизированного тестирования нетехническим пользователям будет бесполезно, но информировать их о вовлеченных процессах. может быть полезным. Вы можете сделать это через документацию, семинары или просто пообщаться в следующий раз.
Я даже видел, как бакалавр выделяет самых громких из этих «х легко» людей и просто приглашает их на один день в отдел, думая, что они либо уйдут, понимая больше о том, что вы делаете, либо они будут просто уходи, думая: «Боже, я действительно не знаю, о чем говорю, я думаю, что был неправ».
источник
Программное обеспечение - это бизнес автоматизации вещей.
Мы пишем программное обеспечение для облегчения скучных, повторяющихся и трудоемких задач. Мы пишем программное обеспечение для автоматизации создания отчетов, сбора данных, общения с другими и т. Д. Написание автоматических тестов - это на самом деле просто написание программного обеспечения, чтобы убедиться, что наше другое программное обеспечение работает так, как мы ожидаем.
Если ваши коллеги понимают, что написание программного обеспечения является трудным делом и требует времени, должно быть довольно легко показать им, что написание большего количества программного обеспечения должно быть трудным и занимать время. Было бы неплохо получить все преимущества автоматизации бесплатно, но, как всегда, нам нужно заранее начать работу, чтобы получить преимущества позже.
Если они этого не понимают, вам нужно либо научить их этому, либо полировать свое резюме.
источник
writing software is hard and takes time, Написание небольшого приложения командной строки быстро. Писать скайнет ИА сложно. Такие общие заявления никого не убедят.Большинство сотрудников проводят свое время либо в «передней» (клиент-босс-стейкхолдер) части компании, либо в «тылу» (где выполняется «настоящая» работа). Эти две функции разные, почти противоположные. (И мало кто работал в обоих). В результате между этими двумя группами часто возникают недоразумения.
Лучший способ обучить, например, «передних» людей, - это провести один или несколько человек в «заднем». Если они закончили «День из жизни ...», у них было бы более реалистичное представление о том, что можно сделать за день, и почему для запуска автоматических тестов требуется больше времени и усилий. Точно так же «задние» люди могут получить день или два на «фронте».
В книге «Как стать богатым» Джон Пол Гетти (магнат своего времени) выступал за такое «перекрестное обучение». По его мнению, продавец, который проводил время на конвейере, где производился продукт, справлялся бы с продажами гораздо лучше, а инженер, который провел день с клиентами, лучше справлялся с «отладкой».
источник
Я не согласен с вашей предпосылкой здесь.
Я большой сторонник автоматизированного тестирования, неважно, модульное тестирование, интеграционное тестирование или тестирование пользовательского интерфейса. Существует множество отличных инструментов для реализации автоматических тестов.
Давайте сравним автоматическое тестирование и ручное тестирование на основе следующего примера:
В веб-приложении протестируйте функциональность «Изменить пароль» существующего пользователя с помощью браузера.
Ручное тестирование :
Легко? На самом деле, нет. Есть много возможных подводных камней в этом процессе.
Быстро? Нет. Ручная работа требует времени.
Теперь попробуем написать автоматический тест :
Легко? Нет! Нам нужно было исследовать инструменты, внедрить их, исправить некоторые ошибки в наших тестах.
Быстро? Нет! Это занимает даже больше времени, чем ручное тестирование.
Но здесь есть большая разница: для будущих тестов вам нужно всего лишь написать сам тест , последний пункт в списке - что было сделано сравнимо быстро. Все исследования и init-скрипты не нужно делать для дальнейших тестов.
И после того, как вы написали тест, вы можете начать его легко. Через несколько секунд (или, может быть, минут, если запуск базы данных и веб-приложения занимает много времени), вы увидите, работает ли подпрограмма «Изменить пароль» или нет. Если есть ошибка, исправьте ее и запустите тест снова - вы сразу увидите, исправлена ли ошибка. Быстро и просто .
Написание автоматических тестов, во-первых, не является ни простым, ни быстрым, но их выполнение.
И это момент, когда вложенное время возвращается.
источник
Тестирование в целом не легкое и не должно быть. Если бы «Боинг» или «Мерседес» не тестировали свои продукты так же тщательно, как они, то они либо были бы банкротами из-за судебных исков, либо прекратили бы свою деятельность за продажу таких предметов низкого качества. Будете ли вы водить машину со скоростью 70 миль в час, зная, что руль может или не может развалиться на части?
Очень трудно предложить способы справиться с мышлением, не понимая, кто эти люди, или их причины. Большинство менеджеров и директоров думают о затратах и судят по тому, что производится. Использование этих критериев делает очень трудным оправдание затрат времени на тестирование. Если это так, то вам нужно будет найти способы, чтобы представить эту задачу как полезную в долгосрочной перспективе, что, конечно, так и есть.
Тот факт, что программное обеспечение не является материальным, не означает, что мы можем уйти, не задумываясь о последствиях неработающих систем, которые мы создаем. Могу поспорить, что в Amazon есть автоматические тесты, и я уверен, что есть люди, которые слишком хорошо знают, каковы последствия отказов их веб-сайтов / услуг.
источник
2 +2 = 4 - один из самых простых кусков кода, который все понимают; И вы можете видеть, как легко понять. Но это не значит, что это «простое» уравнение. Уровень абстракции, необходимый для достижения простого уравнения, довольно сложен. То же самое происходит с методологиями программного обеспечения и тестирования программного обеспечения. Уровень абстракции, который требует фрагмента кода, требует много работы.
Это правда, что хорошая практика приводит к повторному использованию классов и объектов, но в равной степени для достижения этого состояния необходимо инвестировать время и усилия .
источник
У этого вопроса есть две стороны.
С вашей стороны, вы, кажется, думаете, что делаете хорошую работу, и что группа «Автоматизация проста» не знает, о чем они говорят.
С их стороны, из того, что вы говорите, они видят автоматизированные тесты, которые (по их мнению) занимают много времени для производства.
С этого расстояния, с тем небольшим, что нам нужно сделать, мы не знаем, кто «прав» или кто-то «прав».
Как бороться с автоматизацией легко мышления
Поговори с ними. Честно спрашивайте их идеи о том, как это можно сделать лучше. Вовлеките их и вовлекайте. Это единственный способ узнать, действительно ли у них есть что-то положительное. Возможно, у них есть какой-то достойный вклад, и вы можете добиться победы / победы.
Если у них нет реального представления о том, как работает программирование и автоматизированное тестирование, или реалистичных идей о том, как повысить производительность, то, положительно задействовав их, вы сможете показать, как это делается и куда уходит время. Будьте скромны и позитивны, поблагодарив их за вклад / идеи. Подумайте о том, что они сказали: возможно, их предложения вызовут для вас другой способ мышления. Если так, дайте им эту обратную связь. Будучи скромным и позитивным, вы также можете сделать это победой / победой.
Прежде чем говорить с ними, подумайте о том, как создавать, запускать и управлять своими тестами. Какие рамки вы используете? Есть ли другие, которые могут быть лучше? У вас есть «стандартный» шаблон, который вы адаптируете? Может ли создание тестов быть более автоматизированным? Что тебя сдерживает?
источник