Please help me with the next topic: result driven testers! Do they exist? When you are positive about that, what defines a result driven tester? This is the question I’m struggling with! Sometimes you’re listening to a presentation or reading a book about testing and they talk about result driven testing: Focus on the result.

I believe focus on result is important for a tester. This must be part of the testers attitude, the way to do the job. Always the focus on the result, especially the end result for the business. Having said that; this doesn’t mean that this is very clear. Let me give you an example with the following figure.

If you have to test the system under test you can have several test cases. The result can be (from a functional perspective) that everything works fine. But from a users point of view, the user friendliness is very bad. So is this application good for the end user, it does what it has to do, but it costs you double the time than the application you had earlier. What about the maintenance, the application is easy to maintain, but has a very bad security. What is your focus on result in this case? You don’t know the business goal in this situation.

The second issue I’m struggling is, what documents, which people and what systems or oracles offer you the fundament for the business goals? Where can I find the descriptions of these goals.

Thinking and reading about this topic gives me the figure below (this is not a formal scheme or something but just my thoughts). As a tester I have some influence at the left blue column. If I’m only the test engineer in a large organization, my scope is the Detail Test Plan. Depending on your role or the place in the organizations hierarchy you can affect the MTP, GTS or policy.

That means that if you create these documents they must be derived from other documents that tell the result, from a business perspective.

What about a Project Plan? Looks like a good one; normally there is a ‘business case’ inside. But is this business case well-balanced? Does it come up with the end user goals, the manager goals, or with the goals of the people that do the configuration management? Having said that, the question comes up in my mind, is this really the job of the tester? Or is this the auditors work?

Keep in mind that we’re still looking for the answer at the question: What is focus on result? Are In this perspective Project Plans, IT Strategies or the annual plans useful to get the information about the business goals? The more people that work on these documents for example, the bigger the chance that it’s well balanced.  But this is still no guarantee. More important is the thing that the relevant people must be involved, without for example important stakeholders you can’t get the right results.

To have the left blue column in place, you need a mature test organization. And to get insight as a tester into the information that is in the orange part you have to arrange a lot. This isn’t an easy job, and this figure doesn’t give a complete answer. If you think these types of documents can give you an answer to be a result driven testers try to get them. But focus on result. I you don’t expect important answer don’t invest too much time.

Having said that gives me the following question, hopefully you can help me. How can I as a tester in the first place find the business goals, in the second place translate them to testing, and third well-balance them if the organization gives me several answers?

As described above, focus on result is needed. This attitude is sometimes hard to practice because results are covered. Let me give you some tips I use to focus on the result. The things I do to learn about the business and try to get a clear understanding of the business goal are the following:

• Read domain related blogs, magazine and sites with the news about the domain you’re working in.
• Open via the customer site the annual plans, and scroll through the site of the customer you’re working for. You’ll learn a lot about his business.
• Try to find out something about the history of your company, is it a old organization, a new and dynamic one, …?
• Talk with the real end user, last Saturday I had a nice talk with my neighbor. He’s working in a hospital as an IT manager implementing health related systems. The information he gave to me was very useful since I try to get an understanding of the health market for my new job.
• Find other projects that are done before! Read the evaluation reports, lessons learned and other stuff.
• Try to search for laws and legislations of your domain, almost every domain will have some. Companies must be compliant to these, also their software.

With these things you’ll get a better understanding of the market and the customer you’re working for. Maybe you can come closer to the result you have to focus on. With this you can deliver added value to have a shorter time to market or better software, things that will sound familiar to the business.

Please let me know what you think about:

• Is focus on result an attitude for testers?
• How to get in touch with the result? The business goal? Do you have concrete tips

Earlier posts about the testers attitude:

#1: Attitude or methods
#2: Testers are priests
#3: Focus on result, start with the business

1. Tweets that mention Software Testing and more » Blog Archive » Focus on result, starts with the business -- Topsy.com Says:
   May 28th, 2010 at 08:12

   [...] This post was mentioned on Twitter by Ewald Roodenrijs, Ewald Roodenrijs and Bert Veldman, Andreas Prins. Andreas Prins said: Blog: Focus on result, starts with the business! http://tinyurl.com/363uz8k about what focus and goals really are #AoT #testing [...]