"All tests in today's automated regression run have been marked as Untested. What happened?"

"No notifications are being sent for test runs on the channel"

"I pulled latest code, and the framework dependency shows compilation error"

"What does this new method in the framework do?"

How often do you hear such things within your team?

As Quality champions, we need to walk the talk. When we expect our developers to write quality code, write unit tests, build features without introducing bugs, the onus lies on us (as test engineers) to do the same. With almost every test engineering team writing automated tests to check functionality of their products and services, it becomes very important to ensure that the test automation framework and the test scripts are bug-free and follow good standards of software engineering.

It cannot be stressed enough that test automation code should be as good as production code. In order to build production-quality test automation framework and scripts, a number of steps can be taken at:

1. Code & System Level

2. Process & People Level

Our test engineering team went through a transition from having random & unexpected failing test runs to having greater confidence in the quality of the tests. Learn from this case study of our journey to ensure that end-end UI automated tests are built with quality in mind. We will also see demonstration of some of the use cases.

Instead of buying test devices and maintaining them on-premise, there is an ongoing trend to facilitate cloud providers for UI test automation. This talk will explain the basics and provide an overview of the advantages and limitations of this approach. It will also tell the story of how we moved from running a handful of tests against four of our own test devices to executing 100+ scenarios (and counting) on AWS Device Farm, Browserstack and a local simulator farm.