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

10

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

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

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

ming_codes
источник
5
Я присоединился к 10-летнему крошечному стартапу и был первым, кто действительно добавил тесты, которые проводятся ночью. Не потому, что я был гением, но это был первый раз, когда менеджер (также кодер) осознал, что пора добавить их, и что у них наконец есть рабочая сила. Свертываниям часто приходится сначала выживать, а потом совершенствоваться. Конечно, этот запуск был начат не технарями, так что эту функцию нужно было «включить».
Работа
5
10-летний стартап ...?
Пап
Дилберт сказал : «Если передовая практика принята всеми в отрасли, то передовая практика становится посредственностью». Я думаю, это правда, хех.
ming_codes
10-летний стартап ... они должны использовать Java: дизайн 3 года + 7 разработка :) просто шучу (кстати, я - разработчик Java)
nuvio

Ответы:

11

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

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

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

maple_shaft
источник
Время выхода на рынок - это всего лишь миф. Поздние участники рынка могут сдуть существующих игроков: friendster> myspace> facebook.
Джори Себрехтс
@JoeriSebrechts Я прочитал интересную статью о прогрессе программного обеспечения и как это связано с успехом поздних участников. Есть переменные в игре, безопасный период для новичка с подобным решением равен количеству времени для пользовательской базы программного обеспечения, чтобы преобразоваться из Ранних Усыновителей в Обычных Пользователей. Подобное решение, конечно, означает функции, которые похожи и не являются новаторскими по сравнению с первыми на рынке (например, Facebook был новаторским по сравнению с MySpace). Как только критическая масса Ранних Усыновителей достигнута, обычные пользователи начинают мигрировать.
maple_shaft
12

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

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

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

Майк Баранчак
источник
4

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

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

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

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

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

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

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

Марк Бут
источник
1

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

Франсиско Вальдес
источник
1

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

Ryathal
источник
Вы можете быть удивлены, узнав, что лучшие практики не так широко распространены в отрасли. thedailywtf.com
Гари Уиллоуби
@ Гэри - это скорее индустриальная теория или часть утопического мира, где проекты имеют реалистичные сроки, а html имеет семантическое значение, а менеджеры признают, что им не хватает технических знаний, которые помогли бы им принимать более правильные решения ...
Ryathal
«Лучшие практики» обычно означают делать то же, что и все остальные, и получать средний результат. Среднестатистическая компания работает достаточно хорошо, но средний технологический стартап недостаточно далеко, чтобы впечатляюще потерпеть крах.
Дэвид Торнли
1
@DavidThornley - Нет, я думаю, что «Лучшая практика» - это то, что большинство людей считают, что они должны делать, независимо от того, есть ли у них время, энергия или одобрение руководства для этого. * 8 ')
Марк Бут
@Mark Бут: Как правило, когда я слышал фразу, это означает, что я сказал. YMMV, конечно. Тем не менее, Ryathal относится к миру, где проекты имеют реалистичные сроки, и это не обязательно возможно в бизнесе. Выпуск продукта с опозданием на два месяца может быть несущественным или фатальным (особенно для стартапа, которому может грозить нехватка денег), и, к сожалению, часто есть веское экономическое обоснование для получения чего-то, что в основном работает как можно скорее. Мне трудно поверить в «лучшие практики», которые могут обернуть компанию.
Дэвид Торнли
1

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

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

Том Сквайрс
источник
1

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

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

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

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

jfrankcarr
источник