Tester 3.0

Heyhey,

Just recently my colleagues presented this idea about Tester 2.0. Tapani Aaltio even gave an interview about the subject in EuroStar TV. Go Tapsa!

In short Tester 2.0 integrates itself more deeply into the SDLC, understands it better and creates more value this way while Tester 1.0 just does it's job, doesn't collaborate, pretty much stays put and tests. On this level I'm all for Tester 2.0, but what worries me the most is that in the dark side of all this lies the will to make us all developers...

So let's talk about Tester 3.0.

To develop Tester 3.0, we must go deeper into the ideal of Tester 2.0. As said, Tester 2.0 collaborates, cooperates, participates on the whole lenght of SDLC and considers user and stakeholder needs. Tester 2.0 is involved from day one and is an active and proactive member since. It's quite hard to feel bad about this. But at the same time development collaboration is emphasized above everything else. Tester 2.0 should sit among developers, start to understand development more deeply, perhaps read/write some code, even think like developer.

The leading trend in software testing industry is that tester should know how to code. Many companies won't even hire you if you don't know how to code. People like Alberto Savoia give slap-in-the-face presentations about the death of testing, etc. All in all, the message is that if you don't know how to code as a tester, your future is quite grim.

The Holy Trinity

But let's not throw in the towel yet. Let's concentrate on the building blocks of quality for a moment; Development, Verification AND Testing. This is how I see it; Development makes something, Verification makes sure that this something is done right and Testing sees IF this something is done right. Remember what James Bach stated?

“Testing is a quest within a vast, complex, changing space. We seek bugs. It is not the process of demonstrating that the product CAN work, but exploring if it WILL.”

In Verification & Validation testing is incorporated in both and is considered to prove something, which is just wrong. I my previous posts I've ranted about the complex nature of testing and the impossibility to prove anything via it, so I won't repeat myself here. Bottom line; When talking about V&V, don't talk about testing.

As I deframed V&V, my definition of verification might need some explaining... For me verification is all that tries to prove that the something development has done, has been done right. For example when training a boxer, development teaches it to hit, dodge, move, etc. while verification looks when it hits, dodges, moves, etc. and gives feedback if something is not done as it should be. Testing is eventually the training opponent that might do anything to see if it could survive against a real opponent. Coach? Quality management.

Brace yourself; Running scripted test cases, regression testing, applying technical testing like unit testing, test automation (with certain exceptions), etc. are verification to me. You have to apply certain kind of thinking when doing that, namely development-like thinking. You try to achieve something, make something ready and sell it. You have a goal and you pursue it relentlessly. That is something a tester should not do. Of course tester has deadlines and goals like the rest of us, but the ultimate goal for tester is to explore the software and see if it works (Bach statement recap). Developer goes for the goal and reports about something ready. Tester enjoys the ride and reports about the journey to the goal.

The goal and the growth to it. Think about it.

Numerous times I have been a tester or test manager at business side and even more I've stood at the entry gate where vendors try to deliver software or system to customer. The main thing that separates good deliveries from the bad are vendors' ability to report about their doing, their growth to the moment they are delivering something. E.g. Scrum teams' success culminates on their performance at the demo, but so very often as the software or system lives through that brief moment, it is steaming pile of shit when put to wild environment with other systems. And why? Lack of quality culture and because even though they had people titled as testers, no one thought like a tester. No one was interested in making a growth story which could reveal so much to those who are accepting the delivery. When I want to know about quality I don't want to hear the good news; I want to hear the bad news that have grown into good, about challenges and how they were beaten.

Tester 2.0 thinks like a developer. Tester 3.0 thinks like a tester.

A swing

Ok, the most important audience for testers' reporting is indeed development as pretty much all defect reports are assigned from testing to development. But this is unfortunately quite one-dimensional approach. Even though quite some time ago written (1984 to be exact), An Information System Manifesto's message echoes still correctly; 56% of errors as based on requirements as only 7% on code. I've handled thousands of defect or other feedback reports over the years and this ratio is pretty much dead-on. So why spend all the time with developers and trying to find problems and reveal risks on the same level of thinking as they do? How about other stakeholders? How about domain experts and users who stand for the requirements? Why not spend more time with them and try to understand what should be done instead of what has been done?

Tester 2.0 thinks like a developer. Tester 3.0 thinks like a tester.

Someone (was it James Whittaker?) once said that developers are just engineers lost in implementation. Testers thinking like developers might fall into that very same trap. Development can be insanely difficult task and by all means should be supported by testing, but without risking the thought process of a tester or relationship to other, very likely more important stakeholders. Evenly divided cooperation is the key, not just sitting with those who's handywork you're not only to support, but to question too.

The main role of a software tester is to test software, but that's pretty much the definition of Tester 1.0. Tester 2.0 is something more, but this strong direction to development is dangerous as I tried to point out in this post. Tester 3.0 is still only one version more on the road to Tester N; It's contribution to this path is more refined collaboration with stakeholders and understanding of, not only the whole SDLC, but everything affecting it. While development and it's verification gain influence from computer sciences, testing finds flaws in it via psychology, anthropology, even philosophy if you will. The thinking process is different and should be nourished as such. Only by being different testing can truly benefit development.

Deep huh? Well, that's Tester 3.0. ;)

Our quote today defines the very essence of this blog post:

“Problems cannot be solved by the same level of thinking that created them.” -Albert Einstein

Yours truly,

Sami "Tester 2.9" Söderblom