Time for talent with Bea Storm

Hi, my name is Bea, and it’s a pleasure to meet you virtually!

I joined Tactile in 2019 as a QA Tester, initially working on Lily’s Garden shortly after its launch. I was thrilled to be one of the first people to experience new story days each week, and even after five years, I’m still captivated by the story—it always makes me smile when I play it.

Since then, my role has shifted to Automation Engineering. It’s been a long journey to reach my dream job in QA Automation, and I am incredibly grateful to have experienced that journey at Tactile. The path wasn’t always easy, but the support and opportunities I’ve had here have helped me grow both personally and professionally.

Before Tactile

… I worked as a nutritionist in my hometown in Transylvania. I completed my bachelor’s degree in Nutrition and Dietetics at a medical university. But, when I moved to Denmark, I found finding a job in my field challenging. This led me to rethink my career path and explore new opportunities.

Transitioning into the gaming industry was a big shift, but the core of my motivation remained the same: a desire to learn and tackle new and exciting challenges. While working as a nutritionist presented its own difficulties, especially when helping patients make life-changing dietary adjustments, I eventually found more satisfaction in solving problems through automation rather than addressing human health issues. Both roles, however, require careful analysis and problem-solving, and I’ve enjoyed the journey that led me to where I am today.

Joining Tactile

I started as a Story tester and moved into a functional testing role early in my career at Tactile, which required more in-depth test analysis methods. My curiosity and love for learning have always driven me to expand my knowledge. I began studying game development to understand how and where games could break and what areas needed the most testing.

This drive led me to work as an Area Setup Specialist for Penny & Flo, opening up an entirely new world. I discovered my passion for working with Unity and learning programming, which inspired me to apply for a Junior Automation Engineer role.

From Manual QA to Automation Engineering

The shift from manual QA to automation has been exciting, but challenging. Over time, I’ve gained a better understanding of our processes, making the move from manual testing to writing scripts and automating test cases easier.

My current role focuses on building strong collaboration between the manual and automation QA teams. We’ve set a goal to improve QA by working closely together and training the manual QA team on the automation tools we’ve created to enhance our testing process.

This teamwork improved the quality of overall testing, and I’m proud to have helped the manual team grow by showing them how to use these tools and improve their work. It’s been rewarding to be part of this change and help raise the quality at Tactile.

Having an impact

I’m part of a fast-paced, dynamic team that constantly pushes each other to improve. We regularly hold skill-sharing sessions, learning from one another’s work, which is a fantastic opportunity for me as a junior member to grow and gain new skills.

What I love most about Tactile is the flat structure. You really feel it. I’ve had moments where I came up with an idea, and I could go straight to leadership to share it. They listened and discussed it with me, which made me feel valued at every level of the company.

The keys to success

At the start of any career, staying motivated and curious is important—especially in Quality Assurance. Curiosity is key. I’ve always tried to look at my testing tasks from different angles, wondering how things could break or how I could gather more data. Working in the game industry, part of entertainment makes the process even more fun and rewarding. It’s great to be part of an environment where people are relaxed, fun, and passionate about their work.

At Tactile, we create games with genuine heart; that passion really shines through in everything we do.

Two weeks ago, 24 Tactilers (a mix of new and seasoned Tactilers from different teams and functions) headed out to a forest near Roskilde, Denmark for a day of team building. The goal? Strengthening relationships, building closer bonds, and boosting collaboration—all while having some fun in the great outdoors.

Our Head of Talent & Culture, Sarah, joined in on the adventure and shares a bit about the experience below!

Tactile: Sarah, what is your team’s approach to Learning & Development within Tactile?

Sarah: The Talent & Culture team at Tactile is not your traditional HR department. We focus on being agile in offering support and activities throughout the Tactiler journey (from onboarding to offboarding), embracing adaptive implementation rather than a “one size fits all” approach. While some activities are fixed to certain times of the year—like salary reviews and development talks—we generally don’t work on fixed projects. Instead, we prefer to stay flexible, choosing initiatives that make sense for Tactile’s current needs. Over the past year, we’ve been working on enhancing our Learning & Development offerings.

The traditional approach to Learning & Development wouldn’t really work here. We have a flat structure, operate in a lean way, and as for seniority job titles –  well, those are more for LinkedIn profiles 🙂 So, we’ve had to think outside the box—and honestly, we don’t even believe in putting people in boxes.

