Ah yes, testers and me. We go back a long, long time. It’s much like love, really. We had our high a few years ago, when I wrote an article series for an IT magazine. In this series I used practical observations and some basic anthropology to describe the psychological mind set of various practitioners in IT.

Experiencing many different IT organizations across the world, I had noticed that there is a strong correlation between the personality of an individual and his or her role in the IT profession.

It is for example quite easy to distinguish between Java and .Net programmers. The first category has strong analytical tendencies, typically hates practical solutions and prefers a painfully slow process of thinking and rethinking before producing anything (if you’re lucky). Their ADHD brothers and sisters in the Microsoft camp on the other hand, are particularly interested in short-term results. This is reflected in flimsy prototypes, a trial-and-error style of developing and an aversion to anything that tends towards structure or documentation.

As you by now start to realize, the article series generalized just a tiny, little bit.

Some truths however were uncovered that turned out to be difficult to deny. About the megalomania of some ‘enterprise architects’ for example that won’t mind a bit to invent their own Oath of Hippocrates to emphasize the presumed importance of their activities. Or about the self-assertion of project managers who all – almost without exception – have suffered in their childhood from a more successful brother, a particularly critical father or both.

I must admit that within the series, testers were easy targets. From my own experience, I had learned to know testers as rigid, over-serious people. Never a smile, even if errors were found. On the contrary: instead of being happy about detecting bugs, testers would tread the instigators (quite often .Net programmers, obviously) with cold disdain. Clearly, this did not add to the popularity of testers, who often could be found in clusters in the company cantina, isolated from all other people.

But that was then. Much has changed in the meantime. The role of testing in the entire applications lifecycle is much better understood nowadays. It is part of the earliest stages – often right at the core of requirements management –so that developers are not unpleasantly surprised at the end of a project by suddenly appearing wall of testing. Also, testers nowadays immerse themselves much better in the context of a project, which has – step by step – adjusted their initial perspective on the world (“testing is the one and only purpose in life”).

And that context is changing quickly, putting extra demands on testers. A powerful wave of ‘business technology’ solutions is enabling an entirely new generation of applications that are developed quicker, have a shorter lifecycle and typically are implemented in close alignment with the business side of the organization. Often, easy-to-use tools and platforms are applied (think BPM and business rules suites, model-driven development, cloud services, mobile and social platforms, open data and app markets, mash-up tools, self-service BI) that are much better understood by business people as well. It creates an ‘outside-in’ perspective, in which many of the newer innovative solutions are developed far outside the central IT department, or even outside the organization.

It means requirements management is in for some changes – if there is still any requirements management left – with an obvious impact on testing as well. Agile thinking and acting will be the default. And more than ever, both insight in the needs of the business and the power of the next generation of tools will determine success. It will make the role of the tester even more situational. One day, you may be testing a robust, mission-critical ‘Train’ application (check our introduction of the concept in this white paper) that is built for multiple decades of uninterrupted use. Predictability and controllability will be the virtues. The other day, you may be handling an opportunistic ‘Scooter’ application and it may all be about speed, agility and the willingness to accept a certain level of risk.

So in the world of 2012 in which mobile, social and the cloud impose a new rhythm on top of the established, core applications landscape, schizophrenia is not a prerequisite to be a good tester. It would certainly help, though.