Do We Already Know Everything There Is to Know About Software Testing?

The motto came to my mind recently when a colleague told me she had come across some exciting new concepts that would boost our productivity to new heights. 

The colleague had read about the agile testing quadrant and shift left strategy and shared the newly discovered knowledge with me over a coffee break. She ranted away about newly discovered ideas of ”testing starts earlier in the pipeline.” As much as I like Larry David, I did not want to curb her enthusiasm as she went on about how we should choose the right testing approach for each unique situation, even though the idea is as old as the Cynefin framework developed back in 1999.

Nothing New Under the Sun – Should We Stop Reading?

One of my ”Nihil novi sub sole” moments was after Steve McConnell’s landmark book ”Software Project Survival Guide” had been around for a few years and finally landed on my desk. The book presented a well-laid-down approach to software development that works pretty well most of the time for most projects. The book blew my mind away and I thought the approach was indeed something truly novel in existence. 

I was soon instructed to take it down a notch by a more senior developer who had read McConnell’s earlier Code Complete and Rapid Development and was aware of extreme programming, software prototyping, and difficulties of requirements gathering. To him, the book, albeit brilliant, was just a synthesis of existing ideas and vast industry experience and nothing truly original. 

So, we all start from our professional reading somewhere, and our personal experience and history are always limited. For example, I began after Code Complete and Rapid Development were published but before object orientation became mainstream. My enthusiastic colleague seems to have started her professional reading from Agile Testing Quadrants. 

We keep reading to stay professionally current but sometimes I wonder how much we gain from reading yet another book or hearing about new methods. And if we genuinely believed that everything has already been said, could we even stop reading? That would sound a bit too extreme, but the big question applied to the field of software testing remains: do we already know everything there is to know about software testing? Here’s one view of it. 

Agile Manifesto Could Have Unchained Testing

The Agile Manifesto was a huge step for developers, allowing them to interact and communicate more freely as individuals and not be overly constrained by processes and tools. Customer collaboration could now be based on working software instead of bureaucratic contract negotiations, and changing requirements were even welcomed late in the project. 

The principles behind the Agile Manifesto should have equally freed us testers to participate in the most efficient manner possible. But I believe we are not there yet and still face real difficulties getting there. For some reason, doubtful attitudes toward testing still exist and hinder progress. 

Instead of facing those hard problems head-on, we might be tempted to think that yet another method or technique can somehow solve what we as individuals have not been able to. So, we keep looking at new methods.

(On a side note, my testing colleague wrote a piece on the importance of testing in software development, which gives a good view of why these doubtful attitudes can hurt the business).

One Agile Manifesto principle states, ”the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” We, therefore, need to work on our communication skills and somehow break the barriers between the developers and testers if and when they exist. 

Courage and Communication – The Ultimate Method?

There are always plenty of cultural differences, emotional disconnects, and the use of jargon to hinder communication within a team. And we are sometimes still constrained by above-mentioned management attitudes towards testing. I was once in a Scrum project where testers were allowed to attend dailies but only as observers so they wouldn’t interfere with or distract the developers. To ”boost our productivity to new heights” would thus often mean breaking real barriers of inadequate communication and collaboration.

Courage is one effective software testing method. It takes guts to say or admit that you cannot contribute to the software quality and performance because you are not fully given the possibility to understand the user’s needs. Maybe the business analyst and the developers had meetings without you and did not write much on paper for you to read. But saying that aloud has already improved software quality because the problem is no longer hidden and must be dealt with. Fail today rather than later, you see.

So, what about the Agile testing quadrant and Shift left strategy and others – should we keep reading about them? Yes, we definitely should. The more you read, the more well-defined discipline you think testing is, and that will affect how you practice it. However, as the Agile Manifesto and the Scrum values suggest, your communication and collaboration skills and courage could be among the most effective software testing methods you have.

Avainsanat: