2. About myself
• Joris Meerts
• Software tester since 2007
• Capgemini, Testing public, since March 2012
• Context-driven school of testing
• www.testingreferences.com
• Member of the Dutch Exploratory Workshop
on Testing (DEWT)
3. Test all things, hold fast that which is good.
Thessalonians 5:21 (AD 52)
4.
5.
6. Topics
• Some Famous Books
• My Favourite Techniques
• Tracing Some Root Concepts
• So What’s New?
7. The growth of a testing discipline
The growth of a testing discipline has been painfully slow,
despite the acknowledged need for better quality software.
Even the scope of what is or is not a testing activity is not
well defined.
Terminology in the field is unclear and literature that
would establish some foundations has not been written.
Testing as an activity needs and requires more attention.
8. Some Famous Books
Program Test Methods (1973)
• ‘Program’ testing, not
‘software’ testing
• Acceptance testing
• Test levels
• Design for testability
• Test specification
languages
• Test automation
9. Some Famous Books
The Mythical Man-Month (1975)
• Adding people to a late
project only makes it
later (unpartitionable
task).
• Plan to throw one away;
you will, anyhow.
• Let testers scrutinize
specifications long
before coding starts.
10. Some Famous Books
The Art of Software Testing (1979)
• Black box software
testing
• Higher order testing
(reliability,
configuration,
installability, usability
testing)
11. “Testing is an
extremely
creative and
intellectually
challenging
task.”
Some Famous Books
The Art of Software Testing (1979)
“Good software
testing is a
challenging
intellectual
process.”
Cem Kaner, James Bach, Bret
Pettichord – Lessons Learned in
Software Testing (2001)
12. Some Famous Books
Software Engineering Economics (1981)
• Famous cost-of-change
curve.
• The curve is an
important reason for
waterfall development.
13.
14. My Favourite Techniques
Decision Table (1961)
• Burton Grad - Tabular Form in Decision Logic (1961)
• Decision rules for complex applications
• Eliminate inconsistencies and redundancies
16. My Favourite Techniques
Equivalence partitioning (1975)
• John B. Goodenough,
Susan L. Gerhart –
Toward a Theory of Test
Data Selection
• We prove a
fundamental theorem
showing that properly
structured tests are
capable of
demonstrating the
absence of errors in a
program.
17. My Favourite Techniques
State Transition Testing (1978)
• Tsun S. Chow - Testing
Software Design
Modeled by Finite-State
Machines
19. My Favourite Techniques
Exploratory Testing (1988)
• Cem Kaner – Testing Computer Software
• Exploratory testing is not a testing technique. It's a way of
thinking about testing.
21. My Favourite Techniques
Pairwise Testing (1996)
• David M. Cohen, Siddhartha R.
Dalal, Jesse Parelius, Gardner C.
Patton - The Combinatorial
Design Approach to Automatic
Test Generation
• An empirical study of user
interface software at Telcordia
found that most field faults were
caused by either incorrect single
values or by an interaction of
pairs of values.
22. My Favourite Techniques
Soap Opera Testing (2004)
• Hans Buwalda – Soap
Opera Testing
• Tests should be fun and
aggressive
23. Tracing Some Root Concepts
Taylorism (1912)
• Frederick Winslow
Taylor – Principles
of Scientific
Management
• Measurement,
standards,
mechanization
24. Tracing Some Root Concepts
Waterfall (1970)
Winston Royce - Managing the Development of Large Software
Systems
25. “I believe in this
concept, but the
implementation
described above is
risky and invites
failure.”
Tracing Some Root Concepts
Waterfall (1970)
26. Tracing Some Root Concepts
V-model (1986)
Paul E. Rook - Controlling Software Projects
27. Tracing Some Root Concepts
Standards (1)
• IEEE 829 Standard for Software and System Test
Documentation (1983)
• IEEE 1012 Standard for Software Verification and
Validation Plans (1986)
• Capability Maturity Model (1988)
• ISO 9126 Software engineering - Product quality
(1991)
• TMap (1995)
• Testing Maturity Model (1996)
28. Tracing Some Root Concepts
Standards (2)
• BCS Standard for Software Component Testing (1998)
• International Software Testing Qualifications Board
(2002)
• ISO 29119 Software Testing (2012)
29. Tracing Some Root Concepts
Definition of testing
The process consisting of all lifecycle activities,
both static and dynamic, concerned with
planning, preparation and evaluation of
software products and related work products
to determine that they satisfy specified
requirements, to demonstrate that they are fit
for purpose and to detect defects.
ISTQB - Standard glossary of terms used in
Software Testing (2012)
30. So What’s New?
Test is dead
Julian Harty – Traditional Testing R.I.P. (2010)
Goranka Bjedov – The Future of Quality (2011)
James Whittaker – All That Testing is Getting in the
Way of Quality (2011)
Alberto Savoia – Test is Dead (2011)
• Testing slows projects down
• Most testing is futile (incorrect
diagnosis, irrelevant bugs)
• Value of quality < Price of quality
• It’s cheaper to fix the bug than to find it
• Users are better testers!
• Only the code matters
• The value of testing is not in the artifacts
31. So What’s New?
Shifting paradigms
Testing is not a phase
Jack Reeves – What Is Software Design?
(1992)
Les Hatton – Testing is not a phase (1999)
Elisabeth Hendrickson – Agile Testing,Nine
Principles and Six Concrete Practices for
Testing on Agile Teams (2008)
32. So What’s New?
Shifting paradigms
Sapient testing
Cem Kaner, James Bach, Bret Pettichord –
Lessons Learned in Software Testing (2001)
James Bach – Sapient Processes (2007)
33. So What’s New?
Shifting paradigms
Testing skills / competences:
• Communicative
• Precise
• Convincing
• Objective
• Creative
• Sensitive
Tim Koomen, Leo van der Aalst, Bart
Broekman, Michel Vroon - Tmap Next
(2006), page 464 - 465
34. So What’s New?
Shifting paradigms
Testing is the art of skillful
investigation by experimentation
35. So What’s New?
Shifting paradigms
Testing is the infinite process
of comparing the invisible
to the ambiguous
so as to avoid the unthinkable
happening to the anonymous.
James Bach - Becoming a Software Testing
Expert (2006)
36. So What’s New?
Shifting paradigms
“A tester is someone who knows that things
could be different.”
“It's an awkward field. If you wanted solid
ground to stand on, you chose the wrong
vocation."
James Bach – The Gift of Time (2008)
37. So What’s New?
Roles in testing
• Auditor
• Acceptance manager
• Test facilitator
• Cultural host
• Business consultant
• Quality assurance
manager
Editor's Notes
Wie heeft er een boek gelezen over software testen buiten het verplichte curriculum. Hoe kunnen we pretenderen dat we professionals zijn als we niet eens een boek over testen gelezen hebben?Op zich spreekt het lezen van een boek over software testen niet in je voordeel, want er zijn niet heel veel goede boeken over software testen.
Brieven van de apostel Paulus aan de kerk van de Griekse stad Thessaloniki, geschreven omstreeks 52 na Christus.Het Nieuwe Testament zegt dat we alles moeten testen. Hier zijn we inmiddels wel op terug gekomen. Waardoor je ziet dat het vakgebied zich ontwikkelt.
Verhaal over totstandkoming van de tijdlijn.Uitgangspunt was The NineForgettings van Lee Copeland (StartWest 2007). Copeland maakte zich zorgen over het gebrek aan kennis van hoe ons vakgebied zich heeft ontwikkeld. Gemaakt in samenwerking met Dorothy Graham. Wie weet wie Dorothy Graham is?Gebruikt in presentatie van Dorothy Graham voor de SIGIST, 2010. Gebruikt in keynote van ScottBarber, Agile Testing Days 2012.De manieren waarop je naar ontwikkelingen in het vakgebied kunt kijken.
Ik wil het gaan hebben over de geschiedenis. Aan de hand van een overzicht van het vakgebied testen (gehaald uit de geschiedenis) kunnen we echter ook naar de toekomst kijken. Dit gaan we aan het einde van de presentatie dan ook doen.Groen gemarkeerd zijn de gebieden die zich op dit moment het meest ontwikkelen. Bijvoorbeeld: security en performance zijn deelgebieden waarin nieuwe technologie en paradigma’s gevonden worden. Model-based testen is een paradigma dat zich ontwikkelt. En testers nemen nieuwe rollen in, de agile tester is daarvan een goed voorbeeld.De meeste kennis die we hebben is echter oud.
Introductie door William Hetzel. Is er nu echt zo veel veranderd in ons vakgebied?Er zijn nog steeds genoeg mensen die absoluut niet weten wat testen precies is of doet.Er is ruimschoots discussie over de definitie van testen (testingvschecking) of van bijvoorbeeld een testgeval. Het hangt ervan af aan welke expert je het vraagt?En zit er nu echt vooruitgang in het vakgebied? Volgens de aanhangers van Agile moeten programmeurs meer gaan testen en testers meer gaan programmeren. Dan ben je weer terug in de jaren ’70.
Het eerste boek over software testen.Gaat bijvoorbeeld in op acceptatie testen. Genoeg principes die we op dit moment nog hanteren komen naar voren in dit boek.Als testers denken we vaak dat alles wat we doen nieuw is. Zeker Agile mensen hebben daar last van. Wat dit boek aantoont is dat zeker niet alles nieuw is. We zouden vaker de literatuur erop na moeten slaan.
Lessonslearned bij het ontwikkelen van OS/360. De ontwikkeling van OS/360 liep niet zo heel erg lekker.Dit boek is belangrijk omdat het gaat over de praktijk! Een belangrijk wetmatigheid, waar we in de praktijk nog dagelijks tegenaan lopen, is dat het nauwelijks zin heeft om aan het einde van project veel mensen toe te voegen. Dit heeft te maken met de deelbaarheid, de overdraagbaarheid (complexiteit) van taken en de afhankelijkheden tussen taken.Silverbullet ().
Alhoewel in dit boek nog steeds gesproken wordt over ‘program testing’ maakt Myers een belangrijke stap naar black box testen, het testen zonder naar de code te kijken. Dit onderscheid luidt een andere manier van denken over testen in, namelijk dat testen een breder onderzoek is naar het functioneren van de software.Afsplitsing tussen tester en software ontwikkelaar. “A programmingorganisationshouldnot test itsown programs”.
GlenfordMyers loopt vooruit op dingen die we eigenlijk pas in de afgelopen jaren goed zijn gaan beseffen. “Good software testing is a challenging intellectual process.” (Lessons Learned in Software Testing, 2001)
Het ‘Sneeuwwitje en de zeven dwergen’ van software testen.Zo ongeveer elk Nederlands boek over testen verwijst naar dit boek. Boehm voert het (enige) argument om zo vroeg mogelijk te beginnen met testen. Namelijk: des te eerder de fout gevonden wordt, des te minder het kost om de fout op te lossen. Boehmzeft dat we om deze reden op een waterval manier software moeten ontwikkelen. Later (in 1986) schakelt Boehm over op het iteratief ontwikkelen van software.
Uit het artikel van Boehm, 1976. Hierin zijn de eerste drie gegevensverzamelingen zichtbaar (IBM (Fagan), GTE (telefoniebedrijf, Daly, 1977) en TRW (Boehm). Er komen er nog een paar bij in 1981 (Safeguard (Stephenson) en enkele kleinere, minder gestructureerde projecten).Anecdotisch materiaal wordt herhaald en herhaald in ons vakgebied.
In 1961 nog niet als test techniek in gebruik, maar later wel in deze vorm als test techniek aangenomen. Nog steeds actueel voor het testen van bijvoorbeeld bedrijfsregels.
Grafentheorie speelt sinds 1960 een rol in software ontwikkeling (R. M. Karp, "A note on the application of graph theory to digital computer programming,“). Elmendorf’s graaf is wat complexer dan de testgraaf die ik geleerd heb.Grafentheorie is onderdeel van systeemtheorie.
Aanzet tot het ontwerpen van programma’s op een gestructureerde manier (Structured design).Poging om software te maken waar minder fouten in zitten.
Dit artikel is essentieel in software testen om het gezien kan worden als het startpunt van de academische discussie over software testen. Nog steeds is software testen, het formeel bewijzen dat een programma correct is, onderwerp van universitair onderzoek.Rond dit artikel doet een aantal testtechnieken z’n introductie, zoals de analyse van paden en het gebruik van equivalentieklassen.In de onderbouwing nemen Goodenough & Gerhart mee dat er getest moet worden vanuit de specificaties om de volledigheid, validiteit en juistheid van een programma aan te tonen.De vraag is waarom het testen in de praktijk zo weinig in verband staat met de academische discussie.Een antwoord op die vraag is dat de praktijk zelden lijkt op de laboratorium experimenten die onderzoekers uitvoeren. De randvoorwaarden voor een academisch experiment en de randvoorwaarden voor een daadwerkelijk software project verschillen op nogal veel punten.
Finite state machines bestonden al een tijdje. Chow bedenkt hoe je ze kunt testen en hoe je de dekkingsgraad kunt definiëren. Naar dit artikel, dat de basis vormt voor state transition testing, wordt zelden of nooit verwezen.
Gegevenscyclustest. Geen plaatje, verder weinig toelichting nodig.
Exploratory testen is het enige nieuwe paradigma in software testen. Het gaat uit van ontdekking, onderzoek en leren. Gelijktijdig testen uitvoeren en bedenken.
Deze techniek heb ik in een vorige opdracht gebruikt en is erg, erg leerzaam.
Opdelen in klein controleerbare taken.De eerste lopende band die we in testen tegen komen is de volgende:
De meesten van ons zitten regelmatig in een watervalachtig project. Toch weet niet iedereen de bron van waterval ontwikkelen. Ik sprak met een senior architect die de bron niet kende en die het ook werkelijk weinig boeide. Het is hetzelfde als een professionele wielrenner die niets van zijn fiets weet.Waterval gaat over taken die elkaar opvolgen. Als de eerste taak klaar is begint de tweede taak enz.. Dit is in software ontwikkeling uiterst frustrerend, omdat fasen overlappen of misschien in een totaal andere volgorde op elkaar aansluiten. Het is best wel raar dat het waterval model zo’n succes heeft gekend, zeker getuige de volgende opmerking van Royce (de eerste zin onder dit plaatje).
Het is bijzonder dat de waterval de keuze is geworden van zo veel bedrijven en dat de methode nog steeds wordt gebruikt. Misschien wordt er nog mee gewerkt omdat het lijkt alsof het waterval proces beheersbaar is. Misschien heeft het te maken met de omvang van projecten, zijn grote it-projecten heel lastig op een andere manier te realiseren.Waarschijnlijk ook populair doordat het model eenvoudig is en daardoor makkelijker te begrijpen is door bedrijven die software ontwikkeling erbij doen. Agile is uiteindelijk veel complexer en vraagt een ander type, verder gevorderd ontwikkelaar.
Dit V-model komt waarschijnlijk in de buurt van hetgeen Paul Rook in 1986 presenteerde. Dit plaatje is gedateerd 1985 en komt uit een verzameling van Barry Boehm. Paul Rook , GEC Software Ltd (London).Het model wordt zo’n beetje in ieder boek over software testen genoemd, maar er wordt niet verwezen naar een bron. Ook nauwelijks te vinden via Google. Uiteindelijk werd ik door StuartReid getipt over Rook.Het V model is een Europees model (Brits model) dat in de VS misschien minder vaste voet aan de grond heeft gekregen.
Dit zijn de modellen, standaarden en processen op basis waarvan ons vakgebied zich heeft ontwikkeld, zich kenmerkt.
Parallel aan het feit dat sommige partijen nog steeds wanhopig proberen om het definitieve model van testen te maken, loopt het academische debat. Academici doen nog altijd onderzoek naar de theoretische onderbouwing van testen.ISTQB opgericht in 2002.Een en ander houdt in dat het werk in testen zo ingericht moet zijn dat testers vervangbaar zijn. Dat het mogelijk is om een tester van de straat te plukken en verder te gaan.
Deze definitie leunt op processen (dus formele activiteiten) en formele producten. In principe wordt er niet gesproken over wat testen is; ofwel, welke beginselen ten grondslag liggen aan de genoemde evaluatie!
Het gevolg van het in testen is dat rond 2010 testen dood werd verklaard. We hebben het dan over het traditionele definieren van testen aan de hand van een ‘testproces’. De beginselen die ten grondslag liggen aan het proces testen zijn in ieder geval niet meer valide in de start-ups en in de bedrijven die zich uitsluitend bezig houden met het ontwikkelen van software. Deze bedrijven blijken beter af te zijn zonder waterval, zonder fasering, zonder qualityassurance.Een nieuwe filosofie is noodzakelijk.
Reeves: “Testing and debugging are design activities.”Hatton: “Testing is an attitude of mind which permeates the entire software process.”Hendrickson: “Testing is a way of life.”
A sapient process is any process that relies on skilled humans.
TmapNext wijdt 1 ½ van 745 pagina’s aan de vaardigheden waarover een tester moet beschikken, en behoort dus duidelijk tot het oude domein van testen.
Mijn eigen definitie van testen. Testen gaat niet over proces, activiteiten en producten, testen gaat over het doen van onderzoek. Testers zijn onderzoekers en zouden eigenlijk in hoge mate moeten beschikken over de vaardigheden van een onderzoeker.
Vaardigheden op het gebied van onderzoek zijn meer dan gewenst bij de software tester. Zie hier de definitie van testen waarin alleen maar onderzekerheden en onbekenden zitten. Dit komt een stuk dichter in de buurt van het echte testen dan de procesbeschrijving. Alle punten zijn uitzoekwerk voor de tester.Process betekent volgens Bach niet een blokkendoos van activiteiten maar een model (in dit geval heuristieken) dat gebruikt wordt.
In het TestNet jubileum boek staat veel over de toekomst van testen, onder andere over de verschillende rollen van testers.
Het eerste boek over software testen.Gaat bijvoorbeeld in op acceptatie testen