Skip to main content

Categorie: KOM

TestNet Leergang: Share your Brains

De vereniging TestNet verbindt testprofessionals uit het gehele land, van diverse bedrijven en van ieder niveau. Zij doen dit door op regelmatige basis Thema-avonden te organiseren, door trainingsmogelijkheden zoals de werkgroepen en TestNet Summerschool. Daarnaast is TestNet voortdurend op zoek naar nieuwe vormen waarbinnen de leden met en van elkaar kunnen leren. Zo kwam het dat 2B4QA, begin 2017 gevraagd werden om pilot uit te werken voor een nieuwe werkvorm: De TestNet Leergang.

 Ons concept was vrij simpel: Vijf avonden lang werken vier parallelle groepen aan een specifiek topic binnen een vastgesteld kader. Het doel is een concreet, bruikbaar eindproduct. Iedere deelnemer kiest op de avond zelf aan welk onderwerp hij of zij wil bijdragen. Je kiest zelf aan welk product jij je hersenen wilt uitlenen: Share your Brains.

 Het benoemen van het onderwerp, het schetsen van de context en het definiëren van de verschillende vraagstellingen en het daadwerkelijke eindproduct is feitelijk het lastigste van de gehele leergang. Wat is actueel? Wat is voor een ieder interessant? Wat is nog niet eerder volledig uitgewerkt? Bernd en ik besloten op de toepassing van kwaliteitszorg binnen een continuous integration pipeline eens onder de loep te nemen. Dit leidde tot de volgende beschrijving:

 ISO-SQuaRe binnen CI/DevOps

Functionaliteit is de meest belangrijke eigenschap van ieder object. De functionaliteit bepaalt of dit object nuttig is of juist niet. Zo’n object kan van alles zijn: bijvoorbeeld een koffiezetapparaat, een auto, een mobiele telefoon, een stoel of software. In het kader van leergang doelen we op de functionaliteit van de laatste, de software. Deze software kan een interface, een Graphical User Interface (GUI), een webapplicatie of zelfs een compleet informatiesysteem zijn. Voor al deze onderdelen geldt: de functionaliteit beschrijft ‘wat’ de software moet doen. Vervolgens zijn het de compleetheid, correctheid en toepasbaarheid die bepalen op welk niveau de software geschikt is voor haar doel. Dus functionaliteit is uitermate belangrijk. Maar hoe zit het met de andere categorieën, de hoedanigheden van de software? Hoe krijgen we de overall kwaliteit op orde?

 Hoe kunnen we verschillende non-functional testen integreren in een continuous delivery pipeline of een continuous integration proces? Want moeten testen als installability, maintainability niet naast performance en security in een CI-pipeline? Tijdens deze leergang ontwikkelen we samen een wijze waarop verschillende onderdelen van ISO-SQuaRE en de toepassing van de  kwaliteitsattributen (ISO 25010) binnen DevOps-team worden samengevoegd.

De nadruk ligt op de testfase (model 2501x). Hoe kunnen we bijvoorbeeld een PRA uitvoeren binnen een Agile omgeving? Hoe gaan we om met risico-classificatie aan de hand van pokerkaarten en hoe kunnen we functionaliteit en hoedanigheden beoordelen vanuit verschillende rollen (product owner, beheer, development team, architectuur) binnen een continuous integration pipeline?

De Uitvoering

22 maart vond de kick-off plaats. Als vanzelf ontstonden vervolgens de parallelle groepen waarbinnen in de opeenvolgende avonden interessante discussies plaatsvonden, menig idee werd uitgewerkt en het eindproduct langzaam maar zeker vorm begon te krijgen. Wat is de minimale uitgangspositie voor een continuous integration pipeline? Hoe ga je om met een product risico analyse in een DevOps-organisatie? Hoe verhouden de functionaliteiten zich ten opzichte van de karakteristieken van de te ontwikkelen software? Welke relatie bestaat er tussen productkwaliteit, datakwaliteit en de kwaliteit van het informatiesysteem in gebruik?

 Het resultaat

Wat ons betreft is de pilot geslaagd. Het is gebleken dat het oprecht gebruik maken van elkaars kennis en kunde zonder de vraagstelling ter discussie te stellen en met de vrijheid om op ieder moment van onderwerp te kunnen wisselen het mogelijk maakt om heel snel resultaten op te leveren. Het rouleren zorgt voor dynamiek en frisse, verrassende inzichten. Een van te voren vastgestelde doorlooptijd (in dit geval 5 avonden) zorgt voor een duidelijke deadline en vergroot de betrokkenheid. Je weet per slot van rekening waaraan je je verbindt. En dat was dan alleen nog maar de werkvorm. Wat dacht je van de eindproducten?

Op de laatste avond zijn de resultaten gepresenteerd. Een modulaire opbouw voor een continuous integration pipeline, een PRA binnen DevOps-teams en een matrix waarbinnen het verband tussen de verschillende ISO 250xx-normen is uitgewerkt. Mooie, bruikbare producten. Ben jij nieuwsgierig naar het resultaat? Neem dan eens een kijkje in de bibliotheek van TestNet of kom naar TestNet Werkgroepen Presentatie. Wij zullen daar onze resultaten nogmaals aan een breder publiek presenteren

 

ISO Square

ISO 25010

De ISO 25010 is een van de normen binnen de 250xx serie, die tezamen ook wel ISO SQuaRE worden genoemd. Voordat we de diepte ingaan met de 25010 norm, schets ik eerst de 25010.


Hoewel er in de 250xx reeks nog een aantal normen zijn (25050 en hoger) beperk ik me tot de normen zoals die hierboven schematisch zijn weergegeven. De hogere normen richten zich op internationale standaards en technische eisen, die ik in mijn projecten niet tegenkom.

In onze weergave van de ISO SQuaRE hebben we management (ISO 2500x) in het midden geplaatst. Deze richt zich op de kwaliteit van het proces. In Kwaliteit op Maat had ik dit naast de productkwaliteit opgenomen. De kwaliteit van het proces wordt bepaald door Management en Planning. Deze twee (hoofd)categorieën zijn dan ook in de cirkel rond de 2500x opgenomen.


Hoewel je in eerste instantie uit de nummering van de ISO normen een andere volgorde zou opmaken, hanteren wij de volgorde zoals je met de klok mee kunt lezen van rechtsboven naar linksboven. Beginnen met Requirements (2503x), dan Model (2501x) en Kwaliteitsmeting (2504x) om uit te komen bij Evaluatie (2502x). In de buitenste rand lees je per ISO norm de (hoofd)categorieën waarbinnen uiteindelijk via een categorie de kwaliteitsattributen zijn opgenomen. In de 2501x zie je als (hoofd)categorie Product (ISO 25010), deze heeft bijvoorbeeld de categorie Onderhoudbaarheid maar daarbinnen het attribuut Wijzigbaarheid. Hopelijk duizelt het je nog niet. Als dit wel het geval is, neem ik je stap voor stap mee naar de diverse normen.


Ik loop kort de normen na. Requirements (2503x) heeft als (hoofd)categorieën Stakeholder en Software, Model (2501x) heeft Product en Gebruik/Data, Kwaliteitsmeting (2504x) heeft Indicatoren en Referentiemodel en uiteindelijk Evaluatie (2502x) heeft Proces en Herstelbaarheid.


Jullie hebben wel in de gaten dat ik voorlopig stof genoeg heb om over te bloggen. Volgende blog ga ik in op de ISO 25010, Productkwaliteit.

ISO 25010 – Functionaliteit en Hoedanigheid

Functionaliteit en Hoedanigheid – ISO 25010


