Меню

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

8 key performance indicators

Опитайте Нашия Инструмент За Премахване На Проблемите

Тази статия обяснява 8 ключови показатели за ефективност на изданията за качество с помощта на тестовото решение Panaya Test Dynamix от край до край:

Не е тайна, че мениджърите за качество на софтуера са изправени пред нарастващ натиск да доставят висококачествен софтуер с рекордна скорост.

Въпросът, който често задаваме на всички нас, е - „как измерваме успеха си“ по отношение на качеството на софтуера?

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

Накратко, броят на променливите, който играе на приемливо ниво на дефекти с висока тежест не трябва да се подценява. Следователно, за да оцелеем на този пазар, ние трябва да се развиваме непрекъснато, както в нашето мнение, така и в нашите измервателни пръчки.

Това е причината, поради която разработих този списък с 8-те най-важни KPI, които трябва да добавите към вашата карта с показатели за качество и да започнете да проследявате, за да смекчите риска от пускане, да подобрите качеството и да измервате вашия успех веднага.

Основни показатели за ефективност

Какво ще научите:

Основни показатели за ефективност за издаване на качество

# 1) Ефективност на откриване на дефекти (DDE, AKA Процент на откриване на дефекти)

Това е мярка за вашето цялостно регресивно тестване ефикасност. Изчислява се като съотношение на дефекти, открити преди и след пускането от вашите клиенти.

Дефектите, открити след освобождаването, обикновено са известни като „Инциденти“ и са регистрирани в система за помощ, докато дефектите, открити по време на фазите на тестване ( E.g. , Unit, System, Regression или UAT) се идентифицират преди пускането и се документират с инструментите като Тест Panaya Dynamix .

За да изчислите правилно този KPI, винаги трябва да категоризирате версията на софтуера, в която е установен всеки дефект, преди да бъде пусната във вашата производствена среда.

Формулата, често използвана за DDE:

Брой дефекти, идентифицирани при издаване на версията на софтуера /

Брой дефекти при издаване на софтуер + избягали дефекти, идентифицирани от крайните потребители (E.g., Инциденти)

Ето една проста илюстрация:

Да предположим, че са открити 95 дефекта по време на вашия цикъл на регресионно тестване на последния месечен SAP Service Pack и 25 дефекта са регистрирани след издаването. DDE ще се изчисли като 95, разделено на (95 + 25) = 79%.

Имайте предвид, че DDE трябва да се следи с линейна диаграма, която започва от 100% на ден след пускането му в производство. И тъй като вашите вътрешни крайни потребители и клиенти започват да работят с най-новия ви сервизен пакет SAP като пример, те неизбежно ще регистрират няколко инцидента.

Моят опит е, че „лудост по храненето“ се появява през първата седмица 2 дни след като Service Pack достигне продуктивната среда. Тогава ще забележите бърз спад от 100% на около 95% при регистриране на инциденти. Ако вашата компания е на месечна честота на освобождаване на Service Pack, измервайте DDE за период от 30 дни за всеки Service Pack.

От друга страна, ако вашата компания изпълнява само четири (4) основни цикъла на издаване годишно, измервайте я в продължение на 90 дни, за да видите как тя намалява през този период от време.

Какво се счита за „добър DDE“?

Прилича много на показанията на кръвното налягане, които всяка организация и човек еволюират с течение на времето.

Въпреки че медицинската общност определя „оптималното“ отчитане на кръвното налягане като 120/80 - естествено е да наблюдаваме повишаване на систолното кръвно налягане с напредването на възрастта. С DDE специалистите в сферата на промишлеността и лидерите на мисленето казват, че 90% са похвални в повечето индустрии.

Виждал съм обаче, че организациите постигат> 95% DDE последователно, като се преместват наляво с инструменти за симулация на въздействието на промяната, като например Анализ на въздействието на Panaya .

# 2) Системни дефекти (SWD)

Срещали ли сте някога множество дефекти, свързани с едни и същи обекти? Със сигурност бихте го направили. Това е често срещано явление, с което се сблъскват много ръководители на тестове.

