Ticketmaster Launches an Action on Google Assistant

 

At Google I/O 2017, Google announced that third-party Actions with transactional capabilities would become available via Google Assistant on both Android and iOS devices.

The day has arrived.

What is Google Assistant?

Google Assistant is a virtual personal assistant that can engage users in a two-way conversation to help them get things done. An Action on Google is a way for developers to bring their products and services to Google Assistant.

Google Assistant originally debuted on the Google Home device, but is now available on Android devices that are version 6.0 (Marshmallow) and higher, iOS devices with the Google Assistant app installed, Android TV, and Android Wear. Furthermore, with the recent release of the Google Assistant SDK and the growth of the Internet of Things, the Assistant is also available to many more connected devices.

On Android devices, Google Assistant can be invoked by holding the home button or saying “Ok, Google.” Then, without installing anything on the device, a user can access your Action by saying “Talk to your_action_name.

“Talk to Ticketmaster”

The accuracy of speech recognition and the efficiency of a voice search intrigued us. What if we could help fans find events with simple phrases?

“Find a jazz show in New York.”

“What is happening this weekend?”

“Where is Jay-Z touring?”

Early this year, we spoke to Google about our vision and had the privilege of being invited to an Early Access Program to develop an Action on Google with transactional and multimodal capabilities. We were so excited about the invitation that we began development immediately. Not only could we help fans find events via speech, but we could also present an interface to help them visualize their options and provide a mechanism for quick, seamless purchases.

The recent release of Ticketmaster’s Action on Google Assistant marks the result of our partnership. Now a fan can invoke the Ticketmaster Action by saying “Talk to Ticketmaster” and be led through a clear, crisp experience to find an event and purchase tickets.

How does it work?

googleAssistant

Google has integrated API.AI (an intuitive platform that enables the creation of natural, rich conversational experiences) into the Actions on Google development process. API.AI takes the user’s speech or text and breaks it down into the Intents that the Action developer defines. An Intent is simply a way to express what action should be taken based on what the user said. The Intent that API.AI creates can either be handled in the API.AI agent itself or sent to your webhook (via JSON) for fulfillment. The webhook can determine how to handle the Intent from there. For our specific case, we access the Ticketmaster Open Platform APIs to address the fan’s request. Once the webhook determines how to handle the Intent, the speech, text, or graphics data is sent back to API.AI, which formats the response and presents it to the user.

What are multimodal responses?

The multimodal feature provides an audiovisual component to your Action. The recently-released capability allows you to respond to your users using images, cards, lists, carousels, and suggestion chips. This flexibility means you choose the best way to present a user with options. Below are some examples of these UI elements. Lists, carousels, and suggestion chips are all selectable via tapping the element or speaking or typing the text that is on the element.

Example: multimodal elements available for Actions. The user is presented with a tappable list of options (left) or a horizontally scrolling carousel (right).

What is the Transactions API?

The Transactions API lets you accept purchases and reservations with your Action. The API provides a structure to help the user quickly build a shopping cart, supply a delivery address (if applicable), establish the payment method, check out, and confirm a purchase. For our specific case, we have chosen to email the fan their tickets.

Example: Checkout (left) and confirmation (right) steps in the Transactions API.

The integration of different payment methods is perhaps the greatest feature of the Transactions API. Google has provided a mechanism to either link your Action with an existing Google account or to link your existing web application service via OAuth 2.0. Using this mechanism, vendors can either use previously-stored payment methods or quickly integrate other widely-accepted payment processors such as Stripe, Braintree, or Vantiv.

 

Bonus track: Actions simplified for other developers

While Google provides a Node.js SDK to facilitate creating the multimodal and transactional experience, we wanted to create our Action using Kotlin. Since the Kotlin language permits top-level functions (similar to JavaScript) and has robust testing library support (Spek), using Kotlin (over Java) meant we could more easily port Google’s Node.js SDK. Furthermore, Kotlin compiles down to Java byte code so any other Java developers could use it as well. Our own Senior Android Engineer, Patrick Jackson, has taken the JSON spec and created an open-source Kotlin SDK. We encourage other developers to use and contribute to it freely.

The future of ticket purchasing