In mijn vorige blog heb ik de ISO 25010 in de context van ISO SQuaRE geschetst. Deze keer gaan we een eerste stap maken binnen ISO 25010 en wel binnen productkwaliteit. Zoals in de schematische weergave in de vorige blog zagen jullie dat de ISO 25010 is opgedeeld in Productkwaliteit en Gebruik & Data. Natuurlijk ga ik in de toekomst op Gebruik & Data dieper in, maar nu eerst productkwaliteit.


De ISO 25010 is dus in mijn terminologie een hoofdcategorie van ISo SQuaRE en bevat op zichzelf acht categorieën die de eigenschappen van het systeem beschrijven. In het midden staat de categorie Functionele Geschiktheid die bestaat uit Correctheid, Toepasbaarheid en Compleetheid. Nu is Functionele Geschiktheid altijd de belangrijkste eigenschap. Een razendsnelle applicatie die niet toepasbaar is, compleet is of correct functioneert, wordt niet gebruikt en zal zeker niet gaan renderen. Daarom positioneer ik deze ook in het midden. In verschillende presentaties op seminars zie ik een variant op de pyramide van Maslov terugkomen, waarbij Functionele Geschiktheid de onderste laag is. Een mooie vergelijking, want eerst aan de functionele requirements voldoen en pas daarna aan de andere (hoedanigheids) eigenschappen. Ik hanteer hier wederom de indeling die ik in Kwaliteit op Maat heb gehanteerd, namelijk productkwaliteit bestaat uit Functionaliteit en Hoedanigheid.


Als we rechtsboven beginnen en met de klok mee de overige categorieën langslopen, komen we achtereenvolgens Beveiligbaarheid, Overdraagbaarheid, Betrouwbaarheid, Uitwisselbaarheid, Bruikbaarheid, Prestatie-efficiëntie en Onderhoudbaarheid tegen. De komende weken ga ik ze allemaal in mijn blog behandelen. De positionering, volgorde en kleur op zich hebben geen diepere betekenis. Die zijn uitsluitend zo gekozen om de weergave mooi te kunnen opmaken.


Ongeacht welke betekenis een categorie exact heeft, het is belangrijk om in te zien dat voor de verschillende stakeholders van de applicatie de belangrijkheid van een categorie significant verschilt. Vanuit de beheerafdeling is bijvoorbeeld Onderhoudbaarheid belangrijker dan dat voor de gebruikers. Andersom zal voor de gebruikers de Bruikbaarheid weer belangrijker zijn. Iedereen stelt dus zijn eigen eisen en aan alle eisen voldoen is voor een projectmanager niet te doen. Zijn belangrijkste stakeholder, de opdrachtgever, heeft hem meegegeven dat er een goede, bruikbare en onderhoudbare applicatie moet worden ontwikkeld maar wel binnen budget en op tijd. De duivelsdriehoek uit een van mijn vorige blogs.


Hoe bepaal je nu welke categorie belangrijker is en welke stakeholder heeft het meest te zeggen over de totale hoedanigheid. Voor dat ik daar op inga, de komende blog(s) eerst de verschillende categorieën toelichten.


ISO 25010 – Bruikbaarheid

Bruikbaarheid – ISO 25010


De mate waarin een product of systeem gebruikt kan worden door gespecificeerde gebruikers om effectief, efficiënt en naar tevredenheid gespecificeerde doelen te bereiken in een gespecificeerde gebruikscontext.


Bruikbaarheid van een applicatie is wat mij betreft het meest ongrijpbare en dus het moeilijkste te specificeren van alle categorieën. Een ieder die een applicatie gebruikt, ervaart het gebruik nu eenmaal anders. Ben je onervaren, heb je meer behoefte aan ondersteuning, bel je zeer ervaren wil je het liefst zo min mogelijk ondersteuning. Ik heb niet veel HTML-kennis, maar als ik de pagina’s op de website aanpas vind ik het erg handig dat ik dit direct in de HTML kan doen. Als je weet welke statements er nodig zijn, gaat dat gewoon veel sneller dan via de user interface.


