Комментарии 34
думаю для некоторых проектов это убийственно. Во время разработки продукта наверняка проводилось множество исследований, перебирались варианты. А тут можно глядя на тесты написать альтернативу, самой собой дешевле оригинала.
Большое количество проектов ценны не своими ноу-хау (которых может не быть вообще), а инфраструктурой и раскрученным брендом. Стоимость софта в таком случае может теряться на фоне капитальных затрат и рекламной кампании.
А вот тесты тем не менее могут быть ценны.
А вот тесты тем не менее могут быть ценны.
Одним из важнейших качеств продукта является момент выхода его на рынок. Если кто-то сейчас сделает более дешевую и качественную альтернативу, например, Windows, он всё-равно ничего никому не продаст.
Чтобы выйти на рынок нужно или превосходить существующий продкут на порядок (что невозможно при копировании), либо делать продукт нишевым (здесь копирование тоже почти ничего не даст)
Чтобы выйти на рынок нужно или превосходить существующий продкут на порядок (что невозможно при копировании), либо делать продукт нишевым (здесь копирование тоже почти ничего не даст)
Я думаю многие компании побояться это делать, ведь тесты открывают большой пласт информации для поиска проблем безопасности
С другой стороны, если приложить к тестам премию за найденную проблему в безопасности, то ситуацию можно даже улучшить.
Давно известно, что «Security through obscurity» — провальная затея в плане обеспечения безопасности. Чем больше ревьюверов, тем лучше. Конечно, нужна грамотно построенная программа вознаграждения, но она нужна в любом случае.
Соглашусь с предыдущими ораторами но все же поддержу автора. Open-test — это гениально! Без поддержки крупных игроков само по себе не раскрутится, что жаль, но мысль мне лично очень понравилась.
P.S. в сегменте B2B — очень востребованная тема была бы. Для всяких либ и встраиваемых решений.
P.S. в сегменте B2B — очень востребованная тема была бы. Для всяких либ и встраиваемых решений.
Я бы добавил еще один момент, который не описан в статье:
При наличии открытых тестов диалог с разработчиком касательно багов может разительно упроститься. Вместо того, чтобы разбивать стену лбом в общении с первой линией поддержки, проще закоммитить проваливающийся тест и завести на него тикет.
Самим же разработчикам это будет на руку, потому что не придется гадать, что же пошло не так. Плюс получаем армию тестировщиков, которые расширяют систему тестов и, внезапно, еще и платят за это деньги!
В общем, мечты, мечты…
При наличии открытых тестов диалог с разработчиком касательно багов может разительно упроститься. Вместо того, чтобы разбивать стену лбом в общении с первой линией поддержки, проще закоммитить проваливающийся тест и завести на него тикет.
Самим же разработчикам это будет на руку, потому что не придется гадать, что же пошло не так. Плюс получаем армию тестировщиков, которые расширяют систему тестов и, внезапно, еще и платят за это деньги!
В общем, мечты, мечты…
Идея хорошая, но результаты голосования говорят сами за себя: это вряд ли принесет прибыль компаниям, значит вряд ли кто-то будет реализовывать идею («ведь и так берут!»).
Исключение — SDK, тут может сработать.
Исключение — SDK, тут может сработать.
Меня посещала обратная идея — открывать исходники, но скрывать тесты. Если исходников много, то без тестов они бесполезны, я иногда склоняюсь к мысли, что тесты ценнее исходников.
Есть ещё такой тип проприетарного ПО, которое пишется под конкретную систему или заказчика. Я как раз такое разрабытываю — это ПО для машинного зрения (рентгеновский неразрушающий контроль) в промышленности. Иногда вообще на стороне заказчика программировать приходится, подгоняя софт под нужды прямо на месте. Стоит очень дорого, но заказчик получает именно то, что ему нужно. Низкоуровневые юнит тесты, естественно не открываются (да и не нужны они заказчику), а основным документов является акт приёмо-сдаточных испытаний (там своя методика тестирования, но это фактически UAT). Дальше покупатель не остается один-на-один — система с софтом ставится на гарантию (иногда расширенную на несколько лет), и явные ошибки исправляются бесплатно, а новые фишки добавляются за деньги.
Автор, добавьте еще такой опрос: из двух конкурирующих решений с близким функционалом, какое вы бы купили — с открытыми тестами или без таковых?
Что-то мне вспомнился Oracle, который взял одну свободную БД и закрыл к ней тесты.
Хорошо написанные тесты содержат в себе почти всю архитектуру проекта. Мне кажется, имея тесты, очень просто написать под них реализацию, намного проще, чем писать с нуля.
Другое дело, что компания может попробовать защищать себя от этого юридическими способами (ну, раз Оракл смог доказать, что реализации API джавы от Гугла незаконна, то и в данном случае это, наверное, возможно).
Другое дело, что компания может попробовать защищать себя от этого юридическими способами (ну, раз Оракл смог доказать, что реализации API джавы от Гугла незаконна, то и в данном случае это, наверное, возможно).
Вроде как суд между гуглом и ораклом закончился как раз обатным: So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical (https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.)
НЛО прилетело и опубликовало эту надпись здесь
Идея не плоха, но идея без реализации ничего не стоит. Вот если бы Вы привели живой пример такой схемы, можно было бы оценить такой подход. А так… Извините, нет.
Автор видимо забыл для кого пишутся программы. Пользователю как правило не важны технические характеристики ПО, софт либо работает либо нет. Я руководитель отдела в компании, и мне в конце месяца в прогнозе расходов на следующий месяц пришли бумаги на набор софта от майкрософта на 300 тысяч. Я пошел разбираться: откуда столько и оно нам надо ли? Пришел к руководителю группы ХХХХ, он мне на пальцах объяснил что нам надо то-то и то-то, есть альтернативные продукты YYY и ZZZ но в них функционала не хватает. Еще есть системный администратор, который сказал «я эту штуку от майкрософта разверну за 5 минут».
А теперь вопрос: зачем мне ваши тесты? У меня в компании нет программиста который мог бы оценить их результаты, да и не важны они мне: есть софт, который делает то, что необходимо компании и то, что он иногда будет подвисать или мусолить складскую логистику вместо 5 минут целых 6 — тоже погоды не сделает (хотя, конечно, я допускаю что есть вещи где скорость обработки важна, но для 99% потребителей какого-либо софта это не важно — потому что более быстрый аналогичный «софт-конкурент» считает всего на 5% быстрее, а стоит на 25% дороже).
Ваша идея целиком и полностью программистская и для программистов же придуманная. Обычным пользователям никакой пользы пока не видится.
А теперь вопрос: зачем мне ваши тесты? У меня в компании нет программиста который мог бы оценить их результаты, да и не важны они мне: есть софт, который делает то, что необходимо компании и то, что он иногда будет подвисать или мусолить складскую логистику вместо 5 минут целых 6 — тоже погоды не сделает (хотя, конечно, я допускаю что есть вещи где скорость обработки важна, но для 99% потребителей какого-либо софта это не важно — потому что более быстрый аналогичный «софт-конкурент» считает всего на 5% быстрее, а стоит на 25% дороже).
Ваша идея целиком и полностью программистская и для программистов же придуманная. Обычным пользователям никакой пользы пока не видится.
Идея действительно скорее для B2B, чем для массового рынка. Но даже в Вашем примере этому можно найти применение: руководитель группы ХХХ может написать «тесты» в свободной форме, просто словами — мол, надо чтобы продукт делал это и вот это — и отправить их разработчикам YYY и ZZZ, с комментарием, мол, если пройдёте эти тесты — купим ваш продукт. А уже YYY и ZZZ могут (если хотят денег) реализовать данный функционал, перевести свободную форму описания тестов в код — и продемонстрировать результат прохождения тестов.
Идея слишком теоретическая, я, например, не представляю себе как можно открыть все тесты к продукту. Так как тесты пишутся и для компонентов которые не экспортируются из библиотек. В итоге будет лишь какой-то ограниченный набор тестов, не требующий раскрытия внутренностей продукта.
Эта статья носит чисто теоретический характер или Вы планируете у себя внедрять практику открытых тестов?
надо чтобы продукт делал это и вот это — и отправить их разработчикам YYY и ZZZЭто можно и без тестов. Если заранее известно как продукт будет использоваться и есть полноценная триальная версия продукта, то на ней можно проверить обладает ли продукт необходимым функционалом/производительностью и если нет, то написать разработчикам пожелание.
Эта статья носит чисто теоретический характер или Вы планируете у себя внедрять практику открытых тестов?
Разумеется, руководитель отдела не будет запускать тесты. Но он будет прислушваться к мнению экспертов (вот как вы слушали руководителя группы и сисадмина). А они уже при помощи тестов смогут лучше оценить новый продукт.
Великолепная идея. Нету тестов — пошёл нафиг!
Автомобили же тестируют, и даже хвастаются прохождением тех или иных тестов. От банальных на скорость, на вредный выхлоп, до краштестов.
Автомобили же тестируют, и даже хвастаются прохождением тех или иных тестов. От банальных на скорость, на вредный выхлоп, до краштестов.
Идея очень интересная для всех тех продуктов, которые покупаются для разработчиков. Закрытые СУБД, ИС, брокеры очередей, библиотеки компонентов. Особенно полезны могут быть нагрузочные тесты на инфраструктуре покупателя.
Если бы я продавал какой-нибудь «крутой пивот» или «дешевый и сердитый SSO для ентерпрайза», я бы задумался над этим вопросом…
Другой вопрос, что почти ни у кого нет такой культуры, чтобы иметь изолированные тесты :-). Или требуется тестовая инфраструктура, которую невозможно воссоздать за пределами компании, или тестовый билд с дополнительными API, или пачка дополнительных тестовых сервисов, или сам запуск тестов — процедура нетривиальная.
Если бы я продавал какой-нибудь «крутой пивот» или «дешевый и сердитый SSO для ентерпрайза», я бы задумался над этим вопросом…
Другой вопрос, что почти ни у кого нет такой культуры, чтобы иметь изолированные тесты :-). Или требуется тестовая инфраструктура, которую невозможно воссоздать за пределами компании, или тестовый билд с дополнительными API, или пачка дополнительных тестовых сервисов, или сам запуск тестов — процедура нетривиальная.
Отдавать тесты на публику, как по мне, не очень хороший вариант по многим причинам (безопасность, упрощение разработки конкурирующего продукта и т.п.). Компромиссом может стать появление независимых экспертов, которым разработчик может передать тесты под NDA, и которые будут выдавать свою оценку качеству продукта, понятную для конечных пользователей.
Также более мягкий вариант — выдавать только нагрузочные тесты, использующие внешние интерфейсы. Они позволят оценить продукт на близких к реальным условиях. При этом живые пользователи не пострадают, как это обычно происходит, плюс ничего скрытого никто не увидит.
Также более мягкий вариант — выдавать только нагрузочные тесты, использующие внешние интерфейсы. Они позволят оценить продукт на близких к реальным условиях. При этом живые пользователи не пострадают, как это обычно происходит, плюс ничего скрытого никто не увидит.
Идея неплохая, но как бы тут не повторилась история с Фольксвагеном…
Как программист работавший в разных компаниях разрабатывающих проприетарное ПО, скажу, что не всегда тесты пишутся действительно качественно, случается, что они пишутся «чтоб было». А как писали выше, у заказчика вряд ли будут специалисты, средства и время на то, чтоб провести анализ этих тестов (учитывая, что тесты могут использовать какие-то фреймворки, запутанные патерны, инициализации и т.д. и т.п.). Есть компании, например, медицинские, которые сами пишут приёмочные тесты, и не примут релиз пока каждый тест не пройдёт — им это критично, они готовы за это платить. А если для бизнеса поломка продукта не критична, то выбирая продукт бизнес будет ориентироваться на известность, количество существующих клиентов, функционал и цену, а уже потом на наличие тестов. Машины, самолёты, оружие, медицинское оборудование — открыто тестируется просто потому, что их выход из строя очень критичен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Свободу тестам