process innebär en mer restriktiv arbetsprocess och kan därför bidra till denna typ av effekt. Det har dock visat sig att även en organisationsstruktur som är för flexibel kan orsaka stress [48]. Hur utvecklarnas välmående har påverkats av arbetet har inte undersökts. Mer struk- tur i arbetet kan ha haft en negativ påverkar på stressnivåerna, men eftersom utvecklarna varit delaktiga i förändringarbetet kan det argumenteras att de ändå har haft en hög grad av självstyre. Den ekonomiska effekten på företaget har inte varit i fokus så därför dras inga slutsatser i det området. Vetenskapligt har denna studie bidragit till mer insikt i små före- tags inställning till och upplevelse av testning. Den samhälleliga påverkan av studien är sannolikt mycket begränsad i direkt bemärkelse, men lärdomarna från studien kan förhopp- ningsvis underlätta för andra mindre företag som vill börja jobba mer strukturerat med sitt testningsarbete.
6.4
Framtida arbete
Denna studie följde ett pilotprojekt under dess första veckor. Att projektet fortsatte långt efter studiens slut innebar att effekter som förväntades uppstå i projektets senare faser inte hann utvärderas. Detta gäller framförallt tidsåtgång för det löpande underhållet av testsviten och eventuella tidsbesparingar i felsökningen inför leverans. Det vore således intressant att i framtiden återbesöka Exsitec för att utvärdera hur arbetet fortskred, eller konstruera liknande studier med ett längre tidsperspektiv hos liknande företag.
En del av motivationen till denna studie var att fortsätta forskningen inom testning i team med mindre än 10 utvecklare, vilket tidigare gjorts av bland annat Martin et. al. [40]. Detta har gjorts, men det finns fortfarande utrymme för mer forskning inom liknande miljöer för att ge en bredare förståelse och fler insikter inom ämnet.
7
Slutsatser
Målet med denna studie var att ta fram och implementera en strukturerad testprocess som var anpassad till behoven hos små utvecklingsteam. I detta fall bestod teamet av endast två medlemmar. Detta arbete byggdes på två frågeställningar, angående anpassning av MTPF respektive vilka effekter införandet uppnådde.
Anpassningar av MTPF
Nedan beskrivs vilka anpassningar som gjorts av MTPF för att passa det aktuella projektet. Detta besvarar den första forskningsfrågan: "Hur kan Minimal Test Practice Framework anpassas för små webbutvecklingsteam så att den utgör ett strukturerat arbetssätt som ger utvecklarna ett större förtroende för kodens kvalitet och inte innebär en tidsinvestering utvecklarna upplever som för stor?" Testplaneringen skedde endast på projektnivå. Det skedde ingen återkommande testplanering, som MTPF förordar, utan en allmän teststrategi utvecklades som riktlinje för hur det dagliga testarbete skulle ske. Regelbunden planering bedömdes inte vara nödvändig för enhetstest- ning, så det överläts till varje utvecklare att själv planera när denne skulle skriva sina tester. Kodinspektioner är möjliga att införa, men måste hållas flexibla. Kodinspektioner ingår inte i MTPF förrän nivå 3 men infördes på utvecklarnas önskemål. Kodinspektionerna behövde vara väldigt flexibla, både i utförande och som steg i arbetsprocessen. Det fungerar inte att ha som regel att en kodinspektion måste ske vid varje pull-request, då detta kan få arbetet att stanna upp om en annan utvecklare inte finns tillgänglig.
Det fanns ingen formell ansvarfördelning. Teamet bestod endast av två personer och ansvaret togs gemensamt eftersom teamet ansågs jobba så pass nära varandra att helhetsbilden inte skulle gå förlorad. Det visade sig dock att det skrevs mindre tester är vad utvecklarna trodde. Det är möjligt att en testansvarig hade kunnat upptäcka och åtgärda detta.
Det gjordes inte definition av problemsyntax. Detta skalades bort för att minska formaliteten i testprocessen. Utvecklarna rapporterade att de inte stött på några situationer där kommu- nikationen brustit på ett sätt som hade kunnat undvikas av en definierad problemsyntax.
Enhetstester. MTPF specificerar inte vilken sorts tester som ska skrivas. Under studien beslu- tades att testningsarbetet till största del skulle utgöras av enhetstester som skrevs av utveck- larna under utvecklingens gång.
Effekter
Nedan summeras de effekter som utvecklarna observerat som följd av den nya testprocessen och som svarar på den andra frågeställningen: "Ur en utvecklares perspektiv, vilka fördelar och nackdelar medför den framtagna testprocessen?".
Högre förtroende för kodkvaliteten. Att all kod är testad på samma sätt gör att utvecklarna litar mer på att både den egna och andra utvecklares kod gör det den ska.
Automatiserad testning kompletterar manuell testning. Utvecklarna upplever enhetstestning som ett bra komplement till manuella tester men tror inte att det går att undvika manuell testning helt, särskilt för de visuella aspekterna av applikationerna.
Bättre spårbarhet. Enhetstesterna är på en lägre nivå än manuella tester och gör det därför enklare att hitta källan till fel.
Högre produktkvalitet. En bättre förmåga att upptäcka fel har lett till att det hittas flera buggar i koden och den slutgiltiga produktkvaliteten är därmed förbättrad.
Bristande diversifiering Enhetstester fungerade som en bra grund, men utvecklarna kände ett behov av att införa integrationstestning mellan server och frontend som ett stöd i utvecklin- gen.
Större tidsinvestering. I början av projektet blev utvecklingen mer tidskrävande då både testkod och produktionskod behövde skrivas. Det är först på lång sikt processen kan in- nebära en tidsvinst, men det går inte att med säkerhet säga hur stor den vinsten kommer vara.
Lärdomar
Nedan summeras de lärdomar som dragits angående hur en testprocess bör anpassas för att passa små utvecklingsteam.
Enhetstester är en bra grund. De är lätta för utvecklarna att komma igång med och kompletterar manuell testning väl. Från ett längre tidsperspektiv kan det vara nyttigt att komplettera med end-to-end-tester, men vid ett första införande visade sig detta vara för omständigt.
Arbetsflödet behöver vara flexibelt. I små team är det viktigt att kunna jobba flexibelt. Hur det dagliga arbetet ska genomföras får inte vara för fast definierat. I detta fall visade sig att för hårda regler kring kodinspektioner saktade ned arbetet.
En byggserver kan se till att testsviten körs och underhålls. Att testsviten körs automatiskt på en byggserver gör att den inte faller i glömska och blir förlegad.
Det är viktigt att testmiljön är konfigurerad vid projektets start. Att få igång en fungerande test- miljö var ett av de största hindren under studiens gång och bör därför avsättas tid för att göra detta. Detta minskar risken att testsviten hamnar efter från början.
Ha ett långt tidsperspektiv. Ifall organisationen inte har någon tidigare erfarenhet av testning bör nya testaktiviter införas gradvis. I denna studie underskattades tidsåtgången för att in- föra nya åtgärder. Tidsramen bör vara över ett flertal månader om inte år.
Bibliography
[1] Dan Abramov. Redux: Predictable State Container for JavaScript apps. 2017.URL: https: //github.com/reactjs/redux(visited on 03/27/2017).
[2] P. Allen, M. Ramachandran, and H. Abushama. “PRISMS: an approach to software pro- cess improvement for small to medium enterprises”. In: Third International Conference on Quality Software, 2003. Proceedings. (2003). ISSN: 15506002.DOI: 10 . 1109 / QSIC . 2003.1319105.
[3] Yasaman Amannejad, Vahid Garousi, Rob Irving, and Zahra Sahaf. “A search-based approach for cost-effective software test automation decision support and an industrial case study”. In: Proceedings - IEEE 7th International Conference on Software Testing, Veri- fication and Validation Workshops, ICSTW 2014. 2014, pp. 302–311.ISBN: 9780769551944. DOI: 10.1109/ICSTW.2014.34.
[4] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas. Agile Manifesto. 2001.DOI: 10.1177/004057368303900411.
[5] S. Berner, R. Weber, and R.K. Keller. “Observations and lessons learned from auto- mated testing”. In: Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005. (2005), pp. 571–579. ISSN: 02705257.DOI: 10 . 1109 / ICSE . 2005 . 1553603.
[6] Ilene Bernstein, Taratip Suwanassart, and Robert Carlson. “Developing a Testing Ma- turity Model for software test process evaluation and improvement”. In: International Test Conference. Washinton, DC, 1996, pp. 581–589.
[7] Barry Boehm and Victor R. Basili. Software Defect Reduction Top 10 List. 2001.DOI: 10. 1109/2.962984.
[8] Scott Chacon and Ben Straub. Pro Git. [Elektronisk resurs]. [New York] : friends of ED : Apress, [2014], 2014.ISBN: 9781484200766.
[9] Peter Checkland and Sue Holwell. “Action Research: Its Nature and Validity”. In: Sys- temic Practice and Action Research 11.1 (1998), pp. 9–21.ISSN: 1094-429X, 1573-9295.DOI: 10.1023/A:1022908820784. arXiv: arXiv:1011.1669v3.
Bibliography
[10] M Coetzee and M De Villiers. “Sources of job stress, work engagement and career orien- tations of employees in a South African financial institution”. In: Southern African Busi- ness . . . 14.1 (2010), pp. 27–58.ISSN: 1998-8125.URL: http://reference.sabinet. co . za / sa % 7B % 5C _ %7Depublication % 7B % 5C _ %7Darticle / sabr % 7B % 5C _ %7Dv14%7B%5C_%7Dn1%7B%5C_%7Da2.
[11] Lee Copeland. A Practitioner’s Guide to Software Test Design. 1st. London: Artech House, 2004.ISBN: 9781580537919.
[12] Yvonne Dittrich, Kari Rönkkö, Jeanette Eriksson, Christina Hansson, and Olle Lin- deberg. “Cooperative method development : CCCombining qualitative empirical re- search with method, technique and process improvement”. In: Empirical Software Engi- neering 13.3 (2008), pp. 231–260.ISSN: 1382-3256.DOI: 10.1007/s10664-007-9057- 1.
[13] Elfriede Dustin, Jeff Rashka, and John Paul. Automated Software Testing: Introduction, Management, and Performance. 1999, p. 575.ISBN: 0201432870.
[14] T Dybå and T Dingsøyr. “Empirical studies of agile software development: A system- atic review”. In: Information and Software Technology 50.9-10 (2008), pp. 833–859. ISSN: 0950-5849.DOI: 10.1016/j.infsof.2008.01.006.
[15] Hakan Erdogmus, Maurizio Morisio, and Marco Torchiano. “On the effectiveness of the test-first approach to programming”. In: IEEE Transactions on Software Engineering 31.3 (2005), pp. 226–237.ISSN: 00985589.DOI: 10.1109/TSE.2005.37.
[16] Thomas Ericson, Anders Subotic, and Stig Ursing. “TIM - A Test Improvement Model”. In: Software Testing Verification and Reliability 7.4 (1997), pp. 229–246. ISSN: 09600833.
URL: http://www.lucas.lth.se/events/doc2003/0113A.pdf.
[17] Martin Fowler. Continuous Integration. 2006. URL: https : / / www . martinfowler . com/articles/continuousIntegration.html(visited on 04/10/2017).
[18] Vahid Garousi, Michael Felderer, and Tuna Hacalo ˘glu. “Software test maturity assess- ment and test process improvement: A multivocal literature review”. In: Information and Software Technology 85 (2017), pp. 16–42.
[19] P. Grunbacher. “A software assessment process for small software enterprises”. In: EU- ROMICRO 97. Proceedings of the 23rd EUROMICRO Conference: New Frontiers of Infor- mation Technology (Cat. No.97TB100167) Cmm (1997), pp. 123–128.ISSN: 1089-6503.DOI:
10.1109/EURMIC.1997.617236.
[20] Stefan Gruner and Johan Van Zyl. “Software Testing in Small IT Companies: A (not only) South African Problem”. In: South African Computer Journal 47.1 (2011), pp. 7–32. [21] B. Haugset and G.K. Hanssen. “Automated Acceptance Testing: A Literature Review
and an Industrial Case Study”. In: Agile 2008 Conference (2008), pp. 27–38. DOI: 10 .
1109/Agile.2008.82.
[22] Henri Heiskanen, Mika Maunumaa, and Mika Katara. “A test process improvement model for automated test generation”. In: Proceedings of the 13th international conference on Product-Focused Software Process Improvement. 2012, pp. 17–31.ISBN: 978-3-642-31062- 1.DOI: 10.1007/978-3-642-31063-8_3.
[23] Wei Huang, Li Ru, Maple Carsten, Yang Hong-Ji, Foskett David, and Cleaver Vince. “A Novel Lifecycle Model for Web-based Application Development in Small and Medium Enterprises”. In: International Journal of Automation and Computing 7.3 (2010), pp. 389– 398.DOI: 10.1007/s11633-010-0519-3.
[24] ISO/IEC/IEEE. “29119-2:2013 - ISO/IEC/IEEE International Standard for Soft- ware and systems engineering — Software testing — Part 2: Test processes”. In: ISO/IEC/IEEE 29119-2:2013(E) 2013 (2013), pp. 1–68.DOI: 10.1109/IEEESTD.2013.
Bibliography
[25] J C Jacobs and J J M Trienekens. Towards a metrics based verification and validation maturity model. 2002.DOI: 10.1109/STEP.2002.1267622.
[26] Eun Jung. “A Test Process Improvement Model for Embedded Software Develop- ments”. In: Quality Software 2009 QSIC 09 9th International Conference on. 2009, pp. 432– 437.ISBN: 9781424459124.DOI: 10.1109/QSIC.2009.64.
[27] Natalia Juristo, Ana M. Moreno, and Sira Vegas. “Reviewing 25 Years of Testing Tech- nique Experiments”. In: Empirical Software Engineering 9.1 (2004), pp. 7–44.ISSN: 1573- 7616.DOI: 10.1023/B:EMSE.0000013513.48963.1b.
[28] Cem Kaner, James Bach, and Bret Pettichord. Lessons learned in software testing: A context- driven approach. 2002, p. 352.ISBN: 9780471081128. URL: http : / / www . worldcat . org/oclc/439647312.
[29] Katja Karhu, Tiina Repo, Ossi Taipale, and Kari Smolander. “Empirical observations on software testing automation”. In: Proceedings - 2nd International Conference on Software Testing, Verification, and Validation, ICST 2009. 2009, pp. 201–209.ISBN: 9780769536019.
DOI: 10.1109/ICST.2009.16.
[30] Daniel Karlström and Per Runeson. “Integrating agile software development into stage-gate managed product development”. In: Empirical Software Engineering 11.2 (2006), pp. 203–225.ISSN: 13823256.DOI: 10.1007/s10664-006-6402-8.
[31] Daniel Karlström, Per Runeson, and Sara Nordén. “A minimal test practice framework for emerging software organizations”. In: Software Testing Verification and Reliability 15.3 (2005), pp. 145–166.ISSN: 09600833.DOI: 10.1002/stvr.317.
[32] Abhinaya Kasoju, Kai Petersen, and Mika V. Mäntylä. “Analyzing an automotive test- ing process with evidence-based software engineering”. In: Information and Software Technology 55.7 (2013), pp. 1237–1259. ISSN: 09505849. DOI: 10 . 1016 / j . infsof . 2013.01.005.
[33] Jussi Kasurinen, Per Runeson, Leah Riungu, and Kari Smolander. “A self-assessment framework for finding improvement objectives with ISO/IEC 29119 test standard”. In: Communications in Computer and Information Science. Vol. 172. 2011, pp. 25–36.ISBN:
9783642222054.DOI: 10.1007/978-3-642-22206-1.
[34] Jussi Kasurinen, Ossi Taipale, and Kari Smolander. “Software Test Automation in Prac- tice: Empirical Observations”. In: Advances in Software Engineering 2010 (2010), pp. 1–18.
ISSN: 1687-8655.DOI: 10.1155/2010/620836.
[35] Barbara A. Kitchenham, Tore Dyba, and Magne Jorgensen. “Evidence-Based Software Engineering”. In: Proceedings of the 26th International Conference on Software Engineering. Washington, DC: IEEE Computer Society, 2004, pp. 273–281.
[36] Tim Koomen and Martin Pol. Test Process Improvement: A Practical Step-by-step Guide to Structured Testing. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999.ISBN: 0-201-59624-5.
[37] Yanqing Lai, George Saridakis, and Robert Blackburn. “Job stress in the United King- dom: Are small and medium-sized enterprises and large enterprises different?” In: Stress and Health 31.3 (2015), pp. 222–235.ISSN: 15322998.DOI: 10.1002/smi.2549. [38] Xu Xiang Li and Wen Ning Zhang. “The PDCA-based software testing improvement
framework”. In: 2010 International Conference on Apperceiving Computing and Intelligence Analysis, ICACIA 2010 - Proceeding. 2010, pp. 490–494.ISBN: 9781424480265.DOI: 10. 1109/ICACIA.2010.5709948.
[39] Yuan-Fang Li, Paramjit K. Das, and David L. Dowe. “Two decades of Web applica- tion testing—A survey of recent advances”. In: Information Systems 43 (2014), pp. 20–54.
Bibliography
[40] David Martin, John Rooksby, Mark Rouncefield, and Ian Sommerville. “’Good’ Orga- nizational Reasons for ’Bad’ Software Testing: An Ethnographic Study of Testing in a Small Software Company”. In: Proceedings of the 29th IEEE/ACM International Con- ference on Software Engineering (ICSE 2007) (2007), pp. 602–611.ISSN: 0270-5257. DOI: 10.1109/ICSE.2007.1.
[41] L Mathiassen. “Collaborative practice research”. In: Information Technology & People 15.4 (2002), pp. 321–345.
[42] Glenford J Myers, Todd M Thomas, and Corey Sandler. The Art of Software Testing 3rd Edition. Vol. 1. 3. 2011, p. 255. ISBN: 0471469122.DOI: 10 . 1002 / stvr . 321. arXiv: 9809069v1 [arXiv:gr-qc].
[43] Dudekula Mohammad Rafi, Katam Reddy, Kiran Moses, and Kai Petersen. “Benefits and Limitations of Automated Software Testing : Systematic Literature Review and Practitioner Survey”. In: Automation of Software Test (AST), 2012 7th International Work- shop on (2012), pp. 36–42.DOI: 10.1109/IWAST.2012.6228988.
[44] Matthias Rasking. “Experiences developing TMMi as a public model”. In: Commu-R
nications in Computer and Information Science. Vol. 155 CCIS. 2011, pp. 190–193. ISBN: 9783642212321.DOI: 10.1007/978-3-642-21233-8-18.
[45] Ita Richardson and Christiane Gresse von Wangenheim. “Why are small software or- ganizations different?” In: IEEE Software 24.1 (2007), pp. 18–22.ISSN: 07407459. DOI: 10.1109/MS.2007.12.
[46] Per Runeson and Martin Höst. “Guidelines for conducting and reporting case study research in software engineering”. In: Empirical Software Engineering 14.2 (2008), p. 131.
ISSN: 1573-7616.DOI: 10.1007/s10664-008-9102-8.
[47] Hoyeon Ryu, Dong Kuk Ryu, and Jongmoon Baik. “A strategic test process improve- ment approach using an ontological description for MND-TMM”. In: Proceedings - 7th IEEE/ACIS International Conference on Computer and Information Science, IEEE/ACIS ICIS 2008, In conjunction with 2nd IEEE/ACIS Int. Workshop on e-Activity, IEEE/ACIS IWEA 2008. 2008, pp. 561–566.ISBN: 9780769531311.DOI: 10.1109/ICIS.2008.78.
[48] Shoukry D. Saleh and K. Desai. “Occupational stressor for engineers”. In: IEEE Trans- actions on Engineering Management EM-33.1 (1986), pp. 6–12.
[49] Tomas Schweigert, Andreas Nehfort, and Mohsen Ekssir-Monfared. “The Feature Set of TestSPICE 3.0”. In: Communications in Computer and Information Science. Vol. 425. 2014, pp. 309–316.ISBN: 9783662438954.DOI: 10.1007/978-3-662-43896-1_28.
[50] Helen Sharp, Yvonne Dittrich, and Cleidson R B De Souza. “The role of ethnographic studies in empirical software engineering”. In: IEEE Transactions on Software Engineering 42.8 (2016), pp. 786–804.ISSN: 00985589.DOI: 10.1109/TSE.2016.2519887.
[51] Chris Sims and Hillary Louise Johnson. Scrum: A Breathtakingly Brief and Agile Introduc- tion. Dymaxicon, 2012.
[52] Sogeti. TPI Automotive version 1.01. 2004.R URL: http://www.tpiautomotive.de/
Docs/TPI%20automotive%20version%201.01.pdf(visited on 05/30/2017). [53] Sogeti. TPI Next: Business Driven Test Process Improvement. 2009.R ISBN: 978-9-072-
19497-8.
[54] Keith Stobie. “Too much automation or not enough? When to automate testing.” In: Pacific Northwest Software Quality Conference. Portland, Oregon, 2009, pp. 67–77.
[55] Ossi Taipale and Kari Smolander. “Improving Software Testing by Observing Practice”. In: Isese’06 ACM (2006), pp. 262–271.DOI: 10.1145/1159733.1159773.
Bibliography
[56] R. Van Den Broek, M. M. Bonsangue, M. Chaudron, and H. Van Merode. “Integrating testing into agile software development processes”. In: MODELSWARD 2014 - Proceed- ings of the 2nd International Conference on Model-Driven Engineering and Software Devel- opment. 2014, pp. 561–569.ISBN: 9789897580079.URL: http://www.scopus.com/ inward / record . url ? eid = 2 - s2 . 0 - 84906898151 % 7B % 5C & %7DpartnerID = tZOtx3y1.
[57] T. E. J. Vos, B. Marín, M. J. Escalona, and A. Marchetto. “A Methodological Framework for Evaluating Software Testing Techniques and Tools”. In: 2012 12th International Con- ference on Quality Software. Aug. 2012, pp. 230–239.DOI: 10.1109/QSIC.2012.16. [58] Tanja E.J. Vos, Jorge S Sánchez, and Maximilliano Mannise. “Size does matter in pro-
cess improvement”. In: Testing Experience: The Magazine for Professional Testers 3 (2008), pp. 91–95.
[59] Robert K. Yin. Case Study Research . Design and Methods. 2003.DOI: 10 . 1097 / FCH . 0b013e31822dda9e.
A
Intervjufrågor - Fas 1
A.1
Uppvärmningsfrågor
• Hur länge har du jobbat här?
• Hur skulle du beskriva dina arbetsuppgifter? • Vad jobbar du på för projekt för tillfället?
A.2
Huvudfrågor
• Har du någon utbildning eller tidigare erfarenheter inom testning? • Hur ser du på att skriva och utföra tester?
• Är testning något du vill göra/lägga tid på?
Testningen idag
• Hur testar du din kod idag?
• Vilka nivåer av tester utför du? (Enhetstester, integrationstester, etc.) • Vilka delar av applikationen testar du mest?
• Hur avgör du vad som ska testas? • Vilka verktyg använder du?
• Har du använt några andra testverktyg tidigare?
Hur pass bekväm är du med att använda dessa verktyg?
A.2. Huvudfrågor
• Hur mycket av arbetstiden skulle du uppskatta att du lägger på testning? (procentuellt) • Vid manuell testning, upplever du att du kör samma test flera gånger?
Hur testningen upplevs
• Kan du identifiera några delar av mjukvaran som är mer riskbenägna? • Är det något du skulle vilja ändra i hur testningen sker idag?
Ser du några problem?
Ser du några förbättringsåtgärder? • Känner du att du har tid att testa?
Testautomation
• Vad är din inställning till automatiserad testning?
• Vilka delar av mjukvaran tror du bäst skulle gynnas av testautomation? • Vilka delar av mjukvaran tror du inte skulle gynnas av testautomation?
Avslutande
• Vilka problem kan du se med att införa en systematisk testningsmetod?
B
Frågor/Diskussionspunkter -
Slututvärdering
B.1
Införande
• Hur du upplevt att det varit att börja med den nya processen?
B.2
Allmänt
• Vilka är de största förändringarna som märkts av? Vilka nackdelar har du märkt av?
Känner du att några delar av testprocessen inte har varit till någon nytta? • Känns det som att testningen idag sker mer strukturerat?
• Har du i och med testprocessen de riktlinjer som behövs för att genomföra testningen på ett strukturerat sätt?
• Är testprocessen anpassad efter projektets behov? Passar den för små team?
• Hur tror du att processen fungerar för personer med mycket respektive lite erfarenhet av testning?
B.3
Testkvalitet
• Har testningen blivit bättre?
Är det mer tanke bakom hur testningen genomförs? • Tänker du mer på testning ur ett riskperspektiv?
B.4. Produktkvalitet
• Har det blivit lättare att hitta källan till fel som uppstår? • Har du märkt av en ökad förmåga att upptäcka fel?
• Har testernas pålitlighet förändrats? Litar du mer på att automatiserade tester testar rätt grejer jämfört med manuella?
B.4
Produktkvalitet
• Har produktkvaliteten har påverkats?
Har detta märkts av på något konkret sätt?