Автоматизированное тестирование: объяснение его ценности для бизнеса

Для начала я не думаю , что это повторение из других вопросов на модульном тестировании . То, что я ищу помощи, - это формулирование ее ценности для команды программистов, аналитиков, менеджеров и тестировщиков. С помощью автоматических тестов я не думаю, что мне нужно проводить различие между модульными тестами (например, JUnit), BDD (например, JBehave, Fitness) и UI (Selenium, Watir), потому что я думаю, что все они обеспечивают одинаковую ценность (но не стесняйтесь написать ответ, который не согласен :))

Ниже приведен список, который я определил, я ищу ответы, которые помогут расширить или уточнить:

1. Экономия времени и средств : написание автоматических тестов может занимать больше времени, чем письменные тесты. Однако, учитывая, что тесты выполняются несколько раз, предельная работа (т. Е. Затраты / время) для выполнения автоматических тестов на несколько порядков меньше. То, что автоматизированные тесты дешевы, облегчает изменение системы с течением времени.
2. Документация : нет лучшего способа узнать, как работает система, чем ее тесты. Любая другая документация обычно устарела с момента ее написания, но тесты (по крайней мере, те, которые прошли) показывают, как все работает на самом деле. Это верно как для конечного пользователя, так и для документации API.
3. Качество кода : тестовая запись заставляет вас:
   • считать клиентов, потому что тесты являются клиентом
   • ломает зависимости, где тестирование кода часто означает выяснение того, как сделать этот код не требующим доступа к какой-либо другой большой системе

Несколько моих мыслей:

1. Будьте честны, что написание автоматических тестов займет больше времени. Если вы работаете с модульным TDD (который я бы рекомендовал в качестве отправной точки, если вы собираетесь инвестировать в автоматизированное тестирование), вы можете ожидать около 30% дополнительного времени, необходимого для написания кода функции. Ключевым моментом здесь является объяснение того, что эти дополнительные 30% (которые, вероятно, выше, чем 30% в начале, когда ваша команда учится писать хорошие тесты) - это инвестиции, созданные для экономии затрат с течением времени. Как и в случае с TDD на уровне устройства, дизайн вашей системы слабо связан и обладает высокой связностью, что делает вашу систему адаптируемой к изменениям во времени. Новые требования и неожиданные ошибки всегда требуют изменений в вашей системе,
2. Существует много споров о значении тестов уровня Acceptance и уровня пользовательского интерфейса, учитывая количество времени, которое требуется для написания этих тестов, сколько времени требуется для их запуска и сколько им требуется обслуживания. Я бы рекомендовал прочитать эту статью Джеймса Шора об этом.
3. В мире автоматизированного тестирования есть хорошие и плохие способы сделать это. Если вы предоставляете автоматизированное тестирование своему руководству, я бы рассказал о том, как вы планируете обучить свою команду написанию хороших тестов. «Искусство юнит-тестирования» Роя Ошерова, «Эффективная работа с устаревшим кодом» Майкла Фезерса и «Искусство гибкой разработки» Джеймса Шора - все это замечательные книги, которые прямо или косвенно затрагивают эти темы. Вы также должны посмотреть на своего рода тренерскую или формальную подготовку. Это большое изменение.
4. С точки зрения ценности для бизнеса, # 2 и # 3 из ваших пунктов выше на самом деле служат вашей первой точке, так что я бы остановился на точке # 1 и поговорим о том, как # 2 и # 3 служат этой большей точке. Документация делает вашу систему более понятной, что ускоряет работу вашей команды. Качество кода делает вашу систему адаптируемой к изменениям, что ускоряет работу вашей команды. Для деловых людей это все о максимизации потока ценности от момента подачи идеи до момента, когда идея реализована в виде рабочего программного обеспечения.

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

Тестовые расходы

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

Тест Надежности

Этому компьютеру можно доверять для добросовестного выполнения одной и той же процедуры тестирования каждый раз. Человек склонен совершать ошибки и лениться.

Режимы сбоев тестирования компьютера также гораздо более очевидны - он зависал (отчеты о тестировании перестали появляться), имелась небольшая ошибка, которая вызвала ложный результат теста (снова запустите детерминированный тест, и результат будет другим). Если человек пропустит шаг и отметит «ОК», как мы можем сказать?

Испытание на прочность

Для запуска автоматизированный тест должен быть конкретным артефактом (например, фрагментом кода) и, естественно, включен в другие артефакты разработки программного обеспечения - в исходный репозиторий. Ручной тест может быть разработан тестером на листе бумаги для заметок и никогда не оформляться. Бизнесу, скорее всего, понадобятся процессы, чтобы этого не происходило.

Значение теста

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

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

Мое мнение таково, что модульные / интеграционные тесты являются наиболее важными, в то время как если вы применяете некоторый шаблон пользовательского интерфейса, такой как MVC, этого достаточно для большинства проектов. Я обычно проверяю все действия на своих контроллерах / докладчиках и оставляю привязку данных к представлениям.

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

Существует также точка непрерывной интеграции .

Еще одна вещь - нужно стремиться к тому, чтобы качество кода приводило к качеству продукта, ценности для бизнеса и удобству сопровождения - в противном случае это бессмысленно.

Я думаю, что вы должны вести с волшебными пунктами «более низкая стоимость» и «больше возможностей / единицу времени» / меньшего времени цикла.

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

Простота рефакторинга является большим фактором здесь. Имея хороший охват хорошим и читаемым (!!!) модульным тестом, вы можете реорганизовать свою систему, не беспокоясь о компрометации существующей функциональности.

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

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

Области я думаю, что, возможно, будет удача продавать его на

1. Модульные тесты могут занять место многих разработчиков, где вы создаете приложение, чтобы получить доступ к области для отладки / тестирования, не проходя все входы в систему / меню.

2. Тесты позволяют вам настраивать и легко повторять проблемные ситуации - не тратя много времени на настройку тестовых данных (особенно с использованием приличной системы насмешек)

3. Когда вы создаете наборы тестов BDD и UI - вы получите гораздо более быстрый ответ, если есть простые перерывы, чем ожидание в следующий раз, когда тестер смотрит на это

4. Тесты BDD и UI позволяют избежать повторного нажатия кнопок, чтобы проверить все аспекты, на которые могли повлиять ваши изменения, и избавить вас от необходимости запоминать все области.

5. Автоматические сборки часто подсвечиваются, когда кто-то забыл проверить код

6. Тесты помогут вам избежать повторного появления ошибок.

7. Модульные тесты и приличный макет будут означать меньше взаимосвязанного кода и будут легче решаться

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

Кто-то должен поверить, что есть проблема, прежде чем он примет предложенное решение этой проблемы.

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

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

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

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

Аргумент документации, который вы предоставляете, не очень хорош. Разница между поддержанием тестов в актуальном состоянии и документации в актуальном состоянии - просто привычка.

«То, что я ищу помощи, - это формулирование ее ценности для команды программистов, аналитиков, менеджеров и тестировщиков. С помощью автоматических тестов я не думаю, что мне нужно проводить различие между модульными тестами (например, JUnit), BDD ( например, JBehave, Fitness) и UI (Selenium, Watir), потому что я думаю, что все они имеют одинаковую ценность (но не стесняйтесь писать ответ, который не согласен :)) "

Хорошо, я приму этот вызов;)

В основном я работаю с программистами и QA, и мои инструменты - это ruby, rails, testunit, rspec, jasmine и selenium.

Инструменты BDD / TDD rspec и testunit являются частью программирования. Вы не разбиваете их и не говорите о них отдельно с руководством, вы не откладываете их из-за нехватки времени, вы включаете их во все свои оценки времени. Если вас толкают, спросите, сколько у вас есть времени, чтобы объяснить им информатику и программирование. Я не использую эти тесты для внешнего интерфейса

GUI / UI / жасмин / Селен. Это разные. Я сделал это людьми QA, у которых есть опыт программиста. Мы стараемся, чтобы тесты были написаны как можно более надежными и основанными на контенте, а не на макете. (Возможно, новая) стоимость этого должна быть объяснена как смещенная стоимость . Вместо того, чтобы платить с испорченным программным обеспечением, потерянными клиентами и дорогостоящими исправлениями позже, вы платите намного меньше (относительно) сейчас с помощью нескольких простых приемов.

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

Я всегда рекомендую разделить ваши тесты на 4 группы (более подробно здесь ). Оставайтесь со мной здесь, и я пойму, как это поможет вам продать тестирование другим в данный момент.

1. Тесты вашей основной функциональности . То есть для инструмента мониторинга веб-сайтов это будут тесты предупреждений, которые должны срабатывать для веб-сайтов, которые вы отслеживаете. Эти тесты удостоверяются, что этот материал никогда не ломается.
2. Дымовые тесты всего вашего приложения . Например, используя Selenium для навигации по всем ссылкам / кнопкам в веб-приложении и убедитесь, что на сервере нет ошибок. Эти тесты позволят вам не тратить время тестировщиков на явно поврежденные сборки.
3. Тесты любого хрупкого кода . То есть, для этого старого модуля никто никогда не хочет трогать, или сложный кусок кода, который, кажется, всегда содержит ошибки.
4. Тесты, которые разработчики хотели написать, чтобы поддержать их работу . Потому что иногда тесты полезны, когда вы что-то пишете, но не попадаете в вышеперечисленные категории.

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

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