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)