Economie
Testarea eficacității sistemului de control intern
Rakhmankulov I.Sh.
doctor în economie, profesor la Departamentul de Management al Producției, Institutul de Stat pentru Finanțe și Economie din Kazan
Lucrarea arată necesitatea de a testa eficiența sistemului de control intern pentru pregătirea situațiilor financiare, arată procedura de implementare a acestuia. Autorul oferă o evaluare a elementelor de control automat și manual.
Pentru a demonstra eficiența controlului intern asupra pregătirii situațiilor financiare, conducerea ar trebui să stabilească cât de eficient funcționează controalele în companie. În conformitate cu cerințele Legii Sarbanes-Oxley (SOX), testarea trebuie să acopere fiecare dintre cele cinci elemente ale sistemului de control intern (mediu de control, evaluare a riscurilor, proceduri de control, informații și comunicare, monitorizare) în raport cu cerințele de raportare financiară pentru toate componentele sale materiale separat. fiecare unitate de afaceri cheie. Testarea performanței ar trebui să acopere, de asemenea, domeniile asociate cu riscuri specifice în restul unităților de afaceri. Testarea poate fi împărțită în patru etape principale:
1. Determinarea controalelor de testat.
2. Identificarea angajaților care vor efectua teste.
3. Elaborarea și implementarea planurilor de testare.
4. Evaluarea rezultatelor testelor.
În mod obișnuit, acești pași sunt realizați secvențial, dar uneori sunt în neregulă deoarece rezultatele testelor pot forța modificările planului sau pot necesita re-testarea articolelor revizuite. Coordonarea
comitetul de proiect ar trebui să revizuiască și să aprobe planurile de testare care detaliază abordarea principală a procedurii de testare. Conducerea nu trebuie să subestimeze timpul necesar testării și complexitatea care poate apărea în timpul fazei de testare a unui proiect.
Vă recomandăm să stabiliți un dialog deschis cu auditorul extern al companiei cu privire la strategia conducerii pentru testarea eficacității operaționale. Auditorul extern ar trebui, de asemenea, să evalueze planurile detaliate de testare. Evaluarea de către conducere a eficacității controalelor interne asupra pregătirii situațiilor financiare are ca rezultat un nivel de asigurare. Asigurarea adecvată este fundamentală atât în \u200b\u200bevaluarea controlului intern asupra pregătirii situațiilor financiare, cât și în scopul raportului auditorului. Asigurarea adecvată implică faptul că este puțin probabil ca denaturările semnificative să nu fie prevenite sau detectate în timp util. Deși o certitudine suficientă nu este absolută, este un grad ridicat de certitudine. Pentru a obține un grad ridicat de încredere, conducerea trebuie să obțină suficiente dovezi ale proiectării corecte și eficacității operaționale a controalelor pentru a acoperi cerințele financiare.
„Buletin de economie, drept și sociologie”, nr. 1, 2007
Economie
raportarea pentru toate componentele semnificative ale situatiilor financiare din fiecare unitate de afaceri cheie. În timp ce dovezile de audit ale eficacității operaționale se bazează în general pe testarea tradițională (adică eșantionarea și verificarea controlului), conducerea are mai multă discreție în ceea ce privește modul în care vor fi obținute dovezile necesare.
De exemplu, conducerea poate obține dovezi ale proiectării corecte și eficacității operaționale a controalelor printr-un proces de autoevaluare, audituri interne sau monitorizare continuă. Aceasta nu înseamnă că managementul poate evita testarea controalelor cheie. Mai degrabă, înseamnă că managementul poate utiliza surse alternative de dovezi (dacă sunt disponibile) împreună cu testarea detaliată a eșantionului pentru a obține un grad mai mare de încredere. Prin urmare, conducerea poate să nu testeze fiecare control în detaliu în modul în care o face auditorul. În elaborarea planului său de testare, conducerea trebuie să stabilească dacă are alte surse de dovezi decât cele obținute în urma testării detaliate a eșantionului. În cazul în care conducerea stabilește că există astfel de dovezi, aceasta poate decide reducerea dimensiunii eșantionului din eșantionul auditorului, pe care auditorul îl consideră necesar pentru a oferi un grad ridicat de asigurare.
Împreună cu efectuarea altor teste (de exemplu, autoevaluare etc.), conducerea trebuie să utilizeze dimensiuni ale eșantionului astfel încât numărul total de articole testate pentru a evalua eficacitatea operațională a controalelor cheie să nu fie mai mic decât cel prezentat în tabel. Dacă managementul nu are alte surse de dovezi, dimensiunea eșantionului utilizat de conducere pentru testare ar trebui să depășească dimensiunile minime indicate în tabel. În cazul în care una sau mai multe cerințe de raportare financiară cu privire la materiale
există un singur control asociat cu componentele specifice ale situațiilor financiare, atunci când controlul este considerat mai important sau când este necesar un grad mai mare de încredere, dimensiunea eșantionului trebuie, de asemenea, mărită. Testarea continuă ajută la reducerea riscului ca deficiențele semnificative sau semnificative ale sistemului de control intern să fie identificate prea târziu și să nu poată fi corectate până la sfârșitul anului.
Conducerea trebuie să demonstreze că controalele, care acoperă toate cele cinci componente ale modelului COSO, funcționează eficient în toate componentele de raportare financiară, procesele de afaceri și unitățile de afaceri. Natura testelor efectuate pe procedurile de control este, în general, mai simplă decât natura testelor efectuate pe alte componente ale controlului intern. Evaluarea eficacității controalelor legate de componentele COSO, cum ar fi mediul de control, evaluarea riscurilor, informațiile și comunicarea, și monitorizarea necesită, de obicei, mai multă dependență de judecata profesională și analiza calitativă decât în \u200b\u200bevaluarea procedurilor de control.
Deciziile luate în timpul fazelor de scop și documentare determină alegerea unităților de afaceri și testarea care trebuie efectuată (prezentată în tabelul 1). Pentru unitățile de afaceri din prima categorie, testarea va acoperi controalele la nivel de tranzacție pentru componentele materiale ale raportării și proceselor financiare, precum și controalele la nivel de întreprindere. Pentru unitățile de afaceri din a treia categorie, nu este necesară testarea specifică a controalelor. În unitățile de afaceri din a doua categorie, conducerea ar trebui să documenteze și să testeze eficacitatea controalelor la nivel corporativ. De exemplu, pentru a determina dacă politicile contabile ale unei entități sunt respectate, conducerea ar trebui să testeze pe unități de afaceri individuale din categoria 2 pentru a determina dacă acțiunile personalului sunt în concordanță cu politicile contabile aprobate. Conducerea poate obține, de asemenea, dovada funcționării
„Buletin de economie, drept și sociologie”, nr. 1, 2007
Economie
eficiența procedurilor de control desfășurate în aceste unități de afaceri prin instrumente precum autoevaluarea, auditul intern și monitorizarea.
Tabelul 2 prezintă sugestii pentru selectarea minimului necesar de unități de afaceri din categoria 2, în care ar trebui testate controalele la nivel de întreprindere.
Dacă controalele la nivel corporativ nu pot fi invocate pentru unitățile de afaceri din a doua categorie, atunci ar trebui efectuate testări detaliate ale controalelor care acoperă componentele semnificative ale situațiilor financiare.
În conformitate cu standardele de control intern, conducerea poate evalua eficacitatea operațională a controalelor pe baza procedurilor, cum ar fi testarea controalelor prin audit intern, testarea de către alții conform indicațiilor conducerii, utilizarea rapoartelor terților, examinarea dovezilor că au fost exercitate controale sau testarea lor prin autoevaluare. Unele dintre aceste tipuri de evaluări pot fi efectuate ca parte a monitorizării continue a managementului. În toate cazurile, conducerea este responsabilă de (1) competența și obiectivitatea personalului care evaluează controalele; (2) obținerea, ca rezultat al testării, a unor dovezi suficiente pentru a justifica o evaluare a eficacității sistemului de control intern. Pentru a obține un nivel suficient de încredere în rezultatele procesului de autoevaluare, managementul poate fi necesar să fie revizuit independent. Standardul prevede că, în cazurile în care dovezile eficienței operaționale a controlului sunt furnizate de către persoana care exercită controlul, acesta nu poate fi utilizat de auditorul extern pentru a reduce domeniul de aplicare al testării, deoarece persoana care testează controlul nu va fi suficient de obiectivă.
Planul de testare ar trebui să includă descrieri și rezultate ale testelor pentru examinarea și aprobarea rezultatelor testelor de către diferite părți interesate. Planurile de testare trebuie să acopere toate controalele selectate pentru testare și să conțină următoarele elemente cheie:
Controale cheie care trebuie testate - de regulă, conducerea oferă un rezumat al controalelor care trebuie testate la nivelul cerințelor de raportare financiară.
Metode de testare - Există patru metode de testare: confirmare, observare, revizuirea documentelor sau reexecutare.
Eșantion de testare - Planurile ar trebui să indice cantitatea de dovezi ale procedurii de control care urmează să fie testate, precum și metodele și baza pentru selectarea acestora.
Momentul procedurilor - planurile ar trebui să indice momentul testării și intervalul de timp pe care îl acoperă, inclusiv testarea unui eșantion suplimentar de documente planificate de la momentul testării intermediare până la sfârșitul anului.
Descrierea procedurii de testare - Planurile vor detalia procedurile de testare și cerințele de raportare financiară acoperite de procedurile de control al testelor.
Organizarea procedurii de testare - planurile ar trebui să indice cine va efectua testul și când, ce dovezi vor fi analizate și unde se efectuează controlul.
Documentație - Planurile ar trebui să descrie documentația necesară.
Excepții - Planurile ar trebui să descrie modul de investigare și abordare a excepțiilor eșantionului (inconsecvențe) și a momentului în care urmează să fie efectuate teste suplimentare.
Există 4 metode de testare: confirmare, observare, revizuirea documentelor și reexecutare. Folosirea a două sau mai multe dintre aceste metode de testare în același timp oferă un grad mai mare de încredere decât utilizarea uneia dintre ele. Cu cât materialitatea unei componente de informații financiare sau a unui proces de afaceri este mai mare și cu cât este mai mare riscul, cu atât este mai important să se asigure că dovezile sunt obținute prin metode de testare multiple.
„Buletin de economie, drept și sociologie”, nr. 1, 2007
Economie
Domeniul de aplicare al propunerilor de lucru
tabelul 1
Categorie Bilanț minim de acoperire a contului Unități de afaceri Proceduri planificate
1 60 - 70% Unități de afaceri cheie și componente de raportare financiară asociate cu riscuri specifice Evaluare detaliată și testare a controalelor asupra conturilor materiale și (sau riscului specific) și a prezentărilor la site-urile relevante, precum și testarea controalelor la nivel corporativ.
2 25 - 35% Unități de afaceri care sunt cheie în ansamblu Evaluează și testează controale la nivel de întreprindere, dacă este posibil, și ia în considerare obținerea altor dovezi sau efectuarea unor teste de controale în unități de afaceri, dacă nu există controale la nivel de întreprindere.
3 < 5% Объекты, не являющиеся ключевыми ни по отдельности, ни в совокупности Тестирование не требуется.
masa 2
Propuneri pentru selectarea unităților de afaceri
Numărul de unități de afaceri Numărul de unități de afaceri în care urmează să fie testate controalele la nivel de întreprindere
Mai puțin de 20 2 - 4
100 sau mai mult 10 - 20 sau mai mult
niya. Natura controlului influențează, de asemenea, alegerea metodei de testare.
Confirmarea informațiilor legate de eficacitatea operațională a controalelor nu constituie în sine dovezi ale funcționării eficiente a controalelor.
Observarea controalelor oferă un grad mai mare de încredere și poate fi o metodă acceptabilă pentru evaluarea controalelor automate.
Revizuirea documentelor este adesea utilizată pentru a determina dacă controalele manuale sunt în desfășurare.
Efectuarea repetată a procedurii de control oferă cel mai mare grad de încredere. Majoritatea controalelor manuale sunt testate folosind o combinație de metode de testare: confirmare, observare, revizuirea documentelor și reexecutare.
Măsura în care este testată o anumită procedură de control va depinde de o serie de factori, cum ar fi dacă controlul este automat sau manual. Dimensiunea eșantionului pentru testarea controalelor automate poate fi minimă (unul sau mai multe articole), cu condiția ca
„Buletin de economie, drept și sociologie”, nr. 1, 2007
Economie
că controalele computerizate generale aplicate în sistemul IT au fost testate și s-au dovedit a fi eficiente.
Una dintre cele mai frecvente controale automate este introducerea datelor și controalele de editare. Pe baza combinațiilor permise de servicii și prețuri furnizate în baza de date, controlul rezultatelor editării nu permite angajatului care introduce comanda să indice prețul greșit pentru serviciu. Eficacitatea operațională a fiecărui element de control automat ar trebui testată. În acest exemplu, pentru a demonstra eficacitatea operațională a controlului, trebuie introduse mai multe combinații diferite de preț / serviciu incorecte. Uneori, drepturile de acces extinse ale conducerii îi permit să editeze datele introduse și astfel să ocolească controlul automat. Această capacitate de editare a manualului ar trebui testată pentru a evalua o potențială deficiență a sistemului de control intern.
Atunci când testează controalele automate, conducerea ar trebui (1) să se asigure că controalele globale ale computerului sunt eficiente și (2) să efectueze o revizuire detaliată a controalelor în cadrul companiei (de exemplu, revizuiri pre-implementare și post-implementare). În exemplul anterior, conducerea ar fi trebuit să-i facă pe angajați să înțeleagă că controlul asupra introducerii și editării datelor ar trebui să fie eficient în toate circumstanțele. Dacă conducerea nu a efectuat niciodată testarea detaliată a controalelor în software-ul unei companii - nici înainte, nici după implementare - sau controalele asupra modificărilor software-ului sunt slabe, conducerea ar trebui să testeze controalele automate în raport cu designul lor original.
Există mai multe moduri de a îndeplini această sarcină, de la situații de urgență, atunci când se analizează codul programului, până la testarea de la capăt la cap, oferind încredere că controlul acoperă toate lanțurile logice relevante. Pentru software-ul de la dezvoltatori externi care nu a fost modificat,
managementul trebuie să confirme că configurațiile implicite au fost configurate corect și să ofere control asupra modificărilor aduse acestora. Aplicațiile dezvoltate de specialiști externi pentru companie sau dezvoltate de specialiști interni ai companiei pot necesita proceduri mai extinse pentru a valida eficacitatea proiectării controlului.
Principalele concluzii:
1. Asigurarea calității. Dacă conducerea consideră că este necesară o mai mare obiectivitate pentru efectuarea testelor, atunci o persoană sau un departament independent poate fi desemnat să efectueze testarea. Cel mai potrivit și obiectiv candidat pentru această sarcină este departamentul de audit intern, care poate aproba atât planurile de testare, cât și evaluarea rezultatelor acestuia.
2. Structura planurilor de testare. În majoritatea cazurilor, mai multe controale pot fi testate pe un singur eșantion de operațiuni care reflectă fluxul procesului de afaceri, permițând testerului să înțeleagă mai bine modul în care interacționează diferitele proceduri de control. De exemplu, o metodă de testare a controalelor ca parte a procesului de contabilitate a veniturilor este identificarea unui eșantion de noi contracte de vânzare. Autorizarea contractelor poate fi testată verificând dacă semnăturile necesare sunt prezente în cadrul contractului. Corectitudinea prețurilor poate fi verificată prin evaluarea (a) conformității procedurii de modificare a prețului cu instrucțiunile aprobate ale companiei și (b) existența unei autorizări corespunzătoare a acestor prețuri.
3. Diferențele dintre comenzile automate și cele manuale. În majoritatea cazurilor, este ușor să se stabilească dacă controlul este automat sau manual. Uneori, totuși, identificarea acestei diferențe poate fi dificilă. Mecanismul de control se poate baza pe un proces automat, dar componenta sa cheie va fi manuală. De exemplu, un exemplu comun de inspecție este compararea sistematică a rapoartelor de primire a mărfurilor,
„Buletin de economie, drept și sociologie”, nr. 1, 2007
Economie
comenzi de achiziție și facturi de la furnizori. Sistemul generează automat un raport de nepotrivire pentru toate articolele nepotrivite. Aceste neconcordanțe sunt apoi analizate și corectate de către departamentul de conturi de plătit. Acest mecanism de control constă din două elemente (1) potrivire automată în trei direcții și (2) analiză manuală.
de către angajații departamentului contabilitate datorii. Controalele automate și manuale ar trebui evaluate separat, folosind instrucțiuni de testare adecvate.
Literatură:
1. Un ghid practic pentru management. Legea Sarbanes-Oxley (secțiunea 404). Editor: nyu x. 2005 .-- 138 p.
Procesul de testare trebuie să fie eficient în primul rând din punctul de vedere al companiei în care are loc. Compania poate fi interesată de următorii parametri ai procesului de testare:
- Timpul necesar pentru dezvoltarea testelor
- Timp care durează un ciclu de testare
- Calificările personalului necesare pentru proiectarea și efectuarea testelor
Prin modificarea oricăruia dintre acești parametri, o companie poate afecta calitatea testării. Cu toate acestea, este important să înțelegem că orice combinație a acestor parametri poate fi exprimată în termeni monetari și, de regulă, orice proces particular de testare are o combinație optimă, care atinge un nivel suficient de calitate a testării la un cost minim.
Prin automatizarea procesului de testare, desigur, schimbăm procesul de testare și, odată cu acesta, se va schimba combinația optimă a parametrilor de mai sus. De exemplu, se poate aștepta ca timpul necesar pentru dezvoltarea testelor să crească și cerințele pentru calificările personalului vor crește, în timp ce timpul necesar pentru un ciclu de testare va scădea foarte mult. Având în vedere că combinația de parametri a devenit nouă, calitatea testării se va schimba probabil împreună cu costul acesteia. Pentru a putea oferi un echivalent numeric eficacității procesului de testare, se propune fixarea parametrului de calitate la un anumit nivel. Apoi, o estimare numerică a eficacității unei anumite metode de testare va fi suma investiției necesare pentru a se asigura că aceasta asigură un anumit nivel de calitate.
Evaluarea fezabilității automatizării testării se realizează prin calcularea costurilor testării manuale și automate și compararea acestora. De obicei, este imposibil să se calculeze cu precizie fezabilitatea financiară a testelor de automatizare, deoarece depinde de parametri care pot fi înțelese aproximativ în timpul dezvoltării produsului (de exemplu, durata planificată a ciclului de viață al sistemului sau lista exactă a testelor care urmează să fie automatizate).
Pentru a calcula investiția necesară pentru implementarea și funcționarea testelor automate pentru o anumită perioadă (Ip), se folosește următoarea formulă:
I0 - Evaluarea investiției inițiale, care constă în costul licențierii software-ului necesar dezvoltării autotesturilor, costul hardware-ului suplimentar etc.
C0 - O estimare a costului dezvoltării și depanării unei biblioteci de teste automate, care este calculată ca produs al timpului mediu necesar pentru a scrie un test automat de către un dezvoltator de teste (în ore), înmulțit cu prețul orei sale de lucru și numărul total de teste care urmează să fie automatizate.
Ce - O estimare a costului unei runde a tuturor testelor automate, care se calculează ca timpul necesar pregătirii pentru a rula un test, adăugat la timpul mediu luat pentru un test de un tester, înmulțit cu costul unei ore de lucru și cu numărul total de teste. În cazul nostru, această variabilă este considerată 0, deoarece pregătirea pentru ciclul de testare nu este necesară, iar testarea în sine nu necesită un control suplimentar de la angajat și are loc complet autonom.
Ca - O estimare a costului analizei rezultatelor unei iterații a ciclului automatizat de testare, care se calculează ca o estimare a proporției testelor negative înmulțite cu numărul de teste, timpul mediu necesar pentru a analiza motivele pentru o evaluare negativă a unui test de către un tester și prețul unei ore de lucru a unui tester.
Cm - Estimați costul menținerii actualizate a testelor automate. Se calculează ca probabilitatea necesității de a schimba un test între ciclurile de testare, înmulțit cu numărul de teste, cu timpul mediu necesar pentru actualizarea unui test și cu prețul unei ore de lucru a unui tester.
O estimare a costului testării manuale (Gp) este prezentată în următoarea formulă:
G0 - Estimarea costului dezvoltării unei baze de cazuri de testare pentru testarea manuală.
k - Acesta este numărul de testări planificate (cicluri de testare) pentru tot timpul rămas din ciclul de viață al produsului.
Ge - O estimare a costului executării unice a unui ciclu de testare manuală, care se calculează ca timpul mediu petrecut la pregătirea pentru testare plus timpul mediu necesar pentru a finaliza un caz de testare cu un tester, înmulțit cu numărul total de cazuri și cu prețul unei ore de lucru ale unui tester.
Ga - Estimați costul analizei rezultatelor pentru o singură etapă a ciclului de testare manuală. Se calculează ca o estimare a ponderii medii a testelor negative într-o alergare, înmulțită cu numărul de teste, cu timpul mediu necesar pentru a analiza motivele unei evaluări negative a unui test de către un tester și prin prețul unei ore de lucru a unui tester;
Gm - Costul estimat al actualizării testelor manuale. Se calculează ca probabilitatea necesității de a schimba un test între ciclurile de testare, înmulțit cu numărul de teste, cu timpul mediu necesar pentru actualizarea unui test și cu prețul unei ore de lucru a unui tester.
De fiecare dată când eșuăm o altă versiune, începe graba. Cei vinovați apar imediat și adesea suntem noi, testerii. Poate că destinul este ultimul link din ciclul de viață al software-ului, așa că, chiar dacă un dezvoltator petrece mult timp scriind cod, nimeni nu crede că testarea este și persoanele cu anumite capacități.
Nu poți sări deasupra capului, dar poți lucra 10-12 ore. Am auzit foarte des astfel de fraze)))
Atunci când testarea nu satisface nevoile afacerii, atunci apare întrebarea, de ce să testeze deloc, dacă nu au timp să lucreze la timp. Nimeni nu se gândește la ce s-a întâmplat înainte, de ce cerințele nu au fost scrise în mod normal, de ce arhitectura nu a fost gândită, de ce codul este strâmb. Dar când ai un termen limită și nu ai timp să finalizezi testarea, atunci încep imediat să te pedepsească ...
Dar acestea au fost câteva cuvinte despre viața grea a unui tester. Acum la punctul 🙂
După câteva astfel de falsuri, toată lumea începe să se întrebe ce este greșit în procesul nostru de testare. Ca lider, este posibil să înțelegeți problemele, dar cum le comunicați conducerii? Întrebare?
Conducerea are nevoie de cifre, statistici. Cuvinte simple - te-au ascultat, au clătinat din cap, au spus - „Haide, fă” și gata. După aceea, toată lumea așteaptă un miracol de la tine, dar chiar dacă ai făcut ceva și nu ai reușit, tu sau liderul tău primești din nou o pălărie.
Orice modificare trebuie să fie susținută de conducere, iar pentru ca conducerea să o susțină, au nevoie de numere, măsurători, statistici.
De multe ori am văzut cum au încercat să descarce diferite statistici de la urmăritorii de sarcini, spunând că „Eliminăm valorile din JIRA”. Dar să vedem ce este o metrică.
Metrica este o cantitate măsurabilă din punct de vedere tehnic sau procedural care caracterizează starea unui obiect controlat.
Să vedem - echipa noastră găsește 50 de defecte în timpul testelor de acceptare. E mult? Sau puțin? Aceste 50 de defecte vă spun despre starea obiectului de control, în special despre procesul de testare?
Probabil ca nu.
Și dacă vi s-ar spune că numărul de defecte constatate în timpul testului de acceptare este de 80%, în timp ce acesta ar trebui să fie de doar 60%. Cred că este clar imediat că există o mulțime de defecte, respectiv, ca să spunem ușor, codul dezvoltatorilor este plin de g ... .. nesatisfăcător din punct de vedere calitativ.
Cineva ar putea spune de ce testarea atunci? Dar voi spune că defectele sunt timpul de testare, iar timpul de testare este ceea ce ne afectează în mod direct termenul.
Prin urmare, nu avem nevoie doar de valori, ci de indicatori de performanță.
KPI este o valoare care servește ca indicator al stării obiectului de control. O condiție prealabilă este prezența unei valori țintă și a toleranțelor stabilite.
Adică, întotdeauna, atunci când construiți un sistem de valori, trebuie să aveți un obiectiv și abateri acceptabile.
De exemplu, aveți nevoie (obiectivul dvs.) ca 90% din toate defectele să fie rezolvate de la prima iterație. În același timp, înțelegeți că acest lucru nu este întotdeauna posibil, dar chiar dacă numărul de defecte rezolvate prima dată este egal cu 70%, acest lucru este, de asemenea, bun.
Adică ți-ai stabilit un obiectiv și o marjă de eroare. Acum, dacă numărați defectele în versiune și obțineți o valoare de 86%, atunci acest lucru nu este cu siguranță bun, dar nu mai este un eșec.
Din punct de vedere matematic, va arăta ca:
De ce 2 formule? Acest lucru se datorează faptului că există un concept de valori de jos în sus și de sus în jos, adică atunci când valoarea țintă se apropie de 100% sau 0%.
Acestea. dacă vorbim, de exemplu, despre numărul de defecte constatate după implementarea în exploatare industrială, atunci aici, cu atât mai puțin cu atât mai bine, și dacă vorbim despre acoperirea funcționalității prin cazuri de testare, atunci totul va fi invers.
În același timp, nu uitați de modul de calculare a acestei sau a altor valori.
Pentru a obține procentele, piesele etc. de care avem nevoie, trebuie să calculăm fiecare valoare.
Pentru un exemplu ilustrativ, vă voi spune despre metrica „Actualitatea procesării defectelor prin testare”.
Folosind o abordare similară, pe care am descris-o mai sus, formăm, de asemenea, KPI pentru metrică pe baza valorilor și abaterilor țintă.
Nu vă alarmați, în viață nu este la fel de dificil pe cât arată în imagine!
Ce avem?
Ei bine, este clar că numărul lansării, numărul incidentului ...
Critic - cote. cinci,
Major - cote. 3,
Minor - cote. 1.5.
Apoi, trebuie să specificați SLA pentru momentul procesării defectelor. Pentru aceasta, valoarea țintă și timpul maxim de testare admisibil sunt determinate, în același mod în care am descris-o mai sus pentru calcularea valorilor.
Pentru a răspunde la aceste întrebări, vom trece direct la valoarea de performanță și vom pune întrebarea imediat. Și cum se calculează indicatorul dacă valoarea unei interogări poate fi egală cu „zero”. Dacă unul sau mai mulți indicatori sunt egali cu zero, atunci indicatorul final va scădea foarte mult, așa că se pune întrebarea cum să ne echilibrăm calculul astfel încât valorile zero, de exemplu, ale interogărilor cu un factor de severitate de „1”, să nu afecteze foarte mult finalul nostru evaluare.
Greutatea - aceasta este valoarea de care avem nevoie pentru a avea cel mai mic impact al interogărilor asupra notei finale cu o severitate scăzută, și invers, interogarea cu cea mai mare severitate are un impact semnificativ asupra notei, cu condiția să ne depășească această cerere.
Pentru a nu avea o neînțelegere în calcule, vom introduce variabile specifice pentru calcul:
x este timpul efectiv petrecut retestând defectul;
y este abaterea maximă admisibilă;
z este coeficientul de greutate.
Sau în limba obișnuită, este:
W \u003d ESLI (X<=y,1,(x/y)^z)
Astfel, chiar dacă am depăși cadrul SLA stabilit, cererea noastră, în funcție de gravitate, nu ne-ar afecta serios rezultatul.
Totul este așa cum este descris mai sus:
x- timpul efectiv petrecut retestând defectul;
y - abaterea maximă admisibilă;
zEste coeficientul de greutate.
h -timpul planificat conform SLA
Nu mai știu cum să exprim acest lucru printr-o formulă matematică, așa că voi scrie în limbaj programatic cu operatorul DACĂ.
R \u003d IF (x<=h;1;ЕСЛИ(x<=y;(1/z)/(x/y);0))
Ca rezultat, obținem că, dacă am atins obiectivul, atunci valoarea solicitării noastre este 1, dacă depășim abaterea admisibilă, atunci evaluarea este egală cu zero și se calculează greutățile.
Dacă valoarea noastră este între țintă și abaterea maximă admisibilă, atunci în funcție de coeficientul de greutate, valoarea noastră variază în interval.
Acum voi da câteva exemple despre cum va arăta acest lucru în sistemul nostru de măsurători.
Pentru fiecare cerere, în funcție de importanța lor (coeficientul de severitate), există propriul SLA.
Ce vedem aici.
În prima solicitare, tocmai ne-am abătut de la valoarea țintă pentru o oră și avem deja un rating de 30%, în timp ce în a doua solicitare am deviat de asemenea cu doar o oră, dar suma indicatorilor nu mai este de 30%, ci de 42,86%. Adică, factorii de severitate joacă un rol important în formarea indicatorului final de interogare.
În același timp, în cea de-a treia solicitare, am încălcat timpul maxim admis, iar ratingul este egal cu zero, dar greutatea cererii s-a modificat, ceea ce ne permite să calculăm mai corect influența acestei cereri asupra coeficientului final.
Ei bine, pentru a fi siguri de acest lucru, puteți calcula pur și simplu că media aritmetică a indicatorilor va fi de 43,21% și vom obține 33,49%, ceea ce indică un impact serios al interogărilor cu importanță ridicată.
Să schimbăm valorile din sistem cu 1 oră.
în același timp, pentru a 5-a prioritate, valoarea s-a schimbat cu 6%, iar pentru a treia cu 5,36%.
Din nou, importanța unei interogări îi afectează valoarea.
Gata, obținem metrica finală.
Ce este important!
Nu spun că utilizarea sistemului de măsurare ar trebui să se facă prin analogie cu valorile mele, sugerez doar o abordare a întreținerii și colectării acestora.
Într-o organizație, am văzut că și-au dezvoltat propriul cadru pentru colectarea valorilor de la HP ALM și JIRA. Este foarte interesant. Dar este important să ne amintim că un astfel de proces de menținere a valorilor necesită o aderare serioasă la procesele de reglementare.
Ei bine, cel mai important, numai dvs. puteți decide cum și ce valori să colectați. Nu este nevoie să copiați valorile pe care nu le puteți colecta.
Abordarea este complexă, dar puternică.
Încercați și s-ar putea să reușiți și voi!
Alexander Meshkov, Chief Operations Officer la Performance Lab, are peste 5 ani de experiență în testarea software-ului, managementul testelor și consultanță QA. Expert ISTQB, TPI, TMMI.
În ultimii ani, testarea automată a devenit o tendință în dezvoltarea de software, într-un anumit sens, implementarea sa a devenit un „tribut adus modei”. Cu toate acestea, implementarea și întreținerea testelor automate este o procedură foarte consumatoare de resurse și, prin urmare, nu este ieftină. Utilizarea pe scară largă a acestui instrument duce cel mai adesea la pierderi financiare semnificative fără niciun rezultat semnificativ.
Cum puteți utiliza un instrument destul de simplu pentru a evalua eficacitatea posibilă a utilizării testelor automate într-un proiect?
Ce se definește ca „eficiență” a automatizării testelor?
Cel mai comun mod de a evalua eficiența (în primul rând economic) este calculul rentabilității investiției (ROI). Se calculează destul de simplu, fiind raportul dintre profit și costuri. De îndată ce valoarea ROI depășește una, soluția returnează fondurile investite în ea și începe să aducă altele noi.
În cazul automatizării, profit înseamnă economisind la testarea manuală... În plus, profitul în acest caz poate să nu fie evident - de exemplu, rezultatele găsirii defectelor în procesul de testare ad-hoc de către ingineri, al căror timp a fost eliberat din cauza automatizării. Un astfel de profit este destul de dificil de calculat, deci puteți fie să faceți o presupunere (de exemplu + 10%), fie să o omiteți.
Cu toate acestea, economiile nu sunt întotdeauna scopul implementării automatizării. Un exemplu este viteza de execuție a testului (atât în \u200b\u200bceea ce privește viteza de execuție a unui test, cât și frecvența testării). Din mai multe motive, viteza de testare poate fi esențială pentru o afacere - dacă investiția în automatizare plătește profitul rezultat.
Alt exemplu - excluderea „factorului uman” din procesul de testare a sistemului. Acest lucru este important atunci când acuratețea și corectitudinea operațiunilor sunt esențiale pentru afacere. Costul unei astfel de erori poate fi semnificativ mai mare decât costul dezvoltării și menținerii unui test automat.
De ce să măsurăm performanța?
Măsurarea eficacității vă ajută să răspundeți la întrebările: „Merită să implementați automatizarea unui proiect?”, „Când ne va aduce implementarea un rezultat semnificativ?”, „Câte ore de testare manuală vom înlocui?”, „Este posibil să înlocuiți 3 ingineri de testare manuală cu 1 inginer de testare automatizată ? " si etc.
Aceste calcule pot ajuta la formularea obiectivelor (sau valorilor) pentru echipa de automatizare a testelor. De exemplu, economisind X ore pe lună de testare manuală, reducând costul unei echipe de testare cu Y unități convenționale.
Transfer: Olga Alifanova
Asigurarea calității face distincție între verificare și validare. Verificarea răspunde la întrebarea dacă creăm produsul corect și validarea răspunde la întrebare sau dacă creăm ceea ce este necesar. Unele persoane trasează linia dintre asigurarea calității și testare pe baza acestor definiții.
Din punctul meu de vedere, utilizarea termenilor „verificare” și „validare” poate duce la dihotomii false. Pentru mine, testarea este o activitate legată de proiectare și, prin urmare, acoperă o zonă destul de largă. Cred că testele pot deveni un fel de „limbaj comun”. Cred că testele pot codifica direct specificațiile și cerințele. Și cred că testele sunt sursa de cunoștințe despre o zonă sau un produs. Concentrarea prea mare pe diferența dintre verificare și validare este un mod ineficient și ineficient de a înțelege modul în care testarea completează asigurarea calității.
Din punctul meu de vedere, incapacitatea de a percepe testarea și asigurarea calității ca două procese diferite, complementare, este o percepție căreia îi lipsește în mod clar o anumită grație.
De fapt, sunt de acord că distincția dintre verificare și validare este justificată. La urma urmei, eficiența este capacitatea de a face ceva corect. Eficacitatea, pe de altă parte, este capacitatea de a oferi rezultatul corect. Eficiența se concentrează asupra procesului și își propune să-l aducă la sfârșit, iar eficacitatea se referă la produs (adică, de fapt, la rezultatul acestui proces). Puteți spune acest lucru: eficiența se concentrează în primul rând pe evitarea greșelilor, iar eficacitatea - pe succes, indiferent de numărul de greșeli comise pe parcurs.
Cu toate acestea, mi se pare că există o modalitate de a distinge între eficiență și eficacitate mult mai bună decât înțelegerea diferenței dintre verificare și validare. Testarea necesită flexibilitate și inovație.
Și tocmai acesta este punctul în care apare un paradox curios. Ai nevoie de un nivel decent de disciplină și duritate pentru a fi eficient în mod constant. Cu toate acestea, disciplina și reziliența la schimbare fac ca procesele să fie flexibile! Dacă faci același lucru la fel în mod repetat, nu vei fi niciodată copleșit de ceva inovator.
Deoarece eficiența în acest context este legată de verificare, aceasta înseamnă că verificarea se poate transforma într-o activitate statică.
Eficacitatea, pe de altă parte, este mult mai adaptabilă la schimbare și necesită multă flexibilitate. Pentru a obține rezultate bune, trebuie să încurajați inovația, deoarece atunci oamenii se vor gândi la ceea ce fac acum și dacă merită să faceți acest lucru într-un context specific și sub influența unor factori specifici. Cu toate acestea, această flexibilitate și adaptabilitate duce la o bogăție covârșitoare de alegeri și la o potențială incapacitate de a face eforturi conștiente, de rutină, care pot fi reproduse în afara situației actuale.
Deoarece eficiența în contextul nostru este legată de validare, toate cele de mai sus înseamnă că validarea poate deveni o activitate excesiv de dinamică.
Și aici intervin soluții grațioase, care sparg acest cerc vicios și care vă oferă posibilitatea de a vă evalua eficacitatea și performanța dintr-o perspectivă diferită. Harul soluțiilor nu răspunde doar la întrebările dacă am făcut ceva mai bun sau ne-am gândit la ceva mai bun, ci mai degrabă ne oferă un răspuns, am devenit mai buni înțelegând ce se întâmplă, am creat o bază pentru activitățile viitoare?
Harul poate fi privit și ca minimizarea complexității. În lumea dezvoltării, oamenii împart adesea complexitatea soluțiilor în obligatorii și aleatorii. Prin urmare, pentru ca soluțiile de testare să fie elegante, acestea ar trebui să constea doar din „complexitate obligatorie” și practic să nu conțină aleatorii. Sună misterios? Da, este posibil, din câte persoane - atâtea opinii despre unde începe „complexitatea”. Pentru mine, complexitatea deciziilor în testare apare atunci când nu există opțiuni în sistem și există o mare incertitudine.
Dacă permiteți testarea să fie inovatoare și flexibile (adică eficiente), dar să păstrați totuși un anumit nivel de rigiditate și disciplină (eficiență), trebuie să aveți câteva seturi de reguli despre cum să gestionați alegerile (în sensul de a oferi acele alegeri). și incertitudine (cum să o eliminați).
Nu mă voi plictisi pe acest subiect, ci doar să dau exemple despre ceea ce vorbesc. În exemplele mele, vreau să încerc să fac echipele de testare să se gândească la testele lor folosind termenii eficiență, eficacitate și grație. Voi începe cu câteva axiome (nu găsesc alt cuvânt) și voi încerca să-mi fac exemplele cât mai scurte și clare posibil. Există lucruri în care întreaga echipă ar trebui să creadă - sau cel puțin să acționeze ca și când ar crede în ele. Și chiar prima mea axiomă afirmă ceea ce am spus mai sus!
- Testarea poate fi efectuată în mod eficient, eficient și grațios.
- Testarea necesită cercetare activă, profesională, tehnică.
- Scopul testării este furnizarea clară a informațiilor necesare la timp.
- Testerii sunt, într-un anumit sens, scriitori și editori. În consecință, etica harului și mândria profesională sunt atribute indispensabile ale muncii bune, motivate, cu un nivel adecvat de atenție.
Iată câteva exemple pentru a ilustra aceste puncte. În primul rând, să analizăm toate aceste concepte pe măsură ce se aplică unui test.
- Efectiv testul ar trebui să se concentreze pe intrare, proces, ieșire.
- Efectiv testul trebuie să fie expresiv și să demonstreze scopul testului.
- Efectiv testul ar trebui să se concentreze pe un rezultat inteligibil al unei acțiuni specifice și nu pe mai multe în același timp.
- Efectiv testul grupează observațiile împreună.
- Efectiv testul oferă un exemplu concret al datelor pe care le doriți.
- Efectiv testul spune despre condițiile generale în care ar trebui să cadă datele testate.
- Elegant testul descrie comportamentul specific al sistemului și funcționalitatea acestuia.
Acum să aplicăm aceste concepte în suita de testare:
- Efectiv suita de testare determină ce date vor fi valide și care nu.
- Efectiv Suita de testare verifică atât datele valide cât și cele nevalide.
- Efectiv suita de testare grupează tipurile de date în clase.
- Elegant o suită de teste poate fi proiectată pentru cercetarea sarcinilor și proceselor de afaceri.
În cele din urmă, să aplicăm aceste definiții testării ca activitate:
- Efectiv testarea utilizează scripturi pentru a structura procesul de cercetare.
- Efectiv testarea aplică practici exploratorii care aduc variabilitate scripturilor.
- Graţios testarea utilizează practici de cercetare scriptate pentru a demonstra valoarea unei aplicații pentru consumator examinând modul în care este utilizată.
- Efectiv testarea folosește scripturi care arată modul în care produsul își atinge scopul.
- Efectiv testarea utilizează scripturi care demonstrează ce trebuie să se întâmple pentru ca un utilizator să fie satisfăcut.
- Graţios testarea descrie cerințele și demonstrează capacitățile aplicației.
Toate acestea sunt importante pentru a fi conștienți, deoarece ceea ce faceți și cum faceți acest lucru este baza a ceea ce și cum veți face în viitor. De asemenea, susține dinamica grupului și reflecțiile asupra conceptelor de mai sus. La asta mă refer:
- Unii testeri preferă să numească cazurile de testare „condiții de testare”. Unele sunt opuse. Cineva ignoră ambii termeni. Cred că testarea performanței grupează testarea condițiilor și le face variații ale cazurilor de testare. Testarea performanței utilizează condițiile de testare definite de parametrii specifici ai datelor dorite.
- Terminologia „testare pozitivă / negativă” s-a demodat de mult în rândul testerilor cu experiență. Testarea grațioasă se concentrează pe descrierea condițiilor valide și invalide. Aceasta înseamnă că testerii trebuie să testeze în mod eficient și eficient identificând toate condițiile de testare care se pot schimba (care la rândul lor duc la un grup de condiții valide și nevalide) și, de asemenea, se asigură că iau decizii în cunoștință de cauză, alegând seturi de date ignorând restul.
- Testele grațioase sunt campionii testelor tale. Dacă aveți un grup de teste care verifică de fapt lucruri similare și timpul dvs. este limitat, veți avea timp să rulați doar o parte din ele. În astfel de cazuri, utilizați teste care sunt mai susceptibile să dezvăluie un întreg nivel de erori. Astfel de teste pot fi extrem de elegante.
- Un test eficient nu trebuie să fie nici prea simplu, nici prea complex. Desigur, este posibil să înghesuiți o serie întreagă de verificări într-un singur caz, dar posibilele efecte secundare ale acestui mod de a crea teste pot masca o grămadă de bug-uri. În consecință, cazurile de rezultate trebuie să includă puncte de observație diferite (sau o cale diferită către același punct de observație) și să fie executate separat.
- Mai multe tehnici de testare sunt extrem de eficiente în selectarea datelor specifice și organizarea acestor date în combinație sau succesiune. Dar o soluție elegantă va apărea atunci când testerii selectează aceste date pe baza interacțiunii diferitelor funcționalități și fluxuri de date și explorează căile prin interfața cu utilizatorul, înțelegând modul în care o persoană vie va folosi acest sistem.
- Un caz reușit ar trebui să vă poată oferi informații. Aveți nevoie de teste care să răspundă la întrebările pe care le-ați pus. Scopul testului nu este neapărat găsirea unui bug, scopul său este de a colecta informații. Un test nu este valoros atunci când poate găsi o eroare - trebuie să vă poată furniza informații (deși aceste informații pot fi și în prezența unei erori dacă ceva nu este în regulă cu aplicația). O soluție elegantă vizează întotdeauna obținerea de informații specifice în timpul testării.
- Testarea eficientă necesită înțelegerea cerințelor și modul în care acestea se raportează la modul în care utilizatorii percep valoarea produsului nostru. Trebuie să ne înțelegem utilizatorii, nu doar să citim specificațiile și cerințele! Testarea elegantă folosește euristica pentru a structura această înțelegere. De asemenea, forțează testarea pentru a spune povești convingătoare despre acțiunile oamenilor reali.
Poate că ar fi trebuit să remarc de la bun început că nu aveam niciun scop de a mă face adevărul suprem în ceea ce privește răspunsul la întrebarea ce testare va fi eficientă, eficientă și grațioasă. Am vrut doar să-mi transmit poziția: cred că echipele de testare care înțeleg diferența dintre aceste concepte sunt capabile
