ReactJS, TypeScript, Micro Frontends — React fwdays | 27 березня. Долучайся! ✖
Вход и регистрация
×Закрыть
О работе · 6 декабря 2019, 11:43 2059
Serhiy SS

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

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

Під час розмови з ПМ-ом стикнувся з проблемою того що тестування 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
Lyova Zi 10.12.2019 08:40

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

Ответить
Поддержать
Ай Сиктир разрешение 10.12.2019 02:48
тестування 30% часу (і більше) від девелопменту

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

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

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

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

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

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

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

Ответить
Поддержать
Фрэнк Сайдботтом 10.12.2019 07:32
А кого штрафуют, если кода на фичу будет написано больше оплаченного?

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

Ответить
Поддержать
Ай Сиктир
Дмитрий Мирошник Lead QA Automation Engineer 08.12.2019 16:27

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

Ответить
Поддержать
proger 07.12.2019 12:32

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

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

Ответить
Поддержать
Artem Perchyk JavaScript developer в SoftServe 07.12.2019 11:51

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

Ответить
Поддержать
Dmitry Bugay 07.12.2019 11:45
Скільки часу під тестування виділяють у вашій компанії?

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

Ответить
Поддержать
Котэ 06.12.2019 17:51

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

Ответить
Поддержать
Vadim Kopanev .NET Architect 06.12.2019 18:22

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

Ответить
Поддержать
Котэ
Denys Poltorak 06.12.2019 18:29

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

Ответить
Поддержать
Vadim Kopanev
Vadim Kopanev .NET Architect 06.12.2019 18:31

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

Ответить
Поддержать
Denys Poltorak
Mike Gorchak Graphics Device Driver Developer 06.12.2019 15:02

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

Ответить
Поддержать
Alla Zakharenko Senior Test Engineer в GlobalLogic 06.12.2019 14:58

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

Ответить
Поддержать
Serhiy SS 06.12.2019 17:00

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

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

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

Ответить
Поддержать
Alla Zakharenko
Mike Gorchak Graphics Device Driver Developer 06.12.2019 17:37

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

Ответить
Поддержать
Serhiy SS
Denys Poltorak 06.12.2019 18:08

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

Ответить
Поддержать
Mike Gorchak
Denys Poltorak 06.12.2019 14:54

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

Ответить
Поддержать
Senseye 07.12.2019 00:58
1 тестуючий фічі PM

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

Ответить
Поддержать
Denys Poltorak
Denys Poltorak 07.12.2019 12:44

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

Ответить
Поддержать
Senseye
Bender Rodriguez 06.12.2019 14:14

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

Ответить
Поддержать
Serhiy SS 06.12.2019 17:07

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

Ответить
Поддержать
Bender Rodriguez
Bender Rodriguez 06.12.2019 17:13

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

Ответить
Поддержать
Serhiy SS
Alexander Qel 06.12.2019 14:08

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

Ответить
Поддержать
Roman Sheremeta Middle Test Automation Engineer в SoftServe 06.12.2019 13:52

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

Ответить
Поддержать
Serhiy SS 06.12.2019 17:10

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

Ответить
Поддержать
Roman Sheremeta
Леголас Трандуилович 06.12.2019 13:00

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

Ответить
Поддержать
Serhiy SS 06.12.2019 17:11

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

Ответить
Поддержать
Леголас Трандуилович
Леголас Трандуилович 06.12.2019 17:19

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

Ответить
Поддержать
Serhiy SS
Serhiy SS 06.12.2019 17:33

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

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

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

Ответить
Поддержать
Леголас Трандуилович
Леголас Трандуилович 06.12.2019 18:52
то по суті так можна сказати про все тестування

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

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

Ответить
Поддержать
Serhiy SS
Mike Gorchak Graphics Device Driver Developer 06.12.2019 19:43
4. Можливість поступового реліза продукту нашим користувачам, ну і я вже казав, що перші користувачі які його отримають то ми самі, далі він потроху розповзається в середині компанії і тільки після того роздається зовнішнім користувачам.

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

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

Ответить
Поддержать
Леголас Трандуилович
Леголас Трандуилович 06.12.2019 19:47
Большинство крупных заказчиков как раз являются теми юзерами, на которых тестируют, но это выбор заказчиков, они хотят всё самое последнее, т.к. исправление ошибок в этих релизах идёт очень быстро, но могут быть и косяки

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

Ответить
Поддержать
Mike Gorchak
Valentin Nechayev досвідчений чайник Рассела 06.12.2019 21:42

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

Ответить
Поддержать
Senseye
Senseye 07.12.2019 00:54

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

Ответить
Поддержать
Valentin Nechayev
Олексій Пєніє Developer, Java 08.12.2019 10:22

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

IDDQD, товаріщч

Ответить
Поддержать
Senseye

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

Не подписываться

Воспользуйтесь аккаунтом

×
с условиями использования сайта и политикой конфиденциальности.