The Better Tester

This story is now entering the second generation of its characters, and it is time that people should know the truth:

The Past:

In the beginning, there were just line of codes. Simple, structured, looped, complex, and extremely interesting. Then the tasks for the programmer started to get complex and due to this rapidly closing window, the time crunch made the programmers to make mistakes, new kind of mistakes!

At the IDE level, these mistakes were handled on each compilation cycle, but what programmers did not know at that time, that the codes enter a different perspective when they are used at the client side.

To correct and check their own mistakes, these conventional developers needed a companion. Someone who can understand their work, someone who can see things differently and play a supportive role, they needed someone to recheck and run their codes, so eventually it can run smoothly at the client side.  

Hence came the testers. A same, but somewhat different breed of technologists who were now developing a separate layer of programs to test what programmers have already written. For this, these testers used scripting languages, small routines, and data stubs to tackle what a program was doing and tracking its data, integration with other programs, and the logic.

It actually worked brilliantly. Programmers can now have their own code tested from testers and things were starting to get in line.

That was 20 years ago.

The day of reckoning:

One fine day, someone got the idea of getting everything from the top of the desktop and compress that all in singular hand held device, what we used to known as the Cell phones.

As the world enjoyed this revolution of their brick type phones converting into touch screen devices, the developers on the other hand had frowns on their foreheads.

The BIG question at that time was not the line of codes which were used to develop the applications, but how will they cope up to the diversity of devices, the operating system, the dedicated marketing claims, and above all, the users they don’t know about.

With this started a roller coaster ride of updates, sprints, and never ending development life cycles. With this, started the inclusion of testers on a mass scale to cope up with the delivery speed and handling the clients and their UAT meetings.

It was all up and downhill from then on wards.

The Present day:

Now, things are different. We are in a realization state, as development teams understand the value of testing. Only question remains is; does the testers know how to be a better part of the team, and how to be a better tester?

For this, the best thing is to think beyond the line of codes, think beyond the testing processes, the development time lines, and keep the mind towards the user.

Applications are now driven by users. They are the makers and the breakers of the testing and development efforts. In so many words, they are the king makers.

While testing, it is now necessary for testers to design their tests as per the users. This requires an immense enrichment of context and decision making, domain expertise, and a will to think beyond development perspective. This requires critical thinking and an attitude to wear a support hat for the developers and clients.

And the job has just started.

Till then,

Ciao,

Arslan