We are excited to release the Ticketmaster Action on Google Assistant. With the increasing accuracy of natural language processing tools, we believe virtual assistants are the future of human-computer interaction. This radical innovation is another step in the long history of live event ticket purchases: phone calls to the box office, internet searches on the home computer, mobile app purchases, and now, quick, natural conversations with a personal assistant. My favorite group, Straight No Chaser, comes to town every November, and I can’t wait to buy my tickets using Ticketmaster’s Action on Google Assistant!

Ticketmaster Demonstrates Cutting Edge Android Instant Apps Technology at Google I/O

GoogleIo_AIA-partners

It was a typical pleasant bright April day in Hollywood, CA but something  was in the air. Working with the very latest Instant App tools provided by Google, I was delighted to see the following message flash across my dark console, a first of its kind success for our Android development team:

“Successfully pushed instant apps to instantDev!”

Only a few of us who had worked on the Android Instant Apps project were aware that we had just pushed to the developer track, the first step in getting our Instant Apps to the Google Play Store. And only a few weeks later we had a working version ready to be whitelisted for production. 

Working with Google as part of the Instant Apps Early Access Program(EAP) was an incredible experience for our team. It’s always challenging, and sometimes even a bit scary to be at the very cutting edge of technology. At Ticketmaster we have always believed that “game attracts game”, so it was with great pleasure that our team took on this challenging opportunity.  Starting from a boot camp at Mountain View, through to our demo at Google I/O, it was certainly not as “Instant” as the name may imply.

If you work at a large organization, re-architecting your existing application to support Instant Apps, like any new technology, takes a bit of imagination and perseverance. We had to lean on other engineering teams like Google and Branch to help get to our desired experience. In the end it was well worth it. We are happy to have stayed true to our initial vision of using our Native OpenGL seatmap to create a truly unique Instant Apps experience that will provide new ways to attract fans with a better mobile experience. By pushing our vision to Google, we have helped to clear the roadblock for other engineers eager to use Native Libraries (NDK) such as gaming and camera applications in Instant Apps, and made a small milestone in what we believe will be a bright and exciting future for the Android platform.  

To help our fellow native Android developers, we are Giving Away Our Top 5 Secrets to Getting Android Instant Apps Work Started at Your Organization

Tackle Technical Debt.

        Find a way to tackle technical debt as part of your Instant Apps refactor. Tech debt has been a large part of my work at Ticketmaster, which I expanded on as a metaphor in a blog post back in 2015.  In our case, our Instant Apps architecture was able to speed our migration to the Model View Presenter (MVP) architecture pattern while also helping to move away from a deprecated networking stack, and to push forward in development against the new Ticketmaster Open Platform API’s. Developers don’t want to do throw-away work, so building something that will stand the test of time is a goal everyone can get behind, as well as providing new areas of growth.

TechStack

Be Excited to Show and Tell

Enthusiasm is contagious, and Instant Apps make for an incredible demo.  Get comfortable demoing already available Instant Apps functionality in meetings and in individual interactions. Find the best way to show how quickly you can take a user from a deep link to purchase completion, and what a difference it will make to reduce friction. Not everyone may understand why this is so gaming-changing, it’s true that links on the web work instantly already… which leads us to…

Have Pride in the Native Android Platform

        Instant Apps show the full benefit of the native Android platform. It helps to highlight the latest conveniences like SmartLock and Android Pay.  Become an advocate for the Android platform by highlighting key advantages over your mobile website like material design effects and reduced purchase friction.

Links and tracking are the key

        Initially we had a hard time understanding what data we needed to contain within our Instant Apps links, and how best to configure them, both in the Ticketmaster instant app and our full app. Teaming with partners like Branch made it possible for us to include extra information in the links that we would have had trouble supporting, including adding support for non-Android platforms. We used Fabric for easy analytics tracking in real time. It’s important to work out the details of your instant app links as soon as possible so that you can focus engineering resources on building out the key functionality in Instant Apps.

Aim for a Best in Class Fan Experience

        Don’t be afraid of aiming high. Native platform advancements have the ability to blow conventional websites out of the water. Although initially Google was not able to support our native seat map, they eventually were compelled to support our use case in their initial public SDK since we were able to work with them.  It’s always a good sign when your company is “pushing” Google, one of the most advanced software companies in the world.  We will continue working with the Ticketmaster Product team to make this into a great fan experience now that we have resolved the engineering challenges to support our seat map technology. 

