Що є хорошим показником ефективності тестування / тестування?

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

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

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

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

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

Оскільки якість хороша, якщо клієнти не стикаються з проблемами, то хороший показник ефективності (а не ефективності) команди QA та процесу є мірою помилок, виявлених клієнтами, які не знайшли QA .

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

Є кілька показників, які ми використовували на моїй останній роботі для оцінки якості:

• Кількість знайдених помилок. Я ненавиджу цього. Це як "Кількість написаних рядків коду" для розробника.
• Кількість вироблених автоматизованих тестових випадків.
• Відсоток загальної кількості заявок, охоплених функціональним тестуванням.
• Кількість помилок, виявлених під час постановки та виробництва.

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

QA слід виміряти двома основними показниками: скільки помилок минуло QA, щоб знайти їх у полі? Яка їх суворість?

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

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

Компанія, в якій я працюю, використовує ряд показників якості.

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

Що б ви не робили, не орієнтуйтеся на кількість тестів. Це приблизно так само корисно, як і LOC на день.

Багато способів вимірювання ефективності на етапах розробки та тестування під час виконання проекту. Нижче ми використовували заходи в наших проектах. Ефективність розробки вимірюється 4 популярними показниками коду (індекс ремонтопридатності, циклометрична складність, глибина успадкування, класові муфти). Для C # отримає його в Microsoft Visual Studio. Для тестового покриття дуже корисний Ncover / Ndepend. Ефективність тестування, виміряна відсутністю помилок розвитку - перехід останніх 4 спринтів Система тестування помилок, що перекидаються останні 4 спринти Жоден тест автоматизації не пройшов, зокрема, випущені / Особливості поставлені.