Quality Engineering with Anne-Marie Charrett

Events Meetups
#1

on the 3rd Feb 2020 Anne-Marie Charrett delivered a great talk on Quality Engineering as part of the meetups run by MoT cork, Belfast and Edinburgh.
These are the questions we didn’t get to answer on the night, which Anne-Marie has offered to answer in due course

  • How do you get the whole team to really engage in 3 amigos? Any tips or tricks?

  • Would love you to expand on the point of asking others for their perspective on quality and what does it mean to them? How does this help me as a tester? (Further context: I told my manager I was going to do this and he said why would you want to do that, surely you’d get 20 different answers, don’t you want one single view? I’m not sure that I do…)

  • How would you go about bringing an organisation round to the idea of testing in production? They’re very nervy and defensive by the way…

  • How would you assure about quality of the product when there are multiple deploy cycles with in a day?

  • Surely even in a start-up you can select suitable core features/areas for automation (probably not UI level) - you will still get valuable information back to provide to the wider team, it will still be repeatable and valuable longer term, even if some tweaks might be needed down the line?

  • How can advocate and encourage doing exploratory testing as part of the process?

4 Likes
#2

Question: How do you get the whole team to really engage in 3 amigos? Any tips or tricks?

There’s two ways to look at quality. One way is to explore what quality is (think observability, testability). The other way is to explore threats to quality. I find its easier to focus on threats to quality and identify those. I break quality down into different areas (product, process, people, infrastructure, tools, culture) and get them to think about threats to quality in those terms. Greater diversity of roles gives greater diversity of answers.
If there is no energy in the org (for what ever reason) for this, work at a grass roots level with people who are, and focus on making that work visible. Hopefully you will get to a tipping point to get that the momentum moving…that’s the idea anyhow.

Also prepare for any of these meetings. Run through the feature yourself and think about all the potential risks. Then ask questions around those risks.

1 Like
#5

Would love you to expand on the point of asking others for their perspective on quality and what does it mean to them? How does this help me as a tester? (Further context: I told my manager I was going to do this and he said why would you want to do that, surely you’d get 20 different answers, don’t you want one single view? I’m not sure that I do…)

Firstly, I think its awesome that you gave this a go. Trust your gut, you do want a diversity of answers.
Ask your manager if he believes quality is a team responsibility. I suspect he will say yes. Then ask, but if quality means different things to different people, how will that work? There is no shared understanding of what quality is.

If you really want to give people responsibility for quality, it requires a degree of autonomy, them having a say what quality is. IF you don’t do this, you are imposing quality on people. This will result in reluctance to be involved in quality related activities. Soo much here to be said…maybe I should write a blog post. :rofl:

You want to encourage diversity of input. Once you have the input you want the get them to a) comment on the diversity. Ask them how might this diversity impact quality? and. ask them what they think we should do about this? One approach is to collect all the different ideas on what is important and ask them to dot vote to identify the top priorities, then begin focusing on those. You can read about my workshop that does that here

3 Likes
#6

Surely even in a start-up you can select suitable core features/areas for automation (probably not UI level) - you will still get valuable information back to provide to the wider team, it will still be repeatable and valuable longer term, even if some tweaks might be needed down the line?

Firstly thanks so much for this question. You’ve made me sharpen my ideas around this which is awesome…

I think there’s truth in this. And my statement was probably too black and white. My experience with startups is there’s typically no testers. Any test automation is left to the developer. If the developer has the chops, they will put some test automation in which is fantastic. Especially low level non GUI stuff (as you describe). But this has to be balanced with how experimental the feature/product is. If experimentation is such that the code may be dropped then I do think it’s valid to question how useful a lot of test automation is in early stages of experimentation.

I’m now thinking about TDD. This perhaps could be the exception? TDD after all is more design thinking which happens to output automated tests…hmmm, lots to think about!

2 Likes
#7

@amcharrett thank you so much for taking the time to reply to my question and deliver your talk on Wednesday. I’ve already watched it back again… so much content :exploding_head:

I love the workshop idea and really appreciate you sharing it.

1 Like