Last but not least, we would like to thank all the people at Ticketmaster, Google and Branch who helped us develop our Instant Apps Demo for Google I/O.  Kanak Siwach and Aadithya Bangalore Keshavamurthy were both especially helpful in pushing development of our Instant Apps in their 10% time. Henry Ciruelas(@hdigga) is a great leader and manager and our entire QA team are the best in LA tech.  We are looking forward to working with Google and the rest of our team to improve and advance this exciting technology.  We know our fans deserve the best-in-class mobile purchase experience and believe that Instant Apps will help us rock the tech world!

To learn more about Instant Apps at Ticketmaster, please reach out to me on Twitter @JeffKelsey

Our journey to shorter release cycles

The team that is responsible for the development of the ticketing websites of Ticketmaster International has been around for many years.

Where we came from

When we started we had a rather undefined project based process where we released new versions of the site when a project was ready. It was generally many months between each new version. Sometimes over a year. We were using a waterfall approach.

The business made project requests and handed over their requirements to the product team. They then analysed the project and wrote a large specification that they handed over to the visual design team. When designs were done the engineering team analysed the specification and made a technical design. After that, we broke the project down in smaller work items and worked until we were done. Then testers got to work and reported bugs for anything that didn’t follow the specifications. After a few loops of bug fixing and testing again, the new version was tested again for regression issues.

Then the new version was handed over to the operational team that deployed it to a staging environment where the business could see the result. It was common that the end result did not meet the expectations of the stakeholders. All the handovers in the process meant that the original intent was lost.

water-fall_454x172

Where we come from (Image courtesy of iquestgroup.com)

One step at a time

Our first step to improving this was to bring the testers into the same team as the developers. That meant they could test right after something was done. The next step was to regularly demo what we had done for the product team and the business. That meant we got feedback earlier if we were not delivering what was asked for.

We started to do sprints of originally 3 weeks with a demo after each sprint. Then we started to bring product managers into our daily meetings to be closer to the development. Then we made the engineering team more involved in defining the work. We broke the project down to stories that would bring value to the end user. The development team was actively helping product managers breaking down the project to user stories.

We shortened our sprints to two weeks. We also started doing test driven development. That is a way to help driving good technical design by doing automatic tests even before the functionality is developed. We also wrote higher level tests that tested the system from the outside. We decided that a new release would happen every 8 weeks.

After doing that for a while, we moved down to a 5-week cycle. We still had low coverage of automatic tests so we had to test the product manually for regressions at the end of each release. We got stuck in this state for quite some time but were happy with the way things worked. After all, we had come a long way from how we used to work.

We took further steps to work better together. We moved people to the same office, we started to create tools for improving our efficiency of deploying and generally automated as many manual tasks as possible. Coverage of automatic test grew over time.

Our most recent step

We wanted to take a further step to reduce our cycle. This time, the goal was to release to production after every sprint. It had a more profound impact than the changes we did before. All stakeholders would be affected as everyone would need to do their part more often. We decided to ask all stakeholders what such a change would mean for them and what changes were needed to enable a 2-week release cycle. We started tackling the identified issues.

Of course, our main priority in this change is to maintain the high-quality standards we have previously set for ourselves. We measure the rate at which high priority bugs are reported from production and how often and for how long business disruptions occur.  

One leap of faith we have to do when releasing after every sprint is that we removed the regression testing step that we used to have at the end of the cycle. That’s not to mean that we don’t test for regressions. Every story has manual exploratory testing included. All our automatic tests also catch regression issues and they are fixed within minutes of being introduced.  We also need to deploy the new version of code without disrupting sales. The local staff in each country that use our product must be able to translate any new text to the local languages before production deployment.

What we learned

We now have some 2-week releases under our belt and things have gone well. It has uncovered lots of inefficiencies that were hidden before and made everyone rethink their ways of working. Doing something that feels wasteful can be tolerated when you do it only every fifth week. But doing it every other week gets you thinking of ways to improve efficiency much more. It has also made us take the incremental approach much more serious.

I’m very proud of what our team has accomplished so far. It has taken hard work and dedication to reach the point where we are now.  The next steps would be to come to the point where we release code as soon as something is done no matter how small the change.

 

What Ticketmaster is doing about professionalising software careers

