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

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

Логично, что собрать телевизор гораздо быстрее, чем включить его в розетку и проверить, что он работает!))

Логично, что собрать телевизор гораздо быстрее, чем включить его в розетку и проверить, что он работает!))

?! Эм...

Логично, что собрать телевизор гораздо быстрее, чем включить его в розетку и проверить, что он работает!))

Включить в розетку и проверить работоспособность не разные ли вещи? xD

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

я вот хз от куда такое пошло, но это бред

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

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

если только включить и все то зачем много времени

и к бюджету

и к срокам

может выкинуть сырой продукт в срок важнее полностью вылизанного, но позно

Проще говоря. Планирование и в Африке планирование, оно и нужно для того что бы определить такие переменные на тестирование/разработку. Но утверждать без расчетов что одна переменная заведомо всегда должна быть меньше второй не правильно

Может быть программисту стоило 5 минут накодить например 20 строк кода которые делают дофига вещей исходя из фреймворка используемого и тестить это придется х часов где х>2

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

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

Прям, вот, я чувствую, человек на аутсорсе работает. Или на фрилансе.

Это ты про задавшего вопрос?

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

Мне кажется или ты что-то путаешь? Например термины "обязано", "обычно", "зачастую"

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

Просто при разработке фундаментальные вещи, которые программисты кодят изначально, потом редко меняются. Но если они все же меняются немного - то нужна полная регрессия и тогда надо всю систему перепроверять.

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

Из человеческой глупости, как и абстрактные вопросы

По-моему из PMBok.

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

Постановка вопроса странная - тестирование это неотъемлемая часть разработки.

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

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

меня очень интересовало похожее утверждение "тестирование занимает примерно 30% от времени разработки" интресно было откуда именно 30 Спросила на тренинге Антона Семенченко (у него там слад был с каким то процентом от разработки). Говорит во всех фундаментальных книгах такое написано, например в книге "Совершенный код". Тест менеджер с Люксофта сказала что у них ведется внутрення статистика по проетам и цифры и коэффициенты (в том числе соотношение времени тестирования к времени разработки) берутся оттуда ну и тоже вроде 30% у них вышло, но точно не помню На митапе одном я тоже прицепилась к докладчику: откуда цифра процента от разработки. Он тоже ответил - статистика по нашим проектам в компании. Ну то есть -статистически время на тестирование обычно меньше времени на разработку. Статистически.

А они считали с дев тестированием или без? А тестирование требований считали? А тестеры девов тренировали тестировать как в Quality assistance практикуется?

А, там про команду куа

меня очень интересовало похожее утверждение "тестирование занимает примерно 30% от времени разработки" интресно было откуда именно 30 Спросила на тренинге Антона Семенченко (у него там слад был с каким то процентом от разработки). Говорит во всех фундаментальных книгах такое написано, например в книге "Совершенный код". Тест менеджер с Люксофта сказала что у них ведется внутрення статистика по проетам и цифры и коэффициенты (в том числе соотношение времени тестирования к времени разработки) берутся оттуда ну и тоже вроде 30% у них вышло, но точно не помню На митапе одном я тоже прицепилась к докладчику: откуда цифра процента от разработки. Он тоже ответил - статистика по нашим проектам в компании. Ну то есть -статистически время на тестирование обычно меньше времени на разработку. Статистически.

Спасибо)

> Спросила на тренинге Антона Семенченко (у него там слад был с каким то процентом от разработки). Говорит во всех фундаментальных книгах такое написано, например в книге "Совершенный код". Это пример, или он действительно 30% тестирвания к книге "Совершенный код" приплёл?

в книге 50%

А, это книга "Code Complete", а не "Clean Code", как я подумал :)

Эх, любит Семенченко цифры, в которых ничего не понимает.

ваще

не важно, цифири эти

Да вот удивлюяюсь, насколько QAшникам важно прицепиться к этим "30%", как будто других интересных тем нету :D

А если бы статистически было 32%, это бы перевернуло вашу вселенную ?

Ни кто не ни кто не цепляется к цифрам

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

Хммм... Хотя возможно Павлу опять скучно и решил в очередной раз срачь развести? xD

"Не мы начали эту войну"

Ну сам подумай, неужели кто-то из великих умов вывел бы фундаментальную теорему "о максимально допустимом времени тестирования фичи"? Это же бред.

