User:Abd/Software Testen/Algemene kennis

Introductie

In deze module gaan we iets verder in op het begrip "kwaliteit". Het is de bedoeling om wat achtergrondinformatie te geven die van pas kan komen bij de andere modules. Kwaliteit is een ruim begrip en wordt door verschillende mensen verschillend ervaren. We beginnen daarom met een aantal definities die iets trachten te zeggen over het begrip kwaliteit.

Vervolgens gaan we verder in op enkele modellen die gebruikt worden bij het managen / beheersen van kwaliteit. Bij ieder onderdeel worden enkele overwegingen geplaatst die voornamelijk gestoeld zijn op mijn eigen ervaringen.

Definities van kwaliteit

Er zijn diverse definities of beschrijvingen van de term "kwaliteit" te vinden in de literatuur. Om je een indruk te geven kun je de volgende link eens volgen: Kwaliteit. Zoals je kunt zien zijn er nogal wat definities aangaande kwaliteit. Eén element hebben de meeste definities in zich: "Iets moet ergens aan voldoen en dat moet je kunnen meten".

Enkele definities op een rij:

Joseph Juran: Fitness for use (geschiktheid voor gebruik)
Wim Scharpé: Performance x Acceptance (formule Q = P x A, die de nadruk legt op zowel de kenmerken en performantie (de prestaties) van het product als op de acceptatie en tevredenheid van de klant)
Philip B. Crosby: Conformance to requirements (voldoen aan specificaties)
Nederlands Normalisatie Instituut: Geheel van kenmerken van een entiteit dat betrekking heeft op het vermogen van die entiteit om kenbaar gemaakte en vanzelfsprekende behoeften te bevredigen.
ISO 8402: het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften.

Meer informatie: wikipedia.

Crosby

Eén van de meest elegante definities vind ik de definitie van Philip B. Crosby:

Kwaliteit is "voldoen aan eisen".

Met eisen bedoelt hij: Eisen aan het product én eisen van de klant

Zijn "systeem" is gebaseerd op vier pijlers met als doel om de dingen in één keer goed te doen: "doing it right the first time".

De definitie van kwaliteit is: Voldoen aan eisen
Het systeem is: Preventie
De norm is: Geen fouten (t.o.v. de eisen)
De meetlat is: De prijs voor het niet voldoen

Meer informatie over Crosby.

Vertaling naar een "IT-project"

Voldoen aan eisen: Eisen / wensen worden neergelegd in een document dat de requirements beschrijft. Vervolgens wordt dit vertaald naar een ontwerp. Op basis van het ontwerp wordt gebouwd.
Preventie: Lastige, meestal wordt dit vertaald naar een ontwikkelproces met diverse afspraken over de manier waarop het project wordt vormgegeven.
Norm: Soms wordt dit vertaald naar het aantal fouten dat nog in de software mag zitten, deze fouten worden geclassificeerd (wat is de zwaarte van de fout).
Meetlat: Dit worden vaak de "acceptatiecriteria". deze worden door de klant opgesteld en kunnen dienen als meetlat waartegen getest wordt.

Enkele overwegingen

De definities zijn bedoeld om iets te zeggen over de kwaliteit van een product dat uit een fabriek komt. Een fabriek is in wezen een verzameling van processen dat producten voortbrengt. Deze processen zijn vaak te typeren als lopende-band-processen. Dit zijn repeterende processen waarvan wordt verwacht dat de uitkomst, het product, steeds min of meer hetzelfde is. Bijvoorbeeld het maken van potloden. Dit type processen is relatief eenvoudig meetbaar te maken en te verbeteren.

Fabriek

Het gebruikte proces is ongeveer als volgt:

Er wordt een product bedacht, bijvoorbeeld een geel potlood met een bepaalde lengte, dikte en vorm.
De productieprocessen om het te maken worden ingericht
Het resultaat wordt gecontroleerd op de vastgestelde kleur, lengte, dikte en vorm
Het resultaat (een potlood) wordt gedistribueerd en verkocht aan klanten

Bovenstaand voorbeeld is eenvoudig te matchen met de genoemde definities. Voor software-ontwikkelingsprocessen zijn genoemde definities lastiger te matchen.

Software ontwikkeling

Software-ontwikkelingsprojecten zijn vaak beter te vergelijken met een creatief proces waarbij er steeds weer andere ideeën en inzichten zijn en waarbij het productieproces steeds weer anders verloopt. Ook de wensen en eisen zijn gedurende het "productieproces" vaak aan verandering onderhevig. Hierdoor is de meetlat waarmee bepaald wordt of de software goed is (kwaliteit heeft) niet steeds hetzelfde.

