Створюючи кошторис часу для квитків, чи повинен час, який забирається для тестувальників, включати до кошторису квитків? Раніше ми завжди оцінювали без тестування час, але ми говоримо про те, щоб завжди включати його. Це має сенс для нашого нинішнього спринту, останнього перед випуском, оскільки нам потрібно знати загальний час квитків, який займе один тиждень.

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

Щоб було зрозуміло, це для процесу, коли розробники пишуть одиничні, інтеграційні та UI-тести з хорошим покриттям.

Моя рекомендація: Ви або включаєте час тестування в квиток, або додаєте квиток, щоб представити тестове завдання. Будь-який інший підхід змушує вас занижувати реально необхідну роботу.

Хоча час розробника часто є вузьким місцем, на моєму досвіді, існує багато команд, обмежених тестом. Якщо припустити, що обмежуючий ресурс є тим чи іншим без доказів, може вас вкусити.

Як ваш колега, я не бачив успішної організації, яка не враховує час тестування.

Додавання за вашим уточненням: Навіть якщо розробники пишуть автоматизовані тести, зокрема одиничні тести (інтеграційні тести роблять краще), їх недостатньо для належного тестування.

Якщо задіяні люди, які здійснюють контроль за якістю, так чи інакше потрібно оцінити їх час. Тільки якщо ви вирішили вилучити осіб із забезпечення якості з оплати праці, то їхній час роботи фактично зник, і ви можете вилучити його з оцінки. Але це матиме побічні ефекти, які легко ігнорувати. І можливо, вам все одно не вистачає тесту на працездатність, стрес, безпеку та прийняття.

Підкреслено, так

Тестування є частиною процесу розробки. Якщо ваша команда фактично витрачає час на тестування програмного забезпечення, час, проведений на тестування, повинен бути частиною кошторису.

Якщо це спритно, я б включив тестування як частину загальних балів історії. Наприклад, розробка зусиль може бути 1 день, а тестування - 1 день, щоб це було 2-бальною історією.

Це залежить від того, яким є ваше визначення, але зазвичай його завершення, прийняття бізнесу та тестування, підписуються в ітерації. Якщо DoD - це лише прийняття бізнесу, то зусилля для тестування не потрібно включати до сюжетних точок, але їх все одно слід відслідковувати.

Кошторис повинен враховувати всі роботи, необхідні для заповнення квитка. Якщо тестування є обов'язковою частиною квитка, то його слід включити до кошторису. Якщо тестування є окремим квитком, то воно не повинно.

Це, звичайно, може отримати все нечітке, коли ви почнете використовувати точки історії, оскільки різниця між лише 5-ти для дев-8 і лише 8-ма розбитниками буде досить пропорційна деві-і-QA 5 порівняно з dev-і-QA 8.

Я бачив у тому числі роботу тестера. Я бачив, як працюють окремі історії. Я бачив окремі завдання, кожне з яких оцінюється робочою групою. Робіть те, що для вас має сенс, адже процес є для вас, а не навпаки.

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

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

З іншого боку, якщо одна команда проводить усі розробки, тестування та якість, а мета оцінок часу полягає в тому, щоб передбачити і спланувати, що ця команда робить у конкретні часові рамки, то, звичайно, часові оцінки повинні включати QA, а також будь-які інші завдання, які необхідно виконати цій команді для досягнення поставленої мети. З цього питання, якщо вам доведеться провести початкову зустріч для кожного квитка або заповнити трохи паперів при завершенні, тоді адміністратору потрібно десь бути там . Ви не можете просто проігнорувати це.

Якщо все це одна команда, але з окремими ролями «розробники» та «тестери», то це може означати, що у вас є багато квитків, над якими здатна працювати лише одна сторона, і ваша (можливо, цілком гіпотетична) діаграма Ганта виглядає точно так, як виглядатиме діаграма для двох окремих команд. Цей факт засмутить деякі методології більше, ніж інші, і вам може бути краще розділити планування через це, але якщо ви не розділите його, вам доведеться зробити квиток і оцінити все, що повинна зробити команда, або ваші прогнози будуть безнадійними. .

Якщо метою оцінок є щось інше, ніж прогнозування та планування, наприклад, "тому що ми безглуздо дотримуємося порожнього ритуалу, який включає їх", або "тому що керівництво використовує їх як палицю, щоб бити нас, щоб не понаднормати нас", або "тому що ми повинні зробити ставку з фіксованою ціною, і цифри переходять у величезну формулу" (дякую Джо Ву), тоді може бути складніше зрозуміти, що вони повинні включати ;-)

Завжди оцінюйте всю роботу, яку потрібно зробити, щоб історія користувача / функція / квиток дійсно виконана. Ми називаємо це DoneDone .

Ми готові, коли готові до виробництва .

Сюди входить будь-яке ручне та розвідувальне тестування, але навіть тестування прийняття користувача.

Команда Agile повинна мати можливість випустити нову частину готової роботи в будь-який момент. Як:

Робоче програмне забезпечення є основним показником прогресу.

Як дізнатися, чи працює вона, якщо ви її не перевірили? Тепер ви пишете, що час розвитку - це вузьке місце вашого часу. Як QA-інженер, я думаю, що більшість команд мають вузьке місце в тестовій спроможності або вони просто приймають скорочення.

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

Тут є щось дуже важливе: всі оцінки повинні супроводжуватися припущеннями та виключеннями .

Сюди входить уточнення того, що включено: лише розробка, проектування та розробка, тестування розробників та пристроїв, покриття приймальних тестів, розбудова інфраструктури тощо.

Якщо ви надаєте оціночний документ керівнику проекту, він збирається перетворити цей документ у робоче замовлення або заяву про роботу для клієнта або (якщо внутрішній проект) для PMO . Вони можуть мати встановлені формули для додавання накладних витрат (наприклад, деякі проекти можуть додати X% для покриття якості, а потім додати Y% для покриття управління та управління проектами), які встановлюються контрактом або встановлюються досвідом. І ви не хочете подвоюватися. З іншого боку, вони можуть не додавати їх автоматично.

Практика відрізняється. Хто користується цими номерами, повинен знати, що означають цифри, і ви повинні бути чіткими щодо того, включаєте ви час тестування чи ні.

Час повинен бути включений до кошторису, але не слід оцінювати час тестувальників, натомість тестери повинні оцінювати їх час .

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

Інкапсуляція

Я підходжу до цього з точки зору та мови розробки програмного забезпечення.

• Ви маленький гвинтик у великій машині.
• Ззовні вашої команди ваша система квитків діє як інтерфейс / API для вашої команди
• Бізнес-користувачі, які використовують систему квитків, не є розробниками

З гарного дизайну програмного забезпечення ви повинні максимально спростити та інкапсулювати.

Отже, щоб подивитися на процес з точки зору ділових користувачів, вони дійсно дбають лише про дві речі.

1. Скільки це буде коштувати?
2. Ми вже закінчили?

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

Якщо не захистити внутрішній стан вашої команди, пропонується іншим командам керувати вашими ресурсами і поводитися з вашим внутрішнім станом.