Не совсем так. Существуют методологии разработки, где тестировщики подключаются только после написания кода, есть такие, где тестировщики подключаются еще до написания документации. И мне нужно склонить овнера к последнему варианту. Тогда мой вопрос можно перефразировать как "Мне интересны материалы показывающие преимущества таких подходов".

видимо там в какая-то мета-ачивка открывается и кеш в с кучей нолей, чтобы хотеть сделать так без понимания, зачем

имхо, если ты ищешь в интернете пруфы такого подхода, ты идешь от обратного

http://stackoverflow.com/questions/237000/is-there-hard-evidence-of-the-roi-of-unit-testing

Никто не тестирует прототипы

Тесты нужны когда идет разработка бизнес-важных фич

гуглить по словам ROI of QA

100% покрытие тестами невыгодно

www.luxoft-training.ru/blog/veni_vidi_vickie/540.html

Вот я гоню. Я пишу про тестировщиков, а подразумеваю QA

Когда куа стоит подключать

гуглить по словам ROI of QA

Как roi расшифровывается?

return of investments

Возврат инвестиций

Благодарю

Все зависит от разработчиков

Если сидят батьки, которые сами с усамии умеют в bdd - смысла в куа нет до момента демо

www.luxoft-training.ru/blog/veni_vidi_vickie/540.html

спасибо

гуглить по словам ROI of QA

спасибо

Когда куа стоит подключать

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

ага, спасиб, стоимость ошибки - это один из пунктов вокруг которого построю аргументацию

Если сидят батьки, которые сами с усамии умеют в bdd - смысла в куа нет до момента демо

Плохие новости для вас, это не так :)

Не совсем так. Существуют методологии разработки, где тестировщики подключаются только после написания кода, есть такие, где тестировщики подключаются еще до написания документации. И мне нужно склонить овнера к последнему варианту. Тогда мой вопрос можно перефразировать как "Мне интересны материалы показывающие преимущества таких подходов".

У нас на этапе подготовки документации/начала разработки строится матрица покрытия требований - можешь попробовать в подобном направлении покопать/подавить

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

Странное обсуждение: если продукт-овнеру нужно только "пощупать" - а нужно ли его программное решение рынку - то естественно, что он не хочет платить еще и за тестирование. Он хочет получить за минимальные деньги минимальное рабочее решение в минимальные сроки.

к чему навязывать тестирование кому-то, кому оно не нужно ?..

Вот и я не могу понять, там что, есть ачивка для того, кто убедил завести тестирование с бонусом в миллион рублей?

Плохие новости для вас, это не так :)

Ну вам видней, конечно)

Это модно так

Распил бюджета

Странное обсуждение: если продукт-овнеру нужно только "пощупать" - а нужно ли его программное решение рынку - то естественно, что он не хочет платить еще и за тестирование. Он хочет получить за минимальные деньги минимальное рабочее решение в минимальные сроки.

Может быть затем, что прототипы тоже требуют процесса QA? Там, естественно, другие критерии прохождения этого QA и приоритеты оного. Но выпиливать QA совсем == повышать шанс того, что рынко оно будет не нужно.

До демо дня никому ваши процессы не сдались

После интереса, можно хоть в круг тестами обвязаться

До демо дня определяется то, чем будет поделие которое вы лепите.

И процессы волнуют всех участников.

Ну, если конечно вы не интернет магазины на заказ клепаете.

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

Мне кажется, вы не чувствуете контекста

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

по моему мнению, конечно

Мне кажется, вы не чувствуете контекста

Значит, возможно, вы плохо выражаете свои мысли.

Там где все понятно, тесты нужны. Там где нет процесса, тестер это плюс один кому надо все разжевать, это потери времени без ощутимого профита. Если прототип уйдет в ведро по результатам демо дня - зачем нужен еще один рот?)

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

Очередной интернет магазин на заказ и новый стартап с неясным рынком сбыта требуют _разного_ тестирования (QA, конечно же, а не только тестирования).

Почитайте lean startup, может снизойдет до вас откровение про гибкие методологии

Там где все понятно, тесты нужны. Там где нет процесса, тестер это плюс один кому надо все разжевать, это потери времени без ощутимого профита. Если прототип уйдет в ведро по результатам демо дня - зачем нужен еще один рот?)

Затем, что участие QA в создании прототипа повышает шансы на то, что это не уйдет в ведро. Потому что помимо правильности бизнес идеи есть ещё и правильность реализации.

Очередной интернет магазин на заказ и новый стартап с неясным рынком сбыта требуют _разного_ тестирования (QA, конечно же, а не только тестирования).

не буду спорить, согласен с таким утверждением ) Можно спросить у топик стартера про контекст его проблемы, раз такой живой интерес ? @escu1ap

Налажаете с прототипом - закапываете идею.

И куа от этого спасет?)

Почитайте lean startup, может снизойдет до вас откровение про гибкие методологии

