Get to know our Sevendos partners: Hidden Trail!

Hidden Trail - Rethinking Quality Assurance

Sevendos is a newly formed company joining the forces of Polar Squad, Wunderdog, OrangIT, Finitec, Cyberdo, AI Roots and the star of today’s interview: Hidden Trail! Get to know our partners by reading our blog.

I interviewed one of Hidden Trail’s co-founders, Jani Grönman, to better understand what their mission is and how they work in the area of software testing. Read on to get to know them as well!

What is Hidden Trail about?

It’s all about software quality. We want to be re-thinking the way quality assurance (QA) work is done in the software industry. Even if a software development team introduces agile principles, QA is still treated as a separate activity from development. That’s what we want to change. We have seen that some companies are going in the right direction, but there’s still lots to do. For example, how do companies acquire this knowledge and understand those practices?

How did Hidden Trail come to life?

I knew Teemu and Antti, two of the co-founders of Polar Squad. We worked together at Weave (a previous company) and after that, we went our separate ways. But when Polar Squad was founded, as a DevOps company, you have lots of contacts that ask about test automation because it’s a really big part of DevOps. Polar Squad wanted to remain focused on DevOps, so they were thinking: “if we continuously get this kind of work opportunity, we should set up a company to have an answer to this demand”. In the spring of 2021, Teemu contacted me (Jani) to setup that company. There are five co-founders at Hidden Trail: Jani, Toni, Jukka, Pekka and Niko, and now we are around 20 people already. Our history explains our close collaboration with Polar Squad: for example, the Hidden Trail office in Helsinki is shared with that of Polar Squad.  

Jani Grönman, co-founder of Hidden Trail

What problems are you trying to solve in the field of QA?

  • Automation and code. The problem with automation is that it's over-valued as an activity that is not owned properly within the team. You might have QA people or developers creating a lot of automations, but it's not maintained or thought as a part of the codebase or product, and it's not designed and developed the way it's supposed to be. If you talk about things like "clean code", you should always write code with the next developer in mind. The same goes for QA, the code of your tests should always be modular and documented.

  • Lack of a QA Strategy. To be able to choose your QA activities for full benefit of the product, you need a strategy to QA as a whole and test automation is a part of that. Strategy is what guides planning and designing tests, and where to concentrate your QA efforts. Also, in test automation, the big problem is that people doing it don't know where to focus. If you don't know what parts of the product are the most important, you end up with this common situation that you have too many tests. I like to use the "follow the money" principle here: where does your revenue come from, or what are the most valuable parts of your product, that's where you should put the most of your QA efforts. This is specially important with test automation: it's code, so writing and maintaining it is expensive so you need to choose your battles, one does not simply automate everything.

  • Technology choices. There's a notion that with end-to-end (E2E) tests, many companies want to automate their acceptance tests and those often lead to the technology choices (those are UI tests), and browser tests are the ones that are most prone to breaking: they're unreliable. One of our goals is to lead the way in the technology choices in the industry. For example, when it comes to machine learning, we follow the testing practices very closely. Hidden Trail tries to keep up with these trends and upcoming technologies to give the best advice to our clients. UI automation is not there yet.

  • Sourcing and contracting. Too often QA is hired as an afterthought and works in isolation from developers. This is another thing we want to change. Working together with shared goals brings great benefits. For this, the CIOs, CTOs and other decision makers need guidance on how to strategically place QA in R&D projects. Another common theme we see is that the roles and responsibilities of development and QA are not stated clearly enough in contracts. Sometimes even acceptance testing is no-ones responsibility! We have a lot of experience in these contract and sourcing aspects in software projects, so we want to use that for the benefit of the industry too.

What kind of approach do you take to tackle these problems in practice?

  • We want to first promote the understanding that quality is everyone’s business, and good quality brings in more business. We would like to expand this quality mindset to the entire company, because a company should always align their QA strategy with their business strategy. Their business strategy should also be tested (e.g. lean startup principles, studying your market, understanding your product-market fit and what does it mean for you, your stakeholders and your customers). From there, it becomes possible and profitable to bring in more traditional QA into software development teams and simultaneously let the QA strategy be the guidelines for those QA people.

  • For a company-wide adoption of the quality mindset, there should be an advisory team to tackle challenges at various levels. We can bring a team of experienced people with various backgrounds and the quality mindset that can guide and advise on subjects like contracting, C-level management, automations, ways of working, interactions within and between teams, trainings, etc.

  • In terms of execution, a QA assessment is a good way of establishing the current state of things and what the next steps should be. Guidelines and handbooks at the organisational level gives companies unified ways of discussing the various topics surrounding quality at different levels.

  • At the product management level, QA strategies are the way to go and various tools can be used to provide direction to product development teams in QA.

What are your future plans at the moment?

I see the successful companies of the future being the ones that will integrate more tightly their testing in their processes, unlike what we are seeing now. The responsibility of the quality should be improved and Hidden Trail is the best guide for this purpose. It’s what differentiates us from other QA companies, at least in the Nordics. Other companies are just selling CVs to do software testing work, but we have a good cross-section of people from the technical, mindset and coaching aspects of things.

We pride ourselves in being the first Finnish consultancy that has a holistic approach to quality. We want to consolidate our position in the Nordics and in Finland to be even more visible in the public discourse. We would like to have people talking about quality outside of software and in the general public discourse, for example in newspapers and public news. We understand how low-quality products can hurt the economy, and it is often a discussion in the public sphere; in the private sector, the same problems exist, but the failures aren’t as public so we don’t see them as much. We’d like to expand to be able to tackle these problems head on.

How do you see the collaboration between Hidden Trail and Polar Squad, and more generally with Sevendos?

What Polar Squad does seems to be so deep in tech that I could not imagine getting into cases where DevOps expertise is required without them. We have done two assessments and gave some trainings to customers together, so perhaps our common ground is in discovering the state of DevOps and Digital Quality, and training people to have a mindset for modern software development.

Sevendos supports us a lot with internal processes that we share in common with other Sevendos companies, so that has allowed us to focus our attention towards our customers and enabled us to leverage our ecosystem, which has been very beneficial.

Patrick Da Silva