Agile methodologies have become very popular. They are defined in terms of best practices, which aim at developing good quality software faster and cheaper. Unfortunately, agile methodologies do not refer explicitly to quality assurance, which is understood as a planned set of activities performed to provide adequate confidence that a product conforms to established requirements, and which is performed to evaluate the process by which products are developed. The chapter considers the relations of agile practices with software life cycle processes, especially those connected to quality assurance, and tries to answer the question of which agile practices ensure software quality. Next, agile practices associated with quality assurance are assessed from different perspectives and some recommendations for their usage are given. It is observed that modeling has a particular impact on quality assurance.
TopIntroduction
Agile methodologies have become very popular in software companies. In spite of that they do not refer directly to model-driven approach, they help develop software faster and more effectively. Many reports confirm the advantages of an agile approach when applied to small and medium-size scale software projects. Unfortunately, agile methodologies do not refer explicitly to quality assurance. Practitioners of agile methodologies have not yet provided a convincing answer to the question “What is the quality of the software product?”
ISO/IEC/IEEE 24765:2010 (p. 287) provides some general definitions of quality assurance (QA):
A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.
A set of activities designed to evaluate the process by which products are developed or manufactured.
The definitions show that QA is process oriented and focuses on technical requirements (e.g. conformance to standards, procedures, etc.). From this perspective QA may be thought of as a defect-preventing set of activities.
On the other hand, ISO/IEC 12207:2008 (p. 6) defines QA as:
The planned and systematic activities implemented within the quality system, and demonstrated as needed, to provide adequate confidence that an entity will fulfill requirements for quality.
Similar definition of QA is given in KPI Library (http://kpilibrary.com/store/items/33):
Quality assurance is the systematic monitoring and evaluation of the various aspects of a project, service or facility to maximize the probability that minimum standards of quality are being attained by the production process. QA cannot absolutely guarantee the production of quality products.
Two principles included in QA are: “Fit for purpose” – the product should be suitable for the intended purpose; and “Right first time” – mistakes should be eliminated. QA includes regulation of the quality of raw materials, assemblies, products and components, services related to production, and management, production and inspection processes.
These definitions take into consideration not only the technical requirements a product should fulfill but also the requirements for quality, so they have a broader meaning. From this perspective, QA is also thought of as a defect-detecting set of activities.
Sometimes, the activities that focus on defects detection are called Quality Control (QC): “A set of activities designed to evaluate the quality of developed or manufactured product” (ISO/IEC/IEEE 24765:2010, p. 287)).
In the chapter, software quality assurance (SQA) is understood in the broader sense, so this notion includes QC. There are two different purposes for SQA activities (ISO/IEC/IEEE 24765:2010, p. 287): (1) to convince the customer about the quality of the software which he is going to acquire (external perspective) and (2) to support an organization in developing high-quality software (internal perspective)
The first purpose is fulfilled by agile’s approach features e.g. sprint demos, retrospective meetings, acceptation and implementation of proposed changes and so on. In terms of the second aspect, SQA is cited as the one of the software quality management processes (the others two are: quality planning process and quality control process (PMBOK, 2004). All these well-structured processes, together with some additional elements (procedures, quality standards, documentation), constitute the Quality Management System (QMS) inside the organization. QMS is usually adapted to any new project which is undertaken in an organization (i.e. appropriate quality standards, documentation, procedures are chosen). A QMS includes range of techniques and tools for quality management which are used when performing SQA.
In this chapter we are interested in the internal SQA perspective but at the same time we have restricted our considerations only to the execution phase of the project (i.e. software development) and only to the development team perspective. This means that, for example, QMS planning processes are not in the field of our interest (it is assumed that the quality planning process was finished before the development process started). Hence, the quality management system will not be considered further.
The peculiarity of SQA definitions is that the notion of quality is not used directly. SQA abstracts from a concrete definition of software quality, but regardless of the specific definition, emphasizes all the activities that foster quality.