“My wife is doing her accountancy exams so is busy tonight, so I’m staying in to look after the kids” is something you expect to hear in every day conversation. But what about “My partner is doing his software engineering training tonight so I’m unable to come out for a beer?” Why is this still unusual? Are software developers still a product of their bedroom and dorm room past, hacking things together and so often saying ‘yes’ when no other professional would in a similar situation?

Software development, let’s face it, is an immature industry. We build software, but not many of our parents generation did. What we often fail to realise is the number of different roles we play. When we started out in software, we most likely will have felt the excitement of building something, and seeing it work. But to get it to work properly, we likely had to do some testing. As our initial projects mushroom, we start to learn various constraints – so without realising it, we start thinking about the design. Then when we have something that other people start using, they might have found a problem with it. So we need to do some investigative work. Then we find that there are additional requirements which can’t be met by the current design – so we start to think about the architecture.

What we haven’t realised is that we’re doing all the parts of what is known as the Software Development Lifecycle (SDLC): Requirements, Design, Development, Testing & Support.

Let’s think about other roles we play in our life. We may be parents, sons & daughters, friends and neighbours. But what about surfers, fans, climbers, shoppers and garage organisers? What we learn from looking at our lives that way, is that if we don’t plan for these roles, or put any time into them, then there are most likely negative consequences. If as a parent, we put no time or effort into parenting, or trying to be better as a parent, then that’s likely going to have a detrimental effect on us and our children. If as a garage organiser we put no time or effort planning or being a garage organiser, then our garage will remain a mess, and it’ll be impossible to find things when we need them.

sdlc

So the same goes for us as software engineers. We need to plan, prepare and learn how to master the different roles we play, or there will be negative consequences. Software support is often seen as less glamorous than developing, but as engineers it requires sharpening our detective skills to be able to find a metaphorical needle in a haystack. This requires a completely different set of skills to development. So in order to take ourselves more professionally, we need to gain an awareness of these different roles, and gain maturity in developing our skills in these different areas.

Here at Ticketmaster we’ve been Agile for over 6 years now, and we’ve come to the realisation that with that level of maturity, multi-disciplined skills are required in order for development teams to continue to grow in a healthy way. When we reviewed our career progression processes across multiple engineering locations, we also found a lack of consistency across job roles and criteria for career progression. We came to the conclusion that without a transparent process that was consistent across all our teams, it was hard to set expectations and provide our engineers with the optimum experience for growing how they wanted to in their chosen profession.

So what we’ve done at Ticketmaster to address these issues is create a career map – a flexible set of pathways built from what we do as engineers day to day, but that provides both a range of options for career progression along with outline steps of how to get there. This provides mastery of any chosen career progression route, with a clear vision of the outcome that you’re looking for as an engineer.

How did we do this? We used a number of industry standard resources, building on the SWECOM model created by the IEEE, and using influences from other industry models such as SFIA. This has enabled us to build a three part progression guide:

progression guide

  1. SDLC skills – these are built up from the SWECOM model and outline 5 maturity steps in each professional skill, built from the SDLC.
  2. Technical skills – these have been built up using a platform and technology neutral approach, again providing a 5 step program of technical skill for all areas pertinent to Ticketmaster’s engineering strategy.
  3. Behavioural skills – we have outlined four areas for awareness and growing maturity that we believe make the biggest difference to our success as a people first organisation: Team work, Innovation, Results orientation, Professionalism. We can’t and don’t want to mandate behaviour, so we provide lots of examples of what maturity looks like at each level.

So armed with a clear map of what is required to progress, engineers are empowered to make this journey with the support of their colleagues. How do we do that? We used the guiding principles from Drive by Daniel Pink.

Autonomy

It was really important to us that we avoid this scenario, which you may be familiar with:dt_c131214

Again, we considered the engineering profession from the viewpoint of different roles, and saw the role of the manager as a coach, like Boris Becker working with Novak Djokovic. We want to create an environment in which engineers can excel, rather than be micro-managed or stressed by unnecessary distractions. So we trained all our managers to operate with a coaching model in mind at all times, supporting and only intervening from the sidelines when required.

Mastery

