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

25

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

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

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

Ответы:

21

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

  1. Будьте честны, что написание автоматических тестов займет больше времени. Если вы работаете с модульным TDD (который я бы рекомендовал в качестве отправной точки, если вы собираетесь инвестировать в автоматизированное тестирование), вы можете ожидать около 30% дополнительного времени, необходимого для написания кода функции. Ключевым моментом здесь является объяснение того, что эти дополнительные 30% (которые, вероятно, выше, чем 30% в начале, когда ваша команда учится писать хорошие тесты) - это инвестиции, созданные для экономии затрат с течением времени. Как и в случае с TDD на уровне устройства, дизайн вашей системы слабо связан и обладает высокой связностью, что делает вашу систему адаптируемой к изменениям во времени. Новые требования и неожиданные ошибки всегда требуют изменений в вашей системе,
  2. Существует много споров о значении тестов уровня Acceptance и уровня пользовательского интерфейса, учитывая количество времени, которое требуется для написания этих тестов, сколько времени требуется для их запуска и сколько им требуется обслуживания. Я бы рекомендовал прочитать эту статью Джеймса Шора об этом.
  3. В мире автоматизированного тестирования есть хорошие и плохие способы сделать это. Если вы предоставляете автоматизированное тестирование своему руководству, я бы рассказал о том, как вы планируете обучить свою команду написанию хороших тестов. «Искусство юнит-тестирования» Роя Ошерова, «Эффективная работа с устаревшим кодом» Майкла Фезерса и «Искусство гибкой разработки» Джеймса Шора - все это замечательные книги, которые прямо или косвенно затрагивают эти темы. Вы также должны посмотреть на своего рода тренерскую или формальную подготовку. Это большое изменение.
  4. С точки зрения ценности для бизнеса, # 2 и # 3 из ваших пунктов выше на самом деле служат вашей первой точке, так что я бы остановился на точке # 1 и поговорим о том, как # 2 и # 3 служат этой большей точке. Документация делает вашу систему более понятной, что ускоряет работу вашей команды. Качество кода делает вашу систему адаптируемой к изменениям, что ускоряет работу вашей команды. Для деловых людей это все о максимизации потока ценности от момента подачи идеи до момента, когда идея реализована в виде рабочего программного обеспечения.
Брайан Гейхслер
источник
1
+1 хороший ответ. Интересная ссылка на статью Джеймса Шора. Я бы добавил «Чистый кодер » Роберта Мартина в ваш список книг. Я думаю, что разработанные тесты пользовательского интерфейса должны охватывать счастливые пути, в то время как QA (если он существует) записывает исключения. Модульные тесты должны действительно решать исключительные случаи
orangepips
@orangepips - Спасибо за рекомендацию книги. Одним из недостатков этого пользовательского интерфейса является удачный путь, а затем модульные тесты, охватывающие исключения, заключающиеся в том, что эти модульные тесты труднее написать, если вы не проводите модульное тестирование для всего. Модульное тестирование помогает повысить тестируемость вашего приложения, поддерживая низкий уровень связи, в то время как тесты пользовательского интерфейса не требуют, чтобы код под ним был слабо связан.
предназначенный для написания юнит-тестов должен охватывать все.
orangepips
1
@ orangepips - я не согласен. «Уровень качества» / Приемочные тесты должны проверять все, что имеет значение для пользователя, т. Е. Счастливые пути и альтернативные сценарии. В модульных тестах часто используются макеты, заглушки и подделки ... это означает, что существует вероятность того, что модульный тест «счастливого пути» пройдет, но когда все компоненты собраны вместе, сквозной тест «счастливого пути» может завершиться неудачей. Это слишком большой шанс остаться на произвол судьбы.
Гишу
2
@orangepips - Мое возражение было связано с разделением QA / Dev Exceptions / Happy. Модульные тесты существуют, чтобы убедиться, что вы делаете это правильно. Тесты QA / Acceptance существуют, чтобы убедиться, что вы строите правильную систему. Поэтому все сценарии, которые имеют отношение к бизнесу (например, срок действия кредитной карты истек), должны быть проверены QA, прежде чем они заклеймят ее готовой к отправке. Рекомендую автоматизировать приемочные испытания - автоматизировать скучные, рутинные вещи на 80% +. Завершите это с помощью неординарного ручного тестирования без сценариев.
Гишу
9

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

