I’ve recently joined a new Agile team which has grown quickly over the last few months. Although in the past some of the team members have worked with a dedicated tester, several haven’t which means I have to both integrate into a team and educate the team as to why we test.

Below are some of the ways I’ve started on this journey:

INITIAL DISCUSSIONS

Within my first couple of weeks after getting a general lay of the land for the team I booked some time in after one of the team stand ups with a meeting titled “let’s talk about testing”.  The purpose of this meeting was to find out pre-conceived notions the team already had about testing as well as to see if there were any expectations they had for me.

My first questions of “why are we exploratory testing?” and “what’s our team’s expectation for what I can provide you as an exploratory tester?” resulted in a lot of blank stares and tumbleweeds. That was cool though because it gave me the understanding that maybe we needed to start from the basics and work our way up.

I started by answering “why are we exploratory testing?” by showing that information can be thought of as being Explicit, Implicit and Unknown. Investigation and Exploration is used to try to find out information in areas that we have little understanding of, things that we couldn’t test via scripted testing because we don’t know what will happen or don’t even know if it’s a thing at all.

I went on to explain that through exploratory testing and investigations we could find out information that could be used to drive out further scripted tests or even change the course of how we design or develop an idea.

Following on from this I described how exploratory testing as an activity can take place across the lifecycle of a story allowing us to gather information and feedback more readily than with traditional scripted testing.

Using the above diagram, it’s easy to show that exploratory testing goes beyond the “test it once it’s been developed” view of scripted testing and it started to set an expectation that as an exploratory tester I’d be looking to get involved find out information all along the timeline of a story.

From these discussions the team seemed pretty happy with the whys of exploratory testing and also started to have an expectation of what to start expecting from me. I asked if there were any questions that anybody had and was asked one:

How do you keep your independence as a tester if you’re working as part of the team?

That’s a pretty difficult question to answer on the fly but when I’d thought about it for a moment I answered, “I’m not independent to the team, we’re all working towards the same goal and we all want the same thing. I guess that you could say I’m independent to the solution and our testing is to probe the how’s and whys in order to gather and supply you with information as opposed to actually doing the development.” I was really keen that in this answer I would be able to show that as a tester integrated with the team that I am a team member and that I’m not here to throw on the brakes or slow the team down but instead meet the same goal as them; a quality product.

PAIRING

Initially, during my first few weeks I focused on shadowing my new team mates to build up my domain and team knowledge. My questions were much more focused on learning and gathering information on how things work rather than testing.

As I progressed through the first couple of weeks my pairing started to become more involved as I moved from learning to actually testing within the paired sessions.

Difficulties I found when pairing:

• Sometimes when pairing I’ve found that I felt like I didn’t have enough relevant business or technical knowledge to contribute to the work, this could lead me to become passive and start shadowing rather than contributing. In these situations I’ve acknowledged this and have started to ask high level questions like “what is this?” or “could you give me an overview of what we’re doing right now?” so that I could contribute by testing the ideas as well as learning about the work.
• When a new team hasn’t paired with an exploratory tester for a while I found that they sometimes jump ahead into coding without giving any context or wanting to discuss risks or ideas. In this situation I’ve tried to engage the other member of the pair by asking high level questions “could you explain what we’re doing?” or “walk me through what problem we’re solving right now and how we’re doing that.”. If it becomes an issue to get engagement after that then I’ve either shadowed (if I felt I could learn something new by doing so) or said “it looks like you don’t need to pair on this issue, I’ll work on something else next to you but let me know if you need me for anything.”.

TESTING VISIBILITY

As part of our team’s learning about our new exploratory test approach and integrating this into our standard working practice I looked to raise visibility of testing in a number of ways.

Firstly I took the opportunity mob with developers working on a story to run a facilitated whiteboarding session to generate risks and test ideas, this was led by myself in order to encourage the developers on the team to think about generating risks and ways to mitigate them. This was really successful with the team then wanting to take pictures of the mind map and add it to the relevant user story.

Given the positive response to mind mapping I generated additional test idea mind maps to highlight potential risks and added these to upcoming stories that were in grooming. In the next standup following this I explained to the team that I’d done this and said that these could help us during design discussions, coding, generating unit tests and exploratory testing and that I’d be happy to discuss them or change them up based on what we found works. Two standups later one of the developers said how they liked the mind maps and how useful they were – win!

NEXT STEPS

Next on my radar is to:

• Refine the mind maps added to the stories to test the Ideas and the ACs.
• Start to capture test notes from exploratory testing and add them to stories.
• Share the knowledge by pairing with developers in the team to run chartered testing.