Как проводятся программные тесты в технических стартапах?

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

Так что это подняло вопросы. Должны ли технические стартапы писать автоматизированные тесты? Если так, они сделаны так же, как крупные компании-разработчики программного обеспечения? (тест на дым, регрессионный тест и т. д.) Лучше всего, если вы сможете сослаться на некоторые исследовательские статьи на эту тему ... так как я не смог найти ни одной из них самостоятельно.

(Должен признать, что хотя я все еще в начале своей карьеры, но мне еще предстоит увидеть стартап, который серьезно настроен на написание автоматических тестов)

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

Сайты социальных сетей и мобильные приложения компания больших пузырей сейчас, и они отчаянно конкурентоспособны. Иногда разница между продолжением жизни через 4 месяца и 5 месяцев означает, что вы проиграли.

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

Тестирование программного обеспечения не является религией. Это просто очень хорошая идея.

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

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

В течение многих лет, работая в небольших компаниях и стартапах, я не мог понять, что у меня «не было достаточно времени для написания модульных тестов для моего кода» .

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

Недавно мне предложили использовать Test Driven Development, и я обнаружил, что это полное откровение .

Теперь я твердо убежден, что у меня «нет времени, чтобы не писать юнит-тесты» .

По моему опыту, разрабатывая с учетом тестирования, вы получите более чистые интерфейсы, более сфокусированные классы и модули и, как правило, более твердый , тестируемый код.

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

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

Речь идет не о том, кто должен заниматься тестированием программного обеспечения, тестирование программного обеспечения - это своего рода философия разработки программного обеспечения. Тестирование программного обеспечения устанавливает основу для хорошего качества программного обеспечения, и при запуске качество программного обеспечения является бонусом, когда приобретение крупной фирмой не за горами;)

Лучшие практики распространены в отрасли, делаете ли вы бабушку веб-сайт или создаете систему наведения для спутника. За ними всегда должны следовать те, кто хочет считать себя профессионалом, поэтому их называют ЛУЧШИМИ практиками.

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

Это не только для стартапов. У одного из наших поставщиков ИТ-подрядчиков даже нет тестовой среды. Все сделано прямо, чтобы жить, и это большая многонациональная компания по разработке программного обеспечения (страшно!)

Должны ли они? Да. Делают ли они это на практике, а не так часто, как следовало бы.

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

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

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