Interview with Francesco Tartaggia - Director of QA

Francesco Tartaggia, currently Director of Quality Assurance at Etiqa, embarked on his professional journey after earning a degree in Computer Engineering from the University of Padua in 2007. Starting his career as a software engineer at a startup, Francesco demonstrated an early penchant for pushing his boundaries, both personally and professionally.

In 2013, he took a significant step by relocating to Turin, and by 2016, he had become an integral part of the Etiqa team. His initial role at Etiqa saw him as a QA software engineer, where he transitioned from programming to crafting software designed for testing other applications. While well-versed in unit tests, he initially lacked familiarity with the intricacies of automated testing from an end-user's perspective, as well as the broader role of Quality Assurance (QA) in software development.

Reflecting on his early days at Etiqa, Francesco recollects, "I knew what unit tests were, but I had no idea how to automatically test software from an end-user’s perspective. And even less I knew about the broader role of QA in software development. I was lucky again: at Etiqa, I found an amazing manual testing team and a wonderful company culture. I learned a lot about QA, I mean really a lot!"

‍

His journey at Etiqa continued with a one-year stint as an Agile QA consultant, followed by three years as a Business Analyst and Delivery Manager at Italy's largest coffee company. These experiences added a wealth of knowledge and perspectives to Francesco's repertoire.

‍

In a significant turn of events at the end of 2022, assumed the role of Etiqa’s Director of QA. In the course of this interview, he offers a captivating insight into the intricacies of his dynamic role.

‍

Can you provide an overview of your role as the Director of QA at Etiqa and how it contributes to the overall success of the company's projects? 

I think QA is about questioning things. That’s what we do as a team, that’s what I do as a member of the team. At all levels. We question the product, the delivery process, the QA approach itself.

Etiqa’s QA team has a lot of experience, so I only need to ensure we really understand what Quality means to a specific project or client.

I’m directly involved in some of our ongoing projects. For the others, I’m available to support whenever a team member feels they need my advice, my experience, or just an external observer. It’s amazing to see how much creativity and dedication my colleagues put in their job. I truly believe I’m learning so much more from them than the other way around: I feel I’m only needed to ensure we don’t cut corners and take every aspect into consideration when making decisions. On these other projects I stay out of the way of my team and just make sure to engage in periodic retrospectives to keep up with the projects’ status.

‍
I also try to ensure we stay up-to-date with new approaches, making the QA process more efficient, particularly shifting QA left and, altogether, advocating a company-wide quality-oriented attitude. We’re investing heavily on test automation and applying it to different contexts. The team is autonomously experimenting with new test strategies: I help evaluate them, suggest some more, ensure information and learned lessons flow among the whole team so that new ideas can be shared to foster creativity.

‍
My other main responsibility is ensuring the QA team keeps increasing and enhancing their skills and knowledge. I strongly believe in T-shaped skills and multidisciplinary awareness.
I’m also involved in some company-wide strategic projects, like obtaining the ISO 9001 certification and continuously improving our Integrated Management System.

‍

‍

‍In a dynamic field like software development, what are the daily challenges you face in ensuring the quality of the products Etiqa delivers, and how do you address them?

Etiqa was born from the idea that Quality is not just a piece of the puzzle, but a foundational principle supporting every aspect of product development.
It’s naive to think that QA’s goal is to ship a perfect product. 

My team’s primary goal is to understand what Quality means for a given project or client, and then adapt our approaches and practices to the specific quality needs.
For example, ensuring the quality of a Medical Device involves a rigorous testing process, extensive documentation and strict handling of the testing equipment. All of this is needed to support FDA approvals and CE marking applications. On the side of the spectrum, working on a R&D software project to produce a PoC to look for investors and explore new market opportunities requires a completely different approach where the impact of testing on delivery schedules must be minimal and where work-in-progress solutions are acceptable.

In between these two extremes there exists a universe of different project needs and constraints requiring customized QA strategies. Our job is to find those strategies and execute them as effectively and efficiently as possible.

‍
The first step to succeed in this equilibrium game is to listen to clients, to align to their vision and understand what’s important to them, bringing in our experience to support and guide strategic decisions.

‍
Another key aspect is efficiency. Which means both being cost-effective and to guarantee a fast feedback loop to the development team. Etiqa employs a variety of testing techniques, both manual and automated, and we try to constantly shift QA towards early development stages.
A risk-based approach is fundamental when you need to define the right mix of test types to adopt.

