Дмитрий Энтелис: Априори, если только ограничиваться крупным проектом и примерно одинаковой квалификацией команды. Если есть разница, то это правило не работает. Моя практика показала, что в некоторых ситуациях найм дополнительных разработчиков только затягивает проект. То что одним могу сделать X часов, выходило X +- 30% и не за счет постановки задачи, а из-за неэффективности нанятого человека. Ситуация повторялась 4 раза, в итоге отказался от такой затеи. Можете возразить, что надо нанимать более квалифицированных людей. Да, конечно. Только вот тогда для меня проект становится финансово не интересным. Да и опять таки практика показала, что таким людям больше интересен Enterprise и делают они маленькие проекты для развлечения с соответствующим отношением. Опробовано на 3 людях.
Алексей: самое бесполезное дело - сравнивать количество фич у инструментов с разным предназначением. С таким же успехом можно теплое с мягким сравнивать. А WPF вполне успешно развивается, достаточно уйти субъективного мнения и просто почитать об этом blogs.msdn.com/b/dotnet/archive/2014/11/12/announc...
Макс Максимов: технически тоже так называются. В принципе технически это реализуется просто - используйте ViewPageIndicator (его модификацию с иконками) и ViewPager, где каждая страница является фрагментом.
Анна: Так как вопросе не было конкретно сказано, что нужна реализация именно FSM, а не состояний UI, то логично было предложить использовать фрагменты.
Влад Developer: это при условии финансирования. В моем случае стороннее финансирование не нужно, нужна только экспертиза. Да и что такое 7%? Лучше иметь долю на 7% меньшую от многомиллионного бизнеса, чем 100% от бизнеса стоимостью в сотни тысяч, а то и вообще ничего не стоящего.
raidhon: ну-ну. А с продуктовыми компаниями, где один-два разработчика поддерживают весь бизнес не приходилось сталкиваться? Судя по Вашим ответам - кроме аутсурса дешевых простых приложений, где нормальная автоматизация тестирования на сотнях девайсов нафиг не нужна, ничего не делали. Указанные сервисы даже и близко не предоставляют возможностей Test Cloud. Цена далеко не единственный фактор выбора инструмента, и уж тем более не в количестве приложений дело.
Бесполезный спор, на этом я из него выйду.
raidhon: Простой пример. 1 продукт - 1 приложение. 2 разработчика, тестировщиков нет, как и огромного вороха девайсов. Если нанять тестировщика: оплата труда с учетом налогов и косвенных расходов 1.5к $ в месяц. По факту либо будет не успевать тестировать перед релизом, либо будет сидеть без дела после релиза, пока новый функционал не выкатят в тест. Test Cloud - 1$ + немного времени разработчиков на автоматизацию UI-тестов. Проверка сразу на огромном количестве девайсов.
В вопросе нигде прямо не указано на то, что речь идет об инди разработчике. Так что не стоит заранее себя ограничивать одним кейсом, а думать немножко шире.
raidhon: непонимание возможностей платформы и почему у нее такая цена - не повод для негодования. По факту - автоматизированное тестирование даже одного приложения на паре сотен девайсов дешевле ручного тестирования.
mike26: насчет космической цены верно. Однако это дешевле, чем нанять одного хорошего тестера, который все равно не сможет протестировать вручную приложение на таком количестве устройств.
Сервис предпочтительней. По крайней мере его случайно не закроет пользователь. Для обмена сообщениями гораздо проще и надежнее использовать TCP. Подойдет любой вариант - сокеты, WCF, ServiceStack.
