На 3 дев - 1 куа. Саме так оцінюють більшість продактів чи техлідів потребу в кількості тестувальників на продукт. Я знаю багато менеджерів, які від цього впадають в емоції на рівні Кіліана Мерфі, а інші можуть і впасти в лють. Але - чи правда це супер поганий підхід? Чому його використовують взагалі? Давайте розкажу. Для людини, яка не шарить в тестуванні (а рм і так далі в своїй більшості в ньому не шарять), це єдина припустима оцінка, яку вони можуть зробити. Але, коли ви приходите і ви в тому шарите, і намагаєтесь переконати, що треба більше людей - ваш РМ сприймає це лише як "нам треба більше грошей, бо в нас там документація, ризики бла бла бла" - нецікаво. Вас не слухають і це нормально, бо аргументації і показників ніяких немає. Оцінка в кількості дев на кількість куа - працює. Коли працює? - коли це один з купи інших факторів оцінки - коли ви враховуєте не лише кількість дев а й їх грейд, швидкість, якість відповідно до гредйів, швидкості, якості куа, - коли врахован не тільки грейд , а й досвід роботи в домені та інструментах Дууууже узагальнений приклад. На проєкті понабирали джун розробників і над ними поставили 1 сінйора. РМ порахував на 3 джун дев 1 куа. Лід взяв на цей проєкт відповідно 3 мідлів і 2 сінйорів куа. Що відбувається далі ? Тестувальники пінають гумові вироби по куткам. Дев горять. Чому?Тому що дев пишуть повільно, погано, не проходять ніяке рев'ю, віддані задачи одразу з перших кроків тестування сипляться в блок чи кріт... Ботлнек на дев. Формула кількість дев на кількість куа повинна враховувати багато чого. Більше за те - ви повинні балансувати хто з куа яку задачу після якого дев робить. Якщо ви після дев джуна віддасте задачу джуну - вони обидва там й потонуть. Якщо ви задачу дев джуна віддасте сінйору - дев джун замахається, куа сінйор піде знову гумові вироби шукати. При цьому якщо ви віддасте мідлу тестувати задачу після сінйор дев - то все буде збалансовано. Мідлу буде цікаво, +- швидкість роботи буде однакова. Це лише приклади і вони мають виключення з правил, звісно ж. Не завжди то саме так працює. Проте - РМ цього всього не рахують. Більше того - ви теж це не рахуєте і просто кривитесь коли бачите таку формулу від керівника.Кривиться скільки завгодно - але користуйтесь інфою правильно. Наявність відсутність того чи іншого ботлнеку - одна з ваших задач то разгрести. І так, косяки РМ чи техліда, ви теж можете згладити врахувавши і цей момент при оцінці потрібної кількості людей та грейдів на тестування. #qa #qanavigator #estimation