Bullshit Alert! On The Bullshitisation of Software Testing with Maaike Brinkhof

For our seventeenth session of TestBash Home 2021, @maaike.brinkhof takes to the stage to talk about the aspects of software testing that are pointless and the correlations between how testing work is organised versus the amount of bullshit/pointless tasks this adds to a testers job.

We’ll use this Club thread to share resources mentioned during the session and answer any questions we don’t get to during the live session.

5 Likes

Questions:

  1. I appreciate this topic is based on your own views, but don’t you think you might be understating the level of competence required to lead an organisation?

  2. Only 46% of our time is dedicated to our ‘primary tasks’ - but what are our primary tasks? Especially for a tester a lot of our tasks feel intangible.

  3. what do you do against the bullshit you experience in your own job?

  4. What is the most bullshit job you’ve ever had?

  5. do you feel we can detect “bullshit” job offers in testing?

  6. Which category do “work”, like washing dishes, having babies and teaching children sit in. Are we saying that money decides the category and is correlation?

  7. Can a BS job be a good way to work your way up to a non BS job?

  8. Isn’t the level of bullshitisation associated with bigger companies?

  9. it would be useful to actually know how to deal with the types of bs jobs you just listed?

  10. Agreed, trying to sell testability as a requirement, when all the attention is on the customers requirements is nigh on impossible.

  11. When working for yourself, did you find yourself doing any bullshit tasks?

  12. how can an organization move from box ticking testing to systematically validating the quality of the executed tests?

  13. How can we get testability requirements higher on the customer requirement radar?

  14. As an employee you may not see the value, but for managers or others, it could be extremely valuable. Is it a communication and understanding issue?

  15. I agree with you that the bigger the org the more bullshit. But how then do we get committed testers to work on high-risk software that really impacts society?

  16. Are there any drawbacks in confronting the BS, whatever exit strategy you take?

  17. Do you think that becoming a contractor is the best way to avoid being overwhelmed by bullshit ?

  18. How much bullshit is too much? I mean every job has some bullshit to deal with. How do you know if you are in bullshit danger zone?

  19. What is your experience of managing bullshit by: modelling the opposite alongside navigating the bullshit?

Resources:

https://twitter.com/Toffeemen68

https://itdependsblog.blogspot.com/p/home.html

1 Like

Also what was the book title/link pls!

1 Like

@crunchy I believe it was “Bullshit Jobs by David Graeber”

Bullshit_Jobs

1 Like

Yeah I don’t wanna plug a specific book seller so here: Bullshit Jobs - Wikipedia

1 Like

same XD I didn’t knew what to link ahhaaha

This is exactly the reason I started this talk with a warning: it WAS extremely subjective. And at the end of the talk I mentioned again that I can only speak for myself. More importantly, I only spoke of the software testing sphere, not about the leadership of an organisation. I have no idea what that entails as I have no experience in that area so I cannot speak for it or about it. I’ve only been a test lead and test manager for short stints of time and figured out it wasn’t for me.

3 Likes

This is an excellent question and the answer would highly depend on your context.

Testing is way more than interacting with the software, but I do try to maximise my time exploring the application (in my case, a mobile app).

I also think a primary task for me is to “shift left”, so I try to involve myself in the things that happen before code is written: refinements, risk sessions, asking questions. All to try and figure out things before code is written.

My test mission is: I want to be a catalyst, inspirator, facilitator to improve testing as a whole with other people. So I make sure my team ALSO does a lot for testing. The developers in my team help with testing primary tasks as they create most of the automation in testing.
This mission helps to keep me grounded and I check in regularly to make sure I don’t go off track.

What do you think are primary tasks for testing? Answer this yourself, and map it to your current work situation and see what you can improve (if needed).

I try to minimise tasks that I think don’t add value, like writing extensive test reports. I try to do “just enough” for everything. My reports are short, but contain the information that I think the reader needs to know. I prefer talking to my colleagues over communicating in JIRA tickets, if you get my drift.

There is one heuristic that can help guide you in this, it’s from the book The 7 Habits of Highly Effective People. In the book, a quadrant is described.

important / urgent | important / NOT-urgent
NOT-important / urgent | not-important / not-urgent

A lot of people can fall in the trap of spending most of their time in the top-left quadrant because it feels so good. The sense of urgency is there. But don’t forget that most of our valuable work is done in the top-right quadrant: important work that isn’t that urgent.
The 2 bottom quadrants you want to minimise because THIS is where the bullshit happens, imo.
The constant barrage of emails, status reports, interruptions that could have waited, the self-chosen distractions.

