The ecosystem is on a constant acceleration of growth. It becomes even harder to follow the number of startups moving to scaleup while unicorns appear in different parts of the world. But are we able to keep the rhythm in the mid-term?
Quality Engineering is of growing interest for companies searching to continuously deliver value to their users. They must balance the successful experimentation of valuable experiences while ensuring scalable technology foundations.
That challenge of Quality at Speed is easier said than done. In this interview, Filipe Carvalho, Senior Engineering Manager at Talkdesk, one of the top unicorns of Portugal, shares his perspective on using Quality to meet such challenges.
Follow the QE Unit for more exclusive Quality Engineering content.
About Filipe Carvalho
Currently working as a Senior Engineering Manager, leading the SRE Developer Experience and Core Platform clusters in Talkdesk. He has been working as an Engineering Leader of several teams in the SRE area since mid-2019.
Previously he worked in several companies such as Rocket Internet, Farfetch and Talkdesk as a Software Engineer in Test and CI/CD specialist, supporting quality efforts for different applications, technical stacks and companies as a whole. He has also been involved in several communities such as Porto Testers Meetup and events like Commit Porto.
Antoine : Can you start by introducing yourself?
I have started as most of you, probably, as a software engineer. Quality has always been a topic I liked a lot. I started working in the quality area at the end of 2014 as a Quality Engineer focused on automation of tests and pipelines. The main context was on mobile for about 3 to 4 years. I worked in different companies in that area.
After a while in the mobile domain, I decided to pursue a different challenge working in back-end and front-end applications. From that experience, I felt I wanted a different challenge. Currently, I am a Senior Engineering Manager working in the Site Reliability Engineering (SRE) area.
Antoine : Great experience acting on both front, back and operations areas. If you step back from these experiences, which main problems are you trying to solve to deliver better software?
Usually, Quality is not a first-class citizen. The software development step must include Quality everywhere. It starts with coding, deployment, monitoring etc. There are a lot of domains to address, not limited to tests. But what is testing? Is it doing some checks? Is it creating automated checks? Is it thinking about the feature and the value it brings to the customer? What really is Quality? This is the first question: then we can cascade the adequate testing techniques.
We can rely on testing checks, done manually or automatically. What happens typically is that the automated tests code is in itself lacking in Quality. Its level of Quality is as important as the code being tested. This problem, the lack of quality inclusion by design, creates all sorts of cascading implementation issues.
Besides that, we have a similar problem of strategy; more precisely, the lack of strategy. We have automation projects that start focusing on “automation”. The thing is that there is an application and the tests are part of the application. This is not another different project. It shall be understood as a part of it. That’s my view on the inclusion of Quality.
“Quality is a part of the software development lifecycle. It must be implemented at the right level at every step.”
Filipe Carvalho
What happens from my experience is that separated automation projects tend to be abandoned, dying or regularly changing in scope. There is an apparent lack of strategy and focus on what the team is trying to achieve. This is also aligned with the tendency to consistently deliver code in a “best-effort” way instead of a real concern with the value delivered, putting aside quality.
In the end, when we discuss bad or lack of strategy, we go to the actors and their level of knowledge and competencies. We can see for example in the Portuguese market a shortage of experienced Quality Engineers. It is not a problem of people; there are good and promising ones with potential; it is more a problem of recognition and need within the ecosystem. There are not enough professionals in the area to bring more companies to the next level.
This carence is even negative for the existing profiles that can feel alone and demotivate in their context. They will tend to look for environments where they can grow. We want to be with peers from which we can learn a lot, not being the sole top professional. For sure, a senior can still learn from a junior, but emulation is required from an expertise perspective and accelerated learning.
Antoine : If we start our SWOT on Quality, which strengths and weaknesses do you identify?
One of the regular good practices I have seen is the involvement of the team. It is not a separation of concerns. Obviously, we can have a dedicated QA Engineer. But that does not mean that the quality definition, implementation, and implementation will be better than a team composed of engineers, all addressing quality (and not necessarily dedicated quality ones). A whole-team approach can also be very productive. Context is everything. I believe that all engineers should contribute to Quality and grow personally by improving their practices of Quality.
I have seen working well code reviews focusing on the core logic and implementation topics. It means that the teams already automated the trivial and less interesting reviews focusing on formatting for instance. We should question and improve how we can help the team to perform better code review. The involvement of Quality Engineers in code review has also been proven to be useful, even more, if familiar with coding.
Besides that, a team may want to test a feature of a colleague. It should be as simple as checking out the code and running in our machine or in the cloud. It means that powerful automation should be available. Sometimes, we just need to do a verification of the business behaviour with fast iterations. The ability to perform rapidly and easily is critical for fast feedback loops, executing the application locally or remotely.
For a lot of features, we don’t even know if they will be of value to our users. We need to deliver fast to learn and adapt more quickly based on the experimentation. In many cases, the features would be only activated on a small portion of the traffic.
What comes after is weaknesses.
I have also touched a bit on that, but still considering Quality and tests as a nice-to-have is a real problem. If a developer launches a feature realizing it would have more confidence with unit and integration tests afterwards, things will start breaking. From my experience, if we want to deliver faster, we sacrifice Quality in the short term but then face the problem of not being able to iterate.
Another part is the difficulty of transversal knowledge to understanding the various implications of different practices. We can hardly be experts in various areas. We can have more experience in coding, testing, monitoring, observability, requirements. We need these to continuously learn and remain curious while being able to collaborate with different actors. Sometimes we can just lack experience in a specific topic; recognizing it is the first step to cover the gap.
Antoine : In this context, which opportunities do you identify?
I see a couple of opportunities. First, there is a lot of motivation and interest in this area. We can judge it contradictory to what I said before about the experienced profiles. The thing is that we need different challenges to keep our motivation. The increased interest in creating more opportunities for people eager to learn and grow. Everyone has the ability to learn more about the areas, even with a lot of freely accessible content.
They don’t even need a lot of technical content or background. This is quite specific to Quality; this is quite different for a software engineer that needs to deep dive into a series of more technical topics. I have seen very good Quality Engineers that do not code but are able to understand, review, identify monitoring and its operational implications. The combination of expertise is truly valuable.
Sometimes, the coding ability is highly considered for a Quality Engineer. But in reality, it is only one facet of the role required. You can be good at coding but code the wrong thing. This is why coding is not the primarily required skill; critical thinking, Quality and business focus are valuable competencies.
Antoine : And if we continue with the threats?
With time, the rotation of the qualified profiles can help sharing the practices, but they are not there anymore to support them or mentor the team. We have a lot of recent engineers in the area, but they lack experience. In this type of context, they cannot grow at the expected level of exigence and skills.
Another one is the trend of hypergrowth of companies. We have a lot of companies growing fast, from startup to scaleup. While growing fast, Quality and testing are things that start to fall apart first. This tends to put Quality completely aside in the mid-term. We find that in the expression to want something “good, with quality, and cheap”. Usually, Quality is sacrificed. The product can achieve the minimal value expected by the users; however, a series of internal issues will start to fall apart and impact internal operations. Afterwards, more complex problems of reliability, scalability and evolution will appear, impacting the user experience.
Another point is the methodologies available are not sufficiently understood by the actors. There is a lot of content, guidelines and practices available, which is great. The problem is more the understanding and alignment of the industry on these practices. Usually, people partially grab the idea and the buzzwords without understanding the true implications and changes they must implement. There is great content, but filtering and making it valuable in a company context is different. We must be careful of the constant flow of “new” content. A lot of content is repurposed from existing content.
Antoine : Do you have specific practices you found effective, or to the contrary, ineffective in your experience?
I tend to like systematic practices. Some of them are pretty small, requiring small changes but still powerful. When we have a series of user stories that a software engineer will pick to start its development, why not include Quality Engineers from the start? He/she can discuss the approach, ask questions, and also provide a second opinion. He/she can share the most probable edge cases and discuss user scenarios, improving the awareness and implementation of the developer. In the end, it would reduce the effort of rework and accelerate the cycle of development, enabling faster iterations.
Another interesting practice is test automation while the feature is being developed. If the quality engineer discusses with the developer, he can pair the test implementation with the code, enabling much more frequent interactions and sharing. When we talk about peer review, this is a powerful practice for any activity. In this case, enforcing the review of both code and test has been quite powerful from my experience.
The next one is monitoring. Anyone can think about what we need to monitor for our users and product. We can have a variety of roles suggesting improvements. We can have any role able to measure, visualize and use data to take corrective actions. The actors do not necessarily need to be technical profiles.
Antoine : What are the key takeaways to improve the State of Quality?
I would say that every part of the software lifecycle must embed Quality. Quality should be part of every step of the process, not anymore considered as an option. Quality must be embedded early in the cycle, with the whole team involved continuously. Why should we consider quality or test attributes separately? That does not make sense for features we aim to provide to our users. It would be like missing the point.
The knowledge and importance of Quality should be really spread sooner. I am even talking about initial training and universities. I see some schools adding more emphasis on code quality, IT quality and testing part of their program. This is a positive sign for the future, where we still have a long way to go.
All the actors shall be clear that their mission and work is not code but providing value to our users. Code is a way to reach that point but not the only one. We can even require deleting a feature. We tend to forget that part of falling into the interest of solving complex problems. For a lot of experiences, we must excel at one thing only.
Antoine : Do you have content you would recommend on these quality perspectives or that you found inspiring or helpful to remain up to date?
Even if I am not exclusively on Quality topics, I will share how I get into that area. I started with several different resources. The Google testing blog was one of my first inspirations, with not that much but very deep and influential articles. Besides that, I recommend the Ministry of Testing. There are a lot of great resources from a lot of testers and engineers. I invite you to attend an event or the conference Test Bash (note: I’ve gone to TestBash Brighton in the past); I truly recommend it.
Additionally, look for other communities and peers within your area or with common interests. You can generally find a slack, a forum or a meetup group nearby. You will connect with folks having common interests where you can exchange perspectives, difficulties and priorities. You truly grow with these sharings. In Portugal, we have the QE Unit 😉 but also the PTM & MoT in Porto, Quality Talks in Lisbon. Most of these events have been remote recently with fewer interactions but are still valuable as sources of knowledge. I have organized PTM for some years and have kept in contact with many contacts from that time. The discussion and sharing are great for your growth.
In terms of books, I highly recommend to anyone “Crucial Conversations: Tools for Talking When Stakes Are High”. It brings many valuable and actionable ways to communicate more clearly, with more impact and value with all sets of people. Communication is vital for a lot of positions. For a Quality Engineer or a Tester, this is equally true. Communication skills are clearly an essential point of performance as well as personal growth.
Antoine : Thanks a lot Filipe. From this broad perspective of Quality, your vision and inputs are helpful to improve the state of Quality. I wish you a great Quality Engineering journey, happy to have you again on a next interview or round-table.
We can summarize the interview through MAMOS, the Quality Engineering Framework:
- Methods
- Systematic methodologies are required to include Quality at the right level at every stage of the software lifecycle.
- Simple methods implemented step-by-step can make a huge difference when applying early and to the whole team.
- Architecture
- Our product architecture and technology are the first to suffer when speed and cost are favoured. But in the end, fragile foundations will result in a degraded user experience. Quality must be defended and embedded through sound argumentation, examples and results.
- Management
- The role of leader is to align everyone on creating value to the users, stepping back from sole engineering and technology matters.
- Organization
- We should fight organizational silos by applying the whole team approach to quality through systematic transversal rituals.
- Skills
- The shortage of skilled professionals reinforce the need to compose expertises from various backgrounds, keeping an open, curious and collaborative mind as foundations.
Wishing you a successful transformation towards Quality Engineering, the practice of constraining every activity of the software lifecycle to continuous delivery value to our users.
Follow the QE Unit for more exclusive Quality Engineering content.