Can't write code, shouldn't be testing the code either
When it comes to the software engineering then I have number of strong opinions. I wouldn’t call them radical but just different. One belief I have is that people who haven’t spent years developing software shouldn’t be testing the software either. Somehow it just doesn’t make sense and feel right - how can you tell if something is wrong if you never have gone through the pain of trying to do the right thing and therefore never understood the clear differentiation between working software and non-working one?
I’ve been referencing Edward Kit already in number of my posts. Here’s another quote (Chapter 13, page 164) from him:
There are many managers who unfortunately only see testing as a training ground for development, not a place to put their best developers. Too bad. I count myself among the managers who will not hire a person to do testing unless that person is qualified today to join the development group responsible for developing the same product that he or she would be testing.
Pretty strong words, but IMHO the correct ones. One of the basic observations in regards to this subject I made during last couple of years is that the more code you write (or have written) the better chances you have to accomplish something in software testing related positions. (Wow, I just reinvented the wheel!) Constantly reading and writing code assures that you’ll understand what this is all about. One of my recommendations to everyone has been that before testing anything at all the person should spend significant amount of time doing source code inspections and catching the first wave of bugs this way. Static source code analyzers have their limitations, buddy code reviews aren’t always as thorough as they could be (time constraints, pressure to get your own job done, natural tiredness at the end of the day), the development teams usually don't have time to spend days inspecting their code, and I feel pretty confident about arguing with anyone that the time initially spent on inspecting code gives order of magnitude more in return than just starting to hammer on the product. Catch with this is of course that it takes years of product development experience to acquire the skills of looking at the code and telling that something is wrong.
Development experience in the same application domain grows tester’s efficiency I would say again by order of magnitude. Most of the people who have gone through the entire product development cycle have learnt the hard way about how much it costs to find bugs earlier in the cycle vs. two days before shipping. Let's take a basic database application with the web interface for example. If you have done the database development yourself you know bunch of stuff about stored procedures, triggers, query optimization, indexing, transactions etc. and you can start thinking where the big problems might be. If you have done web development before then you'll know where the problems related to web-based solutions reside and so on. Yes, one can take a testing textbook and do all the classical stuff, come up with number of test cases, define equivalence classes, do a bit of performance testing, do a bit of usability testing, do a bit of security testing, do a bit of stress testing etc., but this will be IMHO just scratching the surface lightly. I would bet that in lots of root cause analysis reports when people look at why certain class of bugs hasn’t been found the answer is that nobody knew to look for them.
What am I saying here? That testing in its current form is inefficient and everyone else is wrong and I'm right? Definitely not, but I think thoughts described in this post are rather interesting subject to explore. Maybe someone could run a couple of experiments with the team consisting only of developers and divide them into two parts: coders and verifiers. One could make them periodically change roles and mix all this with a shot of Extreme Programming to look trendier and compare this to traditional software development organization developing the project with similar qualities. Or something like this.
P. S. Since I stopped drinking coffee, I have been writing these strange and provoking posts on software testing and quality assurance. I don’t know what will happen if I’ll also start having breakfast regularly ;-)