Meet Ryan Hanni: A fireside chat with Ontra’s Director of Quality Engineering

Ontra

August 30, 20247 min read

Share This Article

Share This Article

1. Can you share a bit about your professional journey and what led you to join Ontra back in February? What have been your key priorities since you first joined the company?

I worked in Software Quality Assurance (QA) for a SaaS company local to Santa Barbara for about 7.5 years. I grew my career there, surrounded by and learning from some really exceptional people. My colleagues and I moved around together working on similar projects, and we had multi-year project bonds we were very proud of.

The SaaS tech world was shifting quite a bit, and I began looking for a new opportunity somewhere smaller, faster, and different. Enter, Ontra!

What excited me about Ontra was the bias for action toward growth, the adoption of new and innovative engineering practices, the chance to lead a larger team, and the application of AI/ML tech in a space that could really benefit from efficiencies. There are so many ways Ontra can have a positive impact on the lives of our customers and users, freeing them up to focus on important work rather than spending time on mundane and repetitive tasks.

Some of my key priorities since starting at Ontra have been:

  • Overhauling our Quality Engineering process end-to-end,
  • Establishing a bugs and incident management process to measure ourselves against DevOps Research and Assessment (DORA) standards,
  • Building out our Engineering Support team,
  • Addressing Automated Testing inefficiencies, and
  • Creating metrics to support our continuous integration/continuous delivery (CI/CD) goals.

2. Could you describe your main responsibilities as the Director of Quality Engineering?

Quality Engineering is so much more than bugs and testing. My responsibilities extend to all things that could benefit from a quality lens, including automated tests, bugs, streamlined customer escalations, software development lifecycle (SDLC) process improvement, and engineering talent development.

Another big responsibility of mine is building a culture around quality, allowing teams to flourish independently, move quickly (and safely!), and reduce roadblocks or speed bumps to delivery. It shouldn’t be slow and tedious to build products or communicate across departments, and applying the quality lens helps us remove those impediments.

Quality is often viewed as something that comes at the end of a process. However, if we subscribe to that mentality, we miss out on many opportunities to bake quality in from the beginning. Helping others view quality as something we can apply throughout our discrete work steps unlocks so many efficiencies and allows us to achieve our goals smoothly.

3. What are the key engineering principles you emphasize to ensure product quality at Ontra?

A culture around quality is essential for success as an organization. Culture takes time to develop, though. Curiosity and bias for action are two principles I find invaluable when it comes to delivering quality work and products. Too often, we miss out on opportunities or build the wrong thing when we don’t ask enough questions. We might introduce a bug because we didn’t take one extra step and ask: “What happens if I do this?”. In order to build something great and of the highest quality, we really have to embrace curiosity and deeply understand our product, users, and internal teams. If improvement isn’t immediately possible, at least knowing where our blind spots are will help us mitigate risk and move with intention through a challenging landscape.

Bias for action allows us to take what we’ve now understood to be true based on the questions we’ve asked and run with it. If there are too many blockers, speed bumps, or the risk is too high, it becomes difficult to get anything done. I want our teams to exist in a space where taking action is easy and where we have an appetite for risk and a safety net to handle it. When there is friction to deliver results, it defeats creativity and makes people less inclined to “just do it” because it will be difficult or potentially result in a negative outcome. It comes down to asking plenty of questions, informing and eliminating as much risk as we can, and getting the thing done.

4. As you continually expand your team, what key qualities and skills are you seeking in new hires?

When it comes to a quality hire (pun!), we’re looking for folks who have that aforementioned curiosity and bias for action, a love for technology and personal development, and a deep technical background in software engineering and best practices. Beyond that, we’re looking for people who align with our values. I seek candidates who lead with empathy, strive to understand contrasting opinions, and build bridges to help us move as a team rather than a collection of individuals.

Quality Engineers (QEs) are uniquely positioned throughout the lifecycle of development with end-to-end visibility. This allows QEs to see the full picture and view the work from 30,000 feet while simultaneously understanding the 1,000-foot view. The most successful QEs bring different perspectives to each conversation, representing the customer, engineer, user experience, and testing points of view. We design our team with individuals who have overlapping and adjacent depths, giving us breadth across multiple disciplines of software engineering and product development.

5. What role does automation play in your quality assurance processes, and what future trends do you foresee?

Automation is a cornerstone of product development and quality. It gives us confidence that our changes aren’t introducing regressions in behavior and allows us to achieve tasks in a programmatic, fast, and repeatable fashion. Challenges may arise when considering how to introduce automation and the amount, level, and stability of its usage. A balance of unit, integration, and end-to-end tests allows us to comprehensively test our software application. However, just because we have those tests doesn’t guarantee a bug-free, high-quality product. Well-written, comprehensive, fast, and stable automation gives us the confidence to change and ship code quickly. If our automation is unstable, we cannot be confident with the results we get, and our tolerance for risk decreases, making it more difficult to ship features.

The SaaS industry has historically relied on the concept of building automation to represent a pyramid: lots of fast unit tests (the base), slightly slower and fewer integration tests, and even fewer end-to-end (user behavior) tests (the top).

Here’s where I think we’re heading: the “Testing Trophy” over the “Testing Pyramid”. Testing technologies are getting much more advanced and rich with features. This tech allows us to shift away from a traditional pyramid structure and instead start to shape our investment in automation testing more like that of a wide-body trophy with a large base and skinny top. This still encourages lots of unit tests because they are quick and cheap, but emphasizes the importance of component and integration testing to ensure our individual components (units) interact with each other as expected. These tests are pretty stable and much quicker than end-to-ends, and give us high degrees of confidence (assuming we don’t mock too much!). With a significant investment in those two test types, we can focus our end-to-ends on a small set of very realistic, high-value, high-confidence tests that represent complicated user flows and behavior.

6. Can you share any advice for someone looking to pursue a career in quality engineering?

Be an avid consumer of technology trends and sharpen your own technical abilities beyond just being a good automation engineer. The industry is shifting away from Quality Assurance Engineers who perform lots of manual/exploratory testing and moving toward Quality Engineers who produce quality at multiple levels in addition to traditional testing responsibilities.

Mental model formation is essential to the job, and you must be able to digest and pick apart complicated systems and boil them down into discrete components so you can appropriately assess risk and focus your efforts. Treat yourself like a software engineer and understand the knowledge layers required to actually build a piece of software: infrastructure, security, code, automation, and product and industry knowledge. Knowledge of these concerns allows you to have meaningful conversations with Product Managers, UX, Software Engineers, and other key roles.

7. Can you share a couple of fun facts with us?

I really enjoy cooking and eating – consider me a foodie. I travel with my stomach by exploring lots of different eateries and restaurants, and I spend more time researching where to eat than what to do. I’ve completed a Half Ironman (70.3 mi) with the goal of completing a Full Ironman (140.6 mi). I had a long and competitive swimming career; I competed at the 2012 US Olympic Trials and was a Junior National Champion in 2009. My shoulders are absolutely wrecked. I love the Minions and Despicable Me movies. The minions are just hilarious and make me laugh out loud. The Lego Movie is one of my favorites too. I guess I’m still just a kid at heart. I am also an avid Formula One fan and wake up early on Saturdays and Sundays to watch the races.

Explore Category

Interested in working at Ontra?

Open Roles

Explore our content