Like many growing companies, we’ve brought in a lot of new people over the past few years. At the same time, we’re lucky to have a good number of long-term Tactilers. The challenge is that some of our more seasoned Tactilers aren’t always working closely with the newer ones, or even interacting with them on a regular basis, unless of course they are sat in the same team.

That got us thinking: our approach to Learning & Development shouldn’t be siloed. Instead of the typical route—grouping people by tenure, title, or team in workshops—we thought, why not mix it up?

Tactile: So, how did the idea of mixing people up in workshops evolve into an Outdoor Adventure?

Sarah: The idea came from wanting to create cohorts—groups of people with different tenures, functions, and backgrounds—who would go through various learning modules together. These modules are designed to cover the fundamental skills needed to succeed at Tactile, including both soft skills and technical abilities.

But we also wanted to break down barriers and create closer relationships between the group members. We figured the best way to do that was to give them an experience outside of work where they could push themselves, support each other, and, of course, socialize. That’s where the Outdoor Adventure came into play.

As with everything at Tactile, we wanted the team-building experience to be outside the box. We teamed up with Banff People to design an Outdoor Adventure that included a mission where teams had to solve both physical and mental challenges.

The adventure lasted a day and a half. It started with a workshop on team dynamics, followed by the mission itself. After a day full of challenges, we camped out in tents for the night. The next morning, we kicked things off with yoga in the field, followed by a debrief before heading home on a bus.

It was an amazing experience and another project I’m really proud of. Big thanks to Anna Diekelmann and the 22 awesome troopers who came along for the ride!

Tactile: What’s coming up next for the Troopers post this Outdoor adventure?

Sarah: Over the next months, this group of Troopers will continue to meet for more learning and development and of course, they will meet for more social events as well. By the time new Troopers are formed next year, these ‘veteran’ Troopers will be the ones sharing about their own experiences.

The purpose of all of this is to create a deeper bond between Tactilers from different teams, which will continue to break down silos and help to promote the culture of continuous learning and collaboration which we’re growing at Tactile.

Check out more snapshots from the Outdoor Adventure below!

At Tactile, we work in a fast-paced environment and strive to push the boundaries of what our teams are capable of delivering. This is why we have several teams in the business which are focused solely on providing customised tools to our game development and production teams. This enables those teams to work more quickly and efficiently, allowing them to devote more time to innovation, collaboration and creating high-quality user experiences.

One of such teams is our Quality Assurance (QA) Automation team. Their new mission is to become an even bigger part of this toolkit providing ecosystem within Tactile. Their day-to-day workflow currently revolves around supporting five game teams, with Lily’s Garden being their biggest focus. They are a strong team of six with diverse backgrounds, experiences and skill sets, which serves them greatly in trying to shape their team’s mission, which will take them from testers who code to developers who build tools for testers.

To learn more about their transition and the impact it will have on our business as a whole, we sat down with three of the team members: Levente, Alex and Matic.

Previous ways of working

Previously, the automation team had two main channels for carrying out work activities. One was participating in the release process as QA, while the other was providing custom solutions to requests from various teams (such as the Gameboard or the Content Tools Team – who are building tools for our Story & Art teams).

Their process for release testing was managed separately from manual tester teams. This meant that the automation team was in charge of creating, maintaining, executing, and analysing the test runs. If they discovered any issues, they notified the tester stakeholders, who were then in charge of tracking them. This allowed them to take the initiative in testing things they thought were valuable from their perspective, but it also meant that the tester teams’ coverage overlapped.

The team’s new mission

The new scope of the team clearly separates the responsibilities between the two teams, while also empowering both to excel in their own areas. The Automation team’s new mission is essentially to create the automated test cases based on existing test passes (meaning the steps of the test have already been created), and then handing over the execution/analysis part to the tester team. The important detail, however, is that these new tests replace the previously manually executed tests, and thereby eliminate the duplicated work.

This therefore reduces the tedious and repetitive work and frees up time for manual testers to tackle more impactful tasks. It also allows the Automation team to spend more time focusing on constructing a maintainable framework for creating and maintaining these tests. All of this enables us to better ensure that our games work as intended, meet the quality standards we have set for ourselves and fulfil the brand promises we have made to our players. As Alex explains: “It’s not about making the software more complex, but about catering to a really niche need in the current infrastructure that hasn’t been catered to before. We’re collecting a lot of building blocks in the entire Tactile ecosystem and putting them all together. Exciting stuff!”

