Как сделать автоматизированные тесты популярными? [закрыто]

13

Наша кодовая база растет уже 20 лет. У нас около 10 разработчиков + sqa, работающих с 500kloc. Некоторое время назад небольшая команда из нас (2 разработчика, один из sqa) начала работать над автоматизированной тестовой программой. В настоящее время один прогон занимает 11 часов и является интеграционным тестом. Мы работаем над этим, чтобы уменьшить это и уменьшить количество ложных срабатываний, и добиваемся в этом хорошего прогресса. Но детали не должны иметь значения.

Это работает хорошо, и мы продолжаем улучшать его. Нам (небольшой команде) это очень нравится. Если мы что-то нарушаем, мы замечаем день спустя, а не 2 месяца спустя, когда sqa смотрит. Также нашим менеджерам (dev + sqa) идея нравится. Но другие люди в команде просто игнорируют результаты теста. По их мнению, если тесты не проходят после проверки, это проблема теста, а не изменения кода, а просто наш игрушечный проект. Мы несколько раз обсуждали, является ли неудачный тест настоящей ошибкой. В большинстве случаев это так.

Мы не можем и не хотим что-то навязывать. Как мы можем показать, что автоматизированное тестирование - это вещь?

Питер Шнайдер
источник
11
Это не проблема разработки программного обеспечения; это проблема людей.
Роберт Харви
@RobertHarvey Я получил отрицательные отзывы о SO, потому что "основанный на мнении" и комментарий, что этот сайт идеально подходит (и положительные отзывы на этот комментарий). Итак: где я должен спросить? Просвети меня.
Питер Шнайдер
2
Я с @RobertHarvey из-за того, что это проблема людей. Но что касается Workplace, ваш вопрос, вероятно, мы сочли обманом. Например увидеть этот вопрос, принципиально то , что вы просите workplace.stackexchange.com/questions/44964/...
Peter M
1
Не позволяйте тем внизу (или даже близким голосам) обескуражить вас! Некоторые люди могут понять, что такие вопросы важны, и, возможно, могут оказать помощь. Кстати, мои коллеги также не видят полезности автоматизированных тестов, несмотря на то, что предыдущая версия (без каких-либо автоматических тестов) была коробкой с ошибками. Просто измени одну вещь и сломай несколько других, казалось бы, не связанных вещей. Некоторые люди просто не хотят учиться (существует открытое сопротивление против изучения новых вещей).
Бернхард Хиллер
1
Обидно, этот вопрос закрыт. Если разработка программного обеспечения означает что-либо, это означает проблемы работы с реальными людьми, и ответы на такие проблемы будут включать мнение. Тем не менее, пара быстрых идей: (1) если ваши тесты дают ложные отрицания, это определенно увеличит отдачу, потому что результаты будут ощущаться как пустая трата времени; (2) сократить время выполнения, если это вообще возможно. 11 часов не чувствуются сразу, даже если это намного лучше, чем два месяца; (3) sqa примет эти тесты в качестве метрик, которые они смотрят. они уже признаны вашей организацией в этой области.
Дейл Хэгглунд

Ответы:

4

отказ

Хотя я могу звучать как менеджер, я написал это как разработчик, которого также нужно было убедить, что автоматизированные тесты хороши.


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

Следует отметить, что хотя автоматизированные тесты и замедляют их в краткосрочной перспективе, в долгосрочной перспективе это избавит их от многих неприятностей и фактически ускорит их, поскольку они смогут уделять больше внимания разработке новые вещи, и они будут терять меньше времени, занимаясь тем, что разработчики ненавидят: исправлением ошибок.

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

Владимир Стокич
источник
11

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

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

Eternal21
источник
5
Опять же, это может быть что-то еще. Как сопротивление переменам. Если тест не пройден, всегда есть что-то, что нужно исправить, будь то код или тест, поэтому отношение людей к игнорированию тестов из-за их нестабильности неуместно.
Роберт Харви
Мы поговорили с ними, когда были уверены, что что-то сломалось (например, Тест провалился 3 раза подряд после того, как его регистрация повлияла на рассматриваемые функции). Но да, повышение надежности является текущим приоритетом.
Питер Шнайдер
1
@PeterSchneider тест может проваливаться 100 раз подряд, это будет сделано, особенно если тест неверен.
Питер Б
С другой стороны, тест, который никогда не проходит, скорее всего, совершенно бесполезен
Владимир Стокич
1
+1 Хрупкие тесты - определенно проблема. Разработчики должны быть уверены, что написанные ими тесты полезны, не создают ненужных осложнений и не заняты работой .
Андрес Ф.
6

Мы не можем и не хотим что-то навязывать.

Вы определенно должны соблюдать это! Если кто-то вводит новый код и тесты не пройдены, код следует отклонить! Это единственный способ надежно поддерживать большой программный проект.

Банан
источник
Я предполагаю, что это зависит от системы, тестов, масштаба и процесса разработки. Не все ошибки могут быть решены сразу, и не все проблемы должны быть решены сразу.
Ник