“Does testing improve product quality?”
I used to like asking this question during job interviews. The vast majority of the candidates replied that, naturally, testing improved the quality of the application. Nonsense. Testing identifies errors or deficiencies in the application. But identification of errors itself does not improve the quality of the product. If we have a car that does not start, and we do not know the cause, will the performance of the car be improved if we learn that the problem is caused by a dead battery? No. The same holds true with testing. Testing is a measuring instrument used to measure product quality. Whether it will be improved – this does not depend on the tester.
Automatic tests?
Believe me that as soon as your tests start to identify errors in the applications, you will face the pesticide paradox. Errors will start appearing outside of the paths of automatic tests.
How then can we assure application quality? Where does it hide? In what drawer? The answer is as simple as it gets – the quality is in you. It lies hidden in every team member. Only if the team is “aware”, if it has the necessary qualifications and – most importantly – if it works together, can it have a chance of creating a product of good quality.
Responsibility of the team for the product.
The first issue is the responsibility of the team for the product. Yes – of the team. This cannot be the responsibility of an architect, manager or tester. It has to be the responsibility of the whole team. If the team does not feel responsible for the product and if it does not view the product as its “beloved child”, its work will be suboptimal from the start. That is why it is very important to create the sense of responsibility in the developer team and strengthen the team’s ties with the product. In one of the teams I was in, I experienced this first hand. We underwent a kind of transformation, our working method changed with time. The more connected with the product we felt and the better we knew the business premises and the reasons of the various decisions, the better the quality of our product was. Morever, we shared responsibility for making these decisions together with the “bad business”, we had to help it make them. If the responsibility for the entire project lies with a single person, the tasks will be assigned to the developers, who, most likely, will do their job well but will not do anything more unless they are specifically instructed to do so. Without a broader look at the application, its architecture and the future consequences of the adopted solution. Often, this creates a technical debt.
Knowledge and transparency – success keys
The other thing is knowledge. As I have already hinted several sentences earlier, it is important for the entire team and for all team members to have all the knowledge needed to do the job. It is unacceptable, for instance, for one developer to analyse some extra requirement of the client, with the rest of the team not knowing anything about it. First of all, even if this particular person is the best architect in the company, does it mean that he or she will make the best decisions and choose the best solutions? Does it mean that this person is the alpha and the omega? And can a recently employed developer, one that is still studying, for whom this is the first job, not come up with a better idea? Perhaps this developer knows some newer technologies or methodologies that can solve the problem more efficiently? Even if this person does not come up with a brilliant idea, why should he or she not be allowed to participate in the entire process and gain heaps of knowledge from the expertise and experience of a senior colleague? Going on – if the team does not know the vision and strategy of the product, can it work efficiently and well? Are all decisions made in such a situation sure to be good decisions? Not necessarily. What is more, some tasks will seem pointless to the team, they will make no sense. If you work on something that makes no sense to you, will you give it 100%? Exactly. That is why transparency is so important. Transparency is the key.
Teamwork
The relationship between team members is very important. If the team is divided, cliques start to form. Exactly – in such a situation, is the team still a team? Such a group of co-workers, even if it consists of top professionals, has no chance of producing a good-quality product. Conflicts will start soon, and the atmosphere will get worse than all expectations. Can you work efficiently under such conditions? Maybe, but the emotional cost will be tremendous. Mutual respect is a key issue – with respect to people and with respect to their skills. I have worked in a team without respect – trust me, there is nothing pleasant about it. You come to work and only wait for eight hours to pass by. Do such conditions contribute to your creativity? On the contrary – this is the quickest road to professional burnout, when work is done in a “stale” atmosphere, and it ceases to satisfy us. Every one of us is different, we all have different views and experiences, including work experiences. Mutual respect enables us to regard these differences as a resource to draw on.
Scrum – responsibility, transparency, respect
You may find me wrong – you are fully entitled to do so. However, my experience shows that this is indeed true – where there is transparency, where there is respect, where there is responsibility, there, even under unfavourable conditions, a valuable, good-quality product is made. Naturally, this does not mean that a good-quality product will not be created without these values. It may be created, but it will require great effort.
Responsibility, transparency, respect. When I wrote these words, I did not refer to any methodology and I did not have any particular methodology in mind, but now, when the time has come for me to summarise and when I have read the paragraphs above, I notice that I listed three of the values that are at the core of Scrum. The remaining values have also probably been hinted at. Coincidence? Probably not. Therefore, does it mean that there is no quality without Scrum? Of course not. However, its creators knew what values to rely on.