It is important to emphasise that there are some tests that are not planned to be automated, allowing manual testers to keep doing their exploratory work. After all, they are the ones who spend their days interacting with the devices and testing our games on them. It is therefore crucial that they are the ones who are writing the test plans (rather than the Automation team doing so separately), and the Automation team’s duty is to make sure that these steps get executed in a consistent and predictable manner on any given build.

What this new line-up will enable

This new style of working will ultimately save a lot of man hours by avoiding repetitive and lengthy test cases that may require a lot of preparation to run.

An excellent example of such tasks are update tests, which are one of the most tedious tasks assigned to our manual testers. It requires them to first download an old build, do the work they need to do on it, and then upgrade to the new release to make sure that progress persists and everything functions as expected. There is nothing exploratory about their work here, it is simply the tiresome task of downloading 2 separate builds every time a release is being shipped. The Automation team’s new infrastructure will allow them to test this scenario in a fully automated way.

The team also keeps track of the automation codebase corresponding to each build that was released to the users, so if there is ever a need to test functionality on older builds, the manual testers are able to easily pick a version of the tests that was compatible with that version. Alex explains: “If the manual team wants to go back ‘in time’ and test specific features, they can now easily do that. We offer backwards compatibility with old builds, which also enables us to do update tests.”

Alleviating the manual team from having to work on such tasks will therefore enable them to do the work that truly brings value to the release process – investigative work on recent crashes and exploratory tests around new areas that are more prone to having issues.

New challenges and opportunities arising from the transition

Whilst this transition presents many positive opportunities for change, it doesn’t come without a few new obstacles for the team. Since their tools will now be consumed by a team other than themselves, including people with potentially no coding skills, they must ensure that the reports generated clearly show the relevant details about the test performed.

This type of experience engineering has a significant impact on their product’s overall usability, but it also requires them to learn a new set of skills. Levente explains: “The small things add up. We need to account for these nuances when we are creating user-experiences. Previously, we never had to think about someone else interacting with our product, but now this consideration is at the heart of how we work.”

In this mission of creating the best possible experiences for the manual testers, the Automation team requires support from other teams, such as our client and back-end developers. These teams are responsible for developing and maintaining our internal backend infrastructure and can create new features within this infrastructure to provide more functionalities for our testers. This offers an opportunity for a deepened collaboration between the different teams acting in a supporting function.

A great example of the two teams’ work interlinking is the Build Server, our internal game building pipeline. The Build Server integrates the build ordering, test ordering and test report collection into one easy to navigate website. After a build compiles, the testers simply have to select which set of tests they would like to order and then the Test Agent (one part of the Build pipeline) takes care of orchestrating the execution across a pool of mobile devices. The results then get collected and sent back to the Build Server. “The game testers just need to enter one website, one central place, where they can complete this new workflow. The only thing we have to add to it is fitting the reports to their needs,” explains Matic.

Exciting times ahead

After this collaborative workflow has matured, and the coverage for the games is sufficient for the testers, the automation team will have more time to expand upon other exciting areas. One of such areas is Unity runtime testing (we use Unity as our game engine). This will allow them to test our games on the integration level, which will require a deeper insight into the underlying game code architecture. Another big item on their agenda is fully supporting iOS devices for test execution.

“We want to transition from not only black-box testing, but also white-box testing,” says Matic, “Because what we ultimately care about is that the games are performing, independent of the device they’re being played on.”

This shows how the QA Automation team is leveraging a unique constellation of tools and technologies, and is supported in their work by close collaboration with multiple teams across the company. This style of working not only enhances our current workflows but also ensures that our commitment to delivering the highest quality experiences to our players remains paramount, both now and in the long run.

About the co-authors

Levente Buzga completed his bachelor in Computer Science in Budapest. He started his career in a software engineering role within a big data company. Afterwards he relocated to the beautiful Copenhagen and ended up in the QA Automation role at Tactile. In September, he’s starting a master’s course focusing on AI.

Matic Jovan studied electrical engineering in Ljubljana. After completing his studies, he started his career in software development, where he dabbled in Android development and learned more about the general software development practices. He then moved to Copenhagen to start his master’s degree in Computer Science at DTU (Technical University of Denmark), where he also worked as an Android developer and QA Automation Engineer. After graduating, he joined the Tactile Automation team and is extremely excited about the direction shifting away from QA and more towards development.

Alex Anemogiannis is the newest addition to our QA Automation team. He started his career over 5 years ago and has since then worked in both development and QA. He first worked within a hyper-casual gaming studio, then moved to work in an indie gaming start-up, and finally landed in Copenhagen and joined our team at Tactile.