In this section we provide the background, concept and fundamentals of the software quality and quality assurance. The various work done in this area are also summarized in this section.
Quality
Quality was first introduced formally by Bell Laboratories in 1916, and it gradually permeated into software production in the 1970s when military applications where being built (Lewis 2004). The term quality in the software engineering field does not apply as in other engineering disciplines such as manufacturing, in that it is not confined to predefined specifications; in this case, it should be tailored towards specific customer requirements and organizational standards (Sommerville 2007). Quality in the language of software engineering as discussed by Lewis (2004) means ‘meeting requirements’ and ‘fitness for use’. This implies that the software meets the requirements of the users as stated in the requirements specification, and it does exactly what the user needs. This definition makes the requirements engineering process and the resulting documentation very important, since the quality system revolves around it. Quality is considered a vital requirement for software products, a business essential, a competitive necessity, and a survival issue for the software industry (Murugesan 1994). It is a complex concept that is ambiguous and can be difficult to measure. Strong quality focus is emerging in all phases of the software development lifecycle with increasing emphasis on product quality, process maturity, and continual process improvements.
Quality management
Quality management entails all planned systematic activities and processes for creating, controlling and assuring quality. It is not just a task, but it is a habit that needs to be ingrained into a company’s culture (Ebert and Dumke 2011). It also aims to monitor and refine the development process, based on the assumption that the quality of the development process directly affects the quality of the delivered product.
Software quality assurance
There are different definitions for the term software quality assurance (SQA), some of them are stated below:
Software quality assurance, is a well-defined, repeatable process that is integrated with project management and the software development lifecycles to review internal control mechanisms and assure adherence to software standards and procedures. The objective of the process is to assure conformance to requirements, reduce risk, assess internal controls and improve quality while conforming to the stated schedule and budget constraints (Owens and Khazanchi 2009).
Software quality assurance is the planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes and procedures (Agarwal et al. 2007). It includes the process of assuring that standards and procedures are followed throughout the software lifecycle.
Software quality assurance is a process itself which envelopes the entire project and software development life cycle. It is not to be confined to the last stage of software development, or as a means of measuring the produced software. It should begin at the very onset of the project, and span through to the end or retirement of the software itself. This is because quality cannot be added to a finished product, at this stage it can only be patched; SQA is therefore a continuous process and assessment (Thayer and Fairley 1997).
It was reported in (Owens and Khazanchi 2009) that SQA consists of phases and various activities, which should be carried out by a SQA team of skilled professionals independent of the software development team. They proposed and described an SQA process framework as consisting of the following phases:
-
SQA initiation before the commencement of a project, the SQA team is notified of it, and necessary quality control and audit processes are defined.
-
SQA planning the goals and objectives of the software quality assurance plan are defined; quality processes or procedures to be followed, standards and metrics to be used, reviews and audits to be carried out are decided.
-
Requirements assurance validation of requirements to ensure testability, feasibility and completeness.
-
Design assurance verification of design against requirements, and ensuring that the planned methodologies are being used.
-
Development assurance making certain that the development team is following the stated development process and coding standards.
-
Testing assurance verifying that adequate testing has been carried out and defects nave been tracked, recorded and corrected.
-
Implementation assurance providing assurance that the necessary implementation steps have been completed prior to and after implementation.
SQA closing this entails confirming that the necessary project closing activities, post project review and formal documentation of lessons learnt have been completed.
The term software quality assurance is generally used interchangeably with software quality management, likewise in this work.
Quality planning
This is the process where a specific quality plan is developed for particular project. It involves a selection of organizational standards that are specific to the software project in question and the development process to be used. It also specifies how the quality assessment process will be carried out. It helps to evaluate the project at its end, by checking whether the plan and all quality milestones are achieved.
Quality control
This is the process of monitoring the software development process and checking the product or deliverables (such as the design model or code) to make sure the quality plan and organizational standards and procedures are being followed by the development team. Quality control encompasses a set of software engineering actions that help to ensure that each work product meets its quality goals (Pressman 2010). It can be carried out using automated software assessment or by a quality review team. It often involves measurements using software metrics. Any compromise to quality standards that is detected is documented and forwarded to the appropriate personnel for correction. Methods that can be used include design and code walkthroughs, review, testing, inspection and performance checks.
The software quality assurance team
Every member of the overall project team is responsible for maintaining quality in the project, not withstanding, there is still a dire need for a dedicated team committed to the purpose of quality assurance. In previous years, quality assurance was the responsibility of whoever built the product, but that is not so anymore. This team should comprise of people separate from the development team. They assess the product from the customer’s point of view. Their responsibilities include testing, review of documentation (development plans, testing plans, project plan) for completeness and adherence to standards, periodic inspections, reviews and audits (Godbole 2004).
Costs and benefits of software quality assurance
The need for software quality assurance cannot be overemphasized. A lack of it has been shown to be one of the major causes of software project failure. It plays a very vital role in the software life cycle process and can substantially increase the chance of a project’s success. It also helps to mitigate potential risks (Owens and Khazanchi 2009).
Regardless of the tools, techniques and experience of the development team, failure to give heed to software quality can result in exceeding the allocated time and budget for the project, failure to meet project objectives, poor customer satisfaction and excessive rework.
Software quality is not achieved by chance; a product does not just attain the specified requirements by sheer luck. It is the result of deliberate actions and steps which cost time, money and effort. While ensuring quality has a cost, lack of quality has a cost too. The cost of quality can be divided into three: cost of prevention, cost of appraisal and cost of failure. Costs of prevention include costs to plan and coordinate activities in the SQA process; appraisal costs include cost of measuring the product such as testing, review and metrics evaluations while cost of failure include cost to correct an error, or rework a process due to defect. Failure costs can be internal based on defects detected before shipment to the client or external, based on defects detected have deploying at the client’s site (Pressman 2010).
In the long run, quality management decreases production costs because the sooner a defect is located and corrected, the less costly it will be. While the initial costs can be very substantial, it cannot be compared to the adverse effects of losing a customer, a bad reputation, or going out of business. The costs of prevention are easier to bear, than the cost of failure (Lewis 2004).
Challenges inhibiting implementation of software quality assurance
Software companies frequently face many difficult challenges in their attempt to deliver high-quality software and strife to achieve customer satisfaction (Elgebeely 2013). From different literatures, possible factors that can impair software quality management include: impatient management, strict deadlines, developer ego, extra cost required (e.g. for the purchase of tools), bureaucracy, inadequate tools that can help to automate the process, low level of acquaintance and knowledge of the process, lack of organizational training on quality standards, inexistent framework for quality management in the organization, disapproval by top management, contrary beliefs and opinion, and previous futility of the process.
Pitfalls in SQA
From the literature review, a number of general pitfalls practiced by software organizations in a an attempt to ensure quality were identified and discussed in this sub-section.
Software organizations tend to rush into implementing a software quality assurance process without a prior establishment of functional software quality assurance practices within individual departments (Scarpino 2011). Ideally, the reverse is supposed to be the case, quality assurance needs to be enforced first at the departmental level before an encompassing overall process at the top level.
Some software organizations avoid enforcing quality assurance processes in an attempt to ‘cut cost’ and ‘save time’. This is wrong because research has shown that bugs are cheaper to identify and correct during development than after release or deployment at the client’s site (Drake 1996).
Software organizations need to observe and improve their SQA processes from time to time. When an established SQA process or activity is being applied for different projects, the suitability and effectiveness of the process should be monitored for future improvements. However, due to some factors this is not usually implemented and improvements are not made.
Evading some already established processes and/or not adhering strictly to the specified order. Each stage or activity in a SQA process is necessary and essential for the overall effectiveness of the entire process. The results of the overall process cannot be relied upon if the sequence of steps laid down is not duly followed.
Mix-up of roles is another issue. A number of organization mixup roles of personnel in executing some tasks. For example, a development manager closing bugs in the bugs repository after they have been fixed rather than a QA team member, members of the development team managing the requirements document, a developer who also serves as a support staff. All these might make void the essence of the process.
SQA should not be seen as the sole responsibility of the SQA team, but a responsibility of everyone involved in any activity in the entire software development lifecycle. Every worker should be thoroughly informed of what is expected in ensuring quality in whatever role they take part in. Moreover, SQA is much more than testing and should not be delayed until the latter end of the project, rather it should be incorporated right from its inception.
Related works
Generally, quality management processes are not strictly adhered to by software companies, and this reduces the overall quality of the software produced. Several research have been carried out with respect to quality implementations in the development processes of software organizations.
Drake (1996) presented a case study that showed the benefits of ‘applied quality assurance and code-level measurement activities’. The case study presented a software package that had a time-line of 6 months for development, integration and delivery. Due to the tight schedule, throughout the development period, QA activities such as code inspections, walkthroughs, process control and testing were neglected. At the end of the project, the users considered it unacceptable because it took about 4–5 h to perform its critical function. After 2 weeks of an attempt to fix the code, the senior developer realized that the code needed to be reengineered. After about 6 weeks, the new code was ready and that critical section took only few seconds. Due to lack of enforcement of quality, more time and effort was eventually spent.
Laporte et al. (2012), reported the results of a research that measured the cost of software quality. The results from analyzing over 1100 software tasks that spanned about 88,000 h showed that software quality accounts for about 33% of overall project cost—cost of evaluation accounting for the highest (21%), cost of correcting anomalies was next with 10% and then cost of the prevention, the least, at 2%. It cannot be overemphasized that it pays off to carryout preventive measures of ensuring software quality rather than corrective measures.
Researchers have also worked on the impact of organizational factors on quality. Nagappan et al. (2008), carried out a research to provide empirical evidence to validate that organizational factors affect software quality. The authors developed a metric for measurement and applied it to data from Windows Vista. Their results showed that of a truth organizational factors affect failure-proneness, even above metrics like churn, dependencies, complexity. Lavallée and Robillard (2015) also carried out a study to determine how organizational factors affect working conditions of software developers and in turn the quality of software produced. It was observed that decisions made under pressure due to certain organizational factors such as structure of the organization had a negative effect on software quality. The study was carried out via non-participant observation during weekly meetings of an in-house development team of a large telecommunication company over a period of 10 months. Organizational factors including budget protection, scope protection, organizational politics, human resource planning issues and undue pressure from management and senior developers negatively affected the quality of the software products.
Even for companies which implement SQA practices, different issues impede the success and full realization of the benefits of the process. Scarpino (2011), conducted a software quality assurance evaluation on a software organization that develops software for mobile data synchronization and manages software systems. The research which focused on a particular organization was conducted via face to face interviews at the organization. The findings from the research revealed that the organization was more into software testing rather than an entire software quality process. The research revealed a number of issues within the organization: the organization’s test case steps were too bulky, the test case layout was not directly related to functional specifications, e-communication was employed instead of physical communication between members of the QA team and the developers to analyze test activity, lack of involvement of the QA group at the initiation of a change, lack of efficient use of test case and defect repositories (they were not being used as knowledge bases with other relevant departments; the bug tracking tool (Bugzilla) and the test case repository were not being used as expected) mixup of roles between the development manager and the QA team, as well as insufficient communication between the technical, QA and development team.
Scarpino and Kovacs (2008) also researched on the adverse effects of implementing a SQA tool without prior establishment of a software quality process for the organization. An organization that implemented an SQA tool was used for this study. The data was collected via interviews and open observational analysis by an external consultant and an internal QA expert. The following were the findings: team members to use the tool were not given adequate training and assistance, there was no clear documentation of how the system would fit into the company’s software development life cycle, the short time and a lack of initial communication with members of the team led to high resistance towards the implementation of the tool. The tool itself was not properly reviewed to verify that it offered all the company’s expectations. The researchers also noticed an inconsistent review of the implementation progress of the tool.
More specifically, assessment of software quality practices of organizations have also been carried out. An empirical study was carried out in (Pusatli and Misra 2011a) to evaluate the proper implementation of measurement and metric programs in software companies in an area in Turkey. From their research, they observed a common reluctance and lack of interest in utilizing measurements/metrics despite the fact that they are well known in the industry. They also discovered that internationally recognized standards such as ISO and CMMI are only followed if they are explicitly specified as a project’s requirements.
An assessment of the implementations of quality standards in the software industry of Turkey was also carried out (Pusatli and Misra 2011b). They found out that even organizations that have the ISO and CMMI certificates do not follow the prescribed directives of this organization after obtaining the certificates. They found out the companies do not see quality issues as primary, some don’t even know the names of common quality standards; they believe acquiring the standards are just for ‘show-off’ and that they do not necessarily influence the quality of the products, neither do they make the customers happy which is their priority.
Within the context of developing countries, specifically in Nigeria, similar work has also been done.
Soriyan and Heeks (2004) performed a comprehensive study of the Nigerian software industry. Their study cut across a general profile of the industry, reviewing location and ownership of the firms, their personal and job descriptions. The study also covered the type of customers they provide services for, as well as the products and services rendered, not leaving out the processes and methods engaged in executing projects. As a result, an expansive picture of the general state of the software industry in Nigeria at the time of the study was presented. However, the study only gave a general profile on the industry without focus or emphasis on its SQA practices.
A group of researchers also investigated the state of software engineering ethics in Nigeria. They observed nonchalance, dispassion and mass negligence on the issue. They also showed with the aid of a case study, that the ACM/IEEE software engineering code of ethics when applied to software development project helps to resolve ethical dilemmas (Ume and Chukwurah 2012).
A research to feel the pulse of software professionals in Nigeria on their perceptions of the software inspection as a software quality assurance activity was carried out in (Akinola et al. 2009). The authors used a structured questionnaire research instrument for their work. They found out that software inspection is highly neglected in most organization’s software development process, as they consider it a waste of time.
Olalekan (2005) reported a discourse on the state of the software industry in Nigeria. The research highlighted ‘process compromise’, ‘resistance to measurement’ and poor training of students at the higher education institutions as some of the problems befalling the industry. However, the authors only adduced reasons for its mature state, no empirical investigation was carried out.
More closely related is the work by (Aregbesola et al. 2011) who carried out an assessment of how and to what extent software organizations in Nigeria follow organizational processes. Their survey revealed that the companies do not have proper documentation of their organizational software processes and they only apply implicit in-house methods. Using the Software Engineering Institute (SEI) CMMI, model and the SEI Maturity Questionnaire, they measured requirement management, software project planning, software project tracking and oversight, software subcontract management, SQA, and software configuration management. Based on the software process maturity assessment and capability assessment of the industry, the Nigerian software industry is only at the SEI CMMI maturity level 1, while it toggled between 0 and 1 in key process areas.
All these works individually assessed only a part of the entire software quality management process. This research on the other hand takes another dimension, as it seeks to assess the entire processes involved in software quality management and not just a part of it. It also goes beyond that to identify the challenges inhibiting the practice of software quality which the reviewed research works did not assess, this is to discover the peculiarities in the environment that contribute to the current state, so that suitable solutions can be proffered. Moreover, a comparison with the state of the industry in Turkey is made based on the report from a previous research.