Andreas Markussen

The streaming service YouSee TV and Film releases new client software every six weeks, and the limiting factor is the time it takes to do the manual regression test—14 days distributed over six platforms.

To speed this up, I implemented a new QA strategy that includes behavior-driven development and new test automation framework implementations in the same language that front-end developers are using.

The QAs have been trained to run clarification workshops in Example Mapping and have formulated more than 150 businesses.

The use of BDD and Gherkin enables us to have both living documentation and one source of truth for our user-facing requirements across all client types (Android, iOS, web, WebTV, Android TV, tvOS).

Later, we will add set up boxes and smart TV apps.

During the first months of our automatic test implementation, there was no attention to the number of test cases developed. The developers did not fix their broken pipelines for weeks.

We needed to visualize this problem, so I did a back-end AWS Lambda microservice that could receive automatic test reports from Android, Web, iOS, and others to compare runtimes and test statistics.

I added this to the Android and web build pipelines so the iOS team could do it based on the documentation provided.

This enabled us to see if the same business scenario was broken across multiple front ends and thereby suggest whether the back end or an external dependency was causing the failing test.

The periods where the developers' pipelines were red were drastically reduced. We all saw this and were aware of it. This made the POs much more supportive.

We were able to compare the number of business scenarios that were automated (test case count) and the stability and speed (test case execution times).

The developers also got good information back in their CI/CD tools and provided them with fast feedback.

I had to learn Kotlin, Android, Espresso, and Cucumber in six weeks to deliver a test flow of our player app. This delivery included understanding a handful of obstacles and improving the developers' built pipeline to get a decent working pace.

I removed 50% of the waiting time by understanding and optimizing the configuration of Gradle and Firebase.

We finished the project sooner than expected because we were able to do more iterations.

Nemlig.com had an old classical Selenium Java-based web test automation framework, which was not helping them in their release decisions.

I evaluated the issues and recommended replacing the solution with a Cucumber TypeScript Protractor-based solution—state-of-the-art for Angular in 2018—and they agreed that I should make a prototype.

I chose TypeScript and Protractor so that the QA engineers and the web front-end developers could share code and tool stack to enable better collaboration.

I architected the solution, formulated and automated the first 10 business scenarios, and taught the entire Scrum team about BDD.

The QA's wrote the business scenarios, POs approved the scenarios, and the automation engineers automated them.

This meant that I could hand over the automation framework and the process to the team, and they are currently working independently.