Software quality
There is a question about who is responsible for software quality but few can answer it. If you ask ten people, you may have twelve different answers because some people may have more than one answer. Why is it difficult for a simple question like this? Let’s ask people who are working in the software industry: Some programmers believe quality assurance (QA) is responsible for quality, because they have the word “Quality” in the title. Quality assurance people believe testers are responsible for quality because it is their job to check for quality. Testers believe developers are responsible for quality because they build the software. Developers believe architect is responsible for quality because they only implement what the architect designs for software. Architect believes the requirements engineer is responsible for quality because he provides information to the architect. Wrong information leads to wrong design. Requirement engineer believes customers are responsible for quality because they tell the requirements engineer what they want. If they did not clearly explain what they want, that is their problems. Customers believe the project manager is responsible for quality because he is responsible for the entire software product. Project managers believe professors are responsible for quality because they teach software development. If they do not teach about quality then nobody know about it. Basically, no one wants to be responsible for software quality.
The major issue is the distrust between functional groups and the unclear roles and responsibilities in the entire development process. People is only focusing on their jobs, and what they have to do within their limited area. Anything outside of their area is NOT their concern. No one know what other group is doing. No one want to be responsible for the final product. No one is concerned about software quality. Most do not understand the concept of software process or take time to understand the entire software development. They only care about what they do in a limited way. Students are taught about programming so they know how to code and test. They may learn about software life cycle but it is only a vague concept unless they really implement something across the entire life cycle. Even after few years of working, some learned about architect then they only focus on that areas. When people got promoted to managers, they learn how to manage projects because design, code and test are things of the past and jobs of somebody else. Very few are concern about the entire software process or the bigger picture of software development. To them quality is a concept, not a responsibility.
When quality problems happen, the typical situation may happen like this following scenario:
“The developer explains: “The quality problems are caused by bad software requirements specifications, it is the fault of the requirements engineer”. The requirements engineer disagrees: “No it is not me, it is the customers that keep changing their minds and testers do not review changes so defects are not detected”. Testers protest: “The configuration people never tell me anything about changes, they are not documented. It is the fault of configuration managers”. Another tester laments: “It is frustrating. no one appreciate what we do, they do not know that we work hard”. The requirement engineer jumps in: “Testers are the problem, I have no idea what they do, they do not have the skills, many are just graduating from school with no experience”. Tester complains: “It is the developer’s fault, they build the code, if they build bad code, they have to fix them so quality is the developers’ fault”. The developer argues: “We only code what the architect designs, if the design is bad then it is the architect’ fault not us”. The architect is angry: “Quality is what you build in code, not what I design on paper. Quality assurance people must check the code so quality is their responsible”. The quality assurance protests: “I never review the code, I only check the documents. Testers test the code so it must be them”. The tester accuses: “Quality is your job, your title is “Quality assurance” you are the problem, you are lazy”. The project manager steps in: “That is enough, I do not want any arguments in my team. We have a good team here. Quality problems come from someone outside the project, not us. We have to go to the root of the problem which is the customers”. Of course, the blaming continue and software quality problem will never be solved.
The question is who should be responsible for quality? In software development, testing is used to identify defects and prevent them from getting to final product. Testing does NOT create quality and test team is NOT responsible for quality. Testing only provides information about the quality so it can be improved. Basically, test team helps development team to improve the quality because the earlier they find defects, the easier development team can fix them. Test team does NOT change the quality of the software, they only provide test result to the development team. It is up to development team to make decision on how to deal with the defects such as fix them or ignore them.
To ensure quality and make sure defects are fixed, there is a second group called software quality assurance (SQA). The job of SQA is to check and make sure defects are fixed and developers are following the software process. The SQA support the improvement of quality but NOT responsible for quality. Like testers SQA only provides information about the quality so it can be improved. SQA gathers information about processes and products then pass this to developers and managers so they can fix defects. Thus SQA helps reduce the instances of failure in a product as it is used. SQA does not change quality but only make sure the source of errors is eliminated. It is the people who actually implement the design and build of the products who actually CAN improve the quality.
Developer build the code according to the design and requirements. They ARE responsible for the quality of their code and must conduct their own unit tests to check on defects. If they do a bad job, defects will happen. When testers find defects, they will inform developers to fix them. Developers MUST fix these defects since they ARE responsible for the quality of the code. SQA must involve also to make sure that they are fixed accordingly by let project manager know what will happen to the quality if defects are not fixed.
However, if the design is not complete or missing quality attributes than the architect is also responsible for quality. The job of the architect is to review customer requirements thoroughly and derive addition quality attributes to ensure the design is good so developers can implement them. Unfortunately, software architect is rarely taught in school today. The key weakness in current training is the lack of knowledge and skills in one very important area in software development: The architecture training. This missing function in the main cause in the quality of software development.
Of course, architect designs the software based on requirements engineer’s software requirements specification. If the requirements engineer does NOT do a good job in working with customers, understand their needs and document them thoroughly than it is their fault also. Unfortunately like architecture, requirements engineering is rarely taught in schools also. The key weakness in current training is the lack of knowledge and skills in this important area of software development: The requirements engineering training. This missing function is also main cause in the quality of software development.
The project manager is ultimately responsible for the entire project AND the quality of the product. The manager must ensure that the process is being followed, all defects must be fixed before release to customers as well as the requirements are well documented according to customers’ needs. The software architect is designed accordingly with full quality attributes. Basically the project manager is responsible for everything in the project. Unfortunately like architecture and requirements engineering, project management is also rarely taught in schools. The key weakness in current training is the lack of knowledge and skills in this important area of software development: The software project management training. This missing function is probably the most critical factor in the quality of software development.
If you look at the quality you will see that the major problem is the lack of understand about the software process and the assignment of roles, responsibilities and authorities. The division of current software development is divided into functional groups. Each group operate independent of each others. No one know what other group is doing. No one is responsible for the entire process. People is only focusing on their jobs, and what they have to do within their limited area. Anything outside of their area is NOT their concern. No one want to be responsible for the final product. Unfortunately, software process is also rarely taught in schools. The key weakness in current training is the lack of knowledge and skills in this TOTAL VIEW of software development: The software process training. This missing function is probably the reason after so many years, the quality of software development has NOT been improved.
Software students must understand that the roadmap to building high quality software products is software process. Software processes must be defined early and adapted to meet the needs of software engineers as they undertake the development of a software product. A software process provides a framework for managing activities that can very easily get out of control. Different types of projects require different software processes. The software engineer’s work products such as programs, documentation, and data are produced as a consequence of the activities defined by the software process.
Is it time to look at these knowledge and skills are fix the education system? Is it time to focus on quality and reduce costs? Is it time to look at current trainings and ask the right questions? Is it time for software company to learn about software process? Is it time for the software industry to understand the relationship between process and quality? The best indicators of how well a software process has worked are the quality, timeliness, and costs of the software product.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