‍
Agile methodologies are a great fit here because they allow you to constantly re-evaluate and adapt to changing needs.
Agile practices also encourage tight team communication and collaboration, which is the real key to a successful project.

‍

With Etiqa specializing in regulated industries like Healthcare and Digital Therapeutics, how do you approach quality assurance to meet specific regulatory requirements while maintaining innovation and efficiency?

We employ a risk-based approach to define the right test strategy: what needs to be tested and how at every new software release to guarantee the testing process is valid yet efficient.

‍
We developed a very efficient way of testing that allows for fast feedback to developers and thorough verification with minimal impact on the development cycle.

‍
We constantly inspect and adapt the testing strategy to the project’s needs and context. This way we are always flexible.

‍
We keep refining our test cases so that the testing process is optimized and efficient.

‍
We include different types of automation to support both the testing process and the documentation process, which is a critical aspect in highly regulated industries.
Finally, personnel qualification and certification and careful management of our testing equipment are fundamental in this field.

‍

Can you share insights into the testing methodologies and strategies employed by your team to identify and rectify bugs, ensuring the products meet specified requirements?

QA is a lot more than testing, and testing is a lot more than a final check that everything works just before a release.
Our QA teams are constantly in contact with developers, product owners and project managers to guarantee that the whole development team is always aligned on what’s to be done, what’s the quality status of the project and what the next steps are.

‍
We communicate a lot with product owners and developers to ensure that requirements are clear, complete and well understood by everyone in the team.
Designing the test cases and even running them help surface opportunities to clarify or refine requirements: that’s why test case design proceeds mostly in parallel with development so that we can identify issues with requirements as soon as possible.

‍
As for our testing strategies, we leverage both manual and automated testing. We perform both specification verification testing and exploratory testing and the latter gives us a lot of insights about aspects or details that we could have overlooked during analysis or design.

‍
Our main focus is on functional testing, but we also perform UI testing, localization testing, browser/device/OS compatibility testing. Migration testing is also important to ensure that the very process of updating a live system doesn’t cause issues. Security and performance testing are also part of our expertise.

‍
As for automated testing techniques, we range from end-to-end acceptance testing and visual testing, to lower level approaches like unit, integration and contract testing. Automation can also serve as a support for other manual testing activities.

‍
When an issue is detected, the first step is describing and documenting it so that it’s reproducible.
Finally, when a defect gets fixed we perform confirmation testing to ensure the initial issue is actually solved and we apply risk analysis to decide what areas of the solution need retesting to check that the fix didn’t introduce regressions. And of course, if the issue was not covered by a test case, we update our test protocols to include it.

‍

‍‍

Collaboration between development and QA is essential for successful software delivery. How do you foster effective communication and collaboration between these teams, ensuring a smooth and efficient workflow?

Again, Agile practices help a lot here. We usually combine frequent (daily or weekly, depending on the context of the project) in-person meetings, with offline, asynchronous  communication through shared documents and collaborative tools.
Project teams regularly (usually every couple of weeks) engage in retrospective meetings to evaluate the development and QA processes and openly discuss ideas, concerns and issues. 

‍

From your perspective, what are the key skills and qualities that a successful QA professional should possess?

We look for people who are curious and accurate and who care about shipping great products, of course.

‍
A scientific or engineering background is usually preferred. The need to be aware of what a rigorous verification process looks like.
In particular, candidates must understand very clearly things like boundary testing and equivalence classes because you cannot verify every possible input to a system, so you need to understand how to choose your test cases in a way that they still give you the guarantees you need. Also, having a good idea of  how a software system is structured helps a lot in deciding what to test and how. A broad knowledge of software and networking aspects is more important than a deep, specialized one: as QA professionals, we need to consider the whole system and even its context.

‍
A sort of hacking attitude is also a great trait to possess: sometimes you need to think and look for ways to break or challenge a software system to see if it handles an unexpected situation or a failure in the right way. And when you observe something strange in the way an application behaves, you must not shrug it off and move on, but you need to dig deeper and see if there’s a possible flaw hiding somewhere.

‍
Despite having some technical background, it’s fundamental that a QA professional is able to think as a typical final user. Real users (in general) must not be required to have a technical background, or to know how the system works. Adopting the end-user point of view is critical when performing functional or exploratory testing on a product.

‍
Candidates must also be able to communicate very clearly: they must be able to correctly describe a desired feature or malfunction both to business and to highly technical people.

‍
Finally, being able to write good code is another great skill we look for.

‍