для игр не нужна -_-

для игр под мобилки?

нет, для игр на пк

это шутка такая была

не самая смешная)

Ну если человеку нормальные тесты надо делать, зачем ему калабаш впаривать? :)

Ээээ, меня спросили, я ответил. Можешь показать, где я что-то впариваю?

да, спасибо, Semyon, посмотрю и туда)

Ээээ, меня спросили, я ответил. Можешь показать, где я что-то впариваю?

Воу воу, полегче )

И что в твоём понимании нормальные тесты? И почему бдд сразу нет?

Ну, я в своё время писал по бдд тесты и мне показалось, что это две довольно-таки разные парадигмы.

TDD и BDD.

Это разный способ писать одно и то же :)

Я к тому, что если разработка ведется по ТДД, а тесты пишутся по БДД, то это некий методологический коллапс.

Это разный способ писать одно и то же :)

В итоге получая разное на выходе.

Ну, тут takoe

как бы да, но нет

у нас все юнит-тесты пишутся "нормально"

а интеграционка на кукумбере

Воу.

а пишете на чем тесты?

юнит на чём проект

swift/objc

а интеграционку на руби, очевидно

там вариантов немного с кукумбером :)

Так-то да )

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

Есть хэштеги

Твои слова да руководству в уши

Кстати, подскажите, я уже 2 года как с андроидом не работаю. Что сейчас самое популярное? Robotium уже отошёл на задний план?

И какое состояние UIAUTOMATOR?

Самое популярное для чего?

Здесь уже вроде советовали Appium.

Вроде как даже я )

Самое популярное для чего?

Для тестирования андроид приложений с помощью автотестов

Здесь уже вроде советовали Appium.

)

норм фича в вк подвалила https://monosnap.com/file/i39yhW7cJOblbekSM0Z0sB906tWCDC

норм фича в вк подвалила https://monosnap.com/file/i39yhW7cJOblbekSM0Z0sB906tWCDC

которая палит то, что данные не будут удалены даже в случае удаления ?

угу)

Ну у меня первая запись на стене явно не та, которую делал.

Хотя может первая после "Дуров верни стену".

Интересно задать вопрос в массы. Есть ли в вашей компании kpi, и если есть, то каким образом он рассчитывается? Задаю вопрос, т.к. сам большой противник этого дела, а в конторе начинают вводить кпи для разрабов и тестеров)

У нас единственный kpi для разработчиков и тестеров это велосити спринта

он считается на команду, очевидно

никаких персональных kpi нет

Есть идеи как высчитать среднее время на написание одного тест кейса ? :)

засекаешь время на написание каждого, суммируешь и делишь на количество кейсов :)

откуда вообще берутся такие идеи? зачем это нужно?

Засечь общее время написания, делишь на количество..

это банально, давайте сделаем собственные костыли =)

откуда вообще берутся такие идеи? зачем это нужно?

+ к вопросу

Ну видно просят эстимейт

так непонятно же, сколько будет тест кейсов

вот на выполнение время считать - это понятно

какой эстимейт и на что?

для каждой фичи время будет разное

это как просить девов эстимировать среднее время на написание 1-й процедуры

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

+++

например написать 1 кейс на самую простую, но полностью новую фичу может занять час и написать 20 дополнительных кейсов в существующую сюиту - тот же час

откуда вообще берутся такие идеи? зачем это нужно?

Либо управленцы намеренно собираются экономить на исполнителях, либо те же управленцы не понимают что творится ниже этажом и собираются прояснить ситуацию в понятных для себя терминах. Второе встречается чаще.

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

вообще в идее КПИ нет ничего плохого - сами по себе КПИ - это цифры и на относительно длительных периодах они могут показать определённые тенденции. но в краткосрочных оценках - это фейспалм, нет никакой разницы пишется кейс 5 минут или 2 часа, значение имеет только результативность и корреляция с требованиями

Видел команды, в которых, при планировании спринта на 2 недели вперед, время на выполнение задачи оценивается с точностью до 30 минут ?

Если это итеративные задачи, то это нормально.

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

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

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

а если тестов нет?

Видел команды, в которых, при планировании спринта на 2 недели вперед, время на выполнение задачи оценивается с точностью до 30 минут ?

нормальный подход, но зависит от приложения

то есть я знаю как прикинуть, если тестов нет, просто вот вопрос о ситуации ))

нормальный подход, но зависит от приложения

При разработке сложного интернет-сервиса такой подход абсолютно неадекватен

Меньше чем 3-4 часа не имеет смысла делать порог

полдня неопределённости? не проще ли раздробить задачи?

Например задача: какой-нибудь урл из API сервиса периодически отваливается по таймауту. Нужно разобраться в чем причина и устранить.

Как ты это раздробишь? Там нужно целый пласт RnD работ производить

Может это за час решится, а может 2 дня потребуется.

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

вот это меня интересовало. Спасибо!

Главное - понимание что все эти эстимейты это всего лишь опорные точки для продавца хот-догов. Ты даёшь эстимейт и обязуешься его обновить как только станет очевидно, что он, вероятно, нарушится. Всё. Если ты не выполнил задачу в установленное эстимейтом время, это не делает тебя лжецом и лентяем. Конечно, при добросовестном отношении к работе, которую лучше мерить репутацией, а не цифрами.

Твои слова коллекторам бы в уши.

> Если ты не выполнил задачу в установленное эстимейтом время, это не делает тебя лжецом и лентяем. Но если в 50% случаев эти эстимейты не выполняются, то и смысл в таких эстимейтах как бы нету.

А 30 минут можно только ждать пока какой-нибудь аналитик освободится чтобы уточнить у него детали задачи :)

Смысел в эстимейтах есть ибо в общем случае любой эстимейт лучше никакого.

Ну.. Как по мне так спорно

Я о проектной работе. В жизни эстимейты не так важны.

Так давай поспорим =)

То есть ты утверждаешь что при отсутствии эстимейтов можно взять генератор случайных числе и это будет лучше чем ничего?

*чисел

Но прдупреждаю, от вернусь к обсуждению не раньше чем через 5 часов

А я через 4 часа 30 минут

А я томат.

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

Рандомный набор эстимейтов дает ложную надежду менеджерам

А потом наступает разочарование

Ну или радость если таск выполнен быстрее чем ожидалось.

У менеджера развивается нервный тик, маниакально-депрессивный психоз.. Оно надо?