Testers, mind your business

Testers have many jobs at hand. They need to run as many as possible tests to find out useful information about the health of solution to help make decision makers take decisions. Anyone who has experience in testing knows that the real job is not to “run” tests but “design” tests. Similarly the quantity of tests that were executed doesn’t matter if they are not hitting the right target. That is why number of failing vs. passing test cases, number of new defects reported are a poor way to represent quality and hence a poor feed of information to the decision makers.

What matters most is perhaps what the test does and why it is important? In one of my previous posts, I suggested that testers become gray box testers to get some ideas on coming up with some serious tests and hence bugs. Today I want to bring the focus on the business side of the things.

Testing in a way serves a bridge between Business and Technology. You can say that this is true for the entire “engineering” team but perhaps testers are the main guys responsible for this.

TesterBridge

(Picture from http://www.sutterstock.com with edits by me)

Given that the domain you serve will vary from organization to organization and from team to team, it is tough to lay down specific guidelines so as how you can understand the domain. A software serving to help design Nuclear Plants may require it’s testers to learn about all the standards of materials, quality and health/safety. Whereas a software serving the education sector may require it’s testers to understand how brains are educated and what quality education means and what are the experiments done in this area so far.

Therefore I’ll not mention the ‘how’ part of the problem rather focus on ‘why’ it is important for testers to learn more about the domain as the “Golden Circle” suggests that ‘why’ is more important than ‘what’ and ‘how’.

  1. You talk the language of your users

Very early in my career, I was visiting a client with a team to understand the requirements of a solution that we were building for their pharmaceutical setup. Client was represented by 3-4 managers and they were throwing a lot of terms. I don’t remember the exact term of one of the reports that they wanted but one of our team members said the name of the report wrong. Manager politely corrected. When our team member made the same mistake in the conversation, the client said:

“How come you make a solution for us, when you don’t even name the things we need?”

I learned a lesson that day and always prefer to use the terminology that our users would use. That makes all the internal communication that you do as tester become more “user focused” and you know “what user wants will always be fixed”.

  1. You augment the team with “Business facing tests”

Keeping the Agile Quadrants in your mind, you know that your team specially the Programmers are writing most of the technology facing tests, so if you dedicate your efforts towards the tests that mimic the business cases that’s like a perfect combination.

  1. You know what drives what

Pieces when combined become the solution. So as you move your “vision of the tree” to the “vision of the forest”, you start gaining more understanding of why a particular piece is needed to solve a particular problem. This helps you write tests that are like end-to-end or workflow tests (the tests that achieve a particular user workflow). Often such tests results in bugs that surely increase your reputation as a tester who knows how the system works.

How much of your time as tester goes into understanding the domain? And do you list more benefits of this investment?

Tags: ,

6 responses to “Testers, mind your business”

  1. Qamar Tarar says :

    Very good Article.

    Without knowing new Domain, you cannot test properly and you cannot achieve the Quality that is needed to bring a good product to your customers. In order to know the Domain, start with why: why do you want to test in this particular Domain, then How do you want to test and at last What do you want to test.

    In order to know the Domain, you Need all Information regarding team, process, Business. You Need to talk with all stake-holders and then you can start working on a specified Problem.

    Liked by 1 person

  2. Asma says :

    Excellent article. As a tester, when i encounter a system, thoughts start ringing in my mind that “how to test it”. In order to gain completeness in testing, domain knowledge is the key element to it. But it will take time, coordination, research and analysis. If you want to achieve domain knowledge then you need to grasp as many concepts as you can, participate in events addressing on such domain and meet domain experts. You also need to understand the product that what customer will do to the application.

    Liked by 1 person

  3. Qamar Tarar says :

    @Asma:

    very good addition

    Like

    • Asma says :

      Thankyou @qamar

      Like

      • majd says :

        Thanks Asma and Qamar for adding some thoughts on the “how” part. The take-away from your comments for me is that as a tester, I need to talk more to the stakeholders and domain experts to gain knowledge of the domain.

        Like

  4. Qamar Tarar says :

    @Majid, its my pleasure. Yes as a tester you Need to talk more to the stakeholders and Domain experts and the modern way to do so is Agile Testing.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s