Изведнъж виждате огромен ръст в броя на грешките, съобщени в цикъл на UAT. За щастие, обзалагам се, че сте от типа, който следи дефектите на всеки 15 минути и ръчно „свързва“ дубликатите заедно или чете всяко описание, за да разпознаете сами първопричината, нали? Съмнително.

най-добрият софтуер за клониране за Windows 10

И така, какви са вашите възможности за справяне с неизбежната драма на „дефектната инфлация?“

Драмата, която се разиграва при тази нощна реплика с ръководството в щаба относно „Защо толкова внезапно нарастване на дефектите днес?“ (Пауза .... Дълбоко вдишване, преди да отговорите) ... „В процес съм на работа с нашите функционални потенциални клиенти, за да извърша ръчен анализ на първопричината.

Но ние смятаме, че много от проблемите са свързани с общ проблем, но това все още не е идентифицирано ”, звучи познато?

Моето предложение е да започнете да проследявате това, което Panaya призовава „Системни дефекти“ . Проследяването на това ръчно отнема завинаги - повярвайте ми, опитах го много пъти. Също така е болезнено да се прави, докато използвате стари инструменти за ALM, където всичко, което ви остава, е възможността да свързвате дефектите един с друг и да добавяте коментар.

Леле, това наистина помогна! (усещате сарказма?). Но ако сега нямате избор между инструментите, тогава ще трябва да отделите време за правилно проследяване на дефекти в цялата система, за да можете ясно да „обясните“? защо линията на тенденция на грешки се движи нагоре към края на тестовия цикъл, а не надолу.

Ако имате шанс, проверете Panaya Test Dynamix, той има SWD, вграден в самия двигател, който автоматично изчислява SWD за вас в движение.

Дефект в цялата система

Паяжината - Разположен в „Кокпита на риска“ на тази платформа, това е мощно, но просто представяне на 6-те допълнителни ключови показателя за ефективност, което закръглява най-важните KPI, които всеки мениджър за качество, тестване и пускане трябва да проследява.

# 3) Попълване на изискванията

QA мениджърите разбират риска на по-дълбоко ниво, който може да бъде реализиран само с код или видимост на ниво транспорт, навита към всяко изискване. Това изисква правилния набор от инструменти.

Инструментът Panaya ще отговори на нуждите на организациите, управлявани от SAP, които търсят интелигентни предложения за единични тестове и анализ на риска въз основа на транспортната дейност.

Това ниво на проследяване е достъпно в рамките на Panaya Release Dynamix (RDx) .

Попълване на изискванията

# 4) Завършване на разработката

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

Нашите традиционни ALM модели от миналото не са проектирани за модела на непрекъсната доставка днес. За да се преборят с този стар начин на мислене, мениджърите за осигуряване на качеството и тестване трябва да се включат в действието на разработката на приложения, което означава да има импулс за доставяне на потребителски истории.

Не е достатъчно да „седите и да чакате“, докато потребителска история достигне готовия статус. По-скоро трябва да проследим развитието на потребителска история, да присъстваме на ежедневните срещи на Scrum и да говорим открито за възникващите рискове с важни промени, направени в тестваното приложение.

# 5) Покритие на тестовия план

Това е един от любимите ми KPI за проследяване, тъй като не съм принуден да проследявам системата, интеграцията, регресията и покритието на UAT.

В истинския дух на смяна наляво започнах да съветвам относно важността на проследяването на тестовото покритие. Звучи налудничаво, нали? Не е, особено ако имате подходящите инструменти, за да улесните самото изпълнение на единични тестове, но улеснява дори събирането на действителните резултати (доказателства).

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

Изисквания за проследяване

# 6) Анализ на риска от промяна

Рискът е присъщ на всяка промяна, която правим в тествано приложение, но не винаги знаем дали тестваме правилните неща.

Много организации имат собствена дефиниция за това какво означава „риск от промяна“ за тях. В рамките на „Risk Cockpit“ на Release Dynamix (RDx) на Panaya можете да извадите предположенията от проследяването на промените с анализ на въздействието за вашия проект или следваща версия.

RDx систематично изчислява риска за всяко изискване и Ви информира за това как се променя, докато преминавате по-напред в жизнения цикъл на доставката.

Анализ на риска от промяна

