How would you do peer reviews with your fellow QA team members?

Hello all,

At the moment in my company we want to start doing peer reviews inside our QA team. The idea is to share information about how people test, how they write test cases, how to handle bugs and in general to get the products better.

In my head, I picture myself sitting next to my colleague and asking them to show me what they do , how they do it and why. This might be a little dull for some people and they might lose interest very rapidly.

I would like to know how you do it in your teams? Does it improves the knowledge sharing? What are interesting ways to do it?

Thanks for your answers!

Cheers

5 Likes

I’ve never done nor seen this done in 15 years in IT. Seems a waste. I think that’s why I joined sites like MoT and started going to MeetUps: my skills weren’t getting updated and I felt I could do with pushing myself to improve.

If your organisation is willing to facilitate this, I’d tip my hat to them! Great job!

The way I think I’d do this in a company is twofold:

  1. for brainstorming test approach and peer review, get folks in a room and ensure everyone contributes and there’s healthy discussion and debate
  2. for when things don’t go well and bugs escape into the wild: get the team together and do really good root cause analysis

Another option that can work is to encourage something like ‘train your colleagues’ where folks present to the team what they’ve been doing and take feedback with a view to everyone gaining out of it.

Again, sounds like a great idea and wish you well! :slight_smile:

4 Likes

I like the idea of what you are suggesting here. I have worked in places where we have reviewed each others testing to differing levels, whether this be:

  1. “Send me a link to your cases and I’ll review them” - this is usually not the most effective if there is no conversation, but may find some glaring issues

  2. “Lets sit down and walk through your thinking and I’ll help you identify gaps” - will help find more detailed gaps but still isn’t perfect.

  3. “Lets draw a mind map of what ‘we’ need to test and work through whats needed together”

I’ve always pushed for (where possible) number 3, because it’s a collaborative process and removes some of the cognitive biases that come in from being the only testing designing and running tests.

As far as raising defects etc, i think the best way would be to design a boilerplate template of the information needed in the defect, then raise one or two and check them with another member of the team before raising.

Using activities like Riskstorming can also enhance collaboration on testing ideas across a team too and build the confidence of the business in the testing being done.

Sorry, I know there is a lot there, but in my experiences, teams work more effectively when they are naturally reviewing each others work

3 Likes

My team host’s a weekly working session. It’s a non-mandatory meeting that people can drop in and out to tackle difficult issues, get more eyes on a new feature or talk about new tools. This meeting generally has no agenda so that people don’t feel obligated to attend.

@sjprior - I have only used that approach, but with a slight difference. We first list the scenarios to be tested (these are usually 2-3 liners), review those scenarios, write test cases for those scenarios and then review some or all of the test cases.

I guess the above approach might work best for simple and low risk features. But, I am not very confident about complex and higher risk features. Perhaps mind maps or such might be better for those features. But, I think that mind maps are helpful only if other team members (not just QA) participate in creation of the mind map. Once non-QAs had showed me some areas that I did not think of as a lone tester in a project. I guess the more minds, the more useful your mind map can become.

1 Like