Daarmee is het dus lastig om te voldoen aan de definitie zoals Crosby die stelt: Kwaliteit is voldoen aan eisen. Tenzij je er vanuit gaat dat ook in zijn definitie de eisen bijgesteld kunnen worden. De interpretatie is meestal dat de eisen van te voren zijn vastgesteld. "Dan weten we vooraf tenminste wat we moeten gaan maken."

De praktijk wijst anders uit.

Uiteraard zijn op bovenstaande wel wat aanmerkingen te plaatsen, in sommige gevallen kan software ook op een fabrieksmatige manier geproduceerd en gecontroleerd worden. In de meeste gevallen is dat echter niet zo.

Eisen aan het proces

Wat vaak gebeurd is dat er eisen gesteld worden aan de manier (het proces) van software-ontwikkelen om zo enige grip te hebben op de uitkomst (het product) dat wordt geproduceerd. Hier gaan we later verder op in.

Kortom: Als software-tester moet je dus rekening houden met een wijzigende meetlat.

Modellen

Deming

File:Deming.jpeg

Deming Cirkel

De "Deming-Cirkel" is misschien wel één van de bekendste modellen die gebruikt wordt in het kader van Kwaliteit en Kwaliteitsmanagement.

Korte beschrijving van het model

De cirkel is verdeeld in vier met elkaar samenhangende begrippen: Plan, Do, Check en Act. Het model kan gebruikt worden voor voortdurende verbeteringen in organisatie. Het plannen van een activiteit met een helder doel wordt gevolgd door het uitvoeren van die activiteit, het controleren van het resultaat (meten) ten opzichte van het oorspronkelijke doel. Om vervolgens nieuwe activiteiten te formuleren. Omdat de cirkel "doorrolt" kunnen leerervaringen steeds weer meegenomen worden in volgende "rondjes" Plan, Do Check, Act.

Toepassing

Met het model is het mogelijk om activiteiten te kunnen volgen. Elke activiteit doorloopt de vier aangegeven fasen waardoor het managen van de verbeteringsactiviteiten makkelijker wordt. Verbeteractiviteiten "stoppen" vaak na de eerste twee fasen namelijk het plannen en het starten met de uitvoering. Vaak wordt het resultaat niet gemeten en wordt dit ook niet als leerinput voor volgende activiteiten gebruikt. Voor veel organisaties zijn met name de twee fasen, Check en Act een "eye-opener". Het model dwingt een organisatie -als het gevolgd wordt- steeds weer na te denken over de resultaten van hun acties alvorens een volgende activiteit gestart kan worden. Dit zorgt voor een beter gemeten en beheersbaar verbeterproces. De Act-fase wordt ook weleens de Adept-fase genoemd.

Opmerkingen

Doelstellingen, activiteiten en resultaten moeten concreet gemaakt worden bij het toepassen van dit model. Organisaties die bij de activiteiten niet duidelijk of inconsitent zijn zullen moeite hebben met het gebuik van dit model. Het managen van de doelstellingen en het vermogen om ervan te leren zal dan beperkt zijn.

Variant

File:DemingCirkelVariant.jpeg

Variant op de Deming Cirkel

Een variant op de Demingcirkel staat hiernaast afgebeeld. De stijgende lijn waarop de Cirkel staat geeft de richting van de verbeteringen aan (omhoog). Naarmate de cirkel meer rondjes maakt rolt hij hoger langs de lijn. Onder de cirkel is een driehoek getekend. Deze is bedoeld om het behaalde resultaat te borgen zodat de cirkel niet kan terugrollen naar beneden. Het borgen kan op diverse manieren vorm gegeven worden.

Eén van de mogelijkheden is het inrichten van kennismanagement. Hiermee kan alle opgedane ervaring worden vastgelegd en zodoende helpen met het verder verbeteren van een organisatie.

Een andere manier is het vastleggen van procedures zodat iedereen deze kan weten en kan toepassen. Een bekende term in het beschrijven en vastleggen van procedures is ISO (International Organization for Standarization / Internationale Standardisatie Organisatie). Hier komen we later nog eens terug want zij hebben ook een model voor Software Quality.

Zo zijn er nog diverse andere manieren om het terugrollen van de cirkel te voorkomen.

