How will I demo this? A Proactive Approach to Quality Assurance

Every business wants their project team to build and release the best product they can within the known time and resource constraints. In simplistic terms, the team wants to complete the following three phases of software development to the highest standards: -

1. Scoping of work
2. Building of the related features
3. Deployment to production

Phases 2 and 3 are where code and infrastructure exists. From a quality assurance perspective, the practice of writing and maintaining robust and useful test suites for these provides us with feedback on how close we are to our understanding of what the product is. Tangible improvements can be made based on this feedback.

How do we implement something similar for the first phase though? How do we know the story makes sense and can be worked on? How can we minimize the issues that will appear whilst working on a story? And how can we be as proactive as possible in our product quality assurance so that we actually build the right thing?

Tried and tested methods of writing acceptance criteria exist to help us encapsulate the work, tell us what functionality to check. Examples include Given When Then or Specification By Example. These assist in clarifying definitions on what to test for a story, but are they enough?

An approach to assist in getting it right first time round when scoping work is to ask "How will I demo this to the business and what do I need to do so?”

Are we really ready to Showcase?

Consider that the team has been tasked with building a customer feedback mechanism on a website. Straightforward enough: - 

1. The user navigates to the website
2. They click a button and it launches a new email
3. They enter their thoughts and send to a predetermined address. 

We'll need a button that launches a mail app, say Outlook Express as we're working on Windows. The user is to be allowed to enter any text they wish so no in-depth content validation is required. We can write acceptance criteria to validate that the mail client launches, that a mail can be sent and that it can be read at the other end. 

Showtime!

Fast forward to the demo of the completed story. You've already checked the acceptance criteria are ok and are now sitting in a room with the business representative and a user of the site. A computer is in front of you and you're about to show them the new feature.

With the audience watching, you go to the website, click the new link and Outlook pops up a new email window. You point out the prepopulated “To” address, enter "Showing an email" in the subject field, "some text" in the main field and click send. Ta-da!

Stunned faces from the audience. What's this? We work on Lotus Notes. And the offshore team uses Thunderbird. We know free text input is required but do we know if the template sent to one of the team looks OK on Windows 7? 

Also, there has to be a Subject heading of "Feedback on the new interactive company site" so that it can be filtered out from all the other emails that are sent to that address. And can we see the email in the Inbox to see if the filtering is easy enough? How would I access this account? What's the password? Who'll set it up? The list of questions grows …

Where did we go wrong?

We made a few assumptions during scoping of the story that have impacted the value-add of the work for the business and didn't think ahead. Although we provided a functioning feedback mechanism, it's not the feature requested. We can certainly do some rework to make our business representatives happy but this will cost in both time and money. Where did we go wrong and how could we have prevented this?

This highlights an often-forgotten focal point when a team picks up a story - we may have defined acceptance criteria to tell us when we have working functionality, but is that enough to be able to demonstrate the full story to the person paying the bills? A highly effective automated testing suite that runs in 4 seconds and executes 500 tests is part of the solution, however this generally is something that the business is not interested in. In our case study, they wish to envisage their end users/the real customer clicking on the link, entering their comments and having a painless, straightforward experience of providing feedback on the system. They also wish to know that the support team for the application has access to the emails being sent, and that they can read them all. We can't show this at the moment.

Think Ahead, Step Through The Demo

Continually looking forward to the demonstration of the work and stepping through the sequence of events is a powerful way of ensuring that stories are fully completed, and that any constraints (in the case above, an example would be having to send a request to the Infrastructure team for creation of the new email account, which could take days in some organizations) are highlighted as early as possible.

This approach is also a useful starting point when new to the concept of writing stories. If a Business Analyst and Quality Analyst have been tasked with breaking down work into stories and would like to review their work before placing it in the backlog, performing the role-play of being a business user can be quite revealing. Constraints will appear during these discussions - make sure they are, and as soon as possible.

What can we learn from this then?

• When a team is tasked with building a feature, it is essential to consider what the end shall look like. Always consider the question, "How will I demo this to the business and what do I need to do so?”
• Strive for product quality that will please the business requires more than tests alone. Develop a proactive approach to quality can, and does, save time and money.