Looking for your story on "Bullshitization in Software Testing"

Archive
1

I’m creating a presentation around Bullshitization in Software Testing. I have a couple of personal stories to tell, but I’m looking for other people’s experiences too. Have you ever had to do stuff that was bullshit? Or have you observed such situations?

You can fill in the form anonymously and I won’t share or use your story without your consent. So you can also use the form (or this post) to rant, if you so wish.

The presentation will be based on the book “Bullshit Jobs”, which I highly recommend you to read!

8 Likes
2

Bullshitization, I have not heard this term before, it sounds beautiful! :cowboy_hat_face:

3

I made it up and to quote Thor (Avengers - Infinity War) after Drax said “that’s a made up word”: “all words are made up”.

3 Likes
4

It appears that you are looking for bullshit jobs in testing. I have examples.

1 - Useless test manager/lead.
You can use this in your presentation.

See the last paragraph here or below.

I have also seen a test lead who did not really do any real work. They don’t have much knowledge of the product or the tools, and don’t really contribute in terms of code, reviews, strategy, testing labor etc. The rest of us could easily perform whatever clerical work they do such as pulling reports and sharing them etc. Moreover, this person was not exactly bright or creative when it came to testing. This is the kind of dead weight you don’t want on your team. You’ll usually find such people in big companies which have a monopoly of sorts, such as big banks, telecom companies, cable or internet companies, giant & decaying e-commerce companies etc.

2 - KT through BS work.
Please do not use this in your presentation.

I lost my job early in the pandemic and was without a job for several months. After that, I was only two weeks old at a company where there was a lot of staff turnover. Three people in my team announced their departure a few days after I joined. We got emails from incoming and outgoing people quite often.

The company has a reputation for giving very little KT and expecting people to ramp up in a week or two.
I was expected to learn how one of the company’s product works. How? They wanted met to go through all the features mostly on my own and document which pages/screens had 2 or 3 specified UI elements, all in 2 weeks. Most of the UI specs were either outdated or scattered across multiple documents i.e. no reliable source of truth. The test case management tool was littered with small and useless tests for simple buttons and such. I was not familiar with the (complex) product and its frontend and backend. I had not been given the time to even explore the product. Exploring with enough time was ok, but the documentation part was a BS job for me. That’s a dumb and useless way to learn how a product works.

PS - Check out this corporate BS generator. Become a manager and use its BS phrases to sound intelligent. Corporate B.S. Generator

3 Likes
5

Thank you Dave!

I have also seen such a useless test lead. To them being test lead was escaping being a tester and they would fill their time with creating powerpoint presentations for management!

6

Ha, looking forward to the presentation. I watched DG (RIP)'s great overview of the book and so much of software development and especially where QA has been pushed/led/dragged immediately leapt to mind.

I have a fair number of concrete examples but I feel that it’s more the background context that makes it a bullshit job rather than the actual task. I am happy for QA to be taking on an investigation role and clarifying actual behavior (part of our job of informing on risks), but the way in which Product Managers in particular “request” (aka: demand) help makes it turn into a bullshit job in that it’s flunky work (i.e. it’s framed as “I don’t have time to do this, let’s just get QA to do this.”). Example being that a PM was tasked with assessing whether or not a solution to a low image resolution complaint would have other negative impacts. But I was pinged out of the blue and told to basically “see if better image quality would affect load time” on a badly set up test environment. Being tapped as basically a data deriver and compiler “so that I can make a decision on this” rather than bringing me in earlier, to me, turned what could have been a constructive exploration mission into a BS flunky job. Kind of a combo box ticker + flunky.

As we are professional skeptics and are good at thinking, I think a lot of Bullshit Orgs bring QA in either to tick a box (“see we have quality”) or to have a scapegoat (“make my decisions for me.”).

3 Likes
7

Very on point. You could probably create a good talk around this as well! :slight_smile:

Your example is very good too, a situation any tester who takes their work seriously would find frustrating. We are not your damned duct-tape, Product Manager!

1 Like
8

@maaike.brinkhof - I just realized you might find plenty of these stories on Glassdoor & Blind. Of course, the authors could be highly biased, but its worth checking out for an occasional chuckle.

