ReactJS, TypeScript, Micro FrontendsReact fwdays | 27 березня. Долучайся!
×Закрыть

Скільки часу займає тестування на проекті у вашій компанії?

Зіткнувся з цікавим моментом по роботі.

Під час розмови з ПМ-ом стикнувся з проблемою того що тестування 30% часу (і більше) від девелопменту це забагато для замовників. 20-25 % це терпима тривалість тестування за яку замовник готовий платити, все що більше цієї цифри у більшості випадків важко продати.

Я ознайомлений з різними формулами і способами підрахунку тривалості тестування на проекті але питання наступне:

Скільки часу під тестування виділяють у вашій компанії?

Також прозвучало твердження що жодна компанія не може включити 40% тестування. Цікаво так це чи не так.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

у нас пользователи тестят. Куа в команде нет.

тестування 30% часу (і більше) від девелопменту

А на дизайн сколько процентов отводится?

А на требования?

А на юридическое сопровождение?

А уборка офиса на сколько процентов от девелопмента рассчитывается?

А на менеджмент проекта?

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

А процентаж количества строк на одну фичу заказчик как оплачивает? А кого штрафуют, если кода на фичу будет написано больше оплаченного?

А кого штрафуют, если кода на фичу будет написано больше оплаченного?

А что если превышение количества кода только избавит от лишних багов? Заказчик за это доплатит?

Бредовый вопрос, если честно.
Тестирование занимает столько же времени, сколько и разработка, эти процессы идут параллельно. Смотрите, к примеру, V-model как самый простой вариант.
Если мы рассматриваем автотесты, то их разработка идёт в параллели с разработкой кода. Как вариант, если тестирование базируется на UI, тогда тестирование идёт со смещением на 1 или 1/2 спринта, чтобы покрывать уже готовую функциональность.
Если мы рассматриваем мануальные тесты — то на момент, пока идёт разработка функциональности, тестировщики пишут мануальные тесты.
Если же мы говорим о совокупном времени (ну типа за месяц команда разработки биллит 100 часов, команда тестирования 20) — то нормальное соотношение, исходя из моего опыта, 2:1 для небольшого проекта и чистой мануальщины. То есть, на 2 разработчиков приходится 1 тестировщик. При увеличении размера проекта, соотношение должно постепенно расти в сторону увеличения кол-ва тестировщиков, поскольку регрессия неминуемо будет расти. Соотношение 5:1 не является здоровым изначально, это соотношение не даст эффективно проводить все процессы тестирования, вследствие чего некоторые активности неминуемо будут упущены (к примеру, вместо написания нормальных тестов ограничимся смоуком или вообще не будем их писать, а тестировать будем тупо ад хоком), что впоследствии приведёт к граблям, которые больно ударят по лбу.
Для проекта с автоматизированным тестированием, нормальное соотношение будет примерно 3:2 (эмпирика, зависит от используемых фреймворков и сложности проекта), зато будет оставаться примерно константой при росте сложности проекта в дальнейшем.

мені здається що оцінювати у відсотках тестування, це якесь збочення (таке ж саме, як платити за sloc)
тобто якщо замовник хоче мало тестування — робіть мало (більше грошей розробникам піде гг) , хоче більше — робіть більше, це по великому рахунку не проблема менеджера, це проблема сейла

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

Пишем юнит тесты, сколько конкретно времени на них уходит трудно сказать, ну хотя бы 80% coverage стараемся сделать.
Раньше еще загонялись по е2е тестам и вот на них реально уходила тонна времени т.к. протрактор еще та глючная херня. В результате практически отказались от них и я искренне этому рад

Скільки часу під тестування виділяють у вашій компанії?

Ровно столько, сколько нужно, чтобы протестировать напиленный функционал.

Если коснуться авто-тестов, то их грамотное написание может занять (и обязательно займёт) куда больше времени, чем написание кода фичи.

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

все равно потратишь больше времени, чем если не писать

фотки Конфуция не хватает :)