Most importantly though: MAKE your work tangible. At my current client (I just started a month ago ) my mission is also to be very public about how I test and what I test. So every exploratory test session I do I write a nice little story in the JIRA ticket so people KNOW what I have done. I want to be accountable for what I do. The automated tests are clear tangible pieces of work, but the rest of testing can be like that too! Just keep it simple, keep it small. But communicate about what you do.

1 Like

Before I knew about the CRAP framework I was struggling with this.

I chose to voice my concerns a lot, but the way I was doing this wasn’t effective. People just thought I was negative. Some people agreed with me, but were more cautious in expression how they felt whereas I just stomped around like an elephant in a China shop. I ended up antagonising a lot of people, especially people higher up in the hierarchy of the organisation (I don’t give a shit about hierarchy and those people probably didn’t appreciate that of me). Especially the white men in manager positions didn’t appreciate a woman telling them that what they were asking was total nonsense so it got me nowhere. I guess you can still go the “voice your concerns” route if you apply consultancy skills and tact. It’s not what I excel at (I’m working on it).

I once quit my job because of bullshit. I tried to be a test lead and test manager because the company I was working for at the time expected it of me and it truly made me miserable. I had to spend most of my time convincing people of the value of testing (again, struggling with the white men in manager positions) and writing reports and I missed interacting with actual software so much! I felt constantly stressed out because I experienced so much cognitive dissonance because this job felt so pointless to me. I got so miserable my husband said: why don’t you quit your job? It blew my mind that this was even an option, but I took his advice in the end. I needed 2 months sitting at home to feel like myself again. This was when I decided to go self-employed to carve my own path and that path would mean: being “just” a tester. I want to work on the actual creation of software, not the management/leader part of it.

At my current assignment the bullshit is at a minimum. I agreed to do this assignment because the context is really small. Just one mobile team. This seemed promising to me as I’ve been most happy in smaller contexts before. Time will tell if this will be a good experience! So far I’ve seen lots of autonomy for my team, a Product Owner who actively involves us in the decision making, and the team agreed with my Keep It Simple test approach. Good stuff, so far!

1 Like

Test Lead at a big Dutch company (contracter role from when I was working at a consultancy firm) in a team with other test leads. The IT was HUGE there, a couple hundred people in a lot of teams. The teams had no testers so it was my job to help the teams if they had testing problems. It was a bit like being a task-master. Most teams fared just fine without my help. Then, after one month there, the funding was cut from my team. I was just sitting there, twiddling my thumbs and making up work to do. If I feel I can’t add value, I end up feeling miserable. Because I was still an internal employee for the consultancy firm and they struck up a nice hourly rate for me it wasn’t easy to just go away.

I’ve also been a Duct Taper in the job I had before I became a tester. I was working in insurance (bleghhhh!!) and the insurance company had bought an off-the-shelf software to register their clients in. The problem was that if we did just one small change on a client file the system would automatically create a letter to send to the client, notifying them of the change. Problem was, not every change was interesting for the client. So every day, my department received the batch of letters that were printed during the night and we had to open each and every one of them and check if the letter should legitimately be sent to the customer or if the system had sent an unnecessary letter. This is what I had to do with the other junior colleagues every day and it drove me insane. Why didn’t they fix the actual problem??!!

Just 2 funny examples :slight_smile:

2 Likes

Oh boy, this will be an extremely opinionated answer but YES WE CAN.

Red flag phrases:

  • automate all testing
  • automate everything
  • “you want to spend as little time as possible on manual tasks” (what is wrong with manual tasks? Programming is also still “manual”, last time I checked)

Basically: job offers that don’t get that the value of testing is what is going on between your ears but that focus on the automateable outcomes of it. It’s so easy to automate tons of tests and people will be happy and don’t scratch themselves behind their ears and wonder “but was test design involved? Risk-based thinking? Critical thinking? What does the automation miss?”

Automation is the big silver bullet in test job offers, most of the time.

1 Like

I followed the book on this one, but you have a very valid and infuriating point. Unpaid labor wasn’t included.

If I include it, it would be in the category “shit jobs”. Useful work, terribly undervalued.

Actually, unpaid labor isn’t included in GDP calculations of a country so guess what: most work that women still do most of the time is unvalued in terms of money and such. Read the book Invisible Women if you want to feel more angry about this.

1 Like

Ha! I was thinking of the Invisible Women book when I asked this. I think my reason for framing my “work” question like this was more about language. Language which has changed how we classify our worth or value based on how much we earn (which from your slides seem to be directly proportional to the bullshit depths that become possible.) I’m not saying women are more qualified to call out bullshit either, but they more frequently have reasons.
I wonder how often the ways language is used poorly to communicate about the business get miss-interpreted, forcing higher-ups to invent more obtuse gestures. How can we better interpret the business goals, perhaps ask good questions is all we can do.

3 Likes