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

šŸ—„ļø Archive
1

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
2

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
3

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