BRUCEY STORY TIME. Do you trust your dev team to test each others' work?

I had to make this post a question because there’s no category for ‘sharing your hilarious stories’. So feel free to add your own stories or experiences to this thread! Don’t feel obligated to give advice, but I will accept it. Would definitely prefer funny stories though.

Anyway, come in, come in, sit down, have a cup of tea ready to spit out.

Preface: I work with amazing devs who are not typically throw-over-the-fence types, and they have caught some pernickety bugs and are generally awesome, intelligent and caring. The tech function grew and we split our team in two. I went to team B, with one day a week on team A until we hire a new QA. The rest of the time, devs could test each others’ work.

Some of you might find that butt-clenching, but to be honest I was not worried at all. I love team A; they’re competent and they care about quality. They really genuinely care. I had 0 - ZERO - worries leaving things in their capable hands.

Fast-forward to the end of a big ol’ epic, the whole plan coming together after weeks of work. I’d missed my 1 day a week for a couple weeks in a row (ill, then on holiday) so I hadn’t been around for a while. Still 0 worries. Team A, man. If you only knew. Team A is the absolute best. (Don’t tell Team B I said that.)

So I got back from holidays and the manager said “hey, do you mind changing your day this week to tomorrow so you can look through the finished work before we release it?” I was like pfshh sure, not that I’ll find anything, because did I mention how great Team A is at testing? But you know, I didn’t mind so I swapped the days and here we are.

Pulled up the epic just to remind myself of the context, the raison d’être of the work, if you will. Ah yes, I recall the refinement sessions now, the entire reason we started this was to ensure that our users couldn’t [redacted] when they [redacted]. Things got a bit scope-creepy in there and we pulled in a bunch of refactor work, probably nothing to worry about - super beautiful code now, you would not believe the beauty of it. 10/10 coding skills. (Woo, Team A!) But you know, at the end of the day, you gotta make sure the users can’t [redacted] when they [redacted], you know what I mean?

Obviously, I was not going to be able to [redacted] when I [redacted], and I was going to need to get some serious exploratory pants on to find any issues. I got out my android and iOS phones, my iPad, my Nintendo Switch and my tv with an awful in-built browser, and put them on charge ready to start. Reminded myself of the screenreader commands, opened up the dev tools and the api logs.

It began.

First I checked that the user couldn’t [redacted] when they [redacted], and they could totally [redacted] when they [redacted]! They didn’t even need to be smart to [redacted], they could just go right there and [redacted] however much they liked, while they were [redacted].

So anyway, now I gotta go eat my hat, which is sad because the hat was made of trust. xD A reminder that you should never lose sight of your goals, or the context of your work.

8 Likes

Oooh this sounds like a dangerous STORY. #AskingForAFriend

I’ve already shared my own horror story in another thread, so I’ll not repeat, but rather, yes I trust our teams. But I think for anyone who is working across 2 teams, like that, you have the special big girl pants already. Not going to argue or say a thing. Who can attend requirements and triages and planning meetings for 2 teams? Personally, the person I trust least, is me, ace procrastinator Conrad; somehow they do still trust me. I hope my team still know to help me when I get swamped. And from the sounds of it you got swamped there.

1 Like

When I was still a developer, we had this kind of attempt to test each other’s work as an attempt to give me the QA work that I longed for (which is a long story).

For example, a developer is ready to hand it over to QA with his testing evidence. Instead of routing it to them, he’ll route it to a fellow developer, who will execute his own testing. It was great until it got forgotten because everything is urgent for them. When I started nagging them about the idea, it was easily cancelled by the same person who started the idea.

At another employer I had, developers can file bugs and place them on the backlog and they can also pick them up to work on a particular sprint, which is verified by the product owner. This increased QA workload because even developer-filed bugs have to go to QA as well. It did improve the quality of the product at the expense of delays to deliverables - a problem of resourcing that eventually eased out because everyone is committed to the idea and can drive them without any accountability issues.

It’s a good idea, but if the commitment is not there or support from higher-ups, it may not materialize at all or be a disaster. Developers testing each other’s work is a double-edged sword - they can just tag it as passed without even testing it and just hand it over directly to QA (which is a consequence of not having the motivation/will to do the effort and avoiding blame in a toxic environment, preventing ownership and accountability), and your process is as good as nothing.

1 Like