Dear Reader,
Kick-starting myself into the world of possible readers, I find myself ready to write on what I think software testing is absolutely not about, definitely should be about and share how I experience my attempts to contribute to change. It’s time for the era of better software-testing.
As a kid I started testing on my first assignment with the TMap® and later the TMap NEXT® at my side. I wanted to learn all about the black box of software development and as a good boy, I absorbed, without a lot of questioning. Moreover, how could I think about questioning when being taught by Michiel Vroon and Rob Baarda themselves? I was genuinely impressed and learned mostly about the test design techniques and test phases.
It all made perfect sense to me: First there are requirements which get broken down into specifications. In a very good project they will even be broken down into a technical design. When this is all done, coding can start and then everything gets tested in different test levels, each of them having their test cases designed according to the documents available. When the testing phases are over, we go live... Doesn’t that sound like a V-model? (http://www.waterfall-model.com/v-model-waterfall-model/)
It’s like building a house, in fact. First you come up with a plan, the architect makes a blue print, the master builder makes a plan and the house is built in phases, starting with the foundations…
… but wait a minute… when is the house tested? After the last construction part is done? Actually while building a house, testing takes place within every development phase. For example, the foundation is verified when walls are being build. Then why do testers only test when it’s actually too late? And what if the living room didn’t really look like we hoped it to look like during construction? What if we, living in France, bought cheaper power plugs in UK, who will notice and when? … You know where I’m getting at, I suppose. Software development is not like building a house, nor it is like building a car, it’s mostly like software.
Things are often not as easy as they look like. Therefore the V-model, like any other model has disadvantages
- In the V-model requirements don’t change within the development life cycle – Unfortunately even if they don’t change, our language is still too primitive to formulate an unambiguous complete requirement that is understood in a perfectly similar way by all stakeholders and involved parties. Or in other words, let’s accept we’re human.
- Mistakes are only found when all development is already done – No requirements or any other spec is verified up until the moment that all development is done and a go for testing is given. That's too late.
Now, unless you work in the army or for the public sector, the currently most recognized documented best practices and methodologies for testing are difficult to put to actual use. That is mostly because in your project you don’t have a complete industrialized process and/or an immense budget available. The V-model doesn’t really offer the possibility to change your mind or make mistakes during the development lifecycle and requires high discipline on top of that.
I do have to recon on the other hand that it’s easy to plan a test phase 3 months in advance, hire 15 testers to write test cases. Most Project or Program Managers understand that those test cases always go straight to the recycle bin before they actually get executed. They do however like a pro-forma report with execution rates, preferably linked to the amount reopened defects of priority 1, to go to the developers and show them, having the proof in hands that their development is crap and that they are buying time.
Now I hope to all find you nodding heads, agreeing with what I’m saying, but guess what, lots of us are testing in this kind of structure that really does not make sense.
So why do lots of us work in projects that are run like this?
- I know: Because people want things that make sense, that are easy to explain.
Then why does this non-sense make sense?
- It doesn’t. What makes sense is that a V-model makes a complex world look easy and people want easy things
So what can we do make this testing (and project) world a better place?
- Find a way to test that is easy to explain and understand, does make sense and, most of all, really works.
In this blog, mostly, for now, I will describe my frustrations of testing in the European Hemisphere, my inventions and ideas to improve testing and relate with other professions in the project development landscape.
And most of all, I will try to contribute to the common sense in testing.