Читал, не видел ничего про "тестирование не нужно".

И куа от этого спасет?)

Вполне вероятно.

А почему, простите, нет?

Ну тогда с вашей ультимативностью, вам в гугл батенька

Там куа спасло столько проектов, которые потом закрыли

Процесс не значит жизнеспособный

Процесс не значит жизнеспособный

Категорически не распарсил это предложение. Можно подробнее.

Там куа спасло столько проектов, которые потом закрыли

Ваша компания, я уверен, гугл обогнала и утерла и по выручкам, и по успешным проектам, и по внедрению QA, но зачем мы это обсуждаем сейчас?

Именно

Грязный прототип обеспечивает лучший тайм-ту-маркет, а это значит первый на рынке и процесс все еще можно отстроить

Именно, что обогнала? :D

Вы не работали в стартапах

Вы не работали в стартапах

Очень категоричное заявление. Резюме моё видели?

Просто потому что им не нужно такого, убеждать всех ультимативных парней

Живете все еще в России?)

Грязный прототип обеспечивает лучший тайм-ту-маркет, а это значит первый на рынке и процесс все еще можно отстроить

Любой прототип имеет стороны, которыми можно пренебречь и стороны, которые должны быть сделаны качественно, потому что без них потеряется бизнес вэлью. Если вы напряжетесь и перечитаете ещё раз, что я писал выше - то поймете, что я нигде не призывал закапывать миллион человекочасов на идеальное вылизывание прототипа. Я говорил про то, что на этапе создания прототипа QA может, во первых, сильно упростить и помочь в определении этих самых "мастхэв" и "не-мастхэв" вещей и их представлении, а во вторых обеспечить должное качество мастхэвных.

Кто это будет делать, простите?

Живете все еще в России?)

Отличный аргумент, одобряю. Ж)

ERROR: S client not available

Кто это будет делать, простите?

Делать что, простите? Заниматься QA? Очевидно - QA Engineer. Слышали про таких?

Просто культура бизнеса в Америке и в России немного отличается

А разве тут не культуры России?

Помимо Америки и России есть ещё половина мира, если что. Стартапы есть везде, у кого-то сидят QA и делают полезное дело, у кого-то сидят и не делают. А кому-то и без них якобы норм. И что с того? :)

В Америке не будет разговора за мастхев, есть бюджет, есть идея и исполнители, выстрелит - будет все остальное

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

панацеи нет, любой абсолютизм мнений бесполезен :)

В Америке не будет разговора за мастхев, есть бюджет, есть идея и исполнители, выстрелит - будет все остальное

Вы, кажется, слишком погрузились в недра америки, что бы понимать, что пишут на русском. Ещё раз: Выстрелит или не выстрелит - зависит от прототипа (и ещё сотни других факторов, не связанных с разработкой). Качество прототипа (критерии которого сильно отличаются от качества продукта, если что) - напрямую влияет на результат этого самого "выстрелит\не выстрелит". И тут уже вопрос, чьими силами вы это качество будете обеспечивать. Ферштейн?

Мне кажется вы еще не вышли в пубертата с таким стилем общения

Смотрю, у стартаперов из Штатов есть время обсуждать пубертат в России. Вы на этот вопрос ответ тут ищите?

Александр, где ваш меч

Защищайтесь

Если уж пришли с вопросом про тестирование, то и выводите беседу на путь получения ответа по вашему вопросу

Мало того, что вы влезли в разговор не понимая сути

Вы еще и троллить пытаетесь)

А не скатывайте чат не пойми во что. Я вижу, что уже начинаете обсуждать свои и чужие регалии

Обмен мнениями на целесообразность куа в процессе постройки пепелаца

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

из десятка знакомых коллег, которые пишут на RoR сайтики типа магазинов, количество переиспользуемого однотипного кода растет от проекта к проекту. Т.е. заведенные фича-тесты в Capybara и rspec чуть-чуть рефакторятся и всё. Такие проекты и тестирования не требуют зачастую - нужно фичи деливерить, чик чик и в продакшен. А написанные тесты - подспорье для того, что из проекта в проект что-то будет работать, они на удивление однотипны в общем потоке.

ребят, а есть, кто работает удалённо? какие успехи?

ребят, а есть, кто работает удалённо? какие успехи?

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

я имею в виду фултайм

я работал 2.5 года, замечательно

Работала 3,5 года, тоже замечательно)

на какого-то постоянного работодателя? или проекты?

в продуктовой разработке на постоянке

ребят, а есть, кто работает удалённо? какие успехи?

наверное зависит от характера. в моем случае пол года выдержал.

а почему вернулись в офис? каковы причины?

мне предложили релокейшн, так бы не уходил никуда)

лично я работал из дома, и мне сложно скрестить дом и работу. а офис я люблю из-за коллег :)

но я дома в разы продуктивнее (без преувеличения про разы :). иногда очень страдаю)

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

а почему вернулись в офис? каковы причины?

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