This one is from years ago. I don’t know if that department still works the same way.
I, together with 15 of my colleagues, was outsourced to a big company to do the testing for an existing software product they were updating. The department I got to work in had procedures that we had to follow. One of the biggest problems I had with their procedures was the one where they split up the “test case creation” and the “test case execution”.
Test case creation was the domain of the “experienced testers & coordinators”. Given that I had about 5 years of testing experience then, they considered me as one of the experienced one’s. And so I was “allowed” to do that part of the process.
This part was done before development, while the analysts were writing the requirement documentation, so that development could start. This meant meetings with all kinds of people (technical analysts, business people, a lot of managers), and my job was to distill test cases from these meetings and that documentation, so that when development was done, then the tester could verify & validate the end result. Sounds great, in theory, but I was already experienced enough in software testing & development to know that this would not match the reality.
So I “rebelled”, by constantly asking questions about how we would manage the changes to the requirements that I knew would be coming when development started in a few months. When my “test manager” asked me to be “less rebellious” and “just trust the procedures”, I requested to have him discuss me transferring to another assignment (not possible at that time), or at least to transfer me to do the real testing (which they considered a “downgrade”, so they did not understand why I would want that). I got the “downgrade”. Which led me to become the “most senior” of the “manual testers”.
When I got there, I got to see the result of those “test cases” created months prior by those “more experienced” testers/test coordinators. It was somewhat how I expected it to be:
- Test cases that were stale, and did not match the reality of what was delivered
- Testers who were blamed by the developers for not understanding the changes to the requirements that had been necessary, but were of course not documented (because that would have meant the analysts & test coordinators that worked on it 6 months ago needed to be in the loop again, and development would be delayed because of that)
- Testers that were blamed by the test coordinators for not forcing the developers to update the documentation, so that the “proper change procedures could be followed”
- Software that got released with lots of issues, because bugs that were found “outside of the scripts” were not considered bugs, but feature requests, and would have to be solved by a future release (in half a year or so)
Of course, management blamed the lowest rung, the testers, for everything that went wrong. It was never the (bullshit) procedures that were wrong, because they were based on a well known, popular, testing methodology. If all involved “would just followed those procedures it would improve the quality”, because that is what that “test management approach” claimed, according to them.
That assignment was the most bullshit-y thing I had to do in my testing career. I still have an allergic reaction when people use the words “test cases” or “test scripts”, even when they have valid reasons to use those words, because of that experience.
(update: copy pasted this rant in the Google Doc)