Add to del.icio.us Digg it! Add to reddit Add to MyWeb

Test Governance

Hans Buwalda, Chief Architect, LogiGear Corporation

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 the Action Based Testing method we have shifted the focus from “testing” to “test development” (with automated execution). This is successful because creating tests becomes an activity that is more systematic and easier to plan and control, resulting in tangible and valuable products.

Another shift that I would like you to think about is in focus: instead 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 for Test Governance:

• Testing is a large part of the efforts in IT, typically 30% or more.
• Good testing is difficult. It takes skilled staff and there is a lot to learn.
• Testing is usually 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 necessary: It is important to be practical about testing. Test Governance should not lead to introducing all kinds of bureaucracy that nobody cares about. Be careful with impractical standards and heavy processes that miss their purpose.

In my view three key questions should be addressed by a Test Governance policy:

• 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, the organizations policy towards testing. I will discuss these in a future newsletter article. For now, it’s sufficient 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 rightfully so. You should 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 not a good environment to learn and improve best practices. Therefore I recommend considering additional structures that have an “improvement focus”. Solutions include something “traditional” like a central test support department, or a more “light” solution, like one or more coordinating committees with members from various departments.

In addition to formalized structures, consider “soft” ones, where staff members meet and discuss matters of know-how and experience. For example one could introduce internal “Special Interest Groups” (SIG’s) that have regular informal meetings, typically in the off-hours or at lunch. Members of a SIG share a common interest, for example “test design”, “test automation” or “test management” and a meeting 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.

LogiGear's RSS feed