Как начать тестирование в антикультуре? [закрыто]

Я должен сделать признание: формализованное автоматическое тестирование никогда не было частью моего опыта программирования. Сейчас я работаю в очень большой компании со многими разработчиками (большинство из них веб- разработчики того или иного рода), и очевидно, что большинство из них тоже не тестируют *. (* Я не буду продолжать говорить формально ; пожалуйста, сделайте вывод.)

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

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

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

Я лично сделал это с большим успехом. Ключевые факторы успеха:

• Получите (предварительную) поддержку управления. Преимущества автоматических тестов хорошо документированы и должны убедить любого менеджера хотя бы попробовать его. Это включает в себя поиск места в VCS и сервере сборки, потому что
• Автоматизированные тесты дают полную ценность только в том случае, если они выполняются часто и автоматически, так что вы скоро узнаете о проблемах и не будете полагаться на людей, не забывших их запускать. Вам нужен сервер сборки, который запускает их хотя бы ежедневно. Это может быть старая рабочая станция. Дженкинс очень мало работает, чтобы начать работать.
• Подавать пример. Пишите тесты, рассказывайте о преимуществах, которые они вам предоставляют, и когда они обнаруживают ошибки, допущенные другими разработчиками, говорите об этом с точки зрения того, как они были защищены от потенциально гораздо большего смущения.
• Перейти на низко висящие фрукты. Некоторые части приложения будет сложно протестировать, другие - просто. Некоторые будут крепкими, другие хрупкими. Написание тестов для хрупких, но простых в тестировании деталей обеспечивает наибольшую ценность в кратчайшие сроки.
• Посмотрите, можете ли вы написать повторно используемые тесты, например, те соглашения о тестировании или функции, которые должны иметь все модули (веб-страницы, службы REST и т. Д.), Но о которых часто забывают.

Без поддержки управления вы мертвы в воде. Руководство будет утверждать, что вы не выполняете стоящую работу, вы будете оштрафованы за ваши отзывы и, наконец, вас уволят. Есть способы привлечь руководство, чтобы увидеть, что раннее тестирование обходится им дешевле и все такое. Можно изменить культуру, но вы кладете шею на плаху.

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

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

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

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

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

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

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