We’ve empowered our engineering teams by giving them the tools and resources required to progress their careers – and them giving them responsibility for progression. The progression guide makes it clear what is required to progress to the next role. The guide was put together through numerous rounds of consultation, to ensure everyone had a say in how it was constructed. In order to satisfy the requirements of the next role, we have introduced a peer review and assessment process, whereby individuals submit their evidence to show they have mastered the professional, technical and behavioural skills to the appropriate level. What we learnt from engineering led organisations such as Google as well as other industries is not to have a single peer reviewing, but to have a minimum of three to ensure bias is minimised and the process is as objective, fair and transparent as possible.

We’ve rolled out training across all our engineering teams on how the career map process works, and run workshops on how to create suitable objectives in order to reach the requirements for each role. At each stage we have looked to put responsibility for progression with the engineer, but provided suitable support structures to enable and facilitate progression. This includes an online tool specifically created to help manage progress, providing a simple view for instantly seeing what steps are required and a convenient way to store evidence.

Purpose

Software engineering is constantly exploring unchartered territory. That’s why agile has won out over waterfall as a methodology because iterative exploration and learning is almost always better than educated guesswork. Like software projects, software careers are also subject to a high level of flux because of the nature of the industry. Established skills can be rendered redundant overnight by the introduction of a new technology, product or service (e.g. the iPhone, or Uber). By providing engineers with multiple options in terms of charting their career path, we believe that we can avoid exposure to the threat of redundancy of specific technologies by building opportunities for career breadth and depth.

This enables engineers to not only change as the industry does, but also to facilitate proactivity rather than being constantly reactionary, which is far more stressful. Undue stress does not contribute to a healthy working environment, which is what we’re constantly striving for.

But we’re also looking to professionalise our industry, and make software engineering an even more exciting destination than it was a generation ago, when it was really in its infancy. By building our approach on existing standards and the best disciplines from other industries, we’re aiming to show that we’re part of an extremely vibrant but also professional industry which will endure for millennia to come.

Black Friday – Celebrating savings through Kaizen

Whilst the internet whipped itself up into a frenzy about discounted televisions, here at Ticketmaster International we were celebrating savings of a different nature. For a few years, we have been using Kaizen techniques to improve efficiency and quality. “Kaizen”, a term borrowed from lean manufacturing, can be translated from Japanese to mean “good change”: it is a continuous improvement technique which recognises that the individual doing the job is the expert on that job and encourages individuals to make small, incremental changes that are within their power to implement.

Kaizen has been embedded in our business in different ways. For our developers who already use agile techniques, including scrum and Kanban, Kaizen was already at the heart of their operation. Regular retrospective sessions are used to identify, shape and get commitment to incremental changes to development and team behaviour. But whilst Kaizen is familiar to agile developers, it was an alien term to people elsewhere in the business. We initiated a programme to encourage wider adoption of Kaizen and empowered individuals to improve the processes they worked on a daily basis. A reward scheme was initiated and a shortlist of Kaizen implementations is reviewed regularly by the Exec team and celebrated through a number of internal communication channels.

Recently we have seen teams such as Ticketmaster Denmark and our contact centre team in the UK taking the Kaizen programme and making it their own. The contact centre team have started an initiative focussing on incremental changes that improve the customer journey. In Denmark, a Kaizen working group has been formed, not only to encourage Kaizen in their business, but to look at the Kaizen improvements that have been made elsewhere and see how they can be adapted and reused.

Black Friday is a US shopping tradition that is being exported through major online retailers such as Amazon. So with all hype about savings all around us, I asked people from our international business to share their Kaizen time savings and improvements. Here are some of their stories:

  • “We simplified the process for customer services engaging with event promoters. By cutting out intermediary steps they calculate they have saved 6 hours per month.”
  • “Our team have been doing some work to reduce the solution size, which has had a massive impact on [software] build times. So far we have reduced the build time of the solution from around 7 minutes to 2.8 minutes which is a saving of nearly 5 hours per day across the team.”
  • “By standardising print codes in Ireland we reduced duplication and conflict, saving 62 hours per month”
  • “One of my colleagues wrote me a script to automate the collection of KPI data. Hugely helpful and saves me at least 1 day each month.”
  • “We improved the guidance for visitors to the Copenhagen Office which led to a £255 reduction in metro fines and delays in the first 9 months.”

