Black Box, White Box, Gray box throw those words away. Test the thing not the box it came in...
That little gem came straight from Janet Gregory during the Testers Role in Agile Requirements Exploration Workshop at CAST 2016. I struggled with choosing what sessions to attend, I didn't want to miss anything and this workshop meant missing 2 sessions.
I was pretty impressed though, after all I have a copy of her Agile Testing book on a shelf in my work office. Plus this was a shining example of value I could show to leadership at work since they were sponsoring my trip. How often do you get to spend a few hours working with someone that has literally wrote the book on agile testing.
I didn't see the workshop when I was first looking over the schedule, so I missed my chance to get her to sign my copy of her book but she did agree to take a selfie with me. You can see I was clearly geeking out about it...
Personas
Personas aren't new, at some point most testers have probably used them whether consciously or unconsciously. Modeling testing after the behaviors or usage patterns of users real or imaginary. Lately I have been getting into the practice of creating charters for my testing sessions and Janet just in passing mentioned:
Build up personas then use them in your test charters
It was just coincidence, but it sure was a happy one and my brain lit up with ideas. We've been using the Explore, With, To Discover pattern for our test charters and this could just slot right in. Explore X With Persona Y To Discover the meaning of the universe...
It doesn't sound that earth-shattering but I had never considered injecting the persona like that and how elegantly it can describe and inform my testing. We could document our personas in our team wiki so when someone new is brought on we immediately have something they could use to build out their mental model for the testing. A new tester doesn't have to start from scratch, we can seed their imagination.
As a side note Rob Lowry made a remark during the workshop that I want to share because now it's the first thing I think of when I hear personas. It's also a nice reminder to consider users outside or your target audience.
I always model part of my testing as the A$$hole hacker
Persona Bias
Fleshing out your personas may cause an emotional attachment beware of over-resonance it may lead to bias
This dovetailed nicely with something I took away from the Testopsies tutorial, the concept that without an explicit mission, the implicit takes over.
It's only natural we test the product inherently the way we would use it. We are biased towards our own preferences. Creating shared, possibly group defined personas and then applying them explicitly through a charter helps maintain the testers focus on the missions objective.
Example Mapping
Janet also showcased Example Mapping from Matt Wynne as a means to concretely translate business language and test language.
Use examples to set and refine expectations
We were running a little low on time so we used the simple and relatable topic of password complexity. This area seems like a tester right of passage, at some point on some project every tester will deal with password complexity requirements. The exercise was simple, given some basic requirements like you might see from a business analyst come up with examples of each one. Then armed with these examples you can easily have a conversation around Is this what you really want?
Story+Examples+Conversation=Requirement
Just like personas, the concept is simple but that is by design. The simplicity is intentional, you can use these ideas with out pitching a new process. People can participate without special training.
For the first time I really understood and felt the power of the Individuals and interactions over processes and tools from the Agile Manifesto.
We focus on stories but can lose the broader context
This really hit home for me. Being new to a project or team and jumping in to work on a story is particularly hard as tester. We may only be testing a small portion of something but understanding its significance in a broader context shapes our approach. Testers bring perspective and insight to a project so having a tool box of options to help draw in that understanding is extremely important. In the workshop we got to work in small teams and get a hands on opportunity to build those skills. I also had some very talented testers in my group which really showcased the power of pairing.
