Use ‘Test Items’ to help improve upfront collaboration and quality

In the spirit of collaboration and getting testers involved early in the development of new feature stories, we have developed a quality initiative that helps us do this.  We are implementing ‘Test Items’ to be added to our story templates.

For some context… we have small agile teams (8-9 members) and we manage our work using a Kanban board. When a new story is added to the backlog, the whole team gets together to review, estimate, question and provide feedback before the story gets moved to our ‘Next Up’ column on our board.

A developer then grabs the story and starts doing their analysis and deciding on how to implement.

A tester also starts working on the issue as well. The tester does their own analysis of the issue, examines and modifies the acceptance criteria and has early discussions with the developer if they see something amiss. What we are now starting to do, is define test items. These are specific things that the tester is ‘thinking’ about testing, wants to propose or have a discussion about.  These are added to a section of our story template under ‘Testing Considerations’.  The test items should be simple bullet points and contain just enough information for everyone to understand the context.

Here is an example:

Testing Considerations:

T1:  Acceptance Criteria
T2:  Automation
T3:  Configuration parameter removal
T4:  New solr.properties file gets deployed when installing MX
T5:  Valid and invalid entries in solr.properties file
T6:  Starting, stopping, restarting Solr with no errors
T7:  Add part requirement flow still works as expected and parts are returned successfully
T8:  Quality Attributes: performance, security, reliability, usability, etc
T9:  Multiple Browsers
T10: Multi-User access
T11: Data integrity and validation

When the issue is now ready to be worked on, our team then does a ‘3 Amigo’ session where we involve the PO, the developer and the tester to have another discussion prior to work commencing. The developer talks to their implementation plan and ideas, and the tester talks to the various TI’s they have identified. The first two TI’s are typically the same, where we talk about the acceptance criteria, how we will test it manually and what our automation plans are.  The beauty of using TI’s, is we also talk about all the other items we are intending to test as well. This gets us all on board and agreeing to the items. The developer knows ahead of time what we will be testing (so there are no surprises), and we can have intelligent conversations about quality approaches before we even write a single line of code. With the annotations, we can easily reference them in our test sessions as well.

This approach allows us to have a standardized, repeatable process which gets everyone involved in testing discussions from the onset.  Identifying the test items early, gets everyone involved in the whole testing approach, and not solely focusing on the functionality or the acceptance testing.

A good tester is always thinking about all the things that may require testing. This allows us to share that information effectively.

 

The W5 Heuristic – Use it to define the ‘How’

I like to use mind maps from time to time to gather my thoughts.  The beauty of them is their simplicity. The ability to capture thoughts and ideas and display them in a visual nature instead of long winded paragraphs of words is great. They can be useful in some contexts, but certainly can be overdone and over used. Some people tend to ramble on with them. The more content and detail a map contains, the more it can lose its effectiveness.

One method I use from time to time, is to use the ‘W5 Heuristic’ to determine how I will approach work to be done. This can be done for test strategies, test design approaches, what and how to automate, defining problem statements and ideas for resolution or really anything you would like to get done.

The premise is simple. You create a map with the 5 W questions:  Why? Who? What? Where? When?

The responses and discussions should help with the ‘How’, and also in establishing action items going forward.

The following illustration is an example of one:

w5 heuristic snapshot

In this context, I was getting our testers together to help design a new testing repository for our test artifacts.  I used this method as a great way to answer some important questions. You then simply add nodes to them with information that you discuss.

Why?

I always start with ‘Why’.  If you cannot come up with good solid reasons why you want do something or see the value in it, then stop.  This is important in testing, as wasteful activities and processes have no place in our world.  Here we defined why we need a central repository.

Who?

Next is ‘Who’.  We have defined the problem statement and why we need the repository. Next I wanted to find out who would need this information. Which personas would benefit from this.  As with any testing activity, we should always think of who are the stakeholders and personas that may benefit from work that we do.

What?

Now that we have defined the ‘Why’ and the ‘Who’, we now want to think about ‘What’ they may want to see.  This can be applied as a model in any context really.  It helps put us into the mindset of the various personas and try to deliver max value.

Where?

‘Where’, depending on the context of what it is you are mapping out, it can be simple and straightforward like this example. It was decided that a wiki was the best option, but it could certainly have morphed into many options, which would be great for discussion.

When?

This helps establish some timelines, best guesses, priorities and anything else that may be time sensitive or where you may want to apply a deadline or timeline.

Defining all of these and having good discussions, should help in understanding of the ‘How’ you want to implement something.

So, if you are looking for a quick and simple method of trying to get answers, how to get things done, and set action items going forward, give the W5 Heuristic a shot.