Vilka tester särskiljs enligt effektivitetskriteriet. Utvärdering av effektiviteten av de fem stora testet och ett exempel på dess praktiska användning

Det har varit aktuellt i många år, mycket forskning har ägnats åt denna fråga. I den här artikeln använder vi ett exempel riktigt projektöverväga processen för att implementera KPI och metodiken för att bedöma kvaliteten på vårt arbete.

Vad är en KPI?

Så låt oss först vända oss till själva konceptet KPI. KPI (Key Performance Indicator) är en indikator på framgång inom vissa aktiviteter eller för att uppnå vissa mål. Vi kan säga att KPI är en kvantitativt mätbar indikator på faktiskt uppnådda resultat.

I vårt fall är KPI för projektet en indikator på prestandan för hela testteamet. Förutom termen KPI kommer artikeln att använda termen "metrics", med vilken vi kommer att förstå det numeriska värdet för att mäta denna effektivitet.

Varför behöver vi nyckeltal?

Låt oss nu prata om varför vi behövde nyckeltal för projektet och varför vi bestämde oss för att implementera dem. Allt är enkelt här: vi ville se status för projektet när som helst och vidta förebyggande åtgärder för att undvika problem. Tack vare KPI-ansvarig riktning av testning på projektet ser inte bara stark och svaga sidor projektet och hela hans team, men kan också i dynamik spåra konsekvenserna av sina egna ledningsbeslut (vad som gjordes rätt, vilken av fattade beslut var framgångsrika eller misslyckade), och i framtiden - att korrigera dem.

Dessutom kan nyckeltal inte bara innehålla allmänt accepterade kvantitativa indikatorer utan även kvalitativa (till exempel "kundnöjdhetsnivå"). Men låt oss prata om allt i ordning!

Var får man KPI?

Varje projekt är unikt på många sätt. Du bör inte anta att mätvärden från ett projekt kommer att "slå rot" väl på ett annat; de bör utvecklas med hänsyn till projektets särdrag och din kunds förväntningar/oro. Men att omvandla förväntningar till mått kommer att ta tid och tålamod.

Hur var det med oss

Nu kommer jag, som utlovat, att berätta om vårt agerande i projektet.

Så mitt team testade klientens interna programvara, som bestod av flera stora funktionsblock, samt programvaruintegration med back-office-lagringssystem.
Jag ska genast klargöra att med kunden i artikeln menar jag alla personer som är intresserade av att testa produkten och sträva efter att säkerställa att produkten tillfredsställer slutanvändarnas behov och går i kommersiell drift.

Kunden kom till oss med några specifika förväntningar från tester, med sitt eget mål. I det här skedet var min uppgift som chef för testriktningen i projektet att identifiera just dessa mål och förväntningar. Det finns många alternativ för en sådan analys - det är undersökningar, ifyllande av briefs, muntlig kommunikation. Det viktigaste är att ta reda på vad kunden vill ha, vad han är orolig för och vad som "gör ont".

Låt oss ge exempel på kundens uttalanden: "Entiteter "flyger" inte från en modul i programmet till en annan, men de behövs där, mycket är knutet till dem"; "Vi kan inte från gammalt programöverföra information till den nya versionen"; "Vi planerar fullt ut att flytta från ett system till ett annat, så vi kommer att justera överföringen."

Efter att ha format våra kunders förväntningar (eller rädslor) måste vi omvandla dem till ett mål. Det är lätt att gissa att syftet med våra tester var att genomföra integrerad bedömning produktkvalitet genom integration och funktionstestning programvara kund.

Nu var vi tvungna att genomföra nedbrytningsprocessen, det vill säga bryta upp det globala målet i små lösbara uppgifter för projektgruppen. Teamet självt hjälpte mig förresten med detta! Låt oss se hur detta hände, men först, låt oss förtydliga själva termen "nedbrytning" igen och lägga allt på hyllorna.

Sönderfall

Vad är nedbrytning? Nedbrytning är en vetenskaplig metod som använder problemets struktur och låter dig ersätta lösningen av ett stort problem med lösningen av en rad mindre delproblem, om än sammankopplade, men enklare. Principen för nedbrytning är att applikationen som testas (dess separata modul eller funktion) kan betraktas som bestående av delsystem som är relativt oberoende av varandra, som vart och ett är mycket enklare och tydligare att testa än hela systemet på en gång.

Om kunden vill få integrationstestning måste vi bryta ned integrationsfunktionstestningen av produkten. För att göra detta är det nödvändigt att förstå vilka delar kundens system består av, hur många system som är inblandade i datautbyte, vilka åtgärder och på vilka objekt systemanvändare kan utföra osv.

I teorin är allt ganska enkelt och tydligt: ​​från ett stort problem måste du få ett antal små. Det verkar inte vara något komplicerat, men i praktiken står vi ofta inför det faktum att vi helt enkelt inte förstår kriterierna för uppgiftsupplösning, och därför gör vi allt på måfå. Konsekvenserna av ett sådant missförstånd är en ojämn belastning på projektets testare, felbedömning arbetskostnader, missförstånd av uppgifter och olika uppfattning om resultat. För en bättre förståelse av detta ämne, låt oss vända oss till SMART-principen.

SMART princip

Generellt sett är SMART en mnemonisk förkortning som chefer på olika nivåer använder för att memorera principerna för att sätta mål. Varje bokstav i förkortningen har sin egen avkodning:

• Specifik - specifik. När vi ställer en uppgift måste vi tydligt förstå vilket resultat vi vill uppnå. Resultatet ska vara entydigt och förståeligt för alla deltagare i processen - testa teammedlemmar, kunder, chefer på olika nivåer.
• M ätbar - mätbar. Vi behöver uppgifter som går att mäta. Mätbarhet förutsätter med andra ord att det finns kriterier - mätare, prestationsindikatorer.
• En uppnåbar - uppnåbar. I det här fallet Jag skulle döpa om definitionen av "uppnåelig" till "tillgänglig" (tillgänglig för utförande av en anställd med en viss utbildningsnivå och kvalifikationer). En kompetent ledare kommer aldrig att ge en nybörjare en extremt svår uppgift, eftersom han förstår att en nybörjare helt enkelt inte kan klara av det, och den tid som spenderas på att försöka lösa den kan inte returneras. Genom att ta hänsyn till de personliga egenskaperna och egenskaperna hos testteamets anställda i projektet kommer du att kunna fördela belastningen mycket tydligt (och viktigast av allt, jämnt och inom din förmåga), ge nybörjare enkla uppgifter och "stjärnor" och proffs - uppgifter med komplex logik i enlighet med deras styrkor och färdigheter.
• Relevant - relevant, betydande. Är uppgiften verkligen så viktig för oss? Är denna uppgift nödvändig just nu? Vad får vi om vi löser detta problem? Tänk om vi inte bestämmer oss?
• Tidsbestämd - begränsad i tid. Varje uppgift måste ha sin egen tidsram under vilken den måste lösas. Genom att fastställa tidsramar och gränser för att slutföra en uppgift kan du göra processen kontrollerbar och transparent. Chefen kan när som helst se hur arbetet fortskrider.

Så nu har läsaren en förståelse för vilka kriterier som kan användas för att bryta ner en stor uppgift. Vi kan gå vidare.

Efter att den stora uppgiften är uppdelad i ett antal små är det nödvändigt att analysera varje deluppgift. Låt oss lyfta fram dem. Så i vårt projekt dök följande uppsättning åtgärder upp:

• vi täcker med tester all huvudfunktionalitet som ingår i integrationen;
• vi utvecklar testenheter och data;
• testuppgifter för att förbättra funktionaliteten;
• vi startar defekterna som upptäcks under testningen;
• kontrollera releaser och hotfixar;
• se till att på varje ny version produkt från ett system till ett annat, är det möjligt att överföra två prioriterade produkter.

Utöver dessa huvudsakliga deluppgifter har jag identifierat ytterligare några:

• vi vill inte slösa tid på att förklara för utvecklare "vad felet är och hur det kan reproduceras", och därför kommer vi att göra kompetenta och begripliga defekter;
• vårt testarbete bör vara så transparent som möjligt, så vi kommer att tillhandahålla en interimsstatus om versionens tillstånd till kunden;
• vi vill att kunden ska trivas med oss ​​och nästa gång vände han sig till oss igen.

Låt oss nu gå igenom varje deluppgift tillsammans och titta på mätbara indikatorer (mått).

Mätvärden som utgör KPI:er

Täckning av funktionalitet med tester. Hur kan vi mäta det? Vi bestämde oss för måttet "% täckning av xx antal produktmoduler med tester" (mer än detaljerad information hur man beräknar detta kan du hitta i artikeln av Natalia Rukol).

Genom att klicka på bilden öppnas den fullständiga versionen.

Utveckling av testfall och testenheter. Här bestämde vi oss för att arbeta med måttet "antal moduler / funktionella block av produkten för vilka 100% av enheterna är utvecklade."

Testa kundändringar. I det här fallet räknade vi helt enkelt antalet testade revisioner per version och den genomsnittliga tiden som teamet spenderade på verifiering. Vi samlade in dessa indikatorer för att bedöma vad versionen syftade till (för buggfixning eller för introduktion av ny kundfunktionalitet), och därför om vi håller deadlines för implementering av vissa funktioner.

"Införande av defekter". Vi bestämde oss för att använda flera mätvärden som skulle ge oss information om versionens tillstånd: "antal defekter som introducerats av teamet", "antal blockerare prioriterade defekter i versionen".

"Testar versioner och snabbkorrigeringar" vi löste med måtten "% av testade uppgifter inkluderade i versionen och/eller hotfix" (förhållandet mellan testade uppgifter och det totala antalet uppgifter i versionen), "% av testfall som godkänts på versionen" och "% av framgångsrikt slutförande av ärenden på versionen".
Vi beräknar det sista måttet med formeln:



där P1 är de passerade stegen i det första blocket,
P2 - passerade steg på det andra blocket,
Pn - passerade-steg på det n:te blocket,
A1 är antalet steg i det första blocket,
A2 - antalet steg i det andra blocket,
An är antalet steg i det n:te blocket,
N är det totala antalet av alla produktblock.

För att mäta uppgiften förknippad med prestanda för prioriterade produkter utvecklade vi speciellt en matris (den noterade om detta eller det värdet för produkten fungerade eller inte fungerade) och beräknade sedan "% av värdena som fungerar för produkt 1 och produkt 2 per version”. Vi räknar enligt formeln:



där Pp1 är antalet driftvärden för produkt ett,
Ap1 – alla värden för produkten är ett.

Genom att klicka på bilden öppnas den fullständiga versionen.

Efter att ha hanterat huvuduppgifterna gick vi vidare till ytterligare.

Låt mig påminna om att vi inte ville slösa bort vår dyrbara tid på att förklara buggar och kommentera rapporter, men samtidigt var det viktigt för oss att kunden var nöjd med vårt arbete. För den första deluppgiften bestämde vi oss för att använda de kvantitativa indikatorerna "% av defekter som avvisats på versioner med Kan inte återskapa upplösning", och för den andra - "antalet kundförfrågningar om att kommentera delrapporten" och den kvalitativa indikator ”kundnöjdhet med vårt arbete”.
För att bedöma "kundnöjdheten" införde vi tre nivåer - "allt är bra", "det finns små kommentarer/frågor om arbetet" och "allt är dåligt, kunden är missnöjd". Denna indikator är förresten i allmänhet till stor hjälp för snabbt beslutsfattande inom projektgruppen. Om kunden är missnöjd eller upprörd över något för vi en diskussion i hetjakt: vi försöker minimera risker, förstår orsakerna till missnöjet, utarbetar en lösning så snart som möjligt och presenterar den för kunden.

