Test as Early as Possible: 99 Ways Workshop #9

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.


My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.


Suggestion #9: Test as Early as Possible - Gareth Waterhouse


One of the goals of testing is to help make sure we have the opportunity to find and share information on as many aspects about the product as possible. Often, we tend to think of our testing as starting as soon as we have a build that's been deployed. We can get testing done earlier if we pair with the programmer for a story. There's an even earlier opportunity that is available to us if we really want to "test as early as possible", and that is at the beginning of a story. How this is done and what it is called varies. In my current environment, we call this "story kickoff" and that process begins with "The Three Amigos" meeting.


Workshop #9: Have a "Three Amigos" Meeting to Test The Requirements

There is plenty of writing on the web about Three Amigos Meetings, so if you want to get into the details of what they entail and how they can be used in your organization, just do a Google search on "Three Amigos Meetings" and have at it. To keep things simple, I want to discuss this process as it relates to software testing and how software testers can add a lot of value to these meetings, and actually start testing before a single line of code is written.


A Three Amigos meeting in our organization is synonymous with our story kickoffs. In that kickoff there are three attendees; the product owner/product manager (PM), the software developer/programmer (DEV) and the software tester (QA). The purpose of the story kickoff is to make sure that the story has been scoped, that the requirements are understood by all three attendees, and that questions about the requirements are addressed.


In our model, every story is defined with the acceptance criteria for it to be completed. We use a Kanban system and practice "one piece flow" work for a story, so each story get worked on and inspected many times as it goes through its lifecycle. In this first stage, as we walk through and define the acceptance criteria, each acceptance piece then gets discussed. The PM describes what they want to see happen in the story. QA counters with a variety of questions to make sure that we understand what the criteria needs to be for an acceptable completion. DEV discusses, where relevant, some details about the implementation, including hooks or aspects that will help QA with testing the story. We can also bring up other aspects, such as upgrades, migrations, mobile access, accessibility, localization, etc. Once we are all satisfied that we have covered our bases, we consider the story "kicked off" and ready for development work to begin.


As a tester, think of yourself in this meeting, and think about the questions you would want to ask your PM and DEV counterparts:


- have we considered if this feature will translate to mobile devices?

- do we know if the changes we are implementing will have an effect on performance?

- are we using new libraries for the front end? Will those have an effect on navigation or the perceived performance of the application?

- do we understand, and can we envision test scenarios for the new feature?

- do we understand how we will actually test this new feature?

- do the tools that we have allow us to programmatically access values and states?

- have we identified potential security issues associated with the new features?


Each one of these questions is best handled during the Three Amigos meeting, since the cross section of design, implementation and capability to perform the task are all represented. Misunderstandings can be quickly resolved. If they cannot be resolved in the meeting, the responsible party then knows where they have more work to do before the story can be kicked off.


Will this meeting capture everything? In my experience, no. There are unforeseen issues that pop up all the time. There are missed story tests that we realize after the fact. That's a fact of life, and having no missed story tests rarely happens, unless the story is fairly simple. Over time, though, the missed story tests become fewer the more Three Amigos meetings you participate in, since each time through, you remember some of the situations that led to missed story tests in other stories, and you consider those the next time.

Bottom Line:

Three Amigos works as long as everyone participating does their part. As a tester, your goal in this meting is to make sure that you thoroughly understand the requirements as they have been presented. Your best chance to clear up misconceptions and ensure you are on the right track early enough starts here. Testing the requirements means that you can clarify what should be coded from the outset, and that input can greatly shape the direction of the story, and the need for rework later on. If you are not currently doing this in your organization, have a chat with the Development team and the Product Management team and suggest a pilot run of this approach. Getting an opportunity to discuss the story at its earliest stage helps to make sure that everyone is speaking the same language and understands the terms and goals, or as close as three people can possibly get to that happy state.