This QE Unit interview shares the story of Lovys, from start-up to scale-up, where quality made the difference.
João Macedo Pinto is the CTO of Lovys, a company that revolutionizes traditional insurance by offering an all-in-one digital solution in a monthly subscription model.
This interview shares the various maturity stages of engineering at Lovys and how it supported the company’s growth from start-up to scale-up.
The commitment to software quality and quality engineering allowed Lovys to continue its growth, showing the value of an investment in holistic quality.
Join the QE Unit to access exclusive community content.
About João Macedo Pinto
Dedicated to aligning technology with the real needs of the business.
At Lovys, we’re creating a new concept of all-in-one insurance, allowing people to have a simple interface for all their protection needs, from integration to claims, and pay a single monthly subscription instead of the complicated mix. of today’s policies.
Co-founded and developed Prometheus at UpType, an online management solution that automatically organizes, compiles, and analyzes a company’s data with virtually no integration costs.
International experience in Business Intelligence, Data Warehousing / Engineering, and Software development, as well as consulting for the Telco, e-Commerce, GOV and Health industry (Angola, Nigeria, France, USA) and team/project management.
Antoine: Can you start by introducing yourself?
I am currently CTO at Lovys, an InsurTech that operates in the insurance field. In addition to work, I am the father of two children with a beautiful woman who is very busy at this stage of COVID!
At Lovys, I feel that we have made an exciting journey in the field of QA (Quality Assurance). In context, Lovys is not a traditional insurance company: it is a company based on the technology to make insurance available, providing a digital platform. The Lovys intend to do with insurance what Neo Bank made in the financial area a few years ago. We have the examples of Revolut, N26, Activobank that brought the 24/7 mode to the banking industry, very different from the existing paradigm.
We are changing habits both in terms of processes and in terms of digitization. Our motto is precisely “Digital Insurance for Everyone” supported by a digital platform. There are two differentiating factors at Lovys: we are multi-products tailored to geography, and we are multi-country. We currently provide four core products, an additional one in France, and for example, smartphone insurance in Portugal. This geographic logic involves an expansion that will take place in the coming months; I still can’t say where 🙂
We sell insurance under a subscription model with a single monthly payment, regardless of the number of policies and options. Customers have the flexibility to turn services on or off and can interact with Lovys at any time.
Antoine: This 100% digital model creates strong pressure on platform availability and so, to IT?
All digital businesses have a 24/7 exposure where services must be available. The Business Continuity theme is a fundamental theme for us; we must ensure that we are online 24/7 across all our channels and platforms. We offer direct contacts for our customers: 2 websites, 2 native apps, and 1 back-office.
Our offer is very self-service, letting customers interact with their insurance without going to a physical place, reinforcing the devices’ criticality. The app should always work, and not just the front-end, but the entire ecosystem as well. It’s a massive challenge in case of failure, it doesn’t affect just one street.
Antoine: What are the key elements of your architecture to provide that digital platform?
Like most start-up and scale-up companies, we use multiple cloud service providers. We have a presence on Google, Azure, and AWS for different needs. Google Cloud Platform is more on the side of Data & Analytics, AWS for R&D, while Azure supports 90% of the core services.
From an architectural point of view, we started with a monolith that is on the way to modularization. The separation follows a domain approach in Domain-Driven Design (DDD), where we identify the monolithic areas associated with the business. The purpose of this evolution is to allow the development process and teams to scale. A codebase has a limit on the number of developers that can collaborate at the same time. This is where segregation allows you to allocate more teams across different code bases.
In terms of technologies, we use a lot the Microsoft stack, namely .NET Core. In the Front-end part, we use Vue JS, Angular, Swift, or Kotlin to create suitable experiences. We have several development teams with a mix of expertise, experience, and localization that create interesting sharings. Many structural improvements came from diverging points of view, I feel that a lot.
Antoine: You mentioned an interesting path of QA at Lovys. Where does it fit?
In reality, when we started, it was without an officially formalized quality. We had a lot of pressure to create the product where the developers were the major contributors. After this first phase, a first layering appeared between the front and the back-end. Lovys operates in various markets, has offices in several countries; it is in our DNA.
We had the back-end in Leiria, the completely remote front-end in Ukraine. It was at this point that I joined the company and rapidly felt the need for QA. We made a big leap in the organization’s maturity; we now have full-stack squads, with small units having all the necessary skills. We had a phase where the Product team was not fully integrated, which we quickly changed. We’re now at what we call a level 4 maturity, with a Talent Pool for every type of position we gather by mission. It is the organizational model that so far has allowed us to better respond to our needs and projects.
Antoine: I understand you invested in QA; we usually invest our money to solve a problem. What was yours?
The QA came as a cold shower: the number of bugs was increasing dramatically. In Q3 last year, we had 74 bugs recorded on the system, and in Q4 there were 170, an increase of a factor of 2.5. It happened not so much because it worsened the quality of developments but because of the strong acceleration we had. The bugs grew in the same way as our base of features, code, and teams.
Our release cycles had post-release stabilization periods equivalent to development time. We had to act. Each release was impacting services that required live fixes, impacting the development of upcoming features. Teams were focusing on stabilization; it wasn’t easy to deploy or rollback as involving code changes.
“We didn’t want a battalion of testers at the end of the chain; we had to solve the root cause problems right from the start.”
João Macedo Pinto
We were faced with several issues here to solve the quality issue. We weren’t just focused on quality at the end of the chain; we wanted a quality present from the beginning. Because of that, we didn’t go to a battalion of testers to check the staging environment only; it wasn’t going to solve the root causes, maintaining a limitation to the company’s growth. We wanted to include quality in the various stages of the process within our Agile context as soon as possible.
We were growing development teams unable to climb the development due to various rollbacks and reworks.
Antoine: It feels like you were facing the limiting factors of your development system?
Clearly, we were not able to keep with the growth and not delivering the User Experience (UX) or Business Reliability we wanted.
The big challenge is that we had no QA competencies; we could not set up QA alone. At the same time, we were immersed in a large project backlog. Being a start-up looking for Venture Capital (VC), the product should be ready and dynamic. The average delivery time of a feature is a crucial metric in this investment context. At this point, we needed one month and a half to two months to stabilize the site; it was not sustainable.
It was this exercise in reflection that led me to “call a friend”. The majority of the engineering team was in Leiria, and we opted for a proximity solution with the company atale.io, which happened to be in the same office space.
“The big challenge in enabling QA in the company was the lacking of skills and a full backlog.”
João Macedo Pinto
We covered the overall quality matters, starting from the foundations to the much sought-after acceleration. We operated in many areas, reviewing the software development processes to include quality from the beginning; we asked for help in finding, training, and enabling the creation of our QA team and practice.
There was an evangelization effort with the development teams; quality does not start or end with unit testing. Although we have good coverage, it does not solve everything, especially integration issues. This improvement in awareness made the difference for the various actors involved in the value chain.
We set up Continuous Integration and Continuous Deployment (CI / CD) pipelines to a maturity I was not expecting. We have standards of quality gates, reviews, gradual deployment, rollback, and links to the user stories. These foundations and models help us distribute the system; we have a recipe ready for new developments.
Antoine: Did you include QA teams within processes, rituals, and other collaboration mechanisms?
Yes, we work with Agile ceremonies without being in a pure Scrum model. QA is part of the different touchpoints of sharing between the teams. QA has a say at all stages of the process, not just at the end. QA stops being a final layer to become an integrated part in the rest of the processes.
“Quality has a word to say at every step.”
João Macedo Pinto
Our first QA engineers focused on automation to guarantee coverage of the various areas already present. We are committed to automation designed to capture value with its initial and ongoing investment in maintenance. We set priorities based on the areas of the product that are most critical, most core-business. This is the case of the conversion funnel with account creation or self-service subscription.; those areas are essential to our customers and are regularly changed. We benefit from a high degree of confidence in the stability of these services.
Antoine: The point of trust that you mention is interesting; the value of quality is not just technical or in some dashboards. Is there a human part linked to trust and the relationship between Business and IT?
We can have all the dashboards in the world, KPIs, traffic lights; there’s a confidence that we get from all that oversight. This trusting relationship is gradual. It starts with “What You See”, a website that works, “Is What You Get”, on the all green dashboard. If there is a green traffic light and an unresponsive website, we have a problem. It’s a point of attention for us; we don’t overdo the monitoring to limit false negatives.
“The trust relationship is gradual to improve the alignment between business and IT.”
João Macedo Pinto
We use several different tools to accomplish this. The test automation tool is Katalon, in a low-code mode. It’s pretty powerful; it allows us to automate tests for web platforms, native mobile, APIs, with scripting flexibility. We can have a data-driven testing approach using excel files with the various test cases. The Katalon TestOps is the module where we have the reportings available.
We have an integration with our ticketing tool, which is Azure DevOps. When we reference the tests linked to the user stories, we can get the status of the checks in the pipeline executions. Azure DevOps is more than backlog management. It’s a verticalization of tools to support the development process. It provides the backlog, repositories, CI/CD pipelines, test cases, and artifact repository. This integration allows you to have an integrated view between requirements, development, and deliveries. In improvement, we want to use the Azure DevOps test case notion for better visibility.
Antoine: What balance can you draw from this investment, experience, and results? Is the initial problem solved?
In a nutshell, we have great confidence in the robustness of our solutions. The terms are valid both for the recipient, the business, and the producer, IT. Today, the business knows it will get something stable, while IT knows it can detect anomalies and fix them quickly.
“We are now confident in the robustness of our solutions.”
João Macedo Pinto
All this investment allowed us to deliver the site where we had real difficulties. It was a success. This happens without downtime and a very low number of defects. If compared to the old volume, they are even residual. For us, a start-up that turns to a scale-up, to increase its execution and engineering capacity, it is essential We can move quickly without being afraid to break what exists.
Antoine: Will the objective end up being able to sustain the pace of transformation and change in the company?
Exactly, I end up being able to transform the company’s face, its warehouse, its operations with little risk of bringing defects into production. I say this with great confidence. We have coverage that allows this.
Of course, QA alone is not enough. Many interconnected processes contribute to this capability. Quality must be resolved globally, in a holistic perspective, integrated into the various processes. I associate the notion of quality with the fact that a user story has acceptance criteria well-written and clear. QA is not just about automation, it’s not just about writing tests. It should bring added value to other areas.
“A great lesson learned is to be on the lookout for early signs.”
João Macedo Pinto
Detecting, deciding, and acting quickly is fundamental, especially in this ecosystem of start-ups where the opportunity/cost is very important. The time we can waste on rework has much more value if applied to higher value-added tasks. From time to time, running faster may be necessary; always mindful that the cost of the invoice is going to be much higher later on.
One piece of advice I give is to include QA from the beginning.
As we identified, it is a matter of trade-offs. In this context of start-ups, there is no single rule. It is necessary to choose and adapt accordingly. Maintaining transparency and communicating the impacts of the decisions we make are very important. Even more so when we have to make a shortcut without QA, the trade-off must be visible.
QA helps in this aspect of communication. It brings to the table a series of elements due to the observability it provides. This supports process improvement.
Antoine: Does this communication reach all stakeholders?
We can use the example of a new button on the interface. If we only answer that it takes a week in the sole development perspective, the person is thoughtful “A week to put a button? Are you serious?”. Considering that this change involves implementation on various devices, platforms, tests, managing the different nominal and error cases, the perspective changes. Being open, creating a space for discussion with a common language facilitates collaboration.
Antoine: What are your perspectives, priorities, and roadmap?
As a result of the investment made in consulting to create a quality capability, we were able to work with a relatively junior team. The priority is to complement our QA Talent Pool with more senior profiles to extend the model across the organization and its impact. We have to keep up with growth. We plan to double our headcount by the end of the year.
An essential part of my job is recruiting; to be able to collaborate with various people to trace a shared path.
Now, it’s a matter of speed and quality of execution without stepping back.
References
Lovys, “The first insurance you’ll love”: https://www.lovys.com
Atale.io, the company that supported Lovys: https://atale.io
Katalon and Katalon TestOps: https://katalon.com ; https://www.katalon.com/testops/
Azure DevOps: https://azure.microsoft.com/en-us/services/devops/