Use UI Automation to Assist Agile Showcases

Real agile projects take showcases seriously. However, many fake agile projects have no showcases as the team is simply not capable of demonstrating the app. I show an effective and proven approach.

Showcase is considered one of the Agile ceremonies in software development. It is probably the most important one, especially for the teams without on-site customers. Showcases engage the customers to gather feedback (to make sure the development is staying on track). It is also the opportunity to provide real confidence to the customers.

However, I have found fewer and fewer showcases in so-called “Agile” projects in recent years. The teams do ‘Daily-standup’, ‘Sprint planning’, and ‘Retrospectives’, but not real showcases. Though some teams do showcases, their sessions are focused more on showing Agile boards and Velocity Charts on JIRA, rather than showing the implemented user stories in the current sprint.

Before I get to the reason, I would like to share my observation first. The customers DO NOT care about the velocity/burn charts; they don't like seeing JIRA there. They care and only care about seeing the features that were planned (and promised). Some might argue that our customers seem to be OK with JIRA stuff. Wrong! You think this way because you haven’t seen a proper showcase in which all newly implemented features are demonstrated. What I can tell you for the real showcase: once the real business features were demonstrated, the room was suddenly enlightened.

Now the reason: most software teams simply lack the capability to demonstrate newly implemented features (user stories) correctly and reliably in the showcases, after Sprint 3.

The Problem: demonstration goes badly on the showcase

After Sprint 2 or 3, Business Analysts (whoever does the demo) lack the support to demonstrate business features (which consist of more steps than the simple user stories implemented in Sprint 1) correctly. And, of course, the situation will get worse.

I will illustrate it with a typical enterprise application: an insurance claim app.

Sprint 1

Some simple user stories such as User Login/Logout, Start new claim application and Fill the claim form.

Tony, the Business Analyst, demonstrated these features well at showcase #1.

Sprint 2

Newly implemented user stories: Claim form application with 3 different types, Submit application, Reset password.

Tony would find Showcase #2 more challenging as he needs to enter/select more data in more web controls (e.g. textbox, dropdowns) and click more buttons, correctly. With a few minor mistakes, Tony managed to get the job done OK.

Sprint 3

Newly implemented user stories: Allocation Officer (AO) receives the application, AO allocates it to an assessment manager (AM); AM reviews the application

While preparing for the showcase, Tony realized that he would not have enough time to complete the demo if starting a new application for each single insurance time. Tony is smart. Therefore, he pre-created a few claim applications.

The showcase did not go well but was acceptable. Demonstration of the new features involves sign-in/sign-out of 3 or 4 different users. Tony made a few mistakes such as typing the wrong login name and selecting the wrong option.

Then, one customer asked a question: “If you ticked a fast track option, …”. Tony was tired and had no confidence to show it alive, he answered: “It shall work, I will book a time tomorrow to show you”.

Sprint 4

Newly implemented user stories: AM rejects the application; AM sends the application back to AO to re-assignment; the Application needs a couple of uploaded attachments.

The team predicted it would not go well. Therefore, two more business analysts were engaged to participate in the demonstration to relieve Tony from remembering all the steps.

Still, the showcase was a big failure. Business analysts only managed to demonstrate half of the features in the given time. Tony made a few mistakes, including a quite embarrassing one: he typed the wrong password for a user and retried twice, causing the user account to be suspended. Argh!

I think you get the picture: As more user stories are implemented, it is getting very difficult for the business analyst to demonstrate live in a showcase. We all know that typing accuracy drops when others are watching.

Solution: Automation-Assist

I had this idea a few years ago after a disaster showcase by our business analyst. This was a failure of the whole team, and the project manager was about to give up showcases. I came forward and offered a solution: using automation for showcases.

For each implemented user story in the current sprint, I created an automation script. When the Business Analyst was about to start the demonstration, I ran the script to drive the application in a browser (for a web app). The Business Analyst would talk to the audience like the below:

• “An applicant logs in” (pause for a few seconds)

• “Start a new home and content insurance claim, and fill in the details” (pause and highlight some key fields)

• …

• “Now it comes to User Story #123. the assessment manager opens the application, he can review and reject the application”

Automation stopped here. The business analyst started to demonstrate this new feature manually, live.

Positive Impact

Besides all the benefits of a successful showcase, as you may see in agile books, there are more to offer from a showcase:

1. Professionalism

The team will take more pride in their work, especially after seeing the appreciation from the customers. Many customers used the word “Cool” to describe the automation-driven showcases.

2. Customer’s confidence in the team

Customers’ confidence in the team grows when they see the real stuff, not JIRA charts. Trust is built on confidence. With the trust (between customers and the dev team), things will get a lot easier.

3. Get good feedback from the Customers

This is the purpose of showcases. Customers, after seeing the live demo in the showcase, will usually provide valuable feedback. Because the memory is still fresh, they will feel OK to correct some mistakes in the requirement or add related new requirements.

This valuable feedback will save the development team from working on much wrong stuff.

4. Opportunities for the dev team to understand the application

It is common that a typical team member (developer, tester, and business analysts) only understands a part of the application. By seeing the demonstration in the showcase, the team members have the opportunity to see the overall system, which will help their future work.

How?

The concept is quite simple and easy to understand, even those who haven’t done it before can see that it will work well. In terms of implementation, the short answer: create dedicated showcase automation scripts from the automated tests for the user stories. I will show a few examples of running automation scripts for showcases in another article (later this week).

When automation is used for showcases, there will be some differences from the usual test automation execution. Here I will highlight two features:

1. The browser window remains open after the execution of the automation script completes.
   Don't close the browser ( driver.quit in Selenium WebDriver) after the test execution.

2. The execution can be set to pause or slow.
   This allows BA to highlight some features.

Challenge

The challenge is not about the automation script that can be converted from the automation test scripts. The reality is that very few software teams have the capability to accomplish the following two tasks:

1. developing automated test cases for new user stories implemented in the current sprint

2. maintaining all automated tests for the previous sprints.

Most software teams simply don’t have the capability, and incompetent tech leads are not willing to admit it. The simple solution is to seek external help from a real Test Automation Coach (like Facebook getting Watir developer; LinkedIn lured Scott from Google).