Modern Testing Practices for Cross Discipline teams

• This is for you
• Share your work where you can
• Engage in practices that promote feedback

Aim of this piece

The aim of this charter is to provide a framework of how to work with multiple disciplines while focusing on getting high quality user experiences out to end users and ultimately empower yourself as a QA/Tester/QA Engineer and your team to do great things.

I’ve found that teams struggle with balancing their activities, over focus on certain area’s or over stocking on certain skillsets.

What this isn’t is a list of frameworks, automation tools or other tools, I’ve tried to keep it very basic and just focused on behaviours.

Use this if you’re not getting what you want out of your team experience.

Assumptions / Who I think you are

This assumes you’re in a cross functional team with roles like developer ‘front end’ and ‘back end’, QA Engineer/Tester, UX/UI/Product Designer, Product Owner, BA etc etc.

This also assumes that you are a person who works in a testing role and is perhaps not doing day to day what they would like to be doing.

Ways of working

Pair by default

Look for ways to share the load. It may feel slower at the start but you will build relationships with the people you work with and I believe in the end you’ll be moving faster and being more effective.

Find balance between what you like doing and what you know you must do

If you’re more exploratory testing focused then find time for automation and vice versa.

Sharing responsibility can feel scary but there are lots of area’s for you to specialise in that make you indispensable.

Remove yourself as a ‘bottleneck’

By utilising these idea’s you can remove yourself as a bottleneck and free yourself up to cherry pick the work you’d like to do while empowering your team to move quickly and build their skills.

What might work look like?

The beginning

Hypothetically a request comes in? As a team you come together to talk about it.

What value can you add here?

• Create a short exploratory testing charter, maybe it’s just a one liner
• Define other testing activities that need to be undertook
• Do you need data, additional set up? make sure these are defined as prerequisites
• What automation (if any) needs to be put in place? define this up front
• What monitoring is needed? what does success for this request look like?

The Middle

Pair/mob with development on both the development of the request and the creation of the testing scripts.

• Take turns driving (controlling the IDE)
• Discuss openly what you want to achieve
• Come to reasonable compromises
• Stand your ground when you feel you need to

This can be a bit scary, especially if development isn’t your forte but you can ask interesting questions at this stage and get an understanding of the unit testing going into place as well.

The ‘End’

Pair/mob again are you testing a user experience? bring in your designers, bring them in earlier even..

• Dont just go away and test in a silo
• Blur the lines between the middle and end if you want to just make sure you do it together

This is the opportunity for development/designers to learn from you, follow your preset conditions above but also dont be afraid to experiment and go off book a little as well.

• Prioritise your bugs together
• Cycle things through back to the developer and so on until you’re all happy with how things have gone.

---

I sincerely hope this helps you and thanks for reading, if you have any thoughts or challenges add a comment below.