Honoring #IconsOfQuality: Jesper Ottosen

To celebrate the relentless passion and invaluable contributions of leaders in software quality, BrowserStack is proud to honour some of the icons in the testing space. These are the visionaries who not only push the industry forward with their expertise but also enrich the entire testing community by generously sharing their knowledge and thought leadership.

Jesper Ottosen is a test strategy advisor and the Principal Cybersecurity Consultant at NNIT, an international outsourcing company based in Denmark. With over 20 years of experience managing testing activities across complex domains, Jesper specializes in programs that fundamentally change an organization's IT landscape, particularly focusing on EU regulatory compliance and security challenges. Beyond his enterprise work, Jesper has been a foundational pillar of the Ministry of Testing (MoT) community since its inception. As an author of three books and a prolific writer with hundreds of posts on his personal blog, Jesper's dedication to building the next generation of quality professionals makes him a true Icon of Quality.

We spoke with Jesper about the rise of GRC engineering, why software testing is primarily a people problem, and the importance of starting every testing strategy with "why."

---

What excites me in general is to get stuff done, design solutions for complex problems, and build the next generation of quality people.

At work, I lead testing activities for large transformational programs—often things that move whole systems rather than delivering specific features. When moving a system landscape, it’s about setting the direction for various subject matter experts and following up to ensure things are on track.

I often have to make calls on how to approach testing in new contexts. I am the most excited when we have time to consider and analyse the test strategy—how the testing activities support the delivery cadence and align with stakeholder concerns. Too often I have seen “all the test types” thrown at projects without making any impact. If we can get to a place where we visualize the test strategy before any testing, that would be awesome.

Lastly, after being the key test person in too many deliveries, I’m looking to build the next generation even more. That requires a reframing of my own work and role. I have researched this extensively and am putting more people in the spotlight. I am thrilled when my mentees take the stage, even in internal, high-profile meetings.

I get to be involved in quality-adjacent fields of work. One of the fields that I want to highlight is “GRC engineering” in the DevSecOps space. GRC Engineering is about building automation for security requirements. The security team might call it “a control,” but it has properties of a requirement. Often they are government-mandated requirements, and that makes it even more relevant to the stakeholders.

What GRC engineering does is automate the verification of the requirements. Say you have a requirement for encryption protocols; GRC builds a script that can test this. All day, if required. And especially when the audit comes around. It’s not called testing as such, but it surely rhymes.

The more AI, the more critical thinking. And it might not be in the hands of the testers, but rather in the hands of the people doing the testing: verification, prompt output control, Claude Code, code review, and general evaluation of customer needs. I jokingly called this “shift-left-left” as testing activities for software development move even further to the left.

Test cases as primary artifacts will now be redundant as they can be generated. They still need performance/execution, but the crafting and nurturing will diminish. Over time. In some teams.

Start with why. Everyone can generate what to test and how to test. Don’t chase the most recent tooling. Tools come and go. Don’t invest your personality in them either. What ultimately matters is solving business problems and why they need solving.

I read books and blogs and listen to the occasional podcast. I follow some of the curated newsletters of testing content. About once a month I prioritize attending an online meetup like the BrowserStack talks.

It’s first of all a people problem—at least half of it. Stakeholders invest in testing based on their perceived risk for themselves and their organisations. Interacting with stakeholders consistently and in small increments is what helps deliver a good collaboration.

Secondly, the participants in the testing activities need to be handled carefully—like they have volunteered to participate. The test approach, tech stack, and tooling are secondary, and are often based on the people involved, less the technical details.

The field of testing is my primary hobby. I have weekly writing evenings and through that have produced three books, 100 blog posts, and a yearly talk or two.

Besides that, one of my favorite hobby activities is to build LEGO sets. Large vehicles, modular houses, and some of the icons of the LEGO Ideas series. Zoning in and following a script to produce something intricate is a great meditation to me.

(Responses may have been edited for clarity.)

---

Jesper’s perspective serves as a powerful reminder that while technology, tools, and environments constantly evolve, the core of quality remains rooted in human collaboration and strategic intent. By prioritizing the "why" and nurturing the next generation of testers, he demonstrates the lasting impact of a true quality leader.