This year marks 10 years in testing for me. I’ve experienced a lot of things in this decade, including a lot of what doesn’t really work well in testing. I want to share these things with you. I’ve condensed them in small blog posts for your convenience. This is just what I have experienced, it will by no means be an absolute truth; your mileage may vary.
Let’s get started!
Lesson 1 is: testing by itself doesn’t do shit.
It often baffles me when people say “the project is done, it just needs to be tested” as if testing will not yield any useful information that needs to be acted upon. The type of information that testing can yield is (but not limited to): issues, bugs, problems, surprises.
In my 10 years in testing I have never seen the result: “oh everything is fine, carry on”.
What I have seen is the results of testing being ignored, down-played, put on the bottom of the backlog to die a slow death or just plain denied (yay, politics at work!).
For some reason, some managers just want to do the “act of testing”, but don’t realise its true place in software development. I can “perform” this kind of testing, but if the issues I find will be ignored I lose motivation quickly. In that case, testing is just a ritual with little meaning. I want to do proper testing, in a tight feedback loop with developers, and not just because some project manager’s Gantt chart says so.
Testing by itself doesn’t do shit, it doesn’t fix the problems. It just finds information. After (and during) the testing, we need to act on what we’ve found. We need to discuss the issues, triage them, find out what to do with them and then we need to refactor the code and/or change our requirements! This loop never stops.
All this requires that testers work together with other people in the software development team: designers, product owners and most importantly: developers.
I have found my greatest joy in testing while working closely with developers, testing together, fixing things together.
I have hated testing when I was working in a testing team, separate of the developers, always fighting the uphill battle of being taken seriously and getting the issues we found being taken seriously.
I hate it when testing doesn’t do shit. It doesn’t have to be that way.
4 thoughts on “10 Years in Testing, 10 lessons – Lesson 1”
Thank you for the great post. I’d like to hear more. Especially on the battle of beeing taken seriously
When I was in a test team we always had to go OUT of the team to get the issues we found solved, by a dev team or first discussed by a management team. We had to toss them over a wall, so to say.
The people on the other side of that wall had all the reasons to NOT get their normal workflow disrupted so they would do everything they could to get minimal amount of work from us testers.
Because for managers it would endanger their deadline. And for devs, I guess it was just annoying to be confronted with faults in your own work. A seperate test team is like having a police force and the devs are the criminals, and the managers the judges.
When you’re all in the same team, this whole game can be skipped. When I work together with devs and we find issues, it’s not so laden with meaning, just something we fix ASAP and then move on.
I have always enjoyed working close with developers. Never understood why some people want to separate us testers from collaborating with other professions in the project.