ПМ всё правильно говорит. В нашей объединенной команде (27 человек) 3 тестера, из них два продуктовых и 1 для сервисных задач, загружены все, итого 11%. К тестированию нужно подходить грамотно и не тестировать всё подряд и когда нужно и когда не нужно. Многие сервсиные заказчики (аутсорс) вообще противятся когда тестер без нужды их биллит, они сами заказывают тесты по своим внутренним майлстоунам.

Не совсем понятна формулировка «сколько времени занимает». По своему опыту вижу, что стандартный рейт 1 тестировщик на 3 дева очень популярен.

Що малося під формулюванням

«сколько времени занимает».

До прикладу розробка якоїсь фічі займає 3 год. Тобто тестування тієї ж фічі мало б займати 54 хв (тобто 30%). Така сама логіка розрахунку і на проекті. Якщо девелопмент займає 200 год, то тестування на цьому проекті повинне бути орієнтовно 30% тобто 60 год

На самом деле это как стартовать новый поток в коде для вычисления 2+2 и затем тушить его и соединять с основным, его породившим, где накладные расходы для подсчёта 2+2 будут на три-четыре порядка выше самого действия. При грамотно написанном тикете в разделе воспроизведение бага, тестеру или человеку, создавшему тикет, протестировать исправление бага стоит гораздо меньше времени чем 1 час. Второй момент баги нужно группировать по среде (environment) выполнения и тестер должен тестировать не один баг, а целую пачку для этой конкретной среды, потому что часто оверхед на настройку среды может занимать львинную долю времени проверки исправления бага и ради одного бага затевать не стоит.

При хорошем написании ресолва задачи программист пишет, какие фичи могло зацепить его изменение и что именно нужно протестировать.

В нас на 2 програмерів 1 мануал QA та 1 тестуючий фічі PM.
Жорсткого цитклу релізів нема — коли велика фіча готова, відтестована й пофікшена — тоді випускаємо.
Кожна зроблена задача чи баг проходить тестування QA чи PM.

1 тестуючий фічі PM

знайомо, у PM-а є доступ до БД?

В нас нема БД. В нас телефонна станція, вбудована в роутер.

30% от девелопмента — это обычная ленивая эстимация. Естественно, она ни о чем, т.к. сложность и длительность тестирования лишь отдаленно коррелируют с аналогичными оценками по девелопменту. Иногда это не 30%, а 150%.
Для нормальной оценки нужно декомпозировать тестирование каждой задачи на составляющие. Мануальное и автоматизированное отдельно по видам, процессам и артефактам.
Сам процесс оценки добавляет еще пару часов времени, поэтому стараются от этого уйти.
Ставить любой относительный показатель (в процентах) или абсолютный (в часах) без подробного анализа — это самообман.

Детальна декомпозиція можлива за достатньої кількості і якості документації і оголошеного скоупу робіт. За його відсутності важко дати точний естімейт. Що робити в такому випадку?

Ситуация такая же как с девелопментом. Если нет полноценных требований, это не катастрофа, но работа уходит в прототипирование, исследование, спайки и т.д. Там можно выставлять временные рамки — когда остановиться чтобы посмотреть что получилось. Но нельзя сделать эстимейт типа «через 3 дня мы сможем протестировать и оценить качество». Можно сказать: через 3 дня останавливаем тестирование и говорим что успели проверить и что поняли за это время.
Нужно просто чтобы все участники процесса осознавали эту неопределенность, а то часто это становится сюрпризом и стрессом для некоторых.

TDD говорили они, окупится в использовании говорили они..

В мене на жодному проекті не було менше 30%.
Маю знайомих, в яких на проекті тестування нерідко займає 50% від девелопменту.
Але загалом, 30+

Це цікаве питання зі сторони тестування, як оцінити і протестувати все потрібне в обмежений період, але також цікаво як ПМ та інший стаф продає замовнику це тестування яке займає більше 50%

Залежно від того що саме важати тестуванням. Якщо ручне тестування тестерами як окремий процесс — в моєму тімі 0. В цілому по продукту імовірно що відсотків 25% і ця затримка ду-у-уже дратує

В мому випадку йдеться про мануал тестування в процесі розробки. Про яку затримку йде мова?

Ми релізимо щотижня. Дивні чуваки що споживають наш продукт підбирають його в кращому разі через реліз, а то й через 4, в процессі того підбирання проводять ще й якусь ручну верифікацію (триває з тиждень.. тому і підбирають рідко в них там цілий тім зі своєю бюрократією заточенний тільки на підбирання і інтеграцію наших компонент) відповідно фічу я реліжу сьогодні а ті чудаки на букву М підбируть її... ну десь в наступні 5 тижнів.. можливо. А потім ще фіг знає скільки часу будуть викатувати те що, підібрали на користувачів, правда в тому процессі фіча буде теж тестуватись.. але не тестерами, користувачами.

Ну така ситуація різниться від компанії до компанії
а стосовно

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

то по суті так можна сказати про все тестування, з чим я далеко не погоджуюсь так як величезна кількість бігів знайдена тестерами ще до моменту релізу. Так баги залишаться (в силу того що не все можна і потрібно тестувати) але кількість і критичність багів (за умови більш менш якісного тестування) значно зменшиться.

то по суті так можна сказати про все тестування

Сказати можна що завгодно, але то зовсім не означає що то твердження буде істинним. Для того що б тестувати на юзерах і не викатувати їм критичних багів треба дешо мати. У нас для того є
1. Автоматизовані тести. Як юніт тести на все так і купа інтеграційних тестів на багатьох рівнях, бігаючих на великій кількості цільових платформ і покриваючих нефункціональні вимоги
2. Контініус інетегрейшен і контініус делівері. Сьогоді я заливаю код а завтра я як користувач його ж і отримаю на власній машині з дейлі апдейтом.. да, да перші користувачі на кому ми тестуємо то ми ж самі.
3. Широкі можливості моніторити продакшен. При чому як просто збирати з відтам метрики так і проводити автоматичний детекшен різноманітних проблем
4. Можливість поступового реліза продукту нашим користувачам, ну і я вже казав, що перші користувачі які його отримають то ми самі, далі він потроху розповзається в середині компанії і тільки після того роздається зовнішнім користувачам.
5. Можливість помітивши проблему запросити про неї більше інформації.
6. можливість користувачів — переважно нас же самих зарепортити помічену багу

При таких розкладах потреба в ручному тестуванню в принципі мінімальна. А ті хлопці просто морочать нам голову з ручним тестуванням тому що не можуть в автоматизацію. Більшість проблем які ми знаходимо ідуть із репортів внутрішніх користувачів.

4. Можливість поступового реліза продукту нашим користувачам, ну і я вже казав, що перші користувачі які його отримають то ми самі, далі він потроху розповзається в середині компанії і тільки після того роздається зовнішнім користувачам.

У нас похожая схема, есть sw center, через который в зависимости от твоих прав ты можешь получить Latest build, experimental (обычно каждые 6-8 часов, только для внутреннего потребления), Experimental drop (в основном для жирных заказчиков), PM решает какой из билдов туда помещать, Stable (тот который был оттестирован хорошо, обычно каждые две-три недели, не чаще, тоже в основном для жирных заказчиков и для тех у кого средний жирок), ну и GA — General Availability — для всех, его тестирую обычно очень сильно, и в хвост и в гриву, но частота выхода обновлений обычно раз в квартал. Иногда между Experimental и GA может быть несколько лет разработки, т.к. разработка ведётся в других бранчах и потом начинает съезжаться в GA, иногда оно начинает съезжаться в GA, но уже для следующей версии продукта, ибо вечно бесплатно обновлять не получается :)

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

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

Та же самая фигня, после внутренних билдов и перед ГА идут партнеры.

Не тільки на одному.

Коли останній раз відкривав Windows 10 то відчуття, що там багато наворотили, на 95-98 було все просто

А в ігри можна було грати на компах з 16мб оперативи. І що характерно, то були гарні ігри, найкращі, не те що сучасні одноденки

IDDQD, товаріщч

Подписаться на комментарии