Genom att klicka på bilden öppnas den fullständiga versionen.

Vad ger KPI oss som resultat

Att förbereda ett KPI-projekt är en kostsam procedur, men intressant och användbar, och här är varför.
Genom att samla in mätvärdena ovan kan jag få svar på frågorna: exakt vad gjorde mitt team bra, vilka indikatorer växte vi i, var mina beslut korrekta och lägliga? ledningsbeslut. Jag kan när som helst svara på följande frågor till kunden:

• vad är versionens tillstånd;
• vilka produktmoduler som är mest kritiska och buggiga;
• vilka moduler som bör tas upp Särskild uppmärksamhet;
• vilka indikatorer fungerar för prioriterade produkter;
• om det är möjligt att ge produkten i kommersiell drift.

Efter introduktionen av mått på mitt projekt blev det lättare att förbereda delårsrapportering för kunden, hela projektteamet (och killarna har tillgång till projektets KPI) gjorde allt för att växa vår mjukvara.
indikatorer, alla blev mer uppmärksamma och fokuserade!

Istället för en slutsats

I kvalitetslabbet gick vi lite längre och bestämde oss ändå för att samla in en databas med mått som är tillämpliga på våra projekt. Nej, jag säger inte att man kan ta färdigt material och arbeta med det, men varje chef som ställs inför ämnet att implementera KPI på sitt projekt kan hänvisa till denna databas, se måtten från vilka KPI:er samlas in på andra projekt och anpassa dessa mätvärden för att passa dina behov. Vi har också utarbetat en intern reglering (en sorts instruktion för implementering av KPI på projekt), med hjälp av vilken denna process löper smidigt och smärtfritt.

Var inte rädd för att ta dig tid att förbereda och implementering av KPI på projektet: dessa kostnader kommer att betala sig till fullo! Din kund kommer att vara nöjd med det utförda arbetet och den utmärkta kvaliteten på produkten. Han kommer att vända sig till dig om och om igen för att få hjälp!

Fel som minskar testets effektivitet visas om:

• Testet var felaktigt skrivet
• Testet är inte korrekt standardiserat
• Testet är missbrukat

Testdesign

Först och främst är det nödvändigt att tydligt föreställa sig den psykologiska egenskapen som det framtida testet kommer att mäta. Inget test skapas från grunden, vanligtvis ligger det lång tid bakom dess tillkomst. vetenskapligt arbete för studiet av tematiskt material.

Innan designern av det psykologiska testet det finns en svår uppgift - att fullt ut återspegla alla aspekter av den uppmätta psykologiska egenskapen genom det minsta antalet uppgifter. Det sista villkoret är ett av kriterierna för testets effektivitet. Det betyder inte att Cattells personlighetsenkät, som innehåller femtusen frågor, kan anses verkningslös. Med ett så stort antal uppmätta personlighetsfaktorer (16) är detta antal frågor optimalt. Detsamma gäller tester för intelligens, motivation och andra vidsträckta mentala områden. Du bör akta dig för ett frågeformulär, säg, om önskan om risk, som innehåller 250 frågor.

Utöver dessa krav ska testet uppfylla målgrupp som den är riktad till. Uppgifter av lämplig komplexitet och tillgänglighet utvecklas för olika åldersgrupper, för personer med olika mentala störningar, för representanter för olika nationella och språkliga grupper. Om provet erbjuds i en annan språkgrupp eller ett annat land måste det anpassas.

Till anpassning inkluderar inte bara översättning av uppgifter, utan också omstrukturering av fraser, begrepp, ersättning av frasologiska enheter, ordspråk och talesätt med liknande på ett visst språk. Innebörden av frågorna bör förmedlas med hänsyn till denna grupps religiösa åsikter.

Det är också nödvändigt att ta hänsyn till vissa effekter som observeras när man fyller med människor. testuppgifter. Den så kallade sociala önskvärdhetseffekten utlöses när en person i sina svar vill framställa sig själv i ett bättre ljus. Många tester är beväpnade till tänderna" lögnfjäll", fällfrågor etc. Men det här hjälper inte alltid - en person hittar samma frågor, håller sina svar i minnet.

Det finns ett annat sätt - ändra syftet med testet i instruktionerna om detta mål överhuvudtaget avslöjas för ämnet. Då personen, som svarar på frågor, visar sig väl på ena sidan (falskt mål) och ger mer eller mindre tillförlitlig information om den andra sidan (sanna mål), som faktiskt mäts med detta test.

Det finns också krav på formuleringen av frågor, på i vilken ordning de placeras i provet. De beror återigen på den målgrupp som testet är utformat för.

Ett korrekt designat test kan ännu inte kallas utvecklat. För att göra detta måste det vara standardiserat.

Standardisering

Standardisering av testet ger möjlighet att jämföra de data som erhållits med dess hjälp från olika människor. För detta är det nödvändigt att alla dessa människor var under lika villkor. På psykologiskt språk kallas detta "kontroll av alla beroende variabler". Helst skulle den enda oberoende variabeln i testet vara försökspersonens personlighet. För att säkerställa lika villkor ger testutvecklaren särskilda instruktioner för dess implementering. De inkluderar:

• Stimulansmaterialets specificitet
• Tidsbegränsningar
• Instruktion till ämnena
• Exempel på uppdrag
• Tillåtna svar på frågor (om några begränsningar behövs)

Utöver dessa instruktioner innehåller ansökan till testet särskilt fastställda normer för svar (i "rå poäng") och deras tolkning.

Utöver standardisering ska testet testas för dess effektivitet vad gäller tillförlitlighet och validitet. Mycket ofta görs dessa begrepp utbytbara, så låt oss överväga vilken betydelse var och en av dem har.

Pålitlighet

