Pragmatischer en flexibeler testen, mét zekerheid
Situationeel testen ‘It’s all in the mix’
White paper
Colofon Titel
Pragmatischer en flexibeler testen, mét zekerheid!
Versie
1.0 oktober 2013
Uitgebracht door
SYSQA B.V. Kabelstraat 5 1322 AD Almere +31 (0)36 524 11 99
[email protected] www.sysqa.nl
© Copyright 2013 SYSQA B.V. Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elekronisch, mechanisch, door fotokopieën, opnamen, of enige andere manier, zonder voorafgaande toestemming van SYSQA B.V.
2 van 15
White paper
Inhoudsopgave
Over dit white paper
4
Voorwoord
5
1 Flexibeler en pragmatischer testen
6
1.1 Situationeel testen, de essentie
6
1.2 Waarom testen we: value-based testing
6
1.3 Hoe testen we: scripted en non-scripted testing
8
1.4 Situationeel testen: it’s all in the mix
10
2 Flexibeler en pragmatischer testen met situationeel testen
12
2.1 Effecten van het toepassen van situationeel testen
12
2.2 Consequenties van het toepassen van situationeel testen
12
3 Conclusie
14
15
Over SYSQA B.V.
3 van 15
White paper
Over dit white paper Dit white paper geeft een korte en bondige introductie op situationeel testen. Bij de lezer wordt enige ICT-kennis en kennis van zowel systeemontwikkeling als testen verondersteld. De in dit white paper beschreven aanpak geeft de visie van SYSQA op testen weer. Deze visie is uit een aantal bronnen voortgekomen: de dagelijkse praktijk bij onze opdrachtgevers, onze eigen ideeën over testen en allerlei boeken, blogs, presentaties, cursussen, workshops et cetera. Dit white paper is een exclusieve uitgave van SYSQA. Wij hebben ons echter ook laten inspireren door het werk van anderen. Directe links naar hen en dit werk staan in de tekst vermeld, maar naar veel van wat ons heeft geïnspireerd bestaan geen directe links. Toch willen we ook de auteurs van dát werk bedanken . In alfabetische volgorde (achternaam) zijn dit: Gojko Adzic, Henrik Andersson, James Bach, Jon Bach, Sigurdur Birgisson, Michael Bolton, Lisa Crispin, Janet Gregory, Elisabeth Hendrickson, Cem Kaner, Michael Kelly, Lynn McKee, Gitte Ottosen, Huib Schoots en James Whittaker. Verder hebben de volgende medewerkers van SYSQA aan dit white paper meegewerkt (alfabetische volgorde achternaam): Jan Jaap Cannegieter, Bart Fessl, Sven van Galen, Mariëlla van Houte, Teun Klos, Robin Wijngaarden en Roger Wouterse.
4 van 15
White paper
Voorwoord Over SEXY en niet-SEXY Het is niet-SEXY te schrijven dat de waarheid in het midden ligt of dat het compromissen zijn die we moeten sluiten. Veel stoerder is het te schrijven over een revolutie of een wereld veranderende blik en visie over testen. Pas echt SEXY wordt het wanneer compromissen revolutionair blijken te zijn. Situationeel testen is zo’n revolutionair compromis. Per definitie is de best passende testaanpak voor ieder testtraject noch puur scripted testen, noch puur non-scripted testen. ‘It’s all in the mix’. Dit white paper is een handreiking om afhankelijk van de situatie tot goede mixen te komen en daagt u uit zelf goede mixen te maken. Mixen waardoor maximaal onderbouwd inzicht in de kwaliteit van een systeem wordt verkregen, tegen de laagst mogelijke kosten. Of is dat niet-SEXY genoeg? Jan Gieles Directeur SYSQA B.V.
5 van 15
White paper
1
Flexibeler en pragmatischer testen Het testen heeft bij de meeste organisaties een vaste plek gekregen in de ontwikkeling en implementatie van software of systemen. Vaak wordt het testen wel door verschillende stakeholders ervaren als inflexibel en niet-pragmatisch. Dit wordt veroorzaakt door twee aspecten. Het eerste is dat veel organisaties onvoldoende nadenken over de toegevoegde waarde die testen moet hebben. Het tweede is dat veel organisaties altijd dezelfde testaanpak hanteren, ongeacht de kenmerken van het systeem, het project en de organisatie. Dat moet niet alleen anders, het kan ook anders. Het antwoord op de titel van dit white paper ‘Hoe u flexibeler en pragmatischer uw systemen test’ is situationeel testen. In dit hoofdstuk lichten we dit toe.
1.1 Situationeel testen, de essentie Ieder systeem is anders, ieder project wordt op een andere manier aangepakt en iedere organisatie heeft andere verwachtingen van een nieuw systeem of release. Mede daardoor is ieder testtraject anders. Het kent haar eigen specifieke doelstellingen en daarom is er niet één testaanpak die in elke situatie de beste keuze is. Afhankelijk van de situatie moet worden bekeken welke aanpak de beste keuze is. Dit is situationeel testen. Het uitgangspunt van situationeel testen is dat de kenmerken van het systeem, het project en de verwachtingen van de organisatie de testaanpak bepalen. Het gaat erom dat die combinatie van testdoelen, -vormen en –technieken wordt gekozen die tegen de laagst mogelijke kosten en binnen de kortst mogelijke tijd een goed onderbouwd inzicht geeft in de kwaliteit van een systeem. Situationeel testen geeft houvast bij het inrichten en uitvoeren van een testproject en introduceert daarbij kaders die goed toepasbaar zijn. U dient zich echter wel te beseffen dat uitzonderingen mogelijk zijn. De situatie bepaalt de doelstelling en de aanpak! Het uitgangspunt van situationeel testen is om bij het testen maximale waarde te realiseren met zo min mogelijk verspillingen. Zo wordt bij situationeel testen geen overbodige documentatie ontwikkeld en worden geen onnodige activiteiten uitgevoerd. Dit betekent niet dat er géén documentatie wordt ontwikkeld, maar alleen documentatie die nodig is. Situationeel testen draait om twee vragen: waarom testen we en hoe testen we? Hieronder wordt op deze vragen ingegaan.
1.2 Waarom testen we: value-based testing Testen kost tijd en geld! Maar let op, niét testen kost vaak nog meer tijd en geld. Ondanks dat dit helemaal waar is, moet er toch goed worden omgegaan met de spaarzame middelen (tijd en geld) voor testen. Om dat te bereiken, moet eerst worden vastgesteld welke informatiebehoefte er is. Wat moet er eigenlijk worden aangetoond met het testen? Bij situationeel testen gaan we uit van value-based testing. Hierbij wordt met behulp van testen aangetoond wat de waarde van het systeem is voor de opdrachtgever en de gebruikersorganisatie.
6 van 15
White paper
Value-based testing kan nogal abstract overkomen. Door het hanteren van een indeling wordt het echter praktisch en toepasbaar in projecten. De indeling kan per situatie verschillen. Een in de praktijk bewezen manier om value-based testing concreet te maken is door vijf niveaus te onderkennen, waarbij ieder niveau waarde voor de business toevoegt1, zie figuur 1.
Niveau 1 Functionaliteit
Niveau 2 Performance en security
Niveau 3 Gebruikersvriendelijkheid
Niveau 4 Bruikbaar
Niveau 5 Succesvol
Waarde
Figuur 1. De vijf niveaus van value-based testing.
Niveau 1 Functionaliteit Op niveau 1 wordt vastgesteld of de functionaliteit aansluit bij de requirements en of de functionaliteit foutloos werkt. Dit niveau wordt ook wel specificatie gebaseerd testen genoemd omdat het in hoge mate gebaseerd is op vooraf opgestelde specificaties.
Niveau 2 Performance en security Niveau 2 heeft betrekking op de bedrijfszekerheid van het systeem; is het systeem snel genoeg en is het systeem voldoende beveiligd? Het is alleen zinvol deze vragen te beantwoorden wanneer het systeem functioneel gezien doet wat het moet doen. Performance en security bepalen echter wel in hoge mate de waarde van het systeem.
Niveau 3 Gebruikersvriendelijk Niveau 3 richt zich op de mate waarin het systeem eenvoudig begrepen, geleerd en gebruikt kan worden en aantrekkelijk is voor de gebruiker. Dit niveau is niet voor ieder systeem relevant (denk bijvoorbeeld aan technische systemen zonder gebruikersinterface). Voor systemen die door grote groepen, soms onervaren, gebruikers worden gebruikt, is dit niveau vaak doorslaggevend voor de waarde van het systeem.
Niveau 4 Bruikbaar Op niveau 4 wordt de bruikbaarheid van het systeem in de organisatie beoordeeld. Kunnen mede werkers hun taken efficiënt en effectief uitvoeren met het systeem? Past het systeem in de processen van de organisatie?
Niveau 5 Succesvol Het hoogste niveau van value-based testing betreft de vraag of het systeem toegevoegde waarde heeft voor de business. Daarnaast wordt er vastgesteld of de doelstellingen van de organisatie met betrekking tot dit systeem zijn behaald. Op niveau 5 wordt op basis van de businesscase bekeken of het systeem de bedoelde functie vervult en het geplande doel haalt. Er wordt veel breder naar het systeem en het project gekeken. Bovendien worden niet alleen de bekende risico’s onderzocht, maar er wordt ook actief gezocht naar andere risico’s die de waarde van het systeem kunnen bedreigen. Het is aan de opdrachtgever om te bepalen welke van de bovenstaande niveaus van value-based testing voor een specifiek project van belang zijn. Hiervoor gaat de opdrachtgever in overleg met de testmanager, zodat de doelstelling van het testtraject helder is. Het is belangrijk op te merken dat niet 1
Gebaseerd op de keynote presentatie ’Reinventing software quality’ door Gojko Adzic, Agile Testing Days 2013.
7 van 15
White paper
alle niveaus voor alle systemen en organisaties relevant zijn, maar dat de gedachte achter value-based testing wel altijd toepasbaar is. Daarnaast moet bedacht worden dat het uitgangspunt van situationeel testen, dat de situatie de aanpak bepaalt en niet andersom, hierbij overeind blijft. Bovenstaande indeling moet derhalve pragmatisch worden toegepast en afhankelijk van de situatie kunnen andere accenten worden gelegd en niveaus worden weggelaten of toegevoegd. Alternatief voor bovenstaande indeling is het uitvoeren van een analyse op basis van ISO-norm 25010.
1.3 Hoe testen we: scripted en non-scripted testing Nu we weten wat we moeten testen, komen we bij de vraag hoe we het testen moeten aanpakken. In grote lijnen is er een onderscheid te maken tussen scripted testing en non-scripted testing. Het uitgangspunt van scripted testing is dat tests worden uitgevoerd aan de hand van testscripts die met behulp van testtechnieken voorafgaand aan de testuitvoering zijn opgesteld. Scripted testing is gebaseerd op een chronologische aanpak waarbij de fasen planning, voorbereiding, uitvoering en afronding worden doorlopen. Het is sterk gericht op de voorbereiding; hier wordt een aanzienlijk deel van de tijd aan besteed. Er wordt in hoge mate planmatig en methodisch gewerkt. Mede door de focus op de voorbereiding is de doorlooptijd van het totale testen langer. Scripted testing kan worden toegepast als aan een aantal randvoorwaarden wordt voldaan: - De specificaties moeten vroegtijdig af zijn. - De specificaties moeten juist en volledig zijn. - De requirements moeten stabiel zijn. - De testers moeten vroeg in het ontwikkeltraject starten. Non-scripted testing vraagt meer van de kennis en vaardigheden van de tester, de focus ligt op de testuitvoering. Het is gebaseerd op exploratory testen, een testaanpak die uitgaat van de persoonlijke kracht en verantwoordelijkheid van de tester. Bij deze testaanpak is de tester gelijktijdig bezig met het leren over het testobject, het ontwerpen van testgevallen, het uitvoeren van tests en het evalueren van testresultaten. Bij non-scripted testing maakt de tester van tevoren geen uitgebreide scripts, maar past hij de prioriteiten aan op basis van de uitkomsten van eerdere tests. Non-scripted testing is alleen goed toe te passen als aan de volgende randvoorwaarden wordt voldaan: - Er zijn korte lijnen in de organisatie. - De organisatie en het project zijn flexibel. - De organisatie is besluitvaardig. - De tests worden door professionele testers uitgevoerd. Bovenstaande beschrijvingen van scripted testing en non-scripted testing zijn in feite twee uitersten. In de praktijk zijn er verschillende tussenvormen die ieder een andere verhouding tussen scripted en non-scripted kennen. Voorbeelden van deze testvormen zijn factory-based testing, globale scripts, session-based testing, bug-hunts, testtours en freestyle exploratory testing. Deze vormen en hun verhouding ten opzichte van scripted testing en non-scripted testing zijn in figuur 2 opgenomen. Factory based testing
Global scripting
Session based testing
Bug hunts
Test tours
Freestyle exploratory testing
Non-scripted testing Scripted testing Figuur 2. Testvormen ten opzichte van scripted testing en non-scripted testing2. 2
Gebaseerd op de presentatie ‘Telling your exploratory story’ door Jon Bach, Agile 2010 conference.
8 van 15
White paper
Factory-based testing is een testvorm waarbij veel tijd wordt besteed aan het voorbereiden van testen. Tijdens de voorbereiding worden met behulp van testtechnieken testcases opgesteld, op basis van systeemdocumentatie. De testuitvoering bestaat uit het uitvoeren van de testcases. Wanneer de scripts zijn uitgevoerd en er geen bevindingen open staan, wordt het testen afgesloten. Bij global scripting maken de testers veel minder gedetailleerde scripts dan bij factory-based testing. Uitgangspunt is ook hier dat de testers de scripts vóór de testuitvoering maken. De scripts kunnen worden gezien als een checklist die een tester gebruikt tijdens de testuitvoering. Session-based testing3 heeft ook elementen van scripted en non-scripted testing in zich. Deze vorm van testen wordt in sessies van 60 tot 120 minuten gedaan. Iedere testsessie heeft een missie en de tests wordt uitgevoerd aan de hand van een testcharter met daarin testpunten. Een testpunt is een aspect van het systeem dat binnen de missie van de sessie valt en getest moet worden tijdens de sessie. Bij bug-hunts worden allerlei belanghebbenden (bijvoorbeeld gebruikers, projectleiding en programmeurs) op een positieve, energieke manier betrokken bij het testproject. De deelnemers gaat bij een bug-huntsessie in duo’s, aan de hand van een testcharter op zoek naar fouten. De testcharter bevat wederom een testmissie, scope en testpunten. Testtours4 is een vorm van testen waarbij een professionele tester of een duo op zoek gaat naar specifieke fouten. Het type tour dat wordt uitgevoerd bepaalt het type fouten dat wordt gezocht. Voorbeelden van testtours zijn de feature-tour, de claims-tour, de gegevenstour, de a-sociaal-tour, de vorige-versie-tour en de slechte-delen-tour. De meest pure vorm van non-scripted testing is freestyle exploratory testing. Exploratory testing5 is een testaanpak die uitgaat van de persoonlijke kracht en verantwoordelijkheid van de tester. De tester verbetert continu zijn toegevoegde waarde door het leren kennen van het systeem, het maken van het testontwerp, de testuitvoering en het evalueren van de resultaten parallel uit te voeren.
Gebaseerd op het artikel ‘Session-Based Test Management’ van Jonathan Bach, gepubliceerd in Software Testing and Quality Engineering magazine, November 2000 en de tutorial ‘Session-Based Test Management’ van Michael Kelly, Eurostar 2012. 4 Gebaseerd op het boek ‘Exploratory software testing’ van James Whittaker, Addison Wesley, 2010. 5 Gebaseerd op het boek ‘Explore It!’ van Elisabeth Hendrickson, Pragmatic Bookshelf, 2013. 3
9 van 15
White paper
1.4 Situationeel testen: it’s all in the mix Situationeel testen is een niveau van value-based testing aan de ene kant en een keuze van vormen van scripted testing en non-scripted testing aan de andere kant. Ieder testtraject kent zijn eigen mix. Om dit toe te lichten zijn hieronder drie voorbeelden van testprojecten opgenomen. Bij voorbeeld 1 wordt value-based testing niveau 1 t/m 3 toegepast. Er wordt vastgesteld of de functionaliteit goed is, of de performance en security op orde zijn en of het systeem gebruikersvriendelijk is. Dit wordt gedaan met globale scripts, session-based testing en bug-hunts. In tabelvorm ziet dat er als volgt uit:
Niveau valuebased testing
Factorybased testing
Global scripting
Sessionbased testing
Bug-hunts
Testtours
Freestyle exploratory testing
Niveau 5 Niveau 4 Niveau 3 Niveau 2
Project 1
Niveau 1
Voorbeeld 2 heeft een veel beperktere scope. Hier wordt alleen vastgesteld of de functionaliteit goed is, value-based testing niveau 1. Hierbij worden alleen factory-based testing en global scripting toegepast. Testtraject 2 is een voorbeeld van specificatie gebaseerd testen.
Niveau valuebased testing
Factorybased testing
Global scripting
Sessionbased testing
Bug-hunts
Testtours
Freestyle exploratory testing
Niveau 5 Niveau 4 Niveau 3 Niveau 2 Niveau 1
Project 2
10 van 15
White paper
Bij voorbeeld 3 is er sprake van twee testteams, bijvoorbeeld een systeemtestteam en een acceptatietestteam. In dit voorbeeld is het systeemtestteam (STT) verantwoordelijk voor value-based testing niveau 1 en 2. Het systeemtestteam past hiervoor session-based testing toe. Dit is in onderstaande tabel in lichtgrijs gevisualiseerd. Het acceptatietestteam (ATT) is verantwoordelijk voor niveau 3, 4 en 5 van value-based testing en gebruikt hiervoor een combinatie van bug-hunts en freestyle exploratory testing. Zie het donkergrijs in de volgende tabel.
Niveau valuebased testing
Factorybased testing
Global scripting
Sessionbased testing
Bug-hunts
Testtours
Freestyle exploratory testing
Niveau 5 Project 3 ATT
Niveau 4
Project 3 ATT
Niveau 3 Niveau 2 Niveau 1
Project 3 STT
Het laatste voorbeeld laat ook op eenvoudige wijze de taakverdeling tussen een systeemtestteam en een acceptatietestteam zien. Bovenstaande projecten zijn slechts voorbeelden. Voor uw eigen project dient allereerst te worden bepaald wat de doelstelling van het testtraject is, eventueel concreet gemaakt in het gewenste niveau van value-based testing. Vervolgens moet worden bepaald met welke testvormen u dat gaat doen.
11 van 15
White paper
2
Flexibeler en pragmatischer testen met situationeel testen 2.1 Effecten van het toepassen van situationeel testen Flexibiliteit
In de praktijk zien we dat bij veel testtrajecten het vaststellen of de functionaliteit conform de eisen is, het enige doel van het testen is. Er wordt dan niet vastgesteld of: - Het systeem aan eisen op het gebied van performance en security voldoet. - Het systeem gebruikersvriendelijk is. - Het systeem bruikbaar is. - Met het systeem de doelstellingen van het project wordt gehaald. Bij situationeel testen wordt dit wel vastgesteld, waardoor de verwachtingen van de organisatie met betrekking tot het testtraject helder zijn. Het toepassen van value-based testing maakt testtrajecten flexibeler omdat het value-based testing verschillende doelstellingen ondersteund.
Pragmatisch
Bij veel organisaties wordt ieder testtraject op dezelfde manier aangepakt. Het kan zijn dat die ene testaanpak voor een specifiek project perfect is, het kan echter ook zo zijn dat een andere testaanpak minder inspanning vraagt of tot betere resultaten leidt. Testen is een middel, geen doel op zich. En gegeven de situatie moet je wellicht een ander middel, lees: een andere testvorm, wordt ingezet. Om het doel te bereiken zijn alle mogelijke vormen van situationeel testen en combinaties daarvan een optie. Past een bepaald onderdeel niet, of lijkt een bepaalde testvorm niet handig? Kies dan een andere! Het afhankelijk van het systeem, project en organisatie toepassen van verschillende testvormen maakt het testen pragmatischer. Situationeel testen moedigt u aan om flexibel, gestructureerd en pragmatisch om te gaan met testen. Alles mag, als het maar bijdraagt aan het doel. Situationeel testen levert altijd betere resultaten dan het toepassen van één specifieke aanpak. Meestal levert het toepassen van een combinatie van vormen het beste resultaat op: it’s all in the mix.
2.2 Consequenties van het toepassen van situationeel testen Het toepassen van situationeel testen gaat niet vanzelf. Het heeft effect op de gebruikersorganisatie en de testorganisatie. De gebruikersorganisatie moet er rekening mee houden dat zij duidelijk aan moet geven wat het doel van een testtraject is. Om niet in algemeenheden te vervallen, kan de indeling van het value-based testen worden gebruikt. Gevolg hiervan is dat de gebruikersorganisatie van tevoren beter nadenkt over de vraag wat precies van het testtraject wordt verwacht. In de praktijk zien we nogal eens dat het nadenken over deze vraag nieuw is voor een gebruikersorganisatie. Een mogelijke andere consequentie voor de gebruikersorganisatie is dat ze intensief wordt betrokken bij de uitvoering van het testtraject. Een voorbeeld is de toepassing van bug-hunts. Bij bug-hunts worden vaak gebruikers ingezet als tester. De gebruikers moeten hier wel tijd voor hebben zich op voorbereiden en begeleid worden.
12 van 15
White paper
Een consequentie van het toepassen van situationeel testen voor een testorganisatie kan zijn dat ze andere testdoelen kan krijgen. Ineens moeten security- en performancetesten worden uitgevoerd en moet de gebruikersvriendelijkheid en bruikbaarheid worden beoordeeld. Als een testorganisatie moet aantonen of een systeem succesvol is, volstaat testen niet altijd en moeten Quality Assurance activiteiten worden uitgevoerd. Dat is een grote verandering van taken voor een testafdeling. Daarnaast moet een testafdeling meerdere testvormen beheersen. Dat betekent dat de testers zich andere testvormen moeten eigen maken en hier ervaring in moeten opdoen.
13 van 15
White paper
3 Conclusie
Iedere organisatie, ieder systeem en ieder project is anders. Daarom moet ieder testtraject anders worden aangevlogen. Situationeel testen biedt u handvatten voor het stellen van verschillende doelen en verschillende vormen van testen, waarmee u op flexibele wijze, tegen de laagst mogelijke kosten en in een zo kort mogelijke doorlooptijd testtrajecten uitvoert. Situationeel testen moedigt u aan om flexibel, gestructureerd en pragmatisch om te gaan met testen. Het toepassen van situationeel testen gaat niet vanzelf, maar maakt u deze keuze, dan levert u dat altijd betere resultaten op dan het toepassen van één specifieke aanpak.
14 van 15
White paper
Over SYSQA B.V. SYSQA B.V. is een onafhankelijke organisatie, gespecialiseerd in het toepassen van kwaliteits management in ICT. De naam SYSQA (spreek uit ‘siska’) is afgeleid van ‘kwaliteitsSYStemen’ en ‘Quality Assurance’. SYSQA maakt, zelfstandig of samen met de opdrachtgever, kwaliteitszorg in de informatievoorziening toepasbaar op een pragmatische en effectieve wijze. SYSQA bewijst dat, door het op zorgvuldige wijze toepassen van kwaliteitszorg, ICT-projecten succesvol kunnen zijn. Kwaliteit van producten en processen wordt in de ICT steeds belangrijker. Enerzijds omdat opdrachtgevers en gebruikers van systemen onvoldoende kwaliteit niet accepteren en anderzijds omdat het toepassen van kwaliteitszorg tijd en geld bespaart. SYSQA is onafhankelijk en objectief omdat zij geen programmatuur ontwikkelt, geen hardware, pakketten en netwerken levert en omdat zij ook geen onderdeel is van een softwarehuis. Juist bij kwaliteitszorg is dat belangrijk; vaak moet namelijk een oordeel over een product of dienst van iemand anders worden gegeven. Het enige belang van SYSQA is úw belang en het verhogen van de kwaliteit van de informatievoorziening. SYSQA levert ‘full-service’ in kwaliteitszorg in ICT. Zij voert niet alleen uit, maar draagt ook zorg voor inrichting en verbetering. Deze combinatie versterkt elkaar. Bij uitvoeren van kwaliteitszorg moet u denken aan het testen van informatiesystemen, het uitvoeren van informatie-analyses, reviews, inspecties en audits. Dagelijkse werkzaamheden waarmee de kwaliteit geborgd wordt. SYSQA zet gespecialiseerde medewerkers in, die direct in uw project of uw organisatie meewerken. Bij het inrichten en verbeteren moet u denken aan het doorvoeren van procesverbeteringen en het adviseren over de te maken keuzes. Hierbij maakt SYSQA veelvuldig gebruik van bekende standaarden zoals CMMI, PROQA, BISL, ASL, ITIL en ISO. Onze brede ervaring staat garant voor ruime kennis van en ervaring met de diverse methoden en technieken op het gebied van systeemontwikkeling en -beheer. Wij beheersen het ICT-vak en helpen uw organisatie op een hoger niveau te komen.
SYSQA levert diensten op het gebied van:
- Requirements - Quality Assurance - Testen van ICT - Functioneel Beheer - Regievoering en Opdrachtgeverschap - Procesverbetering - Opleidingen
15 van 15
White paper
