1. Non-Coding Activities a Development Team Needs a.k.a ”I don’t code, am I no longer useful?” Maaret Pyhäjärvi| | Twitter: maaretp Test Specialist @ Granlund Oy | Part-time Trainer | FAST | Agile Finland Maaret Pyhäjärvi Nimeä | Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/ http://creativecommons.org/licenses/by/1.0/fi/deed.en

2. Outline In this presentation, I go through some of my personal experiences about the things of value that I work on in a development team as a professional tester without coding. The lessons I share are colored with real life stories of things that have happened. We will address: selecting & clarifying what goes into the development pipeline learning the system on what creates impacts to focus team work confirming and collecting ideas about what to confirm delivering and organizing for product feedback tweaking configurations designing improvement experiments This presentation is intended as a discussion opener on the skills and activities that benefit a development team, and an invitation to share your own experiences of the value you provide and expect someone to provide to create a successful product/system.

3. Context of the Story Years of software development without a tester 10 6 6 04/2012: add 1 tester (=specialist skills to testing that has been done before) 5 5 2 2 PdM SWE

4. How Things Worked in the Past Monthly releases Developers would test (own testing) – No test automation Developers would actively react on feedback (logs & customer contacts) – Quick deployment, positive collaboration Product Managers would accept (test in cycles) – Depth of acceptance depended on other duties & interests/abilities in testing Developers would enhance the feature for bugs and missed requirements – All hours invoicable, unhappy with ”the others” not telling what was needed or accepting well enough No open bugs in the database, but logs tell 10+ % of logged in users experience visible errors, hard to fix without knowing what the user did Month of redoing typical after development declares Done for Product Management – Considered normal that a Done feature cannot be used on first cycle of acceptance

5. What We Work Towards Pride of work and results, fun! Clean code and less of it Less interruptions to new development tasks Avoiding unavoidable rework through discussions before implementing the wrong solution Done includes checked + explored – with results Streamlined acceptance

6. Some Numbers 2013 Summary AspectGMGD System Testing % of Planned 30 %90 % % of Bugs from System Testing 50 %75 % % Fixed from System Testing 76 %94 % Customer Bugs2,9 % (too small due to classification error) 2,5 % (1,3 % of effort) Acceptance pending9,3 %0 % Not quite where we’d want to be, making progress though.

7. Examples of What I Do at Work as ’Testing Specialist’ Learn why the product exists & patiently use the system in varied ways – Example: program errors Provide feedback / log bugs – Example: GM 856 / GD 484 issues in 2013 – Example: Vau Work with product manager & developer to clarify a feature – Example: 3 redos Negotiate smaller workload for the team – Example: test-fix-finalize week Enable trainings and skill building – Example: code retreat Pair up with developers for shared experiences on quality – Example: testing together for inventory mgmt Challenge requirements with product management – Example: spec rewrite prior to implementation Negotiate right skillset ratios for the team – Example: more skilled testing and UI specialists – Example: let 2 people go Point out things that don’t work – Example: unhappiness Make efforts needed with skilled testing visible – Example: testing backlog Fix typos – Example: reporting vs. fixing time Create & Review unit & Selenium test ideas – Example: KSP Provide ideas for how to test a business model – Example: GD productization Create User Help Documentation – Example: GD Help Provide quality perspective for steering groups – Example: Regular reviews of how we are doing Present for end users on behalf of the team – Example: Sales People’s training Not a manager, very much a senior software specialist.

8. Wrapping Up WORK WITH PRODUCT MANAGEMENT selecting & clarifying what goes into the development pipeline learning the system on what creates impacts to focus team work WORK WITH TESTING confirming and collecting ideas about what to confirm delivering and organizing for product feedback FIX NON-CODE tweaking configurations HELP PEOPLE DELIVER VALUE BETTER designing improvement experiments Product management specialist benefit from good collaboration with the team – OUR product – Business Model Canvas, Product Backlog, Specification by Example, Communication Confirm & Explore – Test automation (product owner & implementation), multidimensional use of the system for feedback No strict roles – Fixing problems is allowed for a non- developer and environments take a lot of work Caring for people – People make or break quality – Creative ideas from the outside world

9. Summary Most of developer time goes on thinking for code, not coding, and it is often helpful to share work with others with diverse viewpoints While generalists able to deal with all from CTO to customer support would be great, who really does that with limited learning capabilities and depth of learning needed? MANY ESSENTIAL SKILLS – AND PERSONALITY MATTERS (”tester personality ” - someone who tries things)