1. Slide 1 Improve Testing, Improve Software Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK e: paul@gerrardconsulting.com w: http://gerrardconsulting.com t: 01628 639173

2. Paul Gerrard Paul is the founder and Principal of Gerrard Consulting, a services company focused on increasing the success rate of IT-based projects for clients. He has conducted assignments in all aspects of Software Testing and Quality Assurance. Previously, he has worked as a developer, designer, project manager and consultant for small and large developments using all major technologies and is the webmaster of gerrardconsulting.com and several other websites. Paul has degrees from the Universities of Oxford and London, is Web Secretary for the BCS SIG in Software Testing (SIGIST), Founding Chair of the ISEB Tester Qualification Board and the host/organiser of the UK Test Management Forum conferences. He is a regular speaker at seminars and conferences in the UK, continental Europe and the USA and was recently awarded the “Best Presentation of the Year” prize by the BCS SIGIST. Paul has written many papers and articles, most of which are on the Evolutif website. With Neil Thompson, Paul wrote “Risk-Based E-Business Testing” – the standard text for risk-based testing. In his spare time, Paul is a coach for Maidenhead Rowing club.

3. Primary sources Leading Change, John P Kotter Managing Transitions, William Bridges Managing Change, Bernard Burnes Goal-Directed Project Management, Andersen, Grude, Haug Test Process Improvement, Koomen and Pol. www.tmmifoundation.org 15 years experience in software process improvement.

4. Slide 4 Test Process Improvement is a Waste of Time!

5. How to improve… I want to improve my ( insert any activity here ) _______ people improvement _______ organisation improvement _______ process improvement    Changing people (like me) and organisation (like my company) is so hard – let’s not even think about it

6. The delusion of ‘best practice’ There are no “practice” Olympics to determine the best There is no consensus about which practices are best, unless consensus means “people I respect also say they like it” There are practices that are more likely to be considered good and useful than others, within a certain community and assuming a certain context Good practice is not a matter of popularity. It’s a matter of skill and context. Derived from “No Best Practices”, James Bach, www.satisfice.com

7. The delusion of quality management (a la ISO 9001) Google search for - “ISO 9001” – 14,500,000 - “ISO 9001 Training” – 13,100 - “ISO 9001improves quality” – 1 ISO 9001 in a nutshell - “Document what you do” - “Do what you document” - “Do what you like” ISO 9001 accreditation without reference to the garbage that is produced by the documented processes.

8. Exchange between quality manager and ISO 9001 consultant > 3. The 9000-3 Guidelines suggest the use of a > Life-> Cycle model for software development. Is it > necessary to reference a specific model? No. You do not need to reference a specific lifecycle. But you need to define your development process...which really speaks to the lifecycle of product development. Most development processes are derivatives of some type of model that someone else hatched.

9. Exchange between quality manager and ISO 9001 consultant cont… > I would like to learn more about the certification audit > process and how to document reasonable quality > processes which will allow us to provide the highest > quality to our customers and which fall within the 9001 > standards. The key is putting practices in place that hold up over time and that support getting software out the door faster and better. In the simplest sense, an implementation strategy that has worked for all the implementations I've been involved with is....put fundamental, good software development practices in place that are achievable and can act as a baseline for improvement.....check the standard to make sure you've covered your bases....and evolve the practices as the market and business changes. As regards documentation......it is tougher to write a 5 page design review procedure than a 50 page design review procedure because it requires that you communicate in a cogent fashion. But that's the subject of a "Streamlining Documentation" course that I teach.

10. The delusion of process models (e.g. CMM) Google search - “CMM” – 7,260,000 - “CMM Training” – 14,300 - “CMM improves quality” – “ 1-6 of about 7” Typical CMM user… - CMM level 3 and proud of it - Overall s/w quality, time to deliver is slipping - Changes to be made are obvious - But few can be adopted – they can’t change because they’ll lose their CMM status - What’s going on here?

11. But process models make improvement simple don’t they? People like simple models: - levels of maturity, stepping stones, checklists, roadmaps and outside support for credibility But life is much more complicated, unfortunately “Things should be made as simple as possible, but no simpler” - A. Einstein

12. Deming If you can't describe what you are doing as a process, you don't know what you're doing. - W. Edwards Deming It is not enough to do your best; you must know what to do, and THEN do your best. - W. Edwards Deming

13. Deming 2 I have to disagree with the first statement The second one states the bleedin’ obvious, doesn't it? - e.g. describe playing football, seducing a woman, winning a deal, convincing someone that a project is risky as a process - Is that “process” the critical factor in success?

