MoT Spain - "Dev + QA, not an odd couple" (Q&A questions and presentation slides)

Events Meetups
#1

Hello awesome people! First of all, thank you so much for joining our MoT Spain meetup today! We had tons of fun (even if we were nervous hehe) and your questions made the meetup really enriching.

Who attended the meetup:
17% Devs
66% Testers
17% Other

I’ll post all the questions here so that Daniel Mondria (speaker) and the community can answer them. Daniel Mondria’s slides: Dev+QA not and odd couple.pdf (996.4 KB)

These are my sketchnotes in case someone finds them useful:

Screenshot 2020-06-18 at 20.11.15
Screenshot 2020-06-18 at 20.11.151184×886 395 KB

One last thing, there’s a quick survey here, it’d mean a lot to us if you could fill it in so we can improve: https://bit.ly/2YLAJhn

Muchas gracias!! <3

3 Likes
#2

Is it OK to not want to pair all the time? 100% pairing is a lot! Most of the time I do enjoy working by myself (Question asked by Beren Van Daele)

#3

How do you convince the team to change the mindset and convince the team to pair? (Question asked by Assia Mbarek)

#4

In order to work this way, you should have a (or close to) 1:1 relationship between the number of QAs and Devs. How do you work if this relationship is 1:5 or even bigger? (Question asked by Jose Apuy)

#5

Based on your experience, should we start only by 1 US or start the change for 1 sprint? (Question asked by Assia Mbarek)

#6

Could we start this in fully remote working teams? If so, could you share some tips? (Question asked by Assia Mbarek)

#7

Nice presentation. On top of everything covered, have you considered creating a “threesome” involving PO for improving quality of requirements definition and understanding? (Question asked by Sergi Miso)

#8

Would it be better to pair experienced QA & Devs together or would it help to pair junior QA with experienced Devs so that overall team knowledge improves? (Question asked by Kamalesh Kalarickal)

#9

Do you have a way of measuring the team’s happiness levels to see if they’re happy working this way? (Question from Antonella Scaravilli)

#10

Do you think that the model you shared with us today is the future of IT? (Question asked by Antonella Scaravilli)

#11

Pairing all day is hard. 100% agreed. However, the idea of this is to always pair when you are working on a story. You can take as many breaks as needed, or work by yourself on something that’s not related to the project. When working on a story (either developing or testing it) we should be pairing.

#12

It’s key to get an ally and start the collaboration with that person. When results start to work, look for a third person, as hopefully now 2 people should be looking actively for this. And so on. Little by little, everyone will join as the team gets used to work like this and results are good.
If there’s a strong opposition to the pairing, I’d encourage to work as a team in both Mob Testing and Mob Programming. That may help everyone getting more used to collaborate with each other and facilitate the pairing

1 Like
#13

I don’t expect that ratio to be 1:1. In fact, in my last project, the ratio was 10:1.
The idea is to start pairing a DEV and a QA and keep rotating. This way, little by little, all DEVs will get used to pairing with QAs.
In my case, the DEVs were already pairing, which of course simplifies this. However, if they don’t do, we should advice developers to pair with themselves. This way, they’ll get more used to pairing and make pairing with a QA easier

#14

Start with 1 story by having it tested by a DEV+QA pair. Then let’s do the same with another DEV, and so on.

Once all DEVs have paired in testing a story with a QA, let’s do a sprint where all stories will be tested like this, DEV+QA. And if it works, maintain this (from then on, all stories are tested not only by QA, but also by DEVs).

At this point, DEVs should be able to test stories by themselves, so the QA should not be strictly needed for the testing

Once testing is always done by DEV+QA pair or DEVs (without QAs), start getting involved in the coding.

#15

Sure!
However, there’s an extra challenge with this, us most of us were not used to remote work before.

If you want to try it now, I propose following the same technique I proposed for the previous question from you (one story, keep repeating, and then all sprint stories)

#16

You are absolutely right. Pairing with the PO or BA, is key, as this will help to have clearer ACs, making both development and testing simpler.
However, I’ve left this as out of scope for this talk, as I was focusing in the collaboration between DEVs and QAs.
I believe the PO/BA should work closely not only with QA, but also with DEVs, to make sure stories are clear at all levels.
Whether you follow some formal 3 Amigos or something else, is up to your team to decide.

#17

I think the important part is to have the developer that’s best at teaching to pair with the QAs when focusing on coding.
And the other way around, QA who’s best at teaching to pair for focus on testing.

The other member of the pair is not so important, but the person who has more knowledge in the area we are focusing on (DEV if code, QA if test), should be the best one from the team at explaining.

#18

Not a formal one, no.
However, from my experience I think team happiness will increase due to these factors:

  • 1st QAs will stop being bottlenecks, which will make their work easier
  • No testing bottleneck will remove blockers and increase the feedfback loop about the stories
  • Once new methodology fully stablished, I believe fewer bugs will be raised. Why? Because the team will be able to put more time on the testing area (more people available for it) and testing automation will be also agreed with QAs (so it should be more complete). For sure less bugs will also improve team happiness :slight_smile:
#19

I don’t think we should go so far as saying this will be the future of IT :grin:
However, I believe agile teams should embrace this approach. This idea helps to spread the quality between the team, raises skills from everyone, and increases collaboration at all levels within the team, which I think is key.
In my opinion, Agile teams will slowly flow towards this. So the sooner you do it, the better for you