Taft
источник
7

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

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

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

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

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

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

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

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

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

Фил Миллер
источник
+1 за понятие отчетности и за ссылку в джоулях.
Апельсины
«Этому компьютеру можно доверять для добросовестного выполнения одной и той же процедуры тестирования каждый раз». Стоит помнить, что некоторые люди обнаруживают некоторые ошибки, которые делают что-то неожиданным образом. Довольно часто другой тестер выполняет один и тот же набор инструкций по-разному. Это хорошо, так как увеличивает охват тестирования, поэтому, хотя автоматизация тестирования экономит время и является отличным способом проверки ожидаемых отказов и регрессий, она не может полностью заменить тестирование на людях.
В этом случае представляется предпочтительным дать людям-тестировщикам общие списки областей, которые нужно исследовать и что попробовать, а не подробные инструкции, которые они должны точно повторять.
Фил Миллер
4
@TafT: только бедные или безрассудные люди обходятся без ручного тестирования, но самое ценное ручное тестирование, которое я считаю, скорее исследовательское, чем написанное в природе. Таким образом толчок для автоматизации того, что может быть.
orangepips
5

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

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

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

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

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

Денис Биондик
источник
+1 за непрерывную интеграцию с технической точки зрения. Но я не уверен, как я вижу ваши предложения, облегчающие разговор с нетехническим персоналом (например, аналитиками). Кроме того, что вы думаете о проверке в нескольких браузерах и операционных системах?
orangepips
Ну, я могу просто сказать свою сторону с точки зрения разработчика, об аналитиках - я не совсем понимаю их роль в действительно больших проектах - так что никаких реальных советов там нет. Насчет кросс-браузерных кросс-ОС тестов тоже не было.
Денис Биондик
2

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

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

Gishu
источник
+1 за хороший пост в блоге, хотя эти моменты будут хорошо подняты здесь. Меня поразило то, что у меня нет программистов, которые просто проходят через движения. Тогда как вы предлагаете продвигать качество или хотя бы избегать атмосферы, которая мешает этому?
orangepips
хорошая ссылка. Созревание любого программного процесса занимает много работы. Я думаю, что важным следствием также является сокращение текучести кадров, поэтому у вас достаточно людей с памятью организации и доверием, чтобы продвигать что-то подобное.
orangepips
1

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

Morten
источник
это отличается от моей точки № 1?
orangepips
@orangepips: Нет, я пропустил эту часть. Извините: о) Тем не менее, это важно подчеркнуть
Мортен
1

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

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

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

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

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

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

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

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

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

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

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


источник
+1 за комментарий религии. Я думаю, что есть вопрос определения того, для чего стоит писать автоматизированные тесты, и ясно, что ответ - это не все. OTO, я думаю, нам лучше провести хотя бы несколько автоматических тестов. Возможно, настоящим ключом является признание того, что, по крайней мере, в моей организации узким местом SDLC является QA. Поэтому мои собственные усилия направлены на то, чтобы сгладить эту кривую усилий, заставив развитие взять на себя часть этой ответственности.
orangepips
По отношению к номеру 3) это позволяет строить статистику и формировать отчеты; заметно может быть большой пункт продажи. На этой неделе введение функции X привело к сбою 10 тестов, которые мы обнаружили за время Y, поскольку автоматическое тестирование является хорошей «победой» для проекта, а также помогает документировать риски, связанные с внедрением новых функций в будущем.
1

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

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


источник
1
так как вы думаете, откуда эта информация?
orangepips
0

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

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

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

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

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

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

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

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

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

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

Майкл Даррант
источник
0

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

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

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

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

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

Робин
источник