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?
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:
for brainstorming test approach and peer review, get folks in a room and ensure everyone contributes and thereās healthy discussion and debate
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!
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:
ā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
ā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.
ā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
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.
