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! If you have any questions about these roles, feel free to write me.
