[Me] : - Guruji, if I need to improve my testing process, what is the manifesto that I need to stick to?
[Guruji]:- Like the Agile manifesto, some guys at EuroSTAR have created one for you. Just use them. Basically in the test process improvement manifesto they have tried to define what makes process improvement work and what not
Flexibility over Detailed Processes
In general, having defined processes supports an organization. Only something that is defined can be improvement. It guides new engineers and acts like corporate memory. However building too rigorous processes takes away people values. You want good testers that have the skills to act based on the context of a problem and perceive testing to be a challenging job. Supporting processes are needed but using the processes should give enough flexibility and freedom to testers to allow them to think for themselves and find the best way forwards. You only need “just enough process”.
Best Practices over Templates
Templates are great but even better is to provide examples of how they should be used. What provides more support; a test plan template or three test plan best practices? I guess almost everyone working in practice will choose the latter. When doing test process improvement focus on getting a best practices library set up as soon as possible instead of overspending on defining templates. Don’t worry whether the best practices are the best in the industry. They are the best in your organization and if something better comes along replace them. This is what supports our testing and makes process improvement work
Deployment orientation over Process orientation
Building process is easy, we have already done this so many times and there are numerous examples to be found. However, getting them deployed and thereby changing someone’s behavior is the hard part. Process improvement is all about change management. I have seen test improvement plans that focus almost entirely on defining the testing processes. In successful improvement projects at least 70% of the improvement effort is spent on deployment – “getting the job done”. Defining the processes is the easy part and should only account for a small percentage of the effort and focus
Reviews over Quality Assurance (departments)
Communication and providing feedback are essential to project success. It is exactly this peer review, if applied well, do. In principle also quality assurance officers evaluate documents and provide feedback to engineers. However, once to often I have experiences that quality officers, sorry no offence to those who do a good job !!, are too far away from the testing profession. Their feedback then focuses on conformance to templates and defined processes. Little added value to most projects, I believe. I have also experienced organizations where every test plan is peer reviews by one or two peer test manager giving feedback on the approach and content of the test plan. This is what we want, real feedback to we can use.
Business driven over Model driven
Whatever you do, make sure you know why you are doing it. What is the business problem you are trying to address? What is the test policy supported by management? Just trying to get to TMMi level 2 or 3 without understanding the business context will always fail in the short or long term. When addressing a certain practice from an improvement model, there are most often many different to comply. The business problem (poor product quality, long test execution lead time, costs, etc) will tell you which one to choose. Almost continuously review your process improvement against the business drivers and test policy