Door de steeds verdere integratie van ICT in onze werkzaamheden en privé, worden we steeds meer ervaren in toepassen van de ICT. Digibeten zijn er nog maar nauwelijks, zeker na de introductie van de IPad. Dit heeft natuurlijk als voordeel dat applicaties complexer mogen zijn dan vroeger. Als er nu wordt gezegd met de muis naar de rechter bovenkant van het scherm, houdt niemand meer de muis zelf tegen het scherm aan, maar weet dat je de cursor daarheen moet bewegen met de muis. Toch worden er door de vele apps ook nieuwe impliciete eisen aan een applicatie gesteld. De eis dat het de look and feel van een apple-app moet hebben, heb ik al geregeld gezien. Wat is de look and feel van een Apple-app? Tja, eenzelfde vraag als voorheen roepen dat de applicatie gebruikersvriendelijk moet zijn. Bruikbaarheid is vooral van belang bij online informatiesystemen waar de gebruiker zelf van achter (of is het voor) een beeldscherm systeemhandelingen moet verrichten. Hoe meer deze aansluiten bij de beleving en de dagelijkse praktijk van de gebruiker, hoe bruikbaarder zij het geautomatiseerde informatiesysteem vinden. Borgen dat het informatiesysteem optimaal gebruikt kan worden, draagt bij aan het terugverdienen van de investering voor het verkrijgen van het informatiesysteem.


De nieuwe generatie gebruikers stellen hele andere eisen aan de bruikbaarheid van een applicatie. Een app moet snel duidelijk maken dat deze uitstekend geschiktheid is voor datgene te doen dat de gebruiker verwacht. Hoe snel is een app tegenwoordig niet weer verwijderd en een andere geïnstalleerd? Geen lange selectietrajecten, klikken, installeren, proberen en dan verwijderen of blijven gebruiken. Alles binnen de minuut. Hoewel bruikbaarheid lastig is te specificeren, draagt het wel heel veel bij aan de gebruiksbeleving. Een belangrijke categorie voor de motivatie van de gebruikers derhalve. Er zijn functioneel correcte applicaties vroegtijdig vervangen omdat er niet mee gewerkt kon worden. (of de gebruiker dit niet wilde).


Definities attributen


Herkenbaarheid van geschiktheid (Appropriateness recognisability)

  • De mate waarin gebruikers kunnen herkennen of een product of systeem geschikt is voor hun behoeften.

Leerbaarheid (Learnability)

  • De mate waarin een product of systeem gebruikt kan worden door gespecificeerde gebruikers om gespecificeerde leerdoelen te bereiken met betrekking tot het gebruik van het product of systeem met effectiviteit, efficiëntie, vrijheid van risico en voldoening, in een gespecificeerde gebruikscontext.

Bedienbaarheid (Operability)

  • De mate waarin een product of systeem attributen heeft die het makkelijk maken om het te bedienen en beheersen.

Voorkomen gebruikersfouten (User error protection)

  • De mate waarin het systeem gebruikers beschermt tegen het maken van fouten.

Volmaaktheid gebruikersinteractie (User interface aesthetics)

  • De mate waarin een gebruikersinterface het de gebruiker mogelijk maakt om een plezierige en voldoening gevende interactie te hebben.

Toegankelijkheid (Accessibility)

  • De mate waarin een product of systeem gebruikt kan worden door mensen met de meest uiteenlopende eigenschappen en mogelijkheden om een gespecificeerd doel te bereiken in een gespecificeerde gebruikscontext

ISO 25010 – Betrouwbaarheid

Betrouwbaarheid – ISO 25010


De mate waarin een systeem, product of component gespecificeerde functies uitvoert onder gespecificeerde condities gedurende een gespecificeerde hoeveelheid tijd.


