Language menu for mobile

Articles

Test Governance

Hans Buwalda, LogiGear, 12/29/2005

Software testing is commonly perceived as a chore: products that are made by other developers have to be verified. Chores are something that you don’t want to spend too much attention and money on.

With our Action Based Testing method we have shifted the focus from “testing” to “test development” (with automated execution). This is successful because creating tests becomes a more systematic and easier to plan and control activity, resulting in tangible and valuable products.

Another shift that I would like you to think about is in focus: in stead of regarding software testing as a derivate of software development, give it a central separate focus and manage it as a key asset of the company. To summarize this thought I use the term “Test Governance”.
There is a good case to be made to do so:

  • Testing is a large part of the efforts in IT, typically 30% of all efforts
  • Good testing is very hard to do. It needs skilled staff and there is a lot to learn
  • Testing is often on the critical path of system development and maintenance
  • Test automation is a potential solution, but in itself is very hard to do successfully
  • Testing needs to be organized well, including who is responsible for which tests and how to report results
When discussing Test Governance a word of warning is in place. It is important to be practical about testing. Thinking about Test Governance should not lead to introducing all kinds of bureaucracy that nobody cares about.. Be careful with impractical standards and heavy life cycles that miss their purpose.

In my view three elements should be part of Test Governance:

  • What are the “business test policies” around testing
  • How should testing be organized in projects
  • How should testing be organized across projects

Business test policies are statements that describe, in broad terms, what the point of view is of an organization on testing. I will discuss these in a next newsletter article. Sufficient for now is to know that they should describe the importance of testing in the business of the organization and how it should be organized.

Testing activities are usually part of system development projects. Sometimes they are also organized in separate projects, usually to introduce test automation. Most books and articles on testing are about the activities within projects, and this is rightfully so. Consider creating a standard plan of approach for testing projects that deals with questions like responsibilities, communication structures, resources and skills, and obviously the planning, budget and risks.

However, projects tend to have a very strong “solution focus”: what is it that we need to achieve and how do we get there within given budgets and timelines. Projects are actually not a good environment to learn and improve best practices. Therefore I recommend to consider additional structures that have an “improvement focus”. This could be something traditional like a central test support department, or a more “light” solution, like one or more coordinating committees with members from various departments.

An addition to formalized structures consider “soft” ones, where staff members meet and discuss matters of know how and experience. For example one could introduce “Special Interest Groups” (SIG’s) that have regular informal meetings, typically in the off-hours. Members of a SIG share a common interest, for example “test design”, “test automation” or “test management” and an evening is typically structured around a presentation and discussion. SIG’s can also run sites on the intranet. All of these activities provide an inexpensive and light way to improve competence, but also help people “find” each other for advice and discussion of matters in projects.