It is great to see Kaizen continuous improvement becoming more mainstream in our business and the benefits of small, incremental change being celebrated by such a diverse group. We will continue to evangelise Kaizen and provide coaching to teams who are interested in adopting it as well as other lean techniques and look forward to sharing more success stories with you on Black Friday next year!

In Search of a Reactive Framework (or: How we select new technologies)

About seven or eight months ago we started looking at new and improved ways of creating services instead of our tried and tested Spring framework based approaches. The Spring framework certainly has its merits and we have used it with much success, however, the service we were about to write, called Gateway, was to route millions of requests to other services further down in our architecture layers:

GatewayDiagram_v1

We knew that the service had to run efficiently (thereby saving on hardware) and scale effectively. The event driven, reactive approach was one that we were looking to embrace. After much research we had some concerns. Not only is that space full of different frameworks at different levels of maturity, but we also had to consider our current skill set, which is predominantly Java with a small amount of Scala, Ruby, Clojure (which our data science guys use) and a handful of other languages we’ve picked up through company acquisitions. How could we adopt this new paradigm in the easiest possible way?

What this blog post will detail is the approach we used to select the framework we chose. It’s a tried and tested approach we’ve used before and will continue to use and improve upon in the future.

How we did it

Before we describe the stages of what we did, suffice to say that there is no point in doing a technology selection without a business context and an idea of the service(s) a framework will be used to build.

The technology selection was broken up into the following steps:

  • Identify principles – these are the rules that the framework must adhere to. These are properties that a framework can meet in different ways and contain a degree of flexibility
  • Identify constraints – these are rules that cannot be broken or deviated from in any way. If any are broken, the framework is no longer a candidate.
  • Create a short list of 5 – 10 candidate frameworks
  • Determine high-level requirements and rank using MoSCoW prioritisation
    • Read the documentation, Google groups and other relevant articles and trend data to determine conformance to the requirements, including all options and workarounds if applicable.
    • If any of the Musts are broken by a candidate then it is dropped
    • Create a short list of, ideally, three candidates
  • Create a second set of more detailed requirements, rank using MoSCoW and weight in terms of importance
  • Determine the architecturally significant business stories and error scenarios that the service to be built from the framework needs to implement:
    • Write the end-to-end acceptance tests for these stories. The primary scenario with one or two error scenarios is sufficient.
    • Implement these end to end acceptance tests in all three frameworks – this will give an idea of how well the framework meets the service’s paradigm(s), how easy it is to work with in the develop/test cycle and also make sure to post on the message boards or mailing lists to see how quickly a response arrives from the framework maintainers.
    • Update the second set of more detailed requirements with the results of this experience

Our results are pretty detailed so have been added into a separate PDF that you can download here. We have left this in raw format and hope that they will be a good reference for others.

Outcome and experiences to date

As you can see from the PDF of results, we chose Vertx. It won out not only because of its raw power, but because of it’s fantastic architecture, implementation, ease of use, Google Groups support and the fact that Red Hat employs a small team to develop and maintain it. Indeed, a few weeks after we selected it, it was announced that Red Hat hired two more engineers to work on Vertx.

So overall we have been very happy with our selection of Vertx. We had version 2.1.5 running in production for several months and recently upgrade to Vertx 3. The maintainers’ swift response on the Vertx Google Group definitely helped during our initial development phase and during the upgrade to version 3. Performance wise, the framework is extremely fast and we know that any slow down is most likely due to what we have implemented. Adoption has been a success. From a team of two developers, we scaled to four and now eight. Choosing a Java based framework has been a boon as the only additional complexity that needed to be learned by the developers joining the team was the event driven nature of Vertx (i.e. the framework itself). Had we chosen Scala/Play it would have been much harder. Indeed, with the success of Vertx, our decision to standardise on the JVM as a platform and our embracing of the reactive approach, we have a couple of services being built using Scala and one using Scala/Play. It would be great to hear of your experiences using reactive frameworks. Which ones did you choose? How easy were they to adopt? Please leave a comment, below.

Shipping High Quality Mobile Apps

I want to share a story about a recent career transition I made – moving from program management to quality engineering . I was very nervous about the change since I wasn’t 100% sure whether the decision I made was the right one. There was a huge opportunity on the table to deliver more value to our fans more often. The risk of course was that quality would slip.

Read on to hear how we became featured in the Google Play Store and in Android Central as “AC editors’ Apps of the Week”!