Meer over Deming (en zijn Cirkel) is hier te vinden.

Deming Cirkel en Software-ontwikkelprojecten

De Deming Cirkel is te leggen op de manier waarop (Software) projecten worden vormgegeven:

Plan: Het vaststellen van de te realiseren wensen in bijvoorbeeld een business case, of wellicht al in de requirements (wensen en eisen). In het geval van de businesscase wordt aangegeven waarom bepaalde wensen en eisen van belang zijn. De haalbaarheid wordt ingeschat en de te verwachten resultaten worden ingeschat. Dit laatste kan op diverse manieren gedaan worden. Bijvoorbeeld: 15% minder telefoontjes van klanten, 25% versnelling van doorlooptijden, besparing op kosten met 10.000 euro per jaat, etc.
Do: er wordt een plan gechreven op basis waarvan het project van start gaat. Wensen en eisen worden concreet genoeg gemaakt om te kunnen omzetten in Software. De software wordt ontworpen. Vervolgens gemaakt, getest en vrijgegeven voor gebruik.
Check: Na een afgesproken periode wordt gecontroleerd in hoeverre de doelstellingen (resultaten) zijn behaald. Daarnaast wordt het project geevalueerd om te bepalen wat goed is gegaan en wat beter kan.
Act: Acties worden bepaald voor het vervolg om er voor te zorgen dat het beter gaat.

Deze laatste twee punten worden bijna nooit voldoende goed uitgevoerd. Vaak wordt een evaluatie van het project gedaan met diverse personen. Deze evaluatie wordt op schrift gesteld en er verandert bijna nooit iets. De evaluatie ten aanzien van de doelstellingen wordt ook weleens gedaan maar meestal buiten het zicht van de projectdeelnemers

Filmpje

Kijk hier naar een leuk filmpje over de Deming Cirkel. In het filmpje kun je zien dat de Check-fase is veranderd in de Study-fase. De variant met de "S" zie je steeds vaker toegepast worden. Het filmpje duurt iets meer dan 8 minuten. PDSA Cirkel

EFQM / INK - Model

File:EFQM-Model.png

EFQM / TQM - Model

Samenvatting

Het EFQM-model, in Nederland INK-model genoemd, kent vijf organisatiegebieden en vier resultaatgebieden. De organisatiegebieden worden bestuurd door managers, de resultaatgebieden zijn bedoeld voor het meten van de prestaties van de organisatie.

Organisatiegebieden:

Leiderschap,
Beleid en Strategie
Personeelsbeleid
Middelenmanagement
Processen

Resultaatgbieden zijn:

Waardering door medewerkers
Klantwaardering
Waardering door de maatschappij
Ondernemingsresultaten (financiële en niet-financiële resultaten)

Per resultaatgebied worden de resultaten teruggekoppeld aan de organisatiegebieden en beoordeeld aan de hand van prestatie-indicatoren die zijn afgeleid van de organisatiedoelstellingen. Zo kan bepaald worden of de resultaatgebieden voldoende bijdragen aan de doelstellingen. Eventueel kan dan vanuit de organisatiegebieden de sturing worden aangepast.

Meer over het EFQM-Model: Hier

Toepassing

Dit model is mede ontwikkeld door managers van Philips, Renault en anderen. Door hun input is het model herkenbaar voor andere managers, zijn zien hun kerngebieden / aandachtsgebieden terug in dit model. Het kan helpen bij het verbeteren van de interne en externe kwaliteit van de organisatie, (klantwaardering en maatschappelijk waardering hebben een plaats in het model).

Opmerkingen

Het is een breed model dat tracht een hele organisatie te beschrijven aan de hand van aandachtsgebieden die met elkaar verband houden. Het is een vrij statisch model, dat goed te gebruiken is voor het stellen van een diagnose en het meten van de “kwaliteit” van een organisatie. Mijn inziens missen er, echter, twee zaken in het model:

Wat is de essentie ervan?
Hoe is de (verbeter)actie ondergebracht?

