The Twisty way of automating

When I joined our employee web portal team as a quality analyst in mid-Jan, I was tasked to “automate ASAP and As Much As Possible”. Sounds familiar?

myThoughtworks is our much-loved Thoughtworker webspace that allows us to communicate, collaborate, share and learn across time zones and global offices. With a bustling activity stream (our virtual time around the water-cooler), search and filter capabilities, custom widgets and plugins, profile customization, support to create documents, blogs, polls, discussions, etc., it is tough to summarize our buzzing little beehive (let alone test it!)

The groundwork:

To get started, we first had a team meeting to detail and understand the expectations from the automation exercise. Using these inputs, we charted out our scope and the analysis we needed to do to plan our automation strategy.

We decided upon creating a Mind Map to visualize the different user flows that in turn could depict the automation scope and paths that can be covered in the test scenarios. Understanding the tech stack for each and every plugin and their integration points with Jive was required for us to shortlist potential test automation tools.

Our BA suggested that I pair with her on exploring the functionality of all the custom plugins. Drilling through them for an hour everyday provided great input for our mind map. Pairing with our developers to better understand the code for the plugins and to find their integration points with Jive really helped too.

After I was done creating a twisty mind map, we concluded the following:

• Scope for the automation was limited to automating custom Jive Plugins for the web portal.
• All our custom plugins wrote on top of Jive was written in Java.
• Most of the integration points were in the form of a call to the web service or overridden Jive classes.
• Paths/scenarios that could be automated.
• User Roles that exist should be considered for creating test data.

Automation Mind Map

The automation process

Since our codebase is all in Java and we might need to interact with the plugin APIs directly whenever needed, we thought of keeping the tech stack same. The first choice that popped up for BDT in Java was Twist. I went through the Twist help documentation and then started to spike out a simple use case, or “scenario” as Twist calls it, on the myThoughtworks portal. I chose to automate a common user flow – Login, visit a group, drag-drop a widget, save the changes and logout. The Mind Map that I had created was of great help here; as I had the test inputs, test data, user roles and test workflow handy. Setting up Twist and creating this first scenario was quick and easy.

We have the basic automation framework ready which keeps evolving as per the application’s behavior & functionality being automated. We then used the combination of Twist and a WebDriver in Java to automate the tests and an Ant Task (generated in just few clicks in Twist) to runs the scenarios on the Go Continuous Delivery tool. “User Journeys” (collection of user scenarios) are automated at the Plugin-level, which means we have a single user journey that covers all the happy paths for that particular plugin. We have been creating separate user journeys for each and every plugin that we have.

Sample User Journey

Twist's cool features like reusable Contexts (SetUp & TearDowns in Twist), Data Tables (that identify and map/merge duplicate values in your scenario), integration with Mingle to map scenarios to relevant story cards helped with the automation process.

I am looking forward to automating a lot more challenging tasks that we have including adding users via file uploads and verifying notification emails and emails for inline replies. We are also planning to feed the test results to TTA (It provides a way to do Trend Analysis across the test suites) to get the visibility of test run trends over a period.

Do share your web automation story.