Меню

8 ключових показників ефективності випусків якості (Panaya Test Dynamix Review)

8 key performance indicators

Спробуйте Наш Інструмент Для Усунення Проблем

У цій статті пояснюється 8 ключових показників ефективності випусків якості за допомогою наскрізного тестового рішення Panaya Test Dynamix:

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

Питання, яке ми часто задаємо, - “як ми вимірюємо свій успіх” з точки зору якості програмного забезпечення?

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

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

Ось чому я розробив цей список 8 найкращих KPI, які ви повинні додати до своєї карти показників якості та розпочати відстеження, щоб зменшити ризик випуску, покращити якість та негайно виміряти свій успіх.

Ключові показники ефективності

Що ви дізнаєтесь:

Основні показники ефективності для випуску якості

# 1) Ефективність виявлення дефектів (DDE, AKA Відсоток виявлення дефектів)

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

Дефекти, виявлені після випуску, зазвичай називаються “Інциденти” і реєструються в системі довідкової служби, тоді як дефекти, виявлені на етапах тестування ( Наприклад , Unit, System, Regression або UAT) ідентифікуються до випуску та документуються за допомогою таких інструментів Панайя Тест Динамікс .

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

Формула, яка часто використовується для DDE:

Кількість дефектів, виявлених у випуску версії програмного забезпечення /

Кількість дефектів у випуску програмного забезпечення + униклі дефекти, виявлені кінцевими користувачами (Наприклад,., Інциденти)

Ось проста ілюстрація:

Припустимо, що під час вашого циклу регресійного тестування на цьому останньому щомісячному пакеті оновлень SAP було виявлено 95 дефектів, а після дефекту було зареєстровано 25 дефектів. DDE буде розрахований як 95, поділений на (95 + 25) = 79%.

Майте на увазі, що DDE слід контролювати за допомогою лінійної діаграми, яка починається зі 100% на день після випуску у виробництво. І оскільки ваші внутрішні кінцеві користувачі та клієнти починають працювати з вашим останнім пакетом оновлень SAP як приклад, вони неминуче реєструють кілька випадків.

Запитання щодо технічного співбесіди з ++

На моєму досвіді «шалене годування» відбувається протягом першого тижня через 2 дні після потрапляння пакета оновлень у продуктивне середовище. Саме тоді ви помітите швидке падіння зі 100% до приблизно 95%, коли реєструються інциденти. Якщо ваша компанія користується щомісячним періодом випуску пакета оновлень, тоді вимірюйте DDE протягом 30-денного періоду для кожного пакета оновлень.

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

Що вважається «хорошим DDE»?

Це схоже на показники артеріального тиску, які кожна організація та людина еволюціонують з часом.

Хоча медична спільнота визначає 'оптимальним' показником артеріального тиску значення 120/80 - цілком природно спостерігати підвищення систолічного артеріального тиску в міру старіння. З DDE, як відомо, фахівці в галузі та лідери думок стверджують, що 90% - це похвально в більшості галузей.

Однак я бачив, як організації постійно досягають> 95% DDE, переходячи вліво за допомогою інструментів моделювання впливу змін, таких як Аналіз впливу Панаї .

# 2) Загальносистемні дефекти (SWD)

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

Раптом ви бачите величезний ріст кількості помилок, про які повідомляється в циклі UAT. На щастя, я впевнений, що ви відстежуєте дефекти кожні 15 хвилин і вручну “зв’язуєте” дублікати або читаєте кожен опис, щоб самостійно розпізнати першопричину, так? Сумнівно.

Отже, які ваші варіанти для подолання неминучої драми «інфляції дефектів?»

Драма, яка випливає з цього нічного зворотного дзвінка з керівництвом штабу про “Чому сьогодні такий раптовий підйом дефектів?” (Пауза…. Глибоке дихання перед тим, як відповісти)… «Я зараз працюю з нашими функціональними потенційними клієнтами, щоб провести ручний аналіз першопричини.

Але ми вважаємо, що багато питань стосуються загальної проблеми, але це ще не визначено ', Звучить знайомо?

Я пропоную вам розпочати відстеження того, що називає Паная “Загальносистемні дефекти” . Відстеження цього вручну триває вічно - повірте, я це вже багато разів пробував. Це також боляче робити під час використання застарілих інструментів ALM, де вам залишається лише пов’язати дефекти між собою та додати коментар.

Ого, це справді допомогло! (відчуваєте сарказм?). Але якщо у вас зараз немає можливості вибору інструментів, то вам доведеться виділити час для правильного відстеження загальносистемних дефектів, щоб чітко «пояснити їх»? чому лінія тенденції помилок рухається вгору до кінця тестового циклу, а не вниз.

Якщо у вас є можливість, перевірте Panaya Test Dynamix, він має SWD, вбудований в сам двигун, який автоматично обчислює SWD для вас на льоту.

Загальносистемний дефект

Павутина - Перебуваючи в рамках «Кокпіту ризиків» на цій платформі, це потужне, але просте представлення 6 додаткових ключових показників ефективності, що завершує найважливіші ключові показники ефективності, які повинен відстежувати кожен менеджер з якості, тестування та випуску.

# 3) Виконання вимог

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

