The benefits of unifying our test automation technology in QA

by Ahmed El-Deeb | Berlin
| Foodora
| Foodpanda

14 March 2019

Einstein spent the last 30 years of his life searching for a theory that would unify the universe – the “Theory of Everything”. Such unification would enable us to understand, explain, and potentially manipulate a complex phenomenon composed of multiple forces. We can better understand how parts are interacting together; opening a myriad of applications from time travel to artificial intelligence. At Delivery Hero we did it!

Not in modern physics of course, but we have unified our test automation technology with our product development technology stack – that is, we brought test automation closer to product engineering. To that objective, we ditched our years old standalone test automation frameworks that we built using a programming language different from the one that the product is developed with as well as third party frameworks and code libraries; (e.g. selenium webdriver, capybara, and calabash). We embarked on an ambitious journey of building three totally new test automation frameworks, from the ground up, using the same technology stack and native frameworks as our three product engineering lines: web, Android, and iOS.You may ask yourself, but why?

Software
Engineers and Test Automation Engineers can now speak the same
language. Not only does this increase Software Engineers’ collaboration
in developing tests for their own code, but also takes both types of
Engineers’ skills to the next level through teamwork and technical
dialogues. The code review process is now shared between automation and
development teams, technical challenges are discussed across both teams
for driving solutions, and efforts as well as ideas are cross-fertilised
with testing knowledge, technical innovation and problem solving. In
the end, Software Engineers and Automation Engineers learn from each
other and collaborate closely towards achieving one end result, which is
Quality – through automated processes. Both teams engineer quality!

It
removed roadblocks that long irritated and undermined Test Automation
Engineers’ productivity as their code needed to deal with applications
as a black-box; for instance, preparing application state, code
libraries upgrades, quering element IDs, managing sessions, and mocking
some operations. Now application code and test code are both living in
the same project and have access to the same resources. In other words,
test automation is now native. This increased test automation
capabilities and relieved test automation engineers from tedious
time-consuming housekeeping tasks; empowering them with the technical
capabilities as well as the mental space to focus on developing
value-added testing solutions.

Test automation technological
development will no longer be lagging behind advances in application
development libraries or OS versions. In the olden days, the test
automation team used to wait until third party frameworks provided an
update in response to new development technology releases; such as
development IDEs or a new OS release. Now, since our test automation
frameworks are utilizing native development frameworks, they both get
the same update at relatively the same time. For example, the new Xcode
goes for both the iOS app and the test automation framework too.

Test
Automation Engineers now have the visibility to better understand the
code-base of their product; from testing perspective, enabling them to
make better informed test design and to write test automation code that
best exercises product code, to achieving effective test coverage.
Testing discussion among both teams based on such knowledge also enables
engineers to make their application more testable.

Algorithmic
thinking and problem solving approach is now shared between both teams,
yielding effective automation code that works in harmony with how the
application is working; or even spot when app design is not so smart.
For instance, understanding how mobile apps are handling idle resources
enables Software Engineers to formulate a smarter way of handling them
and changing accordingly how apps are handling such resources.
Additionally, this enables our Test Automation Engineers to develop much
more effective automation code that manipulates idle resources based on
the type needed in each test scenario. This massive improvement is a
clear departure from the old standalone approach that mandated using
arbitrary Sleeps or Waits; since old automation code knew nothing about
this.

Now it’s easier to unify both test automation and
application development infrastructure and build processes essential for
building a true DevOps CI/CD pipeline. Test automation code can now be
optimized to run at the scale of PR with simple commands invoked from
the development project. Major releases can be auto-approved along the
way until they get deployed to production.

In conclusion, we are
happy about getting closer to development and we have been reaping the
benefits from day one. Through this unification of both endeavors, we
are taking test automation to the next level by integrating it into
technological development, we are expanding test automation capabilities
and usefulness, we are also bumping up our teams’ skill-set by adding
testing skills to Software Engineers and technical skills to Automation
Engineers, and we are setting the stage for industry class DevOps CI/CD
pipeline that goes from PR to deployment to production without human
interaction. There are still a few things to learn and there are some
rough edges to be sorted out, but that’s what makes this undertaking
even more exciting for us – we love to continuously learn and
experiment.

Sounds like fun to you? We’re looking for a Test Automation Engineer to support us taking test automation to the next level! Our team is also looking for a Sr. QA Analyst to join us. If you have any questions about these roles, feel free to write me.