Testteknikker med inspiration fra hele verden

Transkript

1 Testteknikker med inspiration fra hele verden Præsenteret af Klaus Olsen På konference i København den 9. juni 2016

2 Klaus Olsen q Stifter og ejer af firmaet softwaretest.dk siden 2000 q Har brugt 23 år på softwaretest, test processer, test forbedringer samt undervisning q q q q q q q Forfatter af Softwaretest kom godt i gang Medstifter af DSTB, næstformand i DSTB Medstifter af non-profit organisationen TMMi Foundation Formand for TMMi Management Executives Medlem af ISTQB som repræsentant for Danmark i 12 år Medforfatter til ISTQB Foundation og Advanced pensum Formand for ISTQB Foundation arbejdsgruppen

3 Præsentationer på konferencer omfatter: Ø EuroSTAR 98 in Münich, Germany Ø Second World Congress on Software Quality 2000 in Yokohama, Japan Ø EuroSTAR 2001 in Stockholm, Sweden Ø Quality Week 2001 in San Francisco, USA Ø EuroSTAR 2003 in Amsterdam, Holland Ø ASTA 2007 in Seoul, Korea Ø Test 2008 in New Delhi, India Ø EuroSTAR 2008 in Haag, Holland Ø ANZTB Test2009 conference Sydney, Australia Ø JSTQB カンファレンス 2010, in Tokyo, Japan Ø ASTA 2010 in Seoul, Korea Ø Czechtest 2011 in Prague, Czech Republic Ø TAPOST 2011 in Riga, Latvia Ø TMMi World Conference 2011 in Seoul, Korea Ø Czechtest 2012 in Prag, Czech Republic Ø Nordic Testing Days 2012 in Tallinn, Estonia Ø ANZTB Test2013 conference in Canberra, Australia Ø FiSTB Testing Assembly 2013 in Helsinki, Finland Ø Testing Portugal 2013 in Lisbon, Portugal Ø DSTB 2014 in Copenhagen, Denmark Ø Sixth World Congress on Software Quality 2014 in London, UK Ø Teszt & Tea 2014 in Budapest, Hungary Ø Czechtest 2015 in Prag, Czech Republic Ø SEETEST 2015 Sofia, Bulgaria q Kontakt Klaus via mail klaus@softwaretest.dk

4

5 Nyd udsigten fra toppen af TIVOLI Hotel før du går hjem

6 Test Maturity Model Integration, TMMi Level 5: Optimization Defect Prevention Test Process Optimization Quality Control Level 4: Management & Measurement Test Measurement Software Quality Evaluation Advanced Peer Reviews Level 3: Defined Test Organization Test Training Program Test Life Cycle and Integration Non-Functional Testing Peer Reviews Level 2: Managed Test Policy and Strategy Test Planning Test Monitoring and Control Test Design and Execution Test Environment Level 1: Initial TMMi maturity levels and process areas 16 Process Areas

7 TMMi assessment & testteknikker Ø Når jeg udfører TMMi Assessments så er test teknikker ofte det områder der scorer lavest Ø Ikke nødvendigvis på beskrivelse af teknikker Ø Men på efterlevelsen ude i projekterne

8 Plan for præsentationen 1 Seoul, Korea Yokohama, Japan New Delhi, Indien ISTQB Report Favoritter

9 Using Mind Map for Software Testing Activities Skrevet af Akira Ikeda & Micky Suzuki Præsenteret på konference i Seoul, Korea i 2007 Udgivet som bog på japansk i

10 Behovet for at anvende Mind Map til test Slide fra Akira Ikeda & Micky Suzuki Nye testere kan have svært ved at oprette test cases og andet materiale til test Hjælp!!! Mind Map kan være løsningen til at oprette test cases for nye testere

11 Sammenligning mellem en ny tester og en erfaren testers måde at tænke Slide fra Akira Ikeda & Micky Suzuki Ny tester Erfaren!!! Specifikation Specifikation Kopierer direkte fra specifikationen Tænker og udvikler fra specifikation til test cases Test cases Test cases!! Ny tester Specifikation Tænker og udvikler fra specifikation til test cases Test cases

12 Anvendelse af Mind Map Slide fra Akira Ikeda & Micky Suzuki Ny tester plus Mind Map næsten identisk med erfaren tester! Ny tester + Mind Map ~ = Erfaren tester

13 Slide fra Akira Ikeda & Micky Suzuki Eksempel på Mind Map fra bogen

14 Skabeloner på nettet - første dag som tester i nyt projekt

15 God dansk introduktion

17 Second World Congress on Software Quality 2000 in Yokohama, Japan Ø Dr. Genichi Taguchi talte om Orthogonal Array Testing, han var 76 år på dette tidspunkt, død i 2012.

18 Consider a system which has 3 parameters and each of them has 3 values. To test all the possible combinations of these parameters (i.e. exhaustive testing) we will need a set of 3^3 = 27 test cases. But instead of testing the system for each combination of parameters, we can use an orthogonal array to select only a subset of these combinations. Using orthogonal array testing, we can maximize the test coverage while minimizing the number of test cases to consider. We here assume that the pair that maximizes interaction between the parameters will have more defects and that the technique works.

19

20 Given that assumption, the table shows the set of nine combination of parameters which are sufficient to catch the fault, considering the interaction of the input parameters, which is very effective and economical. The array is orthogonal, because all possible pair-wise combinations between parameters occurs only once. The given L9 Orthogonal Array assess result of test cases as follows:

21 Single Mode Faults - Single mode faults occur only due to one parameter. For example, in above Orthogonal array if test cases 7, 8 and 9 show error, we can expect that value 3 of parameter 1 is causing the error. Likewise we can detect as well as isolate the error. Double Mode Fault - Double mode fault is caused by the two specific parameters values interacting together. Such an interaction is a harmful interaction between interacting parameters. Multimode Faults - If more than two interacting components produce the consistent erroneous output, then it is a multimode fault. Orthogonal array detects the multimode faults.

23 Test 2008 in New Delhi, India Ø Q-Patterns by Vipul Kocher Questioning Pattern (also known as Q-Pattern) is a set of interrelated QUESTIONS grouped together to: Relate to some aspect of user or software requirements Provide various alternatives to arrive at a solution

24 Q-Patterns i Vipuls egne ord: "Q-Patterns are a great tool for communication of domain specific knowledge across people and continuous skill enhancement. It is also a tool for requirement elicitation and defining specifications".

25 Strukturen (skabelonen) for Q-Patterns Name of the Q-Pattern Intent/Explanation/Definition Classification Metadata Template Version Q-Pattern Version Author Author Contact information Keywords Questions on Usage User Interface Administration Performance Security Internationalization Localization Examples Associated Q-Patterns Specialization

26 Eksempel på Q-Patterns

27 Eksempel på Q-Patterns forsat

28 Skabeloner der kan genbruges You can think of Q-Patterns as a structured set of questions (tests) about the different aspects of a software application under test. They are questions about the system that are categorized, grouped, sorted, and saved for reuse. These Q-Pattern questions can be written ahead of time and stored in a repository of test case templates, developed for requirements and design reviews or built in real-time as a way to both guide and document exploratory testing sessions. Vipul Kocher has developed Q-Patterns for error messages, combo boxes, login screens, list handling and more

30 Testteknikker hentet fra

31 From ISTQB Worldwide Software Testing Practices Report in Which test techniques are utilized by your testing team? 80.0% 70.0% 60.0% 50.0% 40.0% 30.0% 20.0% 10.0% 0.0% Responders

32 Plan for præsentationen 1 Seoul, Korea Yokohama, Japan New Delhi, Indien ISTQB Report Mine favoritter i dag

34 Anvendelse af beslutningstabel Når vi tester systemer, hvor forskellige kombinationer af input skal medføre forskellige resultater, er anvendelsen af beslutningstabeller en god idé Når vi har mere fokus på test af forretningslogik og forretningsregler Styrken ved beslutningstabeltest er, at den danner betingelseskombinationer, der måske ikke ellers ville være blevet afviklet under test

35

36 Hvad er beslutningstabeltest god til? At finde defekter i beslutningslogik: Forveksling af AND og OR Betingelser der er udeladt Betingelser der er vendt forkert (NOT) Fejl i sammensætning af betingelser Test drevet udvikling ATDD & BDD Meget præcis specifikation af krav Let for udviklerne at anvende Minimerer fejl og misforståelser Godt at teste ud fra, reducerer ofte antal test cases

37 Tilstandsovergangstest Testere kan betragte software som: q tilstande, q overgange mellem tilstande, q input eller hændelser der udløser tilstandsændringer q handlinger der kan være resultatet af disse overgange Tests kan designes til at dække: q en typisk rækkefølge af tilstande, q til at dække hver eneste tilstand q til at aktivere alle overgange q til at aktivere specifikke rækkefølger af overgange q eller til at teste ugyldige overgange

38 Tilstandsovergangstest symboler Testere kan betragte software som: q tilstande, q overgange mellem tilstande, q input eller hændelser der udløser tilstandsændringer q handlinger der kan være resultatet af disse overgange Tilstand = Overgang = Hændelse = navn på hændelse Handling = kommando Xxx / yyy

39 Tilstandsovergangstest eksempel Planlæg testen som historier for objekter i systemet: q en vares liv, fra jord til bord i et supermarked q landmand, lager, distribution, på hylden, igennem kassen, ind i koncernregnskabet q et kundeforholds liv, mobiltelefon kunde q køb ny mobil med abonnement, ændre abonnement efter 6 mdr., ændre efter 12 mdr. forlad selskab og køb ny i andet selskab efter 18 mdr.

40 Tilstandsdiagrammer eksempel Tilstand Hændelse Handling (aktion) Off evpoweron / InitPhone On Hændelse Overgang til samme tilstand Overgang Overgang Phone book evcbutton / beep evmenuphonebook / StartPhonebook Handling (aktion)

41 Erfaring: det fungerer super godt. Anvendes i test drevet udvikling, tilgængelig for forretningsanalytiker / forretningstester. Input til SBE Specification By Example. Minimerer fejl og misforståelser. Flere aha oplevelser i projekt gruppen ved gennemgang af disse flows.

42 Plan for præsentationen 1 Seoul, Korea Yokohama, Japan New Delhi, Indien ISTQB Report Dine favoritter?

43

44 Hvilke teknikker anvender du? Diskuter 6 minutter med din sidemand

45 Testteknikker 6 minutter Ø Har du krav / anbefalinger til hvilke testteknikker du skal anvende i de projekter du deltager i? Ø Hvilke testteknikker anvender du mest? (Hvilke testteknikker er mest anvendte i dit firma?) Ø Hvilke testteknikker finder du flest fejl med? (Hvilke testteknikker finder flest fejl i dit firma?)

47 Testteknikker - Plenum Ø Hvem har krav / anbefalinger til hvilke testteknikker i skal anvendes i de projekter i deltager i? Ø Ræk hånden op hvis du har i dit firma Ø Hvilke testteknikker anvender i mest? (Hvilke testteknikker er mest anvendt i dit firma?) Ø Ræk hånden op ved gennemgang af testteknikker Ø Hvilke testteknikker finder du flest fejl med? (Hvilke testteknikker finder flest fejl i dit firma?) Ø Lad os høre eksempler fra jer der kender dem

48

49 Testteknikker effektivitet hvilke finder flest fejl? Ø Når du opretter testcases på din næste opgave, så tilføj et felt med oplysning om hvilken testteknik du har anvendt til at udarbejde denne testcase Ø Når du opretter en fejl ud fra en testcase, så bevar sporbarheden fra testcase til fejl Ø Testmanagement værktøjer gør dette automatisk Ø Som del af jeres lesson learned så undersøg hvilke testcases der finder fejl og derved hvilke testteknikker der er mest effektive

50 Testteknikker effektivitet anvend viden pro-aktivt Ø Opsamle metrikker for hvilke testteknikker der finder flest fejl i jeres organisation Ø Stil krav i fremtidige projekter til hvilke testteknikker der SKAL anvendes Ø Udfør fejl-årsagsanalyse for at identificerer årsagen til at nogle testteknikker finder flere fejl Ø Forbyg denne type fejl i fremtidige projekter

51 Links fra præsentationen TMMi model: Mindmap bog på Amazon i Japan: Skabeloner i mindmaps til genbrug og inspiration: God dansk introduktion til MindMaps: Mere om Dr. Genichi Taguchi og om Orthogonal Array Testing: Mere om Q-patterns: ISTQB Worldwide Software Testing Practices Report in :

52 God fornøjelse Tak for nu J Når du vil vide mere om test klaus@softwaretest.dk Web-site