How can I as tester deliver an added value for my organization? Of course I check that the drawn up requirements and specifications are correctly processed in the software and that the software works correct. But more and more around me I see that this checking is rehabilitated. First there was the idea to automate the test execution software, then to outsource the work India when the automation didn’t hold up to its expectations. Then the ‘financial crisis’ arrived. That meant that automation of test executions could show us again that it seemed to work and it did. Lately you hear more about Model-Based Testing, as I wrote in this post. Model-Based Testing takes over part of the test specification to be automated. What should I do? Where is my added value as a tester? Of course Model-Based Testing shifts the activities of a tester and the automation ensures that you can test more, which means that specific parts can still be tested by a tester (with more attention to this). But really, where is my added value?

That added value is what testing really is about. Testing is a combination of checking, exploring and accepting. So what are checking, exploring and accepting? See The W-model and Check, Explore and Accept for more details on this.

Is checking an added value?
When I look at the trends and innovations about testing around me, I see that checking is no added value for a tester. This work can be performed by inexperienced testers, be outsourced and even done by a computer. Because we only check whether the expected results match the actual results. In specifying on what the results should be when checking lies perhaps an added value, but an important part of the checking, functional checking, can de done with model-based testing (at least part of it). Naturally I as a tester have a direct involvement in creating the model. I can even add some test cases into the model to process any issues I think of. As a test designer/architect I can even create the whole test model. Model-Based Testing only covers the functional part of a system. Other quality attributes should also be checked. A tester should create the test cases for these attributes. And also evaluations are an important part of checking. I think I have stated quite a few times how important evaluations are. When evaluating there is a clear added value of testers. Because testers look (very) critical at documentation. I as a tester can evaluate the documents in a good manner, but the effort of evaluations compared to creating test cases is however much smaller.

The added value of a tester in checking is:

• * create models for model-based testing
• * evaluate documents
• * create non-functional test cases

Can a tester accept?
Can I as a tester accept? No! As a tester I’m usually not the future user of a product. So I cannot fully assess whether the solution is right for the user (in a UAT). This can only de done by the user. Accepting can also be seen as learning to work with the software and integrate it into business, but also getting acquainted with the System under Test (SuT). A testing coordinator can guide the accepting phase, but the real acceptance is done the users. The task of a tester is mainly a warning function; the user (client) self provides the acceptance. However by good cooperation (especially in agile projects) a tester can give a “binding” advice.

The added value of a tester in accepting is:

• * help coordinate the acceptance of the user
• * cooperate with other parties in an Agile project

Is exploring the added value for testers?
OK then, exploring. Exploring is something I as a tester can I do! I am an experienced tester and therefore have the test knowledge to do so. I can also ask the correct questions to get more information about the business and system. And also I don’t take first response as the best, as a result I interview people about their knowledge. A checking tester will not look any further then the written down information. And I also have enough in depth knowledge about the business that I’m testing so that I know where to expect problems. As a tester I should therefore look for in depth information about the processes of my client and from there go testing. I can do this with test cases, but also through (a more creative mindset with) exploratory testing. Using this test approach I can show where the system needs to be adjusted, because the system doesn’t resolve the problem of the customer. I use the specifications or requirements as a starting point and then build out the tests based on my knowledge of business processes and my testing experience. As a tester I can thus provide an added value to my client when I explore the software! To test better I need as much knowledge as possible of a client and its processes. Testers should be closer to the clients processes (business) rather than the technology. And of course specialists are needed that know more about certain technology (like security en usability experts). Besides our basic knowledge of testing, we need to have more business knowledge!

The added value of a tester in exploring is:

• * create and executes test cases from other information than that is documented
• * help the business with testing the business processes
• * find those errors not derived from documentation
• * have technology help in expert work.

1. Robin Says:
   November 24th, 2009 at 22:25

   What I see as perhaps the greatest added value of a tester is the tendency/habit to challenge assumptions and the drive to get rid of uncertainty where possible (since uncertainty leads to assumptions: “We don’t know exactly what the customer wants, so we’ll just assume …”).

   This holds true for all types of testing; if a design document says X, why is that? What is it based on? Why is something modeled the way it is? Is that accurate, does it represent the actual way of working? Are the people you invite for a UAT indeed a good representation of the future users?

   This, for me, is much more important than actual test execution…if the team realizes what needs to be build and why, odds are slim that large issues are found in actual test execution.

2. Ewald Roodenrijs Says:
   November 25th, 2009 at 07:44

   Robin,

   I agree with you. Testers have that natural ‘critism’ to help get rid of those assumptions.

   Thanks for your comment.

   -Ewald