# 7) Риск за изпълнение на теста

Твърде често е за всички организации да проследяват KPI като авторски тестове, преминали тестове, автоматизирани тестове и изпълнени тестове, но какво ще кажете за проследяване на действителните стъпки, изпълнени във всеки от тестовете?

Забелязвали ли сте някога, че много от популярни ALM платформи не предоставяте готови възможности за отчитане за проследяване на напредъка в изпълнението на „стъпка“ на теста? Когато имате много различни „предавания“, възникващи в a UAT цикъл , има смисъл да проследявате риска и състоянието на изпълнението на теста, не само на ниво тест, но и на ниво бизнес процес.

Panaya Test Dynamix просто прави това, извън кутията.

тест за изпълнение на теста

# 8) Изпълнение на дефекти

Проследяващите дефекти по своята същност имат и отрицателна конотация.

В допълнение към проследяването на активни дефекти, дефекти, фиксирани на ден, отхвърлени дефекти и тежки дефекти, ние също предлагаме да наблюдавате разрешаването на дефекти, тъй като те се отнасят до изискванията за обхват.

Много организации не възприемат въз основа на изискванията гледна точка на разрешаването на дефекти.

Защо това решение за тестване?

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

Това е особено полезно за мениджъри за издаване, качество и тестове, които търсят птичи поглед на проект или цикъл на пускане.

Panaya ускорява процеса на тестване за технически ИТ и бизнес потребители, като по този начин намалява общите усилия за тестване с 30-50%:

  • Мениджъри: Сигнали в реално време за тестване и дефекти и предотвратяване на затруднения.
  • Бизнес потребители: Автоматизирано документиране на доказателства от теста и дефекти.
  • Функционални анализатори: Автоматизация на повтарящи се тестови дейности.
  • Професионални тестери: Безпроблемно подобрява улавянето на бизнес знания.
  • Разрешители за дефекти: Намалява напред и назад с тестерите.

Какво още трябва да знаете за това решение

# 1) Panaya Test Dynamix е SaaS решение което означава, че получавате безпроблемна интеграция, чести и безболезнени надстройки, както и наблюдение на локални инструменти за автоматизация.

# 2) Вградени инструменти за сътрудничество рационализирайте циклите на тестване с вградени известия и средства за комуникация.

Автоматичното предаване на тестовите стъпки на следващия потребител елиминира времето на празен ход, облекчава пречките при натоварване и осигурява оптимални работни потоци.

# 3) Интелигентно управление на дефекти дава възможност на потребителите да наблюдават централно дефекти, тяхното разрешаване и засегнатите от тях бизнес процеси.

Когато дефектът бъде открит, автоматично идентифицира всички останали тестове, засегнати от него, и блокира или изпраща известия до тестерите, докато основният дефект бъде разрешен. Отстраненият дефект се затваря автоматично, като се елиминира изоставането на дефектите.

# 4) С подход, ориентиран към бизнес процесите към UAT и SIT, междуфункционални и географски разпръснати експерти по валидизират циклите на UAT въз основа на действителните бизнес процеси (пакетирани приложения).

# 5) Тестови конектори за автоматизация осигуряват пълна интеграция на Panaya Test Dynamix със съществуващите инструменти за автоматизация за ефективни цикли на регресия за минимално време и усилия с цялостни възможности за проследяване и наблюдение.

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

какъв е мрежовият ключ за wifi

Спестява време, без усилия да документира всяко изпълнение на теста - включително доказателства от теста и запис на стъпки за възпроизвеждане на теста, като същевременно намалява напред-назад между разработчиците и тестерите. Документацията е готов за одит , гарантира спазването на всички вътрешни и външни стандарти за качество.

# 7) Автономно тестванеSM за SAP дава възможност за създаване и поддръжка на тестови случаи с нулево докосване, така че вече не е необходимо да се справяте с болките, свързани с улавянето на бизнес знания и процеса на създаване и поддържане на ръчно проектирани скриптове.

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

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

Заключение

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

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

За повече информация можете да разгледате Тест Panaya Dynamix .

Споделете вашите мисли / запитвания в коментарите по-долу.

Препоръчително четене

^