Інструмент Panaya відповість на потреби організацій, що працюють під управлінням SAP, які шукають розумні пропозиції щодо модульних тестів та аналізу ризиків на основі транспортної діяльності.

Цей рівень відстеження доступний у межах Випуск Panaya Dynamix (RDx) .

Виконання вимог

# 4) Завершення розробки

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

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

c # питання та відповіді на технічне співбесіду

Недостатньо “сидіти і чекати”, поки історія користувача досягне готового статусу. Навпаки, ми повинні стежити за розвитком історії користувачів, відвідувати щоденні зустрічі Scrum і відкрито говорити про ризики, що виникають із важливими змінами, що вносяться в тестовану програму.

# 5) Покриття плану випробувань

Це один з моїх улюблених KPI для відстеження, оскільки я не змушений відстежувати систему, інтеграцію, регресію та охоплення UAT.

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

Завдяки вбудованій в програмі Panaya Test Dynamix тестовій програмі запису та відтворення ваша участь у модульному тестуванні стрімко зросте. Ви не тільки зможете з гордістю відобразити Матрицю простежуваності вимог, що показує наскрізне покриття, але й легко продемонструвати фактичні результати своєму аудиторському відділу від підрозділу до регресійного тестування.

Вимоги до простежуваності

# 6) Аналіз ризику змін

Ризик притаманний будь-яким змінам, які ми вносимо до тестованої заявки, але ми не завжди знаємо, чи тестуємо ми правильні речі.

Багато організацій мають власне визначення того, що для них означає „ризик змін”. У межах «Кокпіту ризику» випуску Dynamix (RDx) від Panaya ви можете зняти здогадки з відстеження змін за допомогою аналізу впливу для вашого проекту або наступного випуску.

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

Аналіз ризику змін

# 7) Ризик виконання тесту

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

Ви коли-небудь помічали, що багато хто з популярні ALM-платформи не надають готові можливості звітування для відстеження прогресу виконання «кроку» тесту? Коли у вас є багато різних 'передач', що відбуваються в межах Цикл UAT , має сенс відстежувати ризик виконання тесту та стан не тільки на рівні тесту, але й на рівні бізнес-процесів.

Тест Panaya Dynamix просто робить це нестандартно.

ризик виконання тесту

# 8) Виконання дефектів

Дефекти відстеження за своєю суттю теж мають негативний відтінок.

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

Багато організацій не дотримуються поглядів на вирішення дефектів.

Чому це рішення для тестування?

Завдяки наскрізній простежуваності, вбудованій як у Release Dynamix, так і в Panaya Test Dynamix, ваша організація може відстежувати робочий процес вирішення дефектів від початку до кінця на рівні вимог.

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

Panaya прискорює процес тестування для технічних ІТ та бізнес-користувачів, тим самим зменшуючи загальні зусилля на тестування на 30-50%:

  • Менеджери: Сповіщення в режимі реального часу про тестування та дефекти та запобігання вузьких місць.
  • Бізнес-користувачі: Автоматизоване документування доказів і дефектів.
  • Функціональні аналітики: Автоматизація повторних тестових заходів.
  • Професійні тестери: Плавно покращує збір бізнес-знань.
  • Вирішувачі дефектів: Знижує вперед-назад за допомогою тестерів.

Що ще ви повинні знати про це рішення

# 1) Тест Panaya Dynamix - це рішення SaaS це означає, що ви отримуєте безперебійну інтеграцію, часті та безболісні оновлення, а також моніторинг локальних засобів автоматизації.

# 2) Вбудовані інструменти для співпраці спростити цикли тестування за допомогою вбудованих сповіщень та засобів зв'язку.

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

# 3) Розумне управління дефектами дозволяє користувачам централізовано контролювати дефекти, їх вирішення та впливають на них бізнес-процеси.

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

додаток, щоб шпигувати за іншим телефоном

# 4) З орієнтованим на бізнес-процес підходом до UAT та SIT, Міжфункціональні та географічно розподілені експерти перевіряють цикли UAT на основі фактичних бізнес-процесів (пакетні програми).

# 5) Тестові з'єднувачі автоматизації забезпечити повну інтеграцію Panaya Test Dynamix з існуючими засобами автоматизації для ефективних циклів регресії за мінімальний час та зусилля з цілісними можливостями відстеження та моніторингу.

# 6) Автоматизація перевірки доказів автоматизує ручне тестування, традиційно кероване в Excel та Word.

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

# 7) Автономне тестуванняSM для SAP дозволяє створювати та обслуговувати тестові кейси з нульовим дотиком, тому вам більше не потрібно боротися з болем, пов’язаним із захопленням бізнес-знань та процесом створення та обслуговування сценаріїв, розроблених вручну.

Сценарії можна налаштувати, тоді як машинне навчання пропонує перевірку та пропозиції на основі аналізу натовпу.

# 8) Автоматизований збір бізнес-знань - Omega автоматично створює реальні тестові кейси на основі діяльності бізнес-користувачів, яка безперешкодно фіксується у виробництві за допомогою алгоритмів машинного навчання (SAP).

Висновок

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

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

Щоб отримати додаткову інформацію, ви можете ознайомитися Панайя Тест Динамікс .

Повідомте нам про свої думки / запитання в коментарях нижче.

Рекомендована література

^