Tillförlitlighet förstås som överensstämmelsen mellan de resultat som erhållits vid varje upprepning av testet av samma försöksperson, med resultaten från hans första test. Absolut testtillförlitlighet existerar inte, fel är tillåtna, men ju högre de är desto lägre blir testeffektiviteten. Tillförlitligheten kan kontrolleras med följande metoder:

• test-omtest tillförlitlighet innebär multipel exekvering av ett test och korrelationsjämförelse av de erhållna resultaten.
• delad tillförlitlighet bestäms genom att dela upp testet i två delar och jämföra resultaten av att utföra de två delarna separat.
• motsvarande tillförlitlighet avslöjas genom att presentera testet och dess alternativ till testpersonen. De erhållna resultaten jämförs också med varandra.

Giltighet

Psykologiska ordböcker avslöjar begreppet validitet som graden av överensstämmelse med testet med dess syfte att mäta vad det skapades för; testets faktiska förmåga att mäta den psykologiska egenskap som den görs anspråk på. Kvantitativt kan giltigheten av ett test uttryckas genom korrelationen av resultaten som erhållits med dess hjälp med andra indikatorer, till exempel med framgången för motsvarande aktivitet.

Dessutom kan testets validitet fastställas genom att jämföra dess resultat med resultaten av liknande metoder. Till exempel kan det utvecklade testet för verbal intelligens utföras tillsammans med det välkända Amthauer-testet och sedan jämföra deras resultat. En hög korrelation av resultat skulle innebära hög validitet, dvs nytt test mäter verkligen verbal intelligens, inte talförmåga, minne, uppmärksamhet osv.

Det sades ovan om fel vid användningsstadiet. Brott mot villkoren för dess genomförande, som rekommenderas i ansökningarna, kan leda till en minskning av giltigheten. Anta att vi genomför ett ordminnestest och, när vi ser att ämnet är tillräckligt kapabelt, ökar vi hastigheten för att läsa en lista med ord. I detta fall kommer hastighetsökningen att vara en ytterligare oberoende variabel, med andra ord ett hinder. Som ett resultat kommer vi att i stället för memoreringshastigheten mäta individens stressmotstånd.

Testets validitetsbedömning inkluderar följande steg:

• fastställande av skenbar giltighet(ansiktsgiltighet). Sådan giltighet kan ses, som de säger, "med blotta ögat" - testets övergripande överensstämmelse med dess syfte bedöms.
• definition av begreppsgiltighet(konstruktionsvaliditet). I vilken grad ett test som mäter en egenskap överensstämmer med allmänt accepterade teoretiska idéer om den egenskapen. Som regel bedöms denna giltighet av experter.
• fastställande av empirisk giltighet(empirisk giltighet). Det kriterium (oberoende variabel) väljs som testresultaten associeras med. Till exempel kan kriteriet för ett skolberedskapstest vara den samlade bedömningen av en förstaklassare.
• fastställande av innehållets giltighet(Innehållsvaliditet). Det utvecklade testet bör innehålla frågor för att utvärdera det maximala antalet parametrar för egenskapen som detta test mäter (den första regeln för testförberedelse nämndes ovan - det maximala antalet egenskapsparametrar genom det minsta antalet uppgifter). Denna validitet bedöms också genom peer review.

Förresten, inte bara nya tester klarar ett sådant prov. För närvarande är många forskare upptagna med att analysera effektiviteten av redan kända tester. En ny kontrovers på sidorna av den psykologiska tidskriften "Psychological Science in the Public Interest" ifrågasatte effektiviteten hos sådana "mästare" av psykodiagnostiska verktyg som Rorschachs bläckfläcktest, TAT (tematisk apperceptionstest) och den projektiva testritningen av människofiguren. Det visade sig att dessa psykodiagnostiska metoder har låg empirisk validitet, låg test-omtest-reliabilitet och felaktigt sammanställda normativa indikatorer.

Ovanstående metoder för att utvärdera effektiviteten av ett test hjälper en psykolog att inte bara designa verktyg för att mäta vissa personlighetsdrag, utan också välja de mest högkvalitativa och tillförlitliga testerna från redan utvecklade tester.

Psykologiskt komplex Effecton Studio

Huvudprioriteringen när man skapade Effecton Studio-komplexet var att endast inkludera vetenskapligt baserade och informativa metoder. Dessutom förser vi våra användare, såväl som webbplatsbesökare och nyhetsbrevsläsare, med informationsstöd för psykologiska tekniker. Vi ägnar särskild uppmärksamhet åt effektiviteten och ergonomin i arbetet - efter att ha klarat de psykologiska testerna från Effecton Studio får användaren inte bara råa resultat, utan också deras tolkning, bekväma metoder för grupptestning och statistisk analys.

Många andra funktioner har också utvecklats, som vi rekommenderar att du bekantar dig med genom att ladda ner demoversionen från vår hemsida och beställa komplexet för användning i din organisation. Du kan också informera andra intresserade användare om komplexet, i så fall får du 25 % av transaktionsvärdet.

Olga Danilova.

Exklusivt material från sajten "www.. Text och/eller relaterat material får endast lånas om det finns en direkt och tydligt synlig länk till originalet. Alla rättigheter förbehålls.

Demoversion av komplexet

Målet med prestationsutvärdering, som vissa redan har kallat "olycksformeln" är bara att göra testaren nöjd, så att man med siffror kan visa att den ena fungerar bra och bör klappas på huvudet för det, och den andra är dålig. och behöver smällas ... Utvärdering endast enligt detta kriterium kan inte vara den enda, därför bör den övervägas i samband med andra indikatorer, såsom genomförandet av planen, testautomatisering, etc.

En testares prestation, liksom alla andra anställda, bör kvantifieras, d.v.s. i en mätbar indikator. Men vilka indikatorer ska man välja?

Det första som kommer att tänka på är antalet upptäckta defekter. Och det var denna indikator som jag omedelbart försökte införa i Inreco LAN. En het diskussion uppstod dock omedelbart, vilket fick mig att analysera detta kriterium. Om detta ämne vill jag diskutera i den här artikeln.

