Testimonies from other people about how bullshit has affected their job in software development. Anonymously told to protect their privacy.
Our management said that the system is far too complex to be ever automated, so we did repetitive testing all the time (exactly the kind of type of testing that should be automated). Another thing was that it was expected of us to check for typos and grammar errors made by the content making team, which to me was if we were doing a job somebody else was paid for. We didn’t have a test environment for a long time since the manager didn’t want to “bother” the seniors developers with it. We also frequently had to do reports for PMs that they were supposed to be doing and re-test stuff that had no official fix just because some developer told the manager that it could be working now – which was a complete waste of time!
Tester
Our tester in the team wrote a lot of tests, in excel. To communicate the test data to the developers to put into the integration tests, he copy/pasted the test cases into the functional requirements documents, a word document. The wore document grew from 20 to 300 pages, containing all sorts of copy paste errors. With no versioning available, every test had to be manually checked. The decimal and date formatting was lost between the conversion from excel to word, leading to another week long search for rounding errors in the test data.
Lead Developer
I had to write emails together with the Chief Testmanager as only he was allowed to talk to customers. SPOC FTW!
Test Manager
I was working in a fully DevOps team, working to maintain and migrate a client’s website (1 million+ users) to the cloud. I was involved in all parts. I helped refine requirements, I manually tested, created automation from scratch, built test environments as well as complex data management for those environments. I paired with developers as well as completed some (fairly easy) Dev tickets solo. I helped create our production cloud architecture and our test and deployment pipelines. I worked support and fixed live issues when they arose. After ~6 months, the lead in charge of the project sat me down and told me they didn’t need me on the team as testers make the developers lazy. Not one word of thanks for anything else.
Sole Tester
You know, that one time at test camp, it was so shitty. I was a junior tester in a huge project, at a time when the iSTQB syllabus under “Exploratory Testing” said: “Don’t do that, never, ever!” We had to write test cases before the release started, then they were signed off by dev and customer. During the release we only had to execute everything that specified. The ox poo: When you found a bug, by doing something with the system, that was not specified explicitly in the test case, you were not allowed to create the bug ticket for this. Only bugs that were found by predefined and signed off test cases were allowed. The fields test case and test step were mandatory to be filled, and were checked by defect management before the bug was assigned to dev.
Tester
I had to retest two bug tickets for another team, because reasons. The issues were clearly analyzed, the stack traces told everything you needed to know. One look into the commit showed: yep, that’s fixed. One even had a unit test written to fix the issue and verify it. The teams test manager, the only test manager near and far in that context, insisted that I test both tickets and check some corner cases, that weren’t even corner cases for the actual issue. You know, just because, test has to do something.
Test Automation Architect
Working in a customer facing team, with lots of experienced people, some of them working together closely with the customer. For release deliveries there has to be a QA approval given. That QA approval is purely based on the result of the nightly pipeline run and if all Jira tickets are closed. Literally everyone was checking the pipeline in the morning of the release delivery. But we had to wait with every further pipeline step until any of the QAs gave the official approval to deliver. The approval was never not given, btw. But it partially took until early afternoon to get the mail and continue with the pipeline. Things that could have been done already.
Test Engineer
The org was structured in a way, that QA and dev were as far apart in the hierarchy as possible. My bosses boss was reporting some C-level, and the dev leads bosses boss was reporting to another C-level. Yet they expected from my role to sign off releases and taking the responsibility for production deployments. There was no chance to take any influence on the dev team, they could do whatever they wanted. There was also a long maintained “blame the QA” culture installed. Bugs found in production were always the QA’s fault for not finding it beforehand. And measurements to be taken for that not happening again always had to be made on QA side.
QA Lead
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.
Test Coordinator
I was asked to review JMeter load tests and run the tests on test env. The result showed that the setup can’t handle more than 50 users. When I asked what was the expected load, the reply was “hundreds. We will run a TV ad in a few days”. Telling the CTO about the situation I got in a long email fight where I was told that “failure is not an option”… like I was somehow able to make crappy php app running on a shitty server run more smoothly in a few days. In the end after a few hours (!!!) of emailing the CTO backed off and I felt dread of being a QA
Tester
Dev team reporting Dev Complete to Management, and inviting test to come in and do work in the system, but not allowing test to report tickets in Jira. Why, because things weren’t quite complete and so it would confuse the developers if tickets came in.
Test Lead
The company had never done software testing on their desktop application. They had been acquired by a larger company. The larger company asked them about software testing. They lied and said they didn’t have details but of course they did software testing. They hired me to do software testing on an application that had years of development and no documentation on how it worked. After a week of testing and documenting it, I still hadn’t tested everything. I thought it would be best if I automated all the testing. This was over 22 years ago and automation wasn’t a thing yet. I’d been a software developer for 17 years. So automating the application made sense to me. After a few weeks of automating the application it went from a few days of solid manual testing down to, literally, less than 10 minutes of automation on a desktop application. The site manager (former owner of the small company) asked me how things were going. I told him that I had automated everything and could test the application in a 10 minutes. He came over to the test lab I had setup and watched the automation. Things flashed across the screen so fast you couldn’t really see what it was doing. He told me that the executives from the large office where coming to visit and he wanted to show them the automated testing. But when he saw how fast it was and that it only took 10 minutes, he told me I had to slow it down and put a while loop that went forever around it. He didn’t think it was very impressive how fast it ran.
Tester (first job!)