ну я имею ввиду не про человеко- или не человеко- ориентированный способ, а более простые соображения. Типа того, что экранную клавиатуру, или не экранную, а простую механическую, во-первых видно, т.е. можно посмотреть, куда ты жмешь, во-вторых если у тебя болит палец или ты просто неловкий, ты можешь хоть одним пальцем с ней справиться. А с вашей — обязательно надо двумя руками и чтобы все пальцы работали. А нос почесать чем?
из потенциальных юзеров вычеркиваются те, кто чисто левша или правша или руку сломал, плюс те, кто вслепую не печатает или печатает, но на другой клавиатуре… Да и много ли гиков, которые именно на смартфоне пользуются клавиатурой в таком объеме, чтобы им для этого девайс понадобился. И остаются только те, кто родились для баяна. ИМХО, слишком узкоспециальная вещь, чтобы взлететь на рынке. Хотя с точки зрения разработчика наверное интересно с этим возиться
как после этого жить, если нельзя их всех расстрелять. Вместе с электронным правительством и прочими фигнями, которые обязательно хотят все заверенное нотариусом
ИМХО, корпорации не при чем. Не знаю примера с IT индустрией, а вот с косметикой видела, когда наш концерн Калина купил мою любимую косметическую линию и тупо закрыл, чтобы конкурента убрать. Вот это убийство. А когда тебя никто не трогал, просто вместе телефонных будок появились мобильники — это жизнь
потому и рассылают бесплатно, чтобы пул приложений собрать.
Наверное должно не хватать обратной связи. Ну то есть, когда по экрану пальцем водишь, или мышью — там есть тактильные ощущения. А тут только визуально отслеживать. Хотя дети моментально ко всему адаптируются, поэтому вполне может и полететь
вот кстати, для подобных случаев у нас в авто-тесты встроена фича сохранять скриншот после каждого теста. Ну чтобы запустить все на автомате, а в конце посмотреть на цвет галочек и просмотреть картинки. Это быстрее, чем руками все протыкивать
ну если речь идет о чем-то очень небольшом, то может быть. А на большом проекте, пока кто-то будет делать code review по всем закоулкам, там уже можно десяток новых версий выпустить
сначала делали 1 билд на 1 коммит, в какой-то момент стало сильно не хватать билд серверов, сделали раз в сколько-то времени. Автоматически определить, чей именно коммит сломал билд — невозможно. Поэтому на последнего, кто коммит делал, баг присваивается. Но в билдлоге пишется список всех последних коммитов, поэтому тот, кому этот баг упал, имеет возможность откреститься и отправить его по адресу. Это проще, чем заставить кого-то одного следить за билдами и назначать ответственных.
А вот как это технически делается, не знаю, у нас TFS, по всей видимости где-то на сервере скрипт написан, который баги раскладывает. И кроме багов еще e-mail приходит о сломанном билде. Мы не мгновенно к этому пришли, где-то с год устаканивались с тех пор, как на TFS переехали.
описание наших проектов на www.componentone.com. Тиражируемый софт, контролы и компоненты для .Net.
У нас QA полностью отдельный, т.е. отдельные люди, со своим отдельным начальством. Мы с ними синхронизируемся на уровне квартальных планов. Т.е. они делают и ручное, и автоматизированное тестирование, но это не интегрировано в наш рабочий процесс. Если есть критичные места, которые надо покрывать юнит-тестами — то это полностью на разработчиках.
Что интегрировано в разработку — это автоматические билды на сервере после коммитов. Если очередной билд сломался, то автоматически создается баг и присваивается на того разработчика, который делал последний коммит. Тут никаких дискуссий по поводу «кто должен чинить» не возникает, потому что если билд на сервере не проходит, то нечего отдавать в QA и это может помешать другим разработчикам работать над своим кодом.
QA получает готовый билд, сэмплы, документацию и уже со всем этим работает. Они знают, кто из разработчиков за какой продукт отвечает, и сами расписывают баги по разработчикам. Они же определяют критичность багов и какие баги должны быть обязательно исправлены до релиза. Уже разработчики между собой могут этот баг передать, если видят, что на самом деле проблема где-то в чужой области ответственности. Пофиксенный баг опять автоматом присваивается тестеру, который его нашел, и при следующем билде все начинается сначала. Закрыть баг окончательно может только QA.
Кроме QA баги может постить тех.саппорт (если они смогли их у себя воспроизвести), такие баги всегда имеют более высокий приоритет. Ну и еще у нас есть публичные форумы, где каждый разработчик обязан отвечать на вопросы в пределах своей компетенции как минимум раз в неделю. Кстати, очень много багов приходит именно с этой стороны, никакой QA не может вообразить себе, куда люди засунут наши контролы и что с ними сделают.
наверное, в общем случае менедмент должен оценить соотношение цикла жизни продукта, затрат на разработку/тестирование, потерь от багов ушедших в релиз и т.д., и т.п…
Но если вы планируете, что версий продукта будет больше 3х, и вы не будете каждую версию делать с нуля, то поддержка актуальных тестов должна окупаться. Можно обсуждать объем тестов, покрытие, но совсем отказываться я бы не стала.
тут все от специфики продукта зависит. Вот мы пишем контролы, и если релиз состоялся, то скорей всего публичный интерфейс не будет ломаться (только расширяться) до тех пор, пока это не уйдет в легаси, некоторые вещи живут больше 10 лет, а очередные версии выпускаются несколько раз в год. Поэтому и тесты живут долго. Но конечно, и тесты надо поддерживать, рефакторить и т.д…
ну нельзя же из одной крайности в другую кидаться. Полезно иметь набор автоматизированных тестов, которые покрывают хотя бы основные более-менее стабильные части продукта, либо писать по тесту на каждый найденный баг, чтобы перед выпуском в production делать регрессионные тесты. Регрессионные тесты — это самая нудная часть, поэтому всем хочется на них забить, а как раз тут-то баги и вылазят, когда чинили что-нибудь одно — поломали в другом месте.
ну не знаю, stack overflow точно не обновляется, а про фейсбук вообще почему-то ничего у себя не вижу. Возможно, проблема как раз с тем, что и у вас, и в stack overflow я логинюсь через фейсбук
помнится когда-то давно я об этом писала в саппорт 9facts, но ответа не получила и видимо вы этого так никогда и не прочли, так что повторюсь на похоронах: если бы факты действительно собирались и обновлялись автоматически, то какая-то часть пользователей периодически возвращалась бы посмотреть на обновление своих фактов и сравниться с другими. Почему-то, когда я на сервисе регистрировалась, у меня сложилось ощущение, что это очевидная вещь и так оно и будет. Т.е. если я разрешила использовать facebook как провайдер фактов, то оно оттуда будет обновляться время от времени. Но этого никогда не случилось. А кому интересно заходить на сервис и каждый раз сообщать этому сервису, что у тебя еще один друг на фейсбуке появился.
ИМХО, самая главная ошибка не в отдельных ошибках, а в нулевой реакции на feedback. При всей спорности идеи сервиса, он мог бы жить, если бы, не это… Хотя может быть я попала уже на закрытие. Но тогда чисто из вежливости об этом стоило как-нибудь сообщить хотя бы зарегистрированным пользователям
некое противоречие зашито аж в первом абзаце. С одной стороны куча статей грузит тем, что учит себя мотивировать, а с другой стороны — это все написано еще в одной длинной статье, которая тоже учит как правильно и даже некоторым образом давит, обещая сожаления в старости
Наверное должно не хватать обратной связи. Ну то есть, когда по экрану пальцем водишь, или мышью — там есть тактильные ощущения. А тут только визуально отслеживать. Хотя дети моментально ко всему адаптируются, поэтому вполне может и полететь
А вот как это технически делается, не знаю, у нас TFS, по всей видимости где-то на сервере скрипт написан, который баги раскладывает. И кроме багов еще e-mail приходит о сломанном билде. Мы не мгновенно к этому пришли, где-то с год устаканивались с тех пор, как на TFS переехали.
У нас QA полностью отдельный, т.е. отдельные люди, со своим отдельным начальством. Мы с ними синхронизируемся на уровне квартальных планов. Т.е. они делают и ручное, и автоматизированное тестирование, но это не интегрировано в наш рабочий процесс. Если есть критичные места, которые надо покрывать юнит-тестами — то это полностью на разработчиках.
Что интегрировано в разработку — это автоматические билды на сервере после коммитов. Если очередной билд сломался, то автоматически создается баг и присваивается на того разработчика, который делал последний коммит. Тут никаких дискуссий по поводу «кто должен чинить» не возникает, потому что если билд на сервере не проходит, то нечего отдавать в QA и это может помешать другим разработчикам работать над своим кодом.
QA получает готовый билд, сэмплы, документацию и уже со всем этим работает. Они знают, кто из разработчиков за какой продукт отвечает, и сами расписывают баги по разработчикам. Они же определяют критичность багов и какие баги должны быть обязательно исправлены до релиза. Уже разработчики между собой могут этот баг передать, если видят, что на самом деле проблема где-то в чужой области ответственности. Пофиксенный баг опять автоматом присваивается тестеру, который его нашел, и при следующем билде все начинается сначала. Закрыть баг окончательно может только QA.
Кроме QA баги может постить тех.саппорт (если они смогли их у себя воспроизвести), такие баги всегда имеют более высокий приоритет. Ну и еще у нас есть публичные форумы, где каждый разработчик обязан отвечать на вопросы в пределах своей компетенции как минимум раз в неделю. Кстати, очень много багов приходит именно с этой стороны, никакой QA не может вообразить себе, куда люди засунут наши контролы и что с ними сделают.
Но если вы планируете, что версий продукта будет больше 3х, и вы не будете каждую версию делать с нуля, то поддержка актуальных тестов должна окупаться. Можно обсуждать объем тестов, покрытие, но совсем отказываться я бы не стала.
ИМХО, самая главная ошибка не в отдельных ошибках, а в нулевой реакции на feedback. При всей спорности идеи сервиса, он мог бы жить, если бы, не это… Хотя может быть я попала уже на закрытие. Но тогда чисто из вежливости об этом стоило как-нибудь сообщить хотя бы зарегистрированным пользователям