Let’s imagine an everyday situation: We have a partner and she becomes pregnant, what happy news! From the first moment, we get the news we are assaulted by doubts and nerves, we start to think about what it will be like to be a father/mother, about buying their first change of clothes, decorating their room, whether the flat where we live now is big enough to live with the new member of the family… But before all this, 40 weeks have to pass. A few weeks that progress little by little, until the first ultrasound scan, where they confirm the existence of the baby (or babies). Then, every X weeks, control ultrasounds to give us the news of whether it is a boy or a girl if it is measuring/weighing according to its percentile, if it is gestated in perfect health conditions,… and so on until it finally arrives in the world.
In the above context, would it occur to anyone to wait until the 40th week, at the time of birth, without making any prior revisions, to leave everything to the last minute? The answer is a resounding NO, so why do we do it in the vast majority of software products? And some of you will surely say: “Sure, but it is not comparable to delivering software, with the birth of a baby”. Correct, however, we can also take this analogy to any other scenario of our life: the purchase of a car, a flat, a house, the elaboration of the PowerPoint that our boss sends us to do, a custom-made piece of furniture, …
Why do we leave the forecasting and control tasks in software development to the last stage of the process?
There are many factors. Undoubtedly, the first is the historical factor: At least in Spain, QA/testing is a relatively new discipline. Now we talk about testers, QA, … (we talked about the roles in a previous post) but relatively recently, about 15 years ago, it was not so common to have QA teams. Especially in companies that made critical software (medicine, aviation, …), it was common to have test teams working in silos disconnected from the development teams.
Gradually, the idea that it is important to have test teams testing software coded by development has caught on. And more recently the idea of Quality Assurance has been introduced, which evolves the classic role of the tester.Gradually the idea has taken hold that it is important to have testing teams testing that development-coded software. And more recently the idea of Quality Assurance has been introduced, which evolves the classic role of the tester.
Business factors: Companies today are under enormous pressure to stand out from their competitors, having to deliver products and services with speed and agility. This causes teams to feel a sense of “deliveritis” – deliver, deliver, deliver – controlling potential failure through “shift right” techniques, fixing it in production as soon as it is detected. It is not that shift right and its associated techniques are bad, on the contrary, but they are often not used in the most appropriate way. A clear example of this is A/B testing techniques: More often than not, products are put into production with 0% of users because there are problems that have not been solved. However, for them, the functionality is already “in production”.
Lack of knowledge and training: How many times have we heard the phrase “I want software without bugs”, a clear sign that there is a lack of training in quality topics, not only at the development/product level but also at the top management level.
In addition, another phrase that many of you have probably heard is the classic “I don’t have time for this”, a clear allusion to those testing techniques/activities that we propose and the team is not receptive to because they understand that they are tasks that can “delay the delivery”.
What can we do to reverse the situation and think about quality from the beginning of any project?
Training and communication at all levels: Quality does not come from having a backlog free of bugs or from detecting them in pre-release to production through the execution of tests: Bugs are only the expression of a lack of clear requirements, technical decisions that are not always correct due to the pressure for delivery,… and the way to reduce them is to build from the beginning with quality: Good requirements, good software architectures, clean code, good tests,… and all this is achieved by involving the whole team in the decision making process from the beginning.
In addition, it is important to communicate and train the management team efficiently on the importance of quality. Recent studies by prestigious consulting firms such as Gartner, Deloitte and Capgemini have shown that companies that deliver a product/service with a high level of quality reduce development costs by 25%, increase customer satisfaction by 20% and are 30% more likely to gain market share in their respective contexts.
Efficient management of technical debt/bugs: Technical debt is generated for different reasons, one of the main ones being the pressure to increase productivity. This leads to a so-called “vicious circle”: Wanting to increase productivity increases technical debt, which leads to lower quality code, and contributes to lower productivity, as development will spend a lot of time fixing problems/bugs.
To avoid this, it should not be treated with a specific time every X iterations, but should be treated as a recurring task on a daily basis, taking time to think about the best solutions to code, architecture, and of course, bug fixing problems. Undoubtedly there will always be technical debt, but the idea is that it should be as little as possible.
Good testing and quality practices: Having quality professionals in the companies helps (respecting the companies that decide to do without these professionals) to establish good practices not only in testing, but also in quality. Quality is not only about testing or test automation. It is also about creating maintainable code, scalable architectures,… and this is the work of the whole team.
Organisation: Another important point. It is necessary to understand how to organise/manage human resources: transversal Quality Teams? QA embedded within each of the development teams – what we commonly call Feature Teams (Squads). Each company and each team is different, what works in one company may not work in another, so we have to understand the context of each of them, skills/seniority of the developers to adapt the organisational structure of the Quality team -and of course also of development and product-.
Soft Skills: Those interpersonal skills that are essential to relate to development, product and other stakeholders. These skills will help us to give them feedback, to communicate with them, to empathise, to give our point of view (whether we agree or not) in a respectful way, ….. All these skills will undoubtedly help us to instil quality within the teams and the company from the very beginning of the process.
We will go into more detail on these and many other points in future articles, but until then, what do you think?