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.