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

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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s