De derde categorie is Betrouwbaarheid, die bestaat uit Herstelbaarheid, Foutbestendigheid, Beschikbaarheid en Volwassenheid. In de ISO 9126 was Betrouwbaarheid als attribuut opgenomen, die wij in Kwaliteit op Maat als Bedrijfszekerheid hadden benoemd. Ik volg hier de naamgeving zoals in de ISO 25010 wordt gehanteerd, waarbij ik Bedrijfszekerheid eigenlijk beter dan Betrouwbaarheid vind. In de ISO 25010 is Betrouwbaarheid gepromoveerd naar categorie. Op zich terecht, want organisaties worden steeds meer afhankelijk van de ICT.


Bezoekers van een webshop willen niet alleen toegang tijdens kantooruren. Laat staan als het zelfs een mondiale webshop betreft, dan dient deze 24/7 beschikbaar te zijn. Op ieder gewenst moment moet het dan mogelijk zijn om een order te plaatsen om te voorkomen dat klanten afhaken. Hoe dichter een applicatie bij het uiteindelijke klantcontact wordt gebruikt, hoe belangrijker Beschikbaarheid is. Ook als de noodzaak voor snelheid van handelen hoog is, bijvoorbeeld bij een 112-centrale, dan moet een applicatie beschikbaar te zijn.

Naarmate het informatiesysteem een belangrijkere rol speelt in het primaire bedrijfsproces, zullen strengere eisen aan de Betrouwbaarheid worden gesteld. De noodzaak voor het stellen van eisen heeft te maken met de kans op optreden van uitval, maar vooral ook met de mogelijke gevolgen daarvan.
Een voorbeeld is de software in een hart-bewakingssysteem; aangezien hier mensenlevens in het geding zijn, moet een dergelijk systeem extreem Betrouwbaar zijn.


Sommige systemen moeten 24 uur per dag beschikbaar zijn en dat gedurende 7 dagen per week. Dit is bijvoorbeeld het geval met plaatsreserveringssystemen voor vliegtuigen. Voor andere systemen is het voldoende als ergens in de loop van de week een keer een uur van het systeem gebruik gemaakt kan worden. Wel geldt in het algemeen, dat een gebruiker het als zeer vervelend ervaart als een systeem niet beschikbaar is wanneer hij er op rekent.
Beschikbaarheid binnen productkwaliteit heeft een sterke connectie met de kwaliteit tijdens gebruik (Quality in use). Ik kom hier later op terug.


Definities attributen


Volwassenheid (Maturity)

  • De mate waarin een systeem, product of component aan betrouwbaarheidsbehoeften voldoet onder normale werkomstandigheden.

Beschikbaarheid (Availability)

  • De mate waarin een systeem, product of component operationeel en toegankelijk is wanneer men het wil gebruiken.

Foutbestendigheid (Fault tolerance)

  • De mate waarin een systeem, product of component werkt zoals bedoeld ondanks de aanwezigheid van hard- of softwarefouten.

Herstelbaarheid (Recoverability)

  • De mate waarin het product of systeem, in geval van een onderbreking of bij een fout, de direct betrokken gegevens kan herstellen en het systeem in de gewenste staat kan terug brengen.

Informatiesystemen vallen soms uit. Zeker voor systemen, die over grotere afstand moeten communiceren, is dat niet altijd te vermijden: Er kan onverwacht een communicatieprobleem optreden. Wanneer er eisen worden gesteld aan de beheersing van de gevolgen van een dergelijke storing, worden deze in het kader van Herstelbaarheid expliciet gemaakt. Hoe lang mag de uitval maximaal duren ? Is ingrijpen van een operator mogelijk of moet het systeem zichzelf herstellen ? Hoeveel transacties mogen er maximaal verloren gaan ? Er wordt zelfs zelfherstellende software ontwikkeld. In welke mate dit enkel hardware problemen opvangt of zelfs fouten in de software, de tijd zal het ons leren.


  • 1
  • 2