Introducing native E2E testing: Learnings from the Senior Engineering Program for Women
I made company-wide impact by successfully delivering the introduction of native end-to-end (E2E) testing in mini versions of the Klarna app. The goal was to have automated feature regression tests in our pipelines. I developed this as part of a program for senior engineering women, and today, I want to share the insights and learnings I gained from this experience.
Creating fair and equal opportunities for women
How do we offer women equal and fair opportunities in an industry dominated by men?
Well, there are many ways to work on this topic. One that piqued my curiosity was Klarna’s Senior Engineering Program for Women (SEPW).
As you might wonder as well, my initial thoughts on it as with any other initiatives like this came with a lot of reservations:
Is this fair? Is this the best way for me to ensure that I’m being fairly evaluated? Will it look like I am being brought to a speedlane towards an easy promotion if I happen to get one because I’m a woman? Are we going to get treated like tokens? Is this all just a marketing strategy to promote? Am I being part of and legitimizing something that has no real content and value for my career or other women? What will everyone think?
When we are faced to join initiatives related to gender gap improvements, we might fall into the trap of having all the perfect and right answers before we take risks, or we can accept that there will never be the perfectly carved, impactful and life-changing solution at our doorstep.
We can only experiment and learn from the results to make better decisions as we help evolving into a hopefully more gender-fair world.
As a woman in engineering, I understand the issues, but I don’t claim to have all the answers. And that’s ok.
The program
The SEPW is a way for Klarna to acknowledge and accelerate the professional development of promising engineers and promote diversity within engineering. The 6 month program is designed with the individual’s growth as the main focus, and based on four themes: Execution, Collaboration and Communication, Technology, and Influence.
It includes coaching sessions with exercises such as presenting systems architecture and solutions, and the participants are selected with support from the engineering leads of the department, lasting around 6 months, to a group of 6–8 women. You can find more information on this here.
Going for it
I was offered a spot on the program and after reflecting on the questions I had, I decided to accept. The very first immediate valuable point was that I reached out to past participants to hear about their experience in the program, and the collaboration and support started right there.
Then came figuring out how to balance it with my team’s day-to-day work, in order to adjust the goals and size of the project based on that.
I created a list of projects, defined their impact, duration and effort and asked for feedback from key people.
Finding a project
From my own experience working on the frontend at Klarna and by talking to many other engineers that do the same, a clear pain that most of these teams have became clear: the testing and validation of the release candidate that goes into the app each week.
A lot of manual testing goes into it, which means testing our feature flows (mostly the same each week) in two platforms — iOS and Android. While we do have many tools for different types of automated testing, we were missing one to allow real end to end testing in native apps. One that could truly replace much of, or all release testing.
There were actually multiple attempts in the past to bring native E2E tests to the app for the overall teams along the years, but for a mix of different reasons, they never came to fruition.
After I discovered this opportunity, I took upon myself to work on introducing support to E2E testing on the native platforms.
Along the way, I have crossed paths and worked together with engineers that work on:
- the core frontend tooling, reliability and pipelines of the app
- other teams and departments that were also interested in and working closely with tests, or tooling, or help out the core teams and have a lot of know-how
- end to end testing as a new initiative on its own
- something else but wanted to help test the early stages of the solution
I got the big picture of the state of many of the central pieces in the app, while also spotting redundant work that people were doing between teams and supported in bridging those efforts.
This helped me figure out a more precise plan and goals for myself as well.
Technical challenges and improvements
To bring this project to life, I introduced several changes to our tooling, a few of which I will be illustrating below.
Typescript and globals
I discovered that through different products included in our monorepo, a few Typescript globals were defined, including Jest and JQuery. Since I wanted to include Typescript support in the test definitions, and we were instead using Mocha and Appium, syntax like “expect” or “$” was colliding with the predefined globals. Since these were used in several places, it would be a challenge in itself to migrate the projects to use local definitions.
A big takeaway from this is to always avoid defining globals as there are other libraries that you might want to use in your project later that might have the same syntax commands as your current ones.
To address this, the first step was to exclude the Appium tests folders from the global tsconfig:
"exclude": ["(…)/__appium__/**/*"]In the global clients tsconfig I added Appium test files to the exclusion list:
{
"exclude": ["(…)/__appium__/**/*"]
}Then, in the Appium tooling code, I included only the local files and tests, and also had to ignore the Jest types:
{
"include": ["(…)/__appium__/**/*”, “./**/*"],
"exclude": ["node_modules/@types/jest"]
}In our deprecated Appium tooling, we had centralized tests in a single folder. Since collocation of tests was also introduced, meaning each test file would be able to live next to its feature and be moved around together, and features still needed to be using the global tsconfig, each feature’s tests folder was required to include a tsconfig extending the tooling tsconfig as follows:
{
"extends": "(…)/appium/tsconfig.json"
}Naming conventions
I have also defined a specific namespace for Appium tests:
"app/__appium__/**/*"And in order to help the evaluation and discoverability by our tooling, including it in the .eslintrc.js in the same format:
"**/*.appium-spec"Sub dependencies nightmare
Since I moved the Appium tests from a separate standalone subproject with its own configuration and local dependencies to a central root location in the repo, and by consequence included this tool’s dependencies in the root package.json, a few issues came up with multiple versions of some common sub dependencies used already as well by the rest of the app. This is protected to avoid dependency redundancy in the project, and we use Diglett for detecting these. Since several of these sub dependencies were very common and used already by other areas of our app, it would be nearly impossible to version bump and match all of them in the scope of this project, so I added the needed entries to diglettignore.txt.
The coaching
While working on this project, the SEPW provided coaching sessions. Internal and external presenters shared their expertise, allowing me to apply this knowledge to my project and beyond. Additionally, we as participants had opportunities to present our progress and practice on leadership soft skills, while receiving valuable feedback from coaches and fellow women in the program.
In the scope of these networking sessions, I talked to other women at my level about their work, their SEPW project, and the various engineering, work and gender related challenges they face. We shouldn’t underestimate the power this type of connection brings.
Outcomes
At the end of the program, I delivered on my set goal: working E2E tests in native in feature apps — with efficient runs and less friction in mind, for an enhanced developer experience and speedier pipelines. Ultimately, using this brings a lot more trust and robustness in any changes we make in our and others’ features, knowing that these will not introduce a corner case bug that we only detect the following week while doing release testing once again.
Along with all of this I also brought test collocation, in the features, so that we can scale to many teams easily, and more importantly, have a clear view of ownership and accountability. This has also become the reference for doing the same effort of co-locating our functioning central Cypress tests, and the testing ground to the challenges of that migration, which will save the core teams’ precious implementation time.
I have gained valuable skills in technologies such as Webdriver.io, Appium, Mocha, and Allure.
And ultimately, by promoting these achievements in our Slack channels, I saw more and more people interested and courageous to introduce these types of tests in their own features, reaching out to me for support setting up their local environment.
Learnings
I was able to show what I can do, while improving important tools and my own skills along the way.
I have learned how our core tooling code is set up, and was able to contribute with both suggestions and concrete actions.
I have realized that this type of initiative offers opportunities that may not otherwise be accessible due to various factors, including personal drive, team context, and yes, unconscious gender bias.
What is also very motivating is that, as I finished the program and my project, other women who were curious about the program or already joined a new iteration of it, reached out to me asking for opinions, support and advice — reinforcing the importance of being/having a role model and reference as an engineer.
And of course, I am now also part of a network of fellow engineers from different parts of the company that has participated in the program and the different coaching sessions, as well as the organizers who are clearly invested in the topic of diversity and gender equity. A network with an amazing sense of belonging and shared experiences.
The visibility of my participation on the program has allowed me to promote the initiative, my project and support for Women at Klarna. But also beyond, to effectively contribute to making the program better, and being part of company-wide initiatives that impact the work on the gender gap.
If I could have any advice for my past self, I would say “It will be challenging. It will be completely unfamiliar territory. That’s why you have to go for it!”.