Antalet upptäckta defekter är en extremt hala indikator. Alla resurser på nätverket som diskuterar detta problem upprepar också detta (http://www.software-testing.ru/, blogs.msdn.com/imtesty, it4business.ru, sqadotby.blogspot.com, blogs.msdn.com / larryosterman , sql.ru , http://www.testingperspective.com/ och många, många andra). Efter att ha analyserat min egen erfarenhet och dessa resurser kom jag till följande problemträd:

Först defekt till defekt - disharmoni. En testare kan leta efter defekter i placeringen av knappar i applikationen, den andra kan fördjupa sig i logiken och komma på komplexa testsituationer. I de flesta fall kommer den första testaren att hitta fler defekter, eftersom även förberedelsen av testet kommer att ta honom mycket mindre tid, men värdet av sådana defekter är mycket lägre. Detta problem löses enkelt genom att introducera defektens kriticitet. Det kan utvärderas utifrån antalet defekter som finns i var och en av kategorierna. Till exempel har vi fyra av dem: kritiska, betydande, medelstora och obetydliga. Men eftersom gränsen för att definiera kritikalitet inte är helt klar, även om vi har formella tecken på kritikalitet, kan vi gå två mer tillförlitliga vägar. Den första är att en viss del av de defekter som upptäcks under den valda perioden bör vara icke-kritiska defekter. Det andra är att inte ta hänsyn till mindre brister i bedömningen. På så sätt kämpar vi mot testarens önskan att samla in så många defekter som möjligt genom att beskriva mindre brister, vilket tvingar honom (eller oftare henne) att gräva djupare och hitta allvarliga defekter. Och det är de alltid, tro min erfarenhet. Jag valde det andra alternativet - kassera mindre defekter.

Det andra skälet till "halheten" av ett sådant kriterium är närvaron av ett tillräckligt antal defekter i systemet så att testaren kan hitta dem. Det finns tre faktorer här. Den första är komplexiteten i systemets logik och teknik. Det andra är kvaliteten på kodningen. Och den tredje är projektstadiet. Låt oss ta dessa tre faktorer i ordning. Komplexiteten i logiken och tekniken som systemet är skrivet på påverkar de potentiella brister som kan göras. Dessutom är beroendet här långt ifrån direkt. Om du implementerar enkel logik på en komplex eller obekant plattform, kommer felen främst att vara relaterade till felaktig användning av implementeringstekniken. Om du implementerar komplex logik på en primitiv plattform, kommer fel troligen att vara associerade både med själva logiken och med komplexiteten i att implementera sådan logik på ett primitivt språk. Det vill säga att det behövs en balans när man väljer teknik för att implementera systemet. Men ofta är tekniken dikterad av kunden eller marknaden, så vi kan knappast påverka. Därför återstår det bara att ta hänsyn till denna faktor som en viss koefficient för det potentiella antalet defekter. Dessutom måste värdet av denna koefficient troligen bestämmas av en expert.

Kodningskvalitet. Här kan vi definitivt inte påverka utvecklaren på något sätt. Men vi kan: a) igen, sakkunnigt utvärdera utvecklarens nivå och inkludera den som en annan faktor, och b) försöka förhindra uppkomsten av fel i koden genom enhetstester, vilket gör 100 % kodtäckning med enhetstester till ett obligatoriskt krav .

Projektstadiet. Det har länge varit känt att det är omöjligt att hitta alla defekter, utom kanske för ett trivialt program eller av en slump, eftersom det inte finns någon gräns för perfektion, och varje diskrepans med perfektion kan betraktas som en defekt. Men det är en sak när ett projekt är i det aktiva utvecklingsstadiet och en helt annan när det är i stödfasen. Och om vi också tar hänsyn till faktorerna systemkomplexitet och teknik och kodningskvalitet, är det tydligt att allt detta radikalt påverkar antalet defekter som en testare kan hitta. När projektet närmar sig slutförandet eller supportfasen (vi kallar det hela villkorligt och definierar det intuitivt nu), minskar antalet defekter i systemet, och därmed antalet upptäckta defekter. Och här är det nödvändigt att bestämma det ögonblick då det blir orimligt att kräva att testaren ska hitta ett visst antal defekter. För att fastställa ett sådant ögonblick skulle det vara trevligt att veta vilken del av det totala antalet defekter vi kan hitta och hur många defekter som fortfarande finns kvar i systemet. Detta är ett ämne för en separat diskussion, men en ganska enkel och effektiv statistisk metod kan tillämpas.

Baserat på statistik från tidigare projekt är det möjligt att, med ett visst fel, förstå hur många defekter som fanns i systemet och hur många som upptäcktes av testgruppen under olika perioder av projektet. Således kan du få en viss genomsnittlig indikator på testteamets effektivitet. Den kan brytas ner för varje enskild testare och få en personlig bedömning. Hur mer erfarenhet och statistik, desto mindre blir felet. Du kan också använda metoden "error seeding", när vi vet exakt hur många fel som finns i systemet. Naturligtvis måste ytterligare faktorer beaktas, såsom typen av system, logikens komplexitet, plattformen och så vidare. Så vi får förhållandet mellan projektets fas och andelen upptäckta defekter. Nu kan du tillämpa detta beroende i baksidan: genom att känna till antalet defekter som hittats och den aktuella fasen av projektet, kan vi fastställa det totala antalet defekter i vårt system (med vissa fel, naturligtvis). Och vidare på grundval av indikatorer för personlig eller övergripande bedömning du kan avgöra hur många defekter en testare eller ett team kan hitta under den återstående tiden. Baserat på denna bedömning är det redan möjligt att bestämma kriteriet för testarens effektivitet.

Testarens prestandaindikatorfunktion kan se ut så här:

Defekter- antalet upptäckta defekter,

Allvarlighetsgrad– kritikaliteten hos upptäckta defekter,