Het model is met name te gebruiken om probleemgebieden te indentificeren. Het kan goed worden gebruikt voor het vormgeven en uitvoeren van een zogenaamde Quick Scan. Hierdoor kunnen aandachtsgebieden bloot gelegd worden. Het is mogelijk om deze gebieden vervolgens aan te pakken met behulp van de Deming-Cirkel. Hierna kan vervolgens nogmaals een quick scan worden uitgevoerd om te zien of de aanpassingen resultaat gehad hebben. Verderop zal ik een integraal voorbeeld geven (soort Case) waarbij alle behandelde modellen samenwerken (inclusief het ISO-model 9126 dat bedoeld is voor het beschrijven / beoordelen van de kwaliteit van software. In het volgende deel gaan we verder in op het genoemde ISO 9126-model.

Filmpje

Een goed, misschien beetje saai, filmpje waarin het model nog eens wordt toegelicht. EFQM

ISO 9126 - Model

Samenvatting

File:ISO9126-Model.jpg

ISO 9126-Model

File:ISO9126.pdf

Definities

Het ISO 9126 - model beschrijft een aantal software-eigenschappen. Het geeft een aantal handvatten die kunnen helpen bij het beschrijven van softwareproducten. Het model is onderverdeeld in Kwaliteitseigenschappen en Kwaliteitsattributen. Er zijn 6 eigenschappen, elke eigenschap wordt op haar buurt weer beschreven met een aantal Kwaliteitsattributen. Er zijn 31 attributen, in sommige varianten van dit model zijn er 33 attributen. Ik beschrijf hier het model met 31 attributen.

Kwaliteitseigenschappen, tussen haakjes staat het aantal attributen:

Betrouwbaarheid (5)
Functionaliteit (6)
Efficientie (2)
Bruikbaarheid (8)
Overzetbaarheid (4)
Onderhoudbaarheid (6)

De uitgebreidere definities staan hiernaast.

Toepassing

Zoals gezegd kan het model helpen bij het beschrijven van Softwareproducten. Als een nieuw softwareproject start is intensieve samenwerking nodig tussen de opdrachtgever (meestal business) en de uitvoerder (meestal het project). Dit model kan de discussie helpen vormgeven. Je kunt bijvoorbeeld aangeven welke eigenschappen het meest van belang geacht worden door de opdrachtgever, dit kan vorm geven aan de manier waarop het project wordt ingericht.

Voor het testen van de software kan het model ook helpen om de belangrijkste eigenschappen meer aandacht te geven tijdens het testproces. De attributen geven handvatten voor de testen die uitgevoerd kunnen worden.

Overwegingen

Als je kijkt naar het model dan zul je zien dat zowel de eigenschappen als de attributen niet echt concreet zijn. De eigenschap "Bruikbaarheid" is niet uit te drukken in cijfers zoals "Kilogrammen", "Millimeters", "Kilometers per uur" of iets dergelijks. Dit houdt in dat er altijd interpretatiemogelijkheden zijn. Hierin zit de moeilijkheid van dit model en van software-ontwikkeling in het algemeen. Verder in de cursus komen we hier nog uitgebreid op terug.

Daarnaast mist een belangrijke eigenschap: "Veiligheid". Het model bestaat al geruime tijd. In de software-omgeving die we tegenwoordig hebben, is security (veiligheid) een zeer belangrijk aandachtspunt. De media leggen steeds vaker de gevaren bloot van het niet goed beveiligen van informatie, denk bijvoorbeeld aan het EPD (Electronisch Patienten Dossier, tegenwoordig Landelijk Schakel Punt genoemd). Het EPD is al geruime tijd onderwerp van discussie, er zijn en worden zelfs rechtzaken aangespannen om te achterhalen in hoeverre het EPD de wet "Bescherming Persoongegevens" overtreedt. In de software-omgevingen die we gebruiken heeft "De cloud" (het bewaren van gegevens op "het internet" die, theoretisch, globaal toegankelijk zijn) een steeds belangrijkere rol.

Afronding

We hebben een korte introductie achter de rug met als doel om enige achtergrondkennis te verschaffen over de begrippen "Kwaliteit" en "Kwaliteitsmanagement". Deze kennis is voor iedereen die iets met testen te maken heeft van belang om eea in perspectief te kunnen plaatsen. In de nu volgende case worden alle besproken modellen gebruikt om nog een extra verdieping te geven en om te laten zien hoe deze in de praktijk gebruikt kunnen worden.

De pdf-versie van dit hoofdstuk is te downloaden via "Software Testen: Downloads".

Linkjes

Verder naar de Case: Software Testen: Algemene kennis - Case
Verder naar het volgende hoofdstuk: Software Testen: Projecten
Terug naar Overzichtpagina: Software Testen

Downloads: Software Testen: Downloads 15:56, 16 August 2014 page deleted

Category:Wikiversiteit Category:NL