> Спросила на тренинге Антона Семенченко (у него там слад был с каким то процентом от разработки). Говорит во всех фундаментальных книгах такое написано, например в книге "Совершенный код". Это пример, или он действительно 30% тестирвания к книге "Совершенный код" приплёл?

Привел в пример эту книгу. Я записала. Там 50% максимум суммарно на независимое тестирование +тестирование программистом. Больше, пишут, нецелесообразно тратить.

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

Привел в пример эту книгу. Я записала. Там 50% максимум суммарно на независимое тестирование +тестирование программистом. Больше, пишут, нецелесообразно тратить.

"Нецелесообразно" Адуреть :) впрочем первое издание 1993, тогда еще понимание целей тестирования было весьма специфическое.

В моей апликации смена js экспрешена, который пишеться 15-20 минут влечет за собой несколько дней валидации.Какие 30%?)

Интересно, кто нибудь считал сколько времени уходит на то, что бы бороться с ветрянными мельницами Типа говорит менеджер "тестирование должно занимать 30%" Или "у нас аджайл а вы тут требует какие то задокументированные стори " Или "все должны стоять на стендапе " Или директор такой "тестировщики должны сразу автотесты писать "

Про 30% от девелопмента любят говорить на докладах про эстимации и планирование тестирования. Как один из вариантов расчета времени на тестирование совсем нового проекта: взять процент от девелопмента. именно 30% слышала часто, поэтому возник вопрос почему эта цифра. А от менеджеров и заказчика именно про проценты никогда не слышала. От них скорее прилетает : 1 "а чего так долго?" 2 "А можно быстреее?" На первый вопрос отвечаю обоснованием своих эстимаций (показать чеклисты, что там проверяется, кол~во браузеров или девайсов для тестирования, кол во прогонов, сопутствующие таски и тд) На второй- пересогласование скоупа работ и приоритетов

Ребята, кто-нибудь работал с HP loadRunner?

Представьте, сущевствует такой маразм : метрики моего клиента это количество пройденных и написанных тест кейсов) и все)

Так это ж какой простор для творчества!

Тесты кто-нибудь ревьюит?

а покрытие?

у них больше чем 100 продуктов разных в США, и это единственная их метрика для QA))

Тесты кто-нибудь ревьюит?

да

Эх. Сорвалось.

Количество багов после релиза или багов заведенных никого не волнует

Хотя и тут большой простор для творчества...

Интересуют их только цифры по тест кейсах и все

ERROR: S client not available

По факту куча индусов проходит какие-небудь тк для поднятия своих метрик)) Но это на других продуктах так

Представьте, сущевствует такой маразм : метрики моего клиента это количество пройденных и написанных тест кейсов) и все)

А ваша компания разрабатывает софт для этой компании или аутсорсите тестирование (какое) там?

разрабатывает софт для них, а они его уже продают как свой

Прикольно. Очень) Интересные товарищи))

Ага))) мы были до недавного времени последним их продуктом,тестирование которого не мерялось этими супер метриками)

а какие до этого были метрики?

Вообще никаких, команда сплоченная, все доверяют друг другу

Написал/прошел нужное к-чество тк за неделю и все ты safe)) Метрики пошли наверх и ты productive?

А то какое там покрытие и сколько найденных багов их не интересует))

*Здесь должна быть шутка Задорнова про американцев*

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

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

там большая контора) продуктов где-то под 100, у каждого свой SEM-Software Engineering Manager типа ПМ:)

Это инициатива верхов,тех кто выше этих SEM'ов

А поделитесь метриками для QA с упором на аджайл? Кроме %покрытия и кол-ва багов в продакшне что ещё можно считать?

ROI от тестирования

еще можно считать * (количество затраченных часов на тестирование/количество часов на разработку)-0.3) в степени e.

умножить количество тестерировщиков на часы программистов, и разделить на pi/2.

Из того, что возможно имеет смысл подсчитывать: количество зафейленых юнит тестов (должно стремиться к 0). количество warning-ов и error-ов при сборке проекта (должно стремиться к 0)

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

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

количество [ERROR] записей в логах, для которых нет тикета в JIRA -> должно стремиться к 0

Unit тесты - cчитать Branch Coverage, вместо Line Coverage!

умножить количество тестерировщиков на часы программистов, и разделить на pi/2.

Вот это мне нравится, сразу видно что формула небанальная и в то же время элегантная, как в математике. Явно стоит обратить на нее внимание.

толстота-то какая...

О, привет)

Привет ?

Про деление и возведение в степень, это *сарказм*, правда?