Joining the Android Team

As I joined the passionate team of Android Engineers I knew it was a new beginning of something great and challenging for all of us. As a team we quickly built a strong app foundation and developed a culture of teamwork and support for one another. Our fundamental rule was: check your ego at the door! Everyone on the team supported each other like family. We had a few goals in mind:

  • Reduce Regression time from 2-3 weeks to 8 hrs
  • Build once and ship everywhere
  • Ship high quality software together

In this post, I want to share my personal experience as well as how my team was able to set up our automation framework.

Why Automation?

It all started with a few automation training sessions with our Quality Architect – Eric Lee – in a small conference room on the 2nd floor of our building. As I remember the room was packed with eager QA engineers wanting to learn about making automation work for our mobile apps. Eric demoed sample tests that navigated through a few pages of our app utilizing Cucumber, Appium and Java. When we came out of the training session we realized how we could utilize type of tests to help us meet our main goal “Reduce regression time from 2-3 weeks to 8 hrs”.

Regression test
One of our regression tests

We used our 10% time to setup a small device lab. We started with one device since we came across some challenges running the Ticketmaster Android app across multiple devices due to our Appium configuration. We made an update to our configuration assigning each instance of Appium a unique port as well as assigning a unique port to each of the devices.

Config Changes
Screen Shot 2015-10-23 at 12.06.12 PM

After making these changes, we’re able to execute our test suite across four different devices simultaneously. Our regression tests run overnight and detect any ongoing problems while development is in progress. The team gets a detailed report of what failed in our automation tests bringing everyone aware of any issues that may have been introduced during development. This helps our team bring focus on critical release regressions and allows us to collaborate with one another to come up with the highest quality app.

Android Build pipeline
AndroidBuildpipeline

Automation report
Automationreport

In 2014 having no automation coverage we released our apps only 4 times. On the other hand, this year we have published more than 19 versions of our TM app to the market place. What a difference a year makes! To date, our automation coverage is up to 63% focusing on our critical path of our app. We are still not done and continuing to add more features into our automation suite to get us closer to our goal in reducing our regression time to 8 hrs. With automation in place, we are equipped to have more frequent releases to the marketplace bringing key features to our fans quicker.

Detailed automation report

Next up for the android team is to publish our newly designed app across all international markets. This will give our team a more maintainable code base supporting all regions. As you can imagine, our automation is critical to supporting more markets. The ability to run the same tests across the different binaries for each region and get detailed test reports for very little additional effort is invaluable. Our monthly releases going forward will support a total of 5 markets – build once and ship everywhere!

Culture Change

Shipping High Quality Mobile Apps – Our Android team has the “do it and let’s do it together” attitude that makes me want to come to work every day. During the past few months, our android team have made significant improvements to how we managed our releases and our sprint schedules. With our project and product manager’s help organizing our stories, our grooming sessions have become more engaging and interactive. That helps our team bring focus to the features that we will be developing. Our demos and retrospectives have improved as well – our engineers showcase their work to the stakeholders and other teams, giving each engineer ownership of the work they completed. One of our stakeholders stated this after one of our demos:

“This is a TEAM!

Well done guys. Your pride shows in your work, and it also showed in the demos you gave at the last showcase. I am inspired and impressed. You have improved over the past couple of months, and that shows in this latest release of your app.”

Our quality and software engineers are very passionate about delivering the highest quality features to our fans. For each and every submission and release, the team’s ownership and responsibility is second to none. Whether it’s looking at the reviews on the Google Play store, our crash-free rate, daily active users – the team has great pride and commitment to deliver a high quality app.

Being featured on Google Play Store and Android Central as “AC editors’ Apps of the Week” was a great achievement thanks to the hard work and dedication of the team. We’re continuing to make changes every day to help our team be more efficient. A great example of this is our recent decision to include an app release within each sprint, inclusive of the sprint’s work (as opposed to releasing in the subsequent sprint). Our Android team has become like a family. We enjoy working with each other and we build software in a cohesive way. We are a dedicated team and committed to a mission to be better each day when we come to work at Ticketmaster.

References:

Jenkins: https://jenkins-ci.org/

Appium: http://appium.io/

Selenium: http://www.seleniumhq.org/projects/grid/

Cucumber: https://cucumber.io/docs