During more than 20 years of pursuing a software testing career I’ve seen hundreds of project-based decisions that defied logic or basic reasoning. It is not unusual to be asked to reduce the amount of Testing to be performed due to time and/or budget constraints (even though it was seen as not being enough verification and validation in the first place). It is not unusual to be asked to prioritise specific tests, so that the “safer” bits of the solution give an overall impression that progress is going better than expected. It is not unusual to be asked to attend a meeting with customers and/or business representatives, but to withhold or generalise specific issues. It is not unusual to feel compromised and/or alienated by any or all of these scenarios. But software testers are not alone in the universe with these predicaments.
Room Meat is a concept I first came across during the movie In the Loop. In the Loop was a spin off from one of my fave TV shows of all time – The Thick of It. For the uninitiated, The Thick of It is a British comedy series that’s a bit like Yes, Minister on steroids and with the added bonus that there is absolutely zero political correctness on display during any episode. Which is even more ironic when you consider it’s a program ostensibly about politics. The main reason I love The Thick of It is the irreverence and complete lack of logic – hence my rationale in likening it to my Software Testing experiences.
In every episode of The Thick of It, policies evolve based upon the latest accepted ideology (instead of being developed/utilised strategically). Priorities change continuously, because every day brings a new (usually perceived) disaster. Everyone confuses a risk with an issue (and vice verse). Standards and procedures are never adhered to because they are seen to hamper real progress…. Sound familiar? Nudge, nudge, wink, wink, say no more.
Room Meat is a reference to those in the room that are there to make up the numbers, possibly to provide comfort to others of a nervous disposition. In my experience, on far too many occasions, the Test Team are regularly treated as Room Meat, so that the Project Manager can tick a box. The PM doesn’t want a Test Team that asks difficult questions or wants to make a difference, the PM wants his/her project delivered with the least possible fuss from the cheap seats. This usually results in consigning the Test Team to futile tasks like documenting and counting test cases (and their associated expected outcomes), finding an acceptable number of software bugs and producing daily cover my (that’s the PM’s) arse reports.
Occasionally, an enlightened PM is encountered and the Test Team is engaged early enough in the SDLC to engage in Risk Assessments and/or SWAT Analyses and possibly providing feedback on feasibility and usability. Occasionally, a Test Manager may be asked to present a worst case scenario to the Steering Committee, in order that they may make an informed decision. Occasionally, critical thinking breaks through where follow-my-lead policies once ruled. But these are mere aberrations in most quarters of my universe.
Unfortunately, in my experience, the Test Team is (more often than not) undervalued and under-utilised. Software Testing is an incredibly diverse and complex discipline, which explains why after 20+ years of being a practitioner I have only scratched the surface of the majority of techniques and technologies. I have spent hundreds of days on self-development and networking with some of the biggest Testing brains on the planet, but I am still a small cog in the expanding world of software development. I have been unpopular on projects just because I called out the real risks and issues. I have been called “Eeyore” for walking around with my own cloud hanging over me!! I have not, however, ever compromised my ethics or morals and have never shirked my responsibility in providing essentially quantitative feedback.
From my perspective, there is only one situation worse than being Room Meat and that is being Dead Meat – the poor saps getting the finger pointed at them because “Testing” didn’t find Bug XYZ…
Dateline: Melbourne, Tuesday November 11, 2014