This time I would like to take a look at how quality is supported in software development processes. We will analyze some stages of such processes and check how the explicit presence of individual steps supports the maintenance of quality in teams and organizations.
Below are questions from the years of my observations that are worth asking while looking for answers regarding quality control
- Is the concept of quality clearly defined at every stage of the software development process?
- On what basis is the stage considered to be completed correctly?
- Is the term ‘quality’ discussed, agreed, recorded and announced, or is quality simply ‘expected’ from employees?
- Is it easy to bypass quality control in a given step, for example due to urgency?
The simplest board
For almost 20 years of work in several companies and as a trainer, I visited many offices and talked to many teams. In these offices I saw many boards on which the process of software development of a given team was visualized, e.g. Kanban or Scrum.
Here is an example of the simplest board
How does the above process support quality? Where is the place to review the code or add missing test cases? Where is the place for refactoring, when the code has ceased to be readable by others after making changes, which will hinder its development?
I must admit that the teams I worked in many years ago also used similar boards. Many times the most common question was whether the functionality was already implemented. This question was most often answered by a person acting as a “tester”
Quality is not hide and seek game
Based on my experience in the above case, things such as adding missing tests, having automated code quality reports, refactoring, adjusting the project architecture to new requirements – if they occur, they will be performed in a hidden way … You will not talk about them officially, only programmers will extend the programming or testing phase to stuff them somewhere ..
Steps that are not an official part of this process can easily be skipped. Alternatively, they are done outside the process but this always causes programmers discomfort.
The worst-case scenario is micromanagement based on an incorrect (incomplete) process. When programmers are controlled what they do hour by hour and attention to quality is not an official part of the process, it certainly will not enter the team. Perhaps it will take place in the case of programmers aware of the consequences of technical debt – but still in a hidden form of extending the planned implementation time.
The most extreme case I encountered concerned rewarding the manager for the speed of product delivery, while then the developers / testers were the only “responsible” for the number of defects reported by the customer in the following months. …
Introducing transparency
Are there a checkpoint in the process for this
- Has the code been reviewed?
- Is the code still readable after changes?
- Is the code covered by component and / or integration tests?
The practice is that if we are not officially evaluated for something at work, we probably will not worry about it. It may happen that at the same time, team members are only paid for the speed of delivery and are never judged by the number of defects reported by customers. Who in this case receives a payrise? This approach can create an unhealthy atmosphere between programmers working at a higher speed and those who care more about the quality of the code.
Let’s move on to analyzing the next whiteboard
Does care for quality look better here? Can the code search process be skipped in this case? In addition, this process emphasizes that no one can test the solution in the integration environment before the code review is completed.
Although this configuration sounds more reliable in terms of quality control, I still saw its different results based on different rules of work organization. Here are two real examples
- At least 2 programmers should review the code change. But who in this case is fully responsible for making this review? It may happen that 2 different programmers performed a cursory review at the same time to speed up the task waiting to be tested by an “available” quality engineer. Moreover, each of these two programmers could have assumed that the other would review more thoroughly…
- Only one person reviews the code at the same time and takes full responsibility for readability, coverage of test cases, the possibility of extending if they approve the changes made. If such a person has any doubts about the quality, they have the right to submit their comments to the author or the next reviewer for confirmation.
The second approach seems more resistant to “leakage defects.”
Introducing even more transparency
Let’s add one more column to the board.
In the above case, it is very clear that testing performed by Quality Engineers takes place only in an integration environment. You can also clearly see when the task has already been reviewed and is waiting to be implemented in an integration environment.
Transparency of technical fixes
The result of a code review may be that you need to make corrections. Such a correction can be an urgent refactoring, adding missing integration tests. It can also be setting an appointment session to re-discuss architecture because the problem must be discussed at the level of the whole team.
Some teams may think it’s okay and just put the task to the highest priority back to the “to do” column. But does this make it possible to distinguish a task with new functionality from a “patch” task? Will this not mean that the conversion tasks will compete with the new tasks regarding the new functionality in the “to do” column? Therefore, another option will be to explicitly add a column where the task goes through additional “fixes”.
Of course, the rework/fix column can be omitted if the code review goes well, but its existence emphasizes that making corrections to the code quality is perfectly fine – for example, due to lack of readability or lack of tests coverage – even if the code works as expected.
Any other transparency
Be agile. Periodically discuss all quality control issues during the retrospectives. Place the most important stages regarding quality control in the process. Make them “legal” and official. Take responsibility for quality.
Similarly, another example: deployment into production environment – let it be visible what exactly happens with each task. You can discuss the benefits of such a column yourself.
Summary – ensure quality control visibility
If you want to take care of quality, you must create processes and procedures that encourage people to improve quality and discourage people from skipping it. This should be an environment in which people experience the consequences of their decisions regarding the lack of quality but are also entitled to self-improvement of these principles.
Pay close attention to the shape of your process. Make his steps very clear and well defined in terms of quality control. The process should highlight all things related to requirements, such as quality, code readability, scope of tests, refactoring options, perhaps even exchange of technical and business knowledge.
Remember that procedures and processes ensure psychological safety at work. They constitute guidelines for the performance of our duties and assessment of our work. If the “expected” result is not clearly defined, the probability of its occurrence will be low.
| Published on Java Code Geeks with permission by Wlodek Krakowski, partner at our JCG program. See the original article here: Transparent Quality in Process Opinions expressed by Java Code Geeks contributors are their own. |
