Современный мир ПО очень черно-бело разделён на два лагеря: либо ты opensource-приложение, либо закрытое проприетарное. Нет, есть, конечно, и разные лицензии в открытых проектах и какие-то подвижки закрытых продуктов выкладывать в опенсорс свои части (привет, Google, Facebook, Microsoft). Но всё это не меняет сути дела в принципе — если ты берёшь открытый продукт, то видишь всё, что у него внутри, можешь это оценить и решить, стоит связываться или нет. Если ты хочешь приобрести закрытое ПО, то всё, что остаётся — верить заливающимся соловьями продажникам фирмы-производителя, как у них там всё внутри классно, надёжно, быстро и современно. Ну, вы наверняка были на какой-нибудь такой конференции или презентации, где выходил человек в костюме и час втирал о том, как же всё стало лучше в версии 18.1.1 их продукта и почему его нужно покупать прямо сейчас. Ещё часто можно недельку погонять ограниченный trial-режим, что даст ответ ровно на 1 вопрос: «как работает ограниченный trial-режим в течение недели?». Покупатель всегда остаётся один-на-один с решением «взять и рискнуть» или «не связываться». Объективных данных для принятия решения мало. При этом их, казалось бы, больше и не станет — производитель закрытого продукта не выложит исходники, поскольку именно они составляют коммерческую ценность.Казалось бы — тупик? А давайте рассмотрим следующую мысль — что если мы
1. Производитель показывает, что тесты у него есть. Не то чтобы это автоматом говорило, что продукт хороший, но вот если тестов совсем нет — это уже с полной гарантией говорит, что продукт плохой. Т.е. от оценки «а чёрт его знает, как его там кто тестировал» мы переходим к оценке «так, что-то люди вроде бы пытались тестировать».
2. Производитель не открывает исходный код своего продукта. Да, тесты могут кое-что рассказать об устройстве отдельных модулей и их взаимодействии, но давайте смотреть правде в глаза — дебаггер и дизассемблер раскажут не меньше.
3. Потенциальный покупатель может оценить качество кода тестов. Да, это не код самого продукта, но пишутся тесты обычно теми же людьми, в том же стиле, с тем же отношением к стилю, качеству кода, именованию сущностей, с той же тщательностью. Если у покупателя нет навыков оценить качество кода — можно нанять стороннего консультанта для аудита.
4. Тесты, возможно, удастся даже запустить. Это, конечно, уже потребует от производителя некоторой дополнительной работы — выноса кода в отдельные изолированные компоненты, создание дополнительных моков. Но, скажите мне, что же тут плохого? Данный подход стимулирует писать хороший код продукта, а значит он идёт на пользу всем. Более того, если тесты можно запустить на реальном продукте — их можно использовать для диагностики ошибок, переписки с техподдержкой.
5. Тесты, возможно, удастся расширить для своих нужд. К примеру, есть тест, который проверяет сохранение 1000 документов в базу данных. А нам нужно гарантировать успешное сохранение 100 000 документов. Если задать вопрос производителю ПО, то вы услышите или «да, конечно всё будет работать!» (если попадёте на продажника) или «не знаю, не проверяли на таких количествах» (если попадёте на инженера). Оба ответа бесполезны. Если же у вас будет готовый тест для 1000 документов, вы легко измените его размерность и, запустив, узнаете ответ на свой вопрос.
6. Тесты могут служить документацией на продукт. Особенно это актуально для ПО, предоставляющее SDK для разработчиков. Одно дело читать скучную документацию и совсем другое — взять готовый код, запустить, начать править.
7. Производитель сможет наконец в лицензионном соглашении вместо позорных формулировок «ничего никому совершенно не гарантируется» писать хотя бы «гарантируется прохождение прилагаемых к продукту тестов». Это, согласитесь, значительно лучше, чем коты в мешках, которых нам предлагают сегодня.
8. Острота столкновений opensource и закрытого ПО станет менее кровавой. От «частично открытого» ПО у свидетеля секты GNU глаза наливаться кровью будут уже чуть меньше. Тут, конечно, многое зависит от толкования и пиара, но всё же шаг навстречу это лучше, чем нынешние прямые конфликты.
9. Будет о чём поговорить с пользователями. Многие команды маркетинга и пиара бьются над получением от пользователей адекватного фидбека, втягивание их в разговор, попытки продать дополнительные модули и техподдержку. К сожалению, начинать такие разговоры часто приходится с голого фундамента, беседа не клеится. И совершенно другое дело, когда разговор начинается уже предметно — с заваленного теста, с запроса на добавление фичи, с вопроса о том, почему вот здесь и здесь в тест передаются такие параметры, а не такие, «а где вообще проверяется вот этот случай?» и т.д… Когда разговор технических специалистов приведёт к локализации проблемы или необходимости разработки новой фичи — это будет уже хороший фундамент для обсуждения дальнейшей сделки.
Очень интересно ваше мнение по поводу возможности открытия кода тестов для проприетарного ПО.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (33)
jreznot
17.04.2016 21:00+7Я думаю многие компании побояться это делать, ведь тесты открывают большой пласт информации для поиска проблем безопасности
softaria
18.04.2016 09:36С другой стороны, если приложить к тестам премию за найденную проблему в безопасности, то ситуацию можно даже улучшить.
tangro
18.04.2016 10:30-1Давно известно, что «Security through obscurity» — провальная затея в плане обеспечения безопасности. Чем больше ревьюверов, тем лучше. Конечно, нужна грамотно построенная программа вознаграждения, но она нужна в любом случае.
gearbox
17.04.2016 21:17+7Соглашусь с предыдущими ораторами но все же поддержу автора. Open-test — это гениально! Без поддержки крупных игроков само по себе не раскрутится, что жаль, но мысль мне лично очень понравилась.
P.S. в сегменте B2B — очень востребованная тема была бы. Для всяких либ и встраиваемых решений.
Halt
18.04.2016 08:29+3Я бы добавил еще один момент, который не описан в статье:
При наличии открытых тестов диалог с разработчиком касательно багов может разительно упроститься. Вместо того, чтобы разбивать стену лбом в общении с первой линией поддержки, проще закоммитить проваливающийся тест и завести на него тикет.
Самим же разработчикам это будет на руку, потому что не придется гадать, что же пошло не так. Плюс получаем армию тестировщиков, которые расширяют систему тестов и, внезапно, еще и платят за это деньги!
В общем, мечты, мечты…
istui
17.04.2016 21:39+1Идея хорошая, но результаты голосования говорят сами за себя: это вряд ли принесет прибыль компаниям, значит вряд ли кто-то будет реализовывать идею («ведь и так берут!»).
Исключение — SDK, тут может сработать.softaria
18.04.2016 09:38+1И так берут пока нет альтернатив. А вот если один продукт откроет тесты, а его конкурент — нет, то, скорее всего, первый получит конкурентное преимущество.
mickvav
18.04.2016 09:49Вопросы сформулированы неправильно. Из двух конкурирующих решений я, например, купил бы покрытое открытыми тестами.
MonkAlex
18.04.2016 15:06+1Вся проблема в том, что решение о покупке принимаете не вы?
Открытые тесты слишком незначительный фактор, чтобы он влиял на продажи, имхо.
maxim_ge
17.04.2016 22:42+5Меня посещала обратная идея — открывать исходники, но скрывать тесты. Если исходников много, то без тестов они бесполезны, я иногда склоняюсь к мысли, что тесты ценнее исходников.
softaria
18.04.2016 09:39Исходники можно тупо украсть и выпустить свой продукт, не вложив ни копейки.
С тестами так не выйдет.
AndreyDmitriev
17.04.2016 23:12+2Есть ещё такой тип проприетарного ПО, которое пишется под конкретную систему или заказчика. Я как раз такое разрабытываю — это ПО для машинного зрения (рентгеновский неразрушающий контроль) в промышленности. Иногда вообще на стороне заказчика программировать приходится, подгоняя софт под нужды прямо на месте. Стоит очень дорого, но заказчик получает именно то, что ему нужно. Низкоуровневые юнит тесты, естественно не открываются (да и не нужны они заказчику), а основным документов является акт приёмо-сдаточных испытаний (там своя методика тестирования, но это фактически UAT). Дальше покупатель не остается один-на-один — система с софтом ставится на гарантию (иногда расширенную на несколько лет), и явные ошибки исправляются бесплатно, а новые фишки добавляются за деньги.
mickvav
18.04.2016 09:50+3Автор, добавьте еще такой опрос: из двух конкурирующих решений с близким функционалом, какое вы бы купили — с открытыми тестами или без таковых?
ChALkeRx
18.04.2016 10:20+3Что-то мне вспомнился Oracle, который взял одну свободную БД и закрыл к ней тесты.
VovanZ
18.04.2016 10:20Хорошо написанные тесты содержат в себе почти всю архитектуру проекта. Мне кажется, имея тесты, очень просто написать под них реализацию, намного проще, чем писать с нуля.
Другое дело, что компания может попробовать защищать себя от этого юридическими способами (ну, раз Оракл смог доказать, что реализации API джавы от Гугла незаконна, то и в данном случае это, наверное, возможно).softaria
18.04.2016 10:38Вроде как суд между гуглом и ораклом закончился как раз обатным: 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.)
VovanZ
19.04.2016 08:37Я точно не знаю, чем там всё закончилось, но Гугл вроде бы собирается переходить со своей реализации джавы на OpenJDK именно для того, чтобы избежать дальнейших попыток преследования со стороны Оракла.
softaria
19.04.2016 08:43Вроде одно другому не мешает. Суд выиграли, но могли решить подстраховаться.
barsuksergey
18.04.2016 10:20+1Из другого мира. Когда завод-производитель трубопроводной арматуры предлагает заказчику протестированную арматуру на давление-герметичность-состав материалов, это связано с законом. Либо с ГОСТом и другими стандартами, либо с договорными обязательствами. И это всегда ведёт к удорожанию арматуры. Китайцы, например, очень любят тесты обещать и писать в паспорте, но не делать.
Так что я за тесты. Это дополнительный хороший инструмент. Но если заказчику софта критично надо качество, и он готов платить, то он его получит.
zolt85
18.04.2016 10:21Идея не плоха, но идея без реализации ничего не стоит. Вот если бы Вы привели живой пример такой схемы, можно было бы оценить такой подход. А так… Извините, нет.
SlapUp
18.04.2016 10:21+2Автор видимо забыл для кого пишутся программы. Пользователю как правило не важны технические характеристики ПО, софт либо работает либо нет. Я руководитель отдела в компании, и мне в конце месяца в прогнозе расходов на следующий месяц пришли бумаги на набор софта от майкрософта на 300 тысяч. Я пошел разбираться: откуда столько и оно нам надо ли? Пришел к руководителю группы ХХХХ, он мне на пальцах объяснил что нам надо то-то и то-то, есть альтернативные продукты YYY и ZZZ но в них функционала не хватает. Еще есть системный администратор, который сказал «я эту штуку от майкрософта разверну за 5 минут».
А теперь вопрос: зачем мне ваши тесты? У меня в компании нет программиста который мог бы оценить их результаты, да и не важны они мне: есть софт, который делает то, что необходимо компании и то, что он иногда будет подвисать или мусолить складскую логистику вместо 5 минут целых 6 — тоже погоды не сделает (хотя, конечно, я допускаю что есть вещи где скорость обработки важна, но для 99% потребителей какого-либо софта это не важно — потому что более быстрый аналогичный «софт-конкурент» считает всего на 5% быстрее, а стоит на 25% дороже).
Ваша идея целиком и полностью программистская и для программистов же придуманная. Обычным пользователям никакой пользы пока не видится.tangro
18.04.2016 10:37+1Идея действительно скорее для B2B, чем для массового рынка. Но даже в Вашем примере этому можно найти применение: руководитель группы ХХХ может написать «тесты» в свободной форме, просто словами — мол, надо чтобы продукт делал это и вот это — и отправить их разработчикам YYY и ZZZ, с комментарием, мол, если пройдёте эти тесты — купим ваш продукт. А уже YYY и ZZZ могут (если хотят денег) реализовать данный функционал, перевести свободную форму описания тестов в код — и продемонстрировать результат прохождения тестов.
Hokum
18.04.2016 12:47Идея слишком теоретическая, я, например, не представляю себе как можно открыть все тесты к продукту. Так как тесты пишутся и для компонентов которые не экспортируются из библиотек. В итоге будет лишь какой-то ограниченный набор тестов, не требующий раскрытия внутренностей продукта.
надо чтобы продукт делал это и вот это — и отправить их разработчикам YYY и ZZZ
Это можно и без тестов. Если заранее известно как продукт будет использоваться и есть полноценная триальная версия продукта, то на ней можно проверить обладает ли продукт необходимым функционалом/производительностью и если нет, то написать разработчикам пожелание.
Эта статья носит чисто теоретический характер или Вы планируете у себя внедрять практику открытых тестов?
softaria
18.04.2016 10:42Разумеется, руководитель отдела не будет запускать тесты. Но он будет прислушваться к мнению экспертов (вот как вы слушали руководителя группы и сисадмина). А они уже при помощи тестов смогут лучше оценить новый продукт.
Eric50
18.04.2016 10:24Великолепная идея. Нету тестов — пошёл нафиг!
Автомобили же тестируют, и даже хвастаются прохождением тех или иных тестов. От банальных на скорость, на вредный выхлоп, до краштестов.
Scf
18.04.2016 10:56+1Идея очень интересная для всех тех продуктов, которые покупаются для разработчиков. Закрытые СУБД, ИС, брокеры очередей, библиотеки компонентов. Особенно полезны могут быть нагрузочные тесты на инфраструктуре покупателя.
Если бы я продавал какой-нибудь «крутой пивот» или «дешевый и сердитый SSO для ентерпрайза», я бы задумался над этим вопросом…
Другой вопрос, что почти ни у кого нет такой культуры, чтобы иметь изолированные тесты :-). Или требуется тестовая инфраструктура, которую невозможно воссоздать за пределами компании, или тестовый билд с дополнительными API, или пачка дополнительных тестовых сервисов, или сам запуск тестов — процедура нетривиальная.
batment
18.04.2016 12:50Отдавать тесты на публику, как по мне, не очень хороший вариант по многим причинам (безопасность, упрощение разработки конкурирующего продукта и т.п.). Компромиссом может стать появление независимых экспертов, которым разработчик может передать тесты под NDA, и которые будут выдавать свою оценку качеству продукта, понятную для конечных пользователей.
Также более мягкий вариант — выдавать только нагрузочные тесты, использующие внешние интерфейсы. Они позволят оценить продукт на близких к реальным условиях. При этом живые пользователи не пострадают, как это обычно происходит, плюс ничего скрытого никто не увидит.
vitesse
18.04.2016 18:39Как программист работавший в разных компаниях разрабатывающих проприетарное ПО, скажу, что не всегда тесты пишутся действительно качественно, случается, что они пишутся «чтоб было». А как писали выше, у заказчика вряд ли будут специалисты, средства и время на то, чтоб провести анализ этих тестов (учитывая, что тесты могут использовать какие-то фреймворки, запутанные патерны, инициализации и т.д. и т.п.). Есть компании, например, медицинские, которые сами пишут приёмочные тесты, и не примут релиз пока каждый тест не пройдёт — им это критично, они готовы за это платить. А если для бизнеса поломка продукта не критична, то выбирая продукт бизнес будет ориентироваться на известность, количество существующих клиентов, функционал и цену, а уже потом на наличие тестов. Машины, самолёты, оружие, медицинское оборудование — открыто тестируется просто потому, что их выход из строя очень критичен.
Fedcomp
думаю для некоторых проектов это убийственно. Во время разработки продукта наверняка проводилось множество исследований, перебирались варианты. А тут можно глядя на тесты написать альтернативу, самой собой дешевле оригинала.
Halt
Большое количество проектов ценны не своими ноу-хау (которых может не быть вообще), а инфраструктурой и раскрученным брендом. Стоимость софта в таком случае может теряться на фоне капитальных затрат и рекламной кампании.
А вот тесты тем не менее могут быть ценны.
softaria
Одним из важнейших качеств продукта является момент выхода его на рынок. Если кто-то сейчас сделает более дешевую и качественную альтернативу, например, Windows, он всё-равно ничего никому не продаст.
Чтобы выйти на рынок нужно или превосходить существующий продкут на порядок (что невозможно при копировании), либо делать продукт нишевым (здесь копирование тоже почти ничего не даст)