Komplexitet– komplexiteten i systemlogiken,

plattform– Systemimplementeringsplattform,

Fas- projektets fas,

periodär den aktuella tidsperioden.

Men redan ett specifikt kriterium som en testare måste uppfylla måste väljas empiriskt och med hänsyn till specifikationerna för en viss organisation.

Tänk på alla faktorer det här ögonblicket Hittills har vi inte lyckats, men tillsammans med vår huvudutvecklare Ivan Astafiev och projektledaren Irina Lager kom vi fram till följande formel, som tar hänsyn till antalet defekter och deras kritikalitet:

, var

E– effektivitet, bestäms av antalet upptäckta defekter,

D Kund– antalet defekter som hittats av kunden, men som den bedömda testaren borde ha hittat,

D Testare- antalet defekter som hittats av testaren,

k Och d– Korrigeringsfaktorer för det totala antalet defekter.

Jag vill genast notera att vid utvärdering enligt denna formel bör endast de defekter som hänför sig till den bedömda testarens ansvarsområde beaktas. Om flera testare delar ansvaret för en missad defekt, måste den defekten inkluderas i utvärderingen av varje testare. Dessutom tar inte beräkningen hänsyn till lågkritiska defekter.

Således har vi en parabel av tredje graden, som återspeglar kriteriet för intensiteten av att hitta defekter, som testaren måste uppfylla. I allmänhet, om testarens poäng är över parabeln, betyder det att han fungerar bättre än förväntat, om lägre, så sämre.

Det finns en nyans förknippad med det totala antalet analyserade defekter. Naturligtvis, ju mer statistik, desto bättre, men ibland måste du analysera olika stadier projekt, ibland behöver du bara en uppskattning för varje tidsperiod. Och det är en sak när 4 defekter hittas under perioden och 2 av dem är av kunden, och en helt annan när 100 defekter hittas, och 50 av dem är av kunden. I båda fallen kommer förhållandet mellan antalet defekter som hittas av kunden och testaren att vara lika med 0,5, men vi förstår att i det första fallet är inte allt så illa, och i det andra är det dags att slå larm.

Efter att utan större framgång ha försökt göra en strikt matematisk bindning till det totala antalet defekter, fäste vi, med samma Irina Lagers ord, "kryckor" till denna formel i form av intervall, för var och en av vilka vi bestämde vår egen koefficienter. Det fanns tre intervall: för statistik från 1 till 20 defekter, från 21 till 60 defekter och för statistik över mer än 60 defekter.

Den sista kolumnen i tabellen introducerades för att förklara hur många defekter det är tillåtet för kunden att hitta i detta prov. Följaktligen, ju mindre urvalet är, desto större kan felet vara, och desto fler defekter kan kunden hitta. Ur funktionens synvinkel innebär detta det begränsande minimivärdet på förhållandet mellan antalet defekter som hittas av kunden och testaren, varefter verkningsgraden blir negativ, eller punkten där grafen korsar X-axeln. ju mindre provet är, desto mer rätt bör skärningspunkten med axeln vara. Ledarmässigt betyder detta att ju mindre urvalet är, desto mindre korrekt är en sådan bedömning, därför utgår vi från principen att testare bör utvärderas mindre strikt på ett mindre urval.

Vi har grafer av följande form:

Den svarta grafen återspeglar kriteriet för provtagning av fler än 60 defekter, gult för 21-60 defekter, grönt för provtagning av mindre än 20 defekter. Det kan ses att ju större urvalet är, desto mer till vänster korsar grafen x-axeln. Som redan nämnts, för den utvärderande medarbetaren innebär detta att ju större urvalet är, desto mer kan man lita på denna siffra.

Utvärderingsmetoden består i att beräkna effektiviteten av testarens arbete enligt formel (2), med hänsyn till korrigeringsfaktorerna och jämföra denna uppskattning med det erforderliga värdet på grafen. Om poängen är över grafen uppfyller testaren förväntningarna, om den är lägre arbetar testaren under den obligatoriska "stapeln". Jag vill också notera att alla dessa siffror valdes empiriskt, och för varje organisation kan de ändras och väljas mer exakt över tid. Därför välkomnar jag bara kommentarer (här eller på min personliga blogg) och förbättringar.

Denna metod för utvärdering av förhållandet mellan antalet defekter som hittats av testteamet och kunden/användaren/klienten förefaller mig rimlig och mer eller mindre objektiv. Det är sant att en sådan bedömning kan utföras först efter projektets slutförande, eller åtminstone om det finns aktiva externa användare av systemet. Men vad händer om produkten inte används ännu? Hur utvärderar man en testares arbete i detta fall?

Dessutom skapar denna teknik för att utvärdera effektiviteten hos en testare flera ytterligare problem:

1. En defekt börjar delas upp i flera mindre.

· Testledaren, som uppmärksammat en sådan situation, bör stoppa den med informella metoder.

2. Defekthantering blir mer komplex på grund av det ökande antalet dubbla poster.

· Regler för att logga defekter till felspårningssystemet, inklusive obligatorisk granskning av liknande defekter, kan hjälpa till att lösa detta problem.

3. Bristande kvalitetsbedömning av de upptäckta defekterna, eftersom testarens enda mål är antalet defekter och, som ett resultat, bristen på motivation för testaren att söka efter "kvalitets"defekter. Ändå kan man inte sätta likhetstecken mellan kritikaliteten och "kvaliteten" hos en defekt, det andra är ett mindre formaliserat koncept.

· Här bör den avgörande rollen spelas av både testarens och ledarens "attityd". Endast en allmän korrekt (!) förståelse av innebörden av en sådan kvantifiering kan lösa detta problem.

Genom att sammanfatta allt ovan kommer vi till slutsatsen att det inte bara är svårt, utan inte heller helt korrekt att utvärdera en testares arbete endast med antalet upptäckta defekter. Därför bör antalet upptäckta defekter endast vara en av indikatorerna för den integrerade bedömningen av testarens arbete, och inte i dess rena form, utan med hänsyn till de faktorer jag har listat.

Testprocessen bör vara effektiv i första hand ur det företag där den äger rum. Företag kan vara intresserade av följande parametrar i testprocessen:

• Tid som krävs för att utveckla tester
• Tiden det tar för en testcykel
• Kvalificering av personal som krävs för att utveckla och genomföra tester

Genom att ändra någon av dessa parametrar kan företaget påverka testkvaliteten. Det är dock viktigt att förstå att vilken kombination av dessa parametrar som helst kan uttryckas i monetära termer, och som regel har varje speciell testprocess en optimal kombination som uppnår en tillräcklig nivå av testkvalitet till minimala monetära kostnader.

Genom att automatisera testprocessen ändrar vi naturligtvis testprocessen, och med den kommer även den optimala kombinationen av ovanstående parametrar att förändras. Det kan till exempel förväntas att tiden som krävs för att utveckla tester kommer att öka och kraven på personalens kvalifikationer kommer att öka, samtidigt som den tid som tas upp av en testcykel kommer att minska kraftigt. Med tanke på att kombinationen av parametrar har blivit ny, kommer kvaliteten på testningen troligen att förändras tillsammans med dess kostnad. För att kunna ge en numerisk motsvarighet till testprocessens effektivitet föreslås att kvalitetsparametern fixeras på en viss nivå. Då blir den numeriska bedömningen av effektiviteten hos en viss testmetod mängden investeringar som krävs för att säkerställa att den ger en viss kvalitetsnivå.

Genomförbarheten av testautomatisering bedöms genom att beräkna kostnaderna för manuell och automatiserad testning och jämföra dem. Det är vanligtvis omöjligt att exakt beräkna den ekonomiska genomförbarheten av testautomatisering, eftersom det beror på parametrar som bara kan förstås grovt under produktutvecklingsprocessen (till exempel den planerade längden livscykel system eller en exakt lista över tester som ska automatiseras).

För att beräkna investeringen som krävs för implementering och drift av automatiserade tester för den tilldelade perioden (Ip), används följande formel:

I0 - En uppskattning av den initiala investeringen, som består av kostnaden för licenser för nödvändig programvara för att utveckla autotester, kostnaden för ytterligare hårdvara, etc.

C0 - En uppskattning av kostnaden för att utveckla och felsöka ett automatiserat testbibliotek, som beräknas som produkten av den genomsnittliga tid som behövs för att skriva ett automatiserat test av en testutvecklare (i timmar), multiplicerat med priset på hans arbetstimme och det totala antalet tester som ska automatiseras.

Ce - En uppskattning av kostnaden för en körning av alla automatiserade tester, som beräknas som den tid som krävs för att förbereda sig för testning, läggs till den genomsnittliga tiden för att slutföra ett test med en testare, multiplicerat med kostnaden för en arbetstimme och totalt antal tester. I vårt fall tas denna variabel som 0, eftersom förberedelse för testcykeln inte krävs, och själva testningen kräver inte ytterligare kontroll från den anställde och är helt autonom.

Ca - En uppskattning av kostnaden för att analysera resultaten av en iteration av en automatiserad testcykel, som beräknas som en uppskattning av andelen negativa tester, multiplicerat med antalet tester, med den genomsnittliga tid som krävs för att analysera orsakerna till en negativ bedömning av ett test av en testare och av priset för en arbetstimme av testaren.

Cm - Uppskatta kostnaden för att hålla automatiserade tester igång. Den beräknas som sannolikheten för behovet av att ändra ett test mellan testcyklerna, multiplicerat med antalet tester, med den genomsnittliga tid som krävs för att uppdatera ett test och med priset för en arbetstimme för testaren.

Uppskattad kostnad för manuell testning (Gp) presenteras i följande formel:

G0 - Uppskattning av kostnaden för att utveckla en databas med testfall för manuell testning.

k - Detta är antalet planerade testkörningar (testcykler) för den återstående tiden av produktens livscykel.

Ge - En uppskattning av kostnaden för att utföra en manuell testcykel en gång, vilken beräknas som den genomsnittliga tid som spenderas för att förbereda för testning plus den genomsnittliga tid som krävs för att slutföra ett testfall med en testare, multiplicerat med det totala antalet fall och med priset för en arbetstimme av testaren.

Ga - En uppskattning av kostnaden för att analysera resultaten för en körning av den manuella testcykeln. Den beräknas som en uppskattning av den genomsnittliga andelen negativa tester i en körning, multiplicerad med antalet tester, med den genomsnittliga tid som krävs för att analysera orsakerna till en negativ bedömning av ett test av en testare, och med priset för en arbetstid för en testare;

Gm - Uppskattning av kostnaden för att hålla manuella tester uppdaterade. Den beräknas som sannolikheten för behovet av att ändra ett test mellan testcyklerna, multiplicerat med antalet tester, med den genomsnittliga tid som krävs för att uppdatera ett test och med priset för en arbetstimme för en testare.

Vid behov: att bedöma relationen i teamet, medarbetarnas intresse av att uppnå resultat och deras motivation.

Woodcock test

Instruktion

Läs påståendena som beskriver ditt lag och ringa in siffrorna på dem du håller med. Om du tror att påståendet inte är helt sant, lämna då svarsfältet tomt.

Lägg inte mycket tid på att tänka på varje påstående: några sekunder räcker.

Kom ihåg att resultaten bara är vettiga om du är uppriktig.

Testa

1. Vårt team utmärker sig i ledarskap.

2. Beslut verkar påtvingas oss.

3. Människor uppmuntras inte att säga ifrån.

4. I en svår situation tar alla upp sina intressen.

5. Kommunikationen behöver förbättras.

6. Beslut fattas om otillräcklig nivå hierarki.

7. Vissa chefer är inte uppriktiga mot sig själva.

8. Vi ifrågasätter sällan innehållet eller användbarheten av våra möten.

9. Otillräckliga utvecklingsmöjligheter skapas.

10. Vi bråkar ofta med andra divisioner.

11. Teammedlemmar kommunicerar inte bra med varandra.

12. Det är tydligt vad organisationen förväntar sig av vårt team.

13. Den accepterade ordern ifrågasätts sällan.

14. I verkligheten är det inte klart för någon vart vi är på väg.

15. Folk säger inte vad de verkligen tycker.

16. Människor har positionen "min koja är på kanten."

17. I ett team är konflikter destruktiva.

18. Beslut grundas på otillräcklig information.

19. Vissa chefer är inte betrodda.

20. Vi lär oss inte av våra misstag.

21. Chefer hjälper inte sina underordnade att lära sig.

22. Relationer med andra grupper är coola.

23. Vi tänker inte så bra på vår position inom organisationen.

24. Vårt team är "politiskt" mottagligt.

25. Vi finner ofta att vi saknar de rätta kvalifikationerna.

26. Vi är alla väldigt upptagna, men det verkar som att vi inte har tid med allt.

27. Kontroversiella frågor gömmer sig under mattan.

28. Det skulle hjälpa om människor var mer villiga att erkänna sina misstag.

29. Det finns misstro och fientlighet.

30. Människor får inte fatta beslut.

31. Lite lojalitet till laget.

32. Åsikter utifrån är inte välkomna.

33. Bör ha en stor arbetsrotation.

34. Vi arbetar sällan effektivt med andra team.

35. Vi misslyckades med att säkerställa samarbete med andra team och enheter.

36. Förmågan att arbeta i ett team är ett urvalskriterium för tillträde till denna organisation.

37. Ingen gör de nödvändiga kopplingarna till andra grupper.

38. Vi lägger inte ner den tid som krävs för att planera för framtiden.

39. Sköra frågor undviks.

40. Det händer att någon har blivit "huggen i ryggen".

41. Vi jobbar inte riktigt ihop.

42. Fel människor fattar beslut.

43. Chefer är svaga och inte redo att slåss och kräver uppmärksamhet på sin synvinkel.

44. Jag får inte tillräckligt med feedback.

45. Olämpliga typer av färdigheter utvecklas.

46. ​​Hjälp kommer inte från andra delar av organisationen.

47. Det finns ett starkt missförstånd mellan vårt team och fackföreningarna som sätter press på oss.

48. Lagarbete belönas i denna organisation.

49. Vi uppmärksammar inte relationer tillräckligt.

50. Vi har inte en klar uppfattning om vad som förväntas av oss.

51. Ärlighet är det inte funktion vårt lag.

52. Jag känner inte stöd från mina kollegor.

53. Färdigheter och information är inte väl spridd.

54. Tillgänglig starka personligheter som går sin egen väg.

55. Självrespekt är ogynnsamt.

56. Vi borde lägga mer tid på att diskutera arbetssätt.

57. Chefer tar inte personlig utveckling på allvar.

58. Andra delar av organisationen förstår oss inte.

59. Vi misslyckas med att förmedla vårt budskap till omvärlden.

60. Personer i teamet har goda kontakter med andra medlemmar i organisationen.

61. Ofta når vi beslut för snabbt.

62. Ett handlingssätt som värdesätter individen har lite att göra med vad som har uppnåtts.

63. För många hemligheter.

64. Konflikter undviks.

65. Oenigheter korrupta.

66. Engagemanget för lösningar är lågt.

67. Våra chefer tror att större tillsyn förbättrar resultaten.

68. För många avstängningar i vårt lag.

69. Det är tydligt att det finns bättre möjligheter i en annan enhet.

70. Vi lägger mycket energi på att skydda våra gränser.

71. Teammedlemmar förstår inte vad som förväntas av dem.

72. Organisationens kultur uppmuntrar lagarbete.

73. Vi uppmärksammar inte nya idéer tillräckligt.

74. Prioriteringarna är inte klara.

75. Människor är inte tillräckligt involverade i beslutsfattandet.

76. För många ömsesidiga anklagelser och förebråelser.

77. De lyssnar inte alltid.

78. Vi utnyttjar inte den kompetens vi har fullt ut.

79. Chefer tror att människor till sin natur är lata.

80. Vi lägger mycket tid på att göra och spenderar inte tillräckligt med tid på att tänka.

81. Individens önskan att växa uppmuntras inte.

82. Vi försöker inte förstå andra lags synvinkel.

83. Vi misslyckas med att lyssna på våra kunder.

84. Teamet arbetar i enlighet med organisationens mål.

Tack för svaren!

Nyckeln till Woodcock-testet för att utvärdera teamprestationer

Beskrivning

Woodcock-testet är utformat för att mäta lagets prestation. Låter dig utvärdera relationen i teamet, medarbetarnas intresse av att få resultat och deras motivation. Företagets lojalitet och nivån av interaktion mellan organisationens avdelningar beaktas också.

Principen för testning är enkel. Varje gruppmedlem, oavsett position, fyller i ett frågeformulär som innehåller 84 påståenden. Därefter beräknas och analyseras resultaten enligt en särskild tabell.

Om du tvivlar på att teammedlemmarna kommer att svara ärligt på frågor, försök att säkerställa testningens anonymitet. I stort sett är detta redan en indikator på relationen i teamet. Trots det är testning fortfarande användbar, eftersom dess resultat gör att du kan identifiera brister i teamets arbete mer exakt.

Dessutom är det mycket användbart att jämföra testresultaten från chefer och deras underordnade. Detta låter dig bedöma atmosfären i laget och bestämma graden av förtroende hos underordnade till ledarskapet.

Nyckeln till testet

Överför de markerade svaren från frågeformuläret till resultattabellen. Räkna antalet markeringar i varje kolumn. Skriv mängden i raden "Totalt".

Resultattabell

Överför kolumnantalet från raden "Totalt" till tabellen.