@faintly.macabre - Nice example! It reminded me of a similar job I was given by PMs. That is why I hope I can become “exceptional” in my job, so that I don’t have to deal with BS less often.

Sorry, I could not resist sharing this with you. QA is the bottom most bird.

Imgur

PS - Excuse the offensive word in the image.

2 Likes
9

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)

6 Likes
10

And you can guarantee that if all concerned had followed the “proper procedures”, the whole development and rollout process would have taken even longer, there would still have been a high number of bugs, and the testers at the bottom of the pile would still get all the blame.

2 Likes
11

@sarah.teugels

Oh man that sounds hauntingly familiar and painful. My favourite is when you are thrown something to test, given a haphazard product brief for context (all in all, it’s fine, you just dig around and find the context yourself) but then every time you stray from the path “oh that’s out of scope, that’s out of scope, no don’t worry about that.”

Narrator’s voice: it was not out of scope to the VP of Product

4 Likes
12

Wow Sarah, this is a quintessential BULLSHIT story, deserving of all caps.

How long did you have to stay in this assignment?

13

I stayed there for 6 months total: almost 2 months in the “test coordinator” role, and the rest as “tester”. I was lucky that another test manager requested me specifically for another project.

1 Like
14

I have a few stories on this but the one that jumps out to me is one from a couple of years ago.

I worked in an org which didn’t value testing atall, it was seen as an expense and a regulatory check box rather than providing value. I guess the problem was, there was actually a team (a large team of 50+) of testers who were actually really skilled but they were boxed into only running 1000s of manual tests at the very end of projects without any visibility of the projects before dev had finished. On my first day I simply asked a PM if we could help review requirements to give us more insight before code was written and I got the push back “we haven’t got that kind of funds for testing, we can only afford you getting involved when development have finished”. Even though the testers were all perm employees…

Wasn’t helped by the head of dept, only really worrying about what made them look good and taking any piece of innovation from the team as their own ideas and presenting them at conferences.

In the end I did help transform the culture somewhat by being that annoying voice of “don’t forget about quality!” but it was hard work and draining mentally so I needed to get out

1 Like
15

I can tell you already that the main theme in the bullshit stories that people have sent in so far is quite infuriating: testing is used as the dumping ground of IT. Got problems? Blame testing! Don’t want to know the truth? Have testing go through rituals instead of real testing to pretend all is fine.

It truly is infuriating.

3 Likes
16

I’m surprised I haven’t seen the every popular “You don’t need to test that.” I call Bullshit on that one a lot. I recall one time where a Vice-President had a pet project to improve the Teradata queries for our Teradata users. He limited the scope of testing and I refused. The Project Manager asked why and I said I’d had 3 previous Teradata projects and not one didn’t have a critical bug. I got approval to test my way and found one critical bug, and five high priority bugs, in the areas I was supposed to skip over. The people making the code changes didn’t know the system and had no idea of the validation rules and behavior they were working in. I also found them the original documentation on the rules with the source code so the in-the-dark developers could fix it fast.

3 Likes
17

I’ve been asked to test a feature in order to determine what development work had or had not been done on that feature. There were no design documents, change requests, acceptance criteria…nothing! Some development work was started around a year prior to the request but the plug was pulled and management had no idea what had been completed and what was outstanding so they wanted me to use exploratory testing to find out but I had no idea what the system behaviour would look like. So I’d perform an action, see if anything happened but then had no idea if that meant something hadn’t been developed or I simply wasn’t performing the right action to start with or if in fact nothing was meant to happen.

1 Like
18

This is an interesting one!

In general we see “bullshit work” as work that shouldn’t be done because it’s unnecessary, but the inverse can certainly be true for testing: we can be asked to NOT do proper work to uphold the fake reality that everyting is fine. That’s certainly bullshit

19

And how did this situation finish? What was done with your findings and questions?

20

In the end, nothing. The client that requested the feature decided to pull the plug. During my investigation I just ended up asking questions one after another to the development team that worked on it so actually it would have made better use of time for the dev team to check the code and commits they had made against the Jira’s to determine what I was tasked with.

1 Like