14. People need process? A big problem with process is it becomes all encompassing Process folk sell process and cast all things in terms of it, forgetting that people who are smart, succeed in spite of process, not because of it It could be argued, that less smart people need process - (By less smart, we're talking about people who need so much structure and enforced discipline they can only operate in the military, or in prison probably) Is our industry really staffed by such people? Do we really want production-line workers?

15. Physics quotes… “I believe that a scientist looking at nonscientific problems is just as dumb as the next guy” “It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong” Richard P. Feynman

16. Process quotes “I believe that a process consultant looking at non- process problems is just as dumb as the next guy” “It doesn't matter how beautiful your process model is, it doesn't matter how smart you are. If it doesn't agree with reality, it's wrong” me

17. Slide 17 Software Success Improvement

18. Principles of change Current behaviour assessed in the context of current problems, goals and constraints Aspirations drive the definition of goals People in the job define and consent to the required changes in behaviour People supported by - Personal/team development plans - Infrastructure investment (process, technology, tools, environment) specific to the change Transitions are managed, not assumed.

19. Vision This is where the practitioners, with support, identify the changes to make External model (TPI, TMMi, TOM, brainstorming) might provide improvement suggestions Practitioners identify the specific problems, underlying causes, changes to be made, and pathway to the vision.

20. Section 3 – Example Findings (rapidly growing software house) 3.1Some Perceptions 3.2Product Quality 3.3Customer Management 3.4Organisation and Methodology 3.5Planning and Scheduling 3.6Product and Release Management 3.7Development 3.8Developer Testing 3.9System Testing 3.10Support

21. Perceptions (3 of 15) 1.“No one can test”. There is a perception that no-one in the company is testing well enough to stabilise and improve the quality of the product. The support/test team are split between support and testing and support always takes priority. The team aren’t ‘career testers’ or focused on criticising and ‘breaking’ the product and haven’t had any formal testing training. Developers do not perform thorough unit testing. Requirements are not reviewed. 2.“No one is responsible for quality”. Although one could say everyone is responsible for quality, no one owns it because all groups are under pressure to compromise and see no way of resisting that pressure. No one owns quality because they don’t have authority to say no. 3.There has been a reluctance to implement a more structured process because of past experience. When a dedicated QA manager was recruited, they found it difficult to implement even basic processes. Probably their approach was to write processes and assume they could implement themselves. This negative experience discouraged attempts to try alternatives so practices are largely unchanged.

22. Section 4 - Recommendations 4.1Company Management 4.2Organisation and Planning 4.3Methodology 4.4Product Management - Requirements 4.5Product Management – Project/Work Package Management 4.6Releases/Installations/Customer Support 4.7Development - Design 4.8Development – Better Practices 4.9Development – Product Development, Refactoring 4.10Development – Testing 4.11Training 4.12System Testing

23. Need to adopt changes based on findings, not idealised models ‘Whole-Process’ assessments not just testing Recommendations aren’t just testing-related: - Could be a change in requirements/development/CM… - Could be a change in attitude, leadership, policy - Could be a change in organisation - Could be a change in emphasis - Could be an agile approach - Could be a novel approach - Could be a change in personnel None of these changes are promoted by current testing models, but are almost always required.

24. Section 5 - Implementation 5.1Explanation 5.2Organisation and Management 5.3Product Strategy 5.4Customer Support/Product Improvement/Implementation 5.5Project/Change/Release Management 5.6Development Methodology 5.7Test Strategy 5.8Development Test Methodology 5.9Design Process 5.10Development Process 5.11Training

25. Sample recommendations (3 of 73) 1.Organisation and Management 1.Recommendations: 4 6 8 9 10 IDRecommendation CostQuickChangeQualityTime 4Conduct a post implementation review of major releases. Periodically review the costs of bug fixing and enhancements Work Packages. Learn lessons. Make changes. 6Identify key resources who are “bottlenecks”, “irreplaceable” or have conflicting roles (e.g. team leadership and team membership). Require these staff to mentor/coach a colleague(s) (who may have to be hired) to reduce the risk of over dependency/burnout etc. 8Define specific roles, objectives, responsibilities for PS, product management, development, documentation, testing, support in the context of software product development, maintenance and support. Constraint s

26. Alternatives are old fashioned, IT centric, inflexible Improvement models implement waterfall approaches: - Structured, systematic, bureaucratic, v-model based - Favoured by service companies selling large teams They try to resolve symptoms through testing, when many ‘testing’ symptoms are caused by problems elsewhere Less than 5% of these approaches focus on people issues IT focused, not business focused Every organisation is unique, their problems and causes are probably unique too - models just can’t accommodate this.

27. Summary You have to treat every change project as unique You need to understand how things are But you also need to understand the reasons WHY they are You must listen to practitioners and managers - To hear their ideas for improvement - To align/augment ideas with the known constraints - To refine the vision to be something achievable.

28. Slide 28 Thank-You www.gerrardconsulting.c om paul@gerrardconsulting. com Improve Testing, Improve Software