QA | Quality Assurance Methodologies
Tags: codequality, qa, software, improvement
Published: 2023-02-28 15:41:44

Quality Management (QM) is a global concept, within which other nested concepts are included: Quality Assurance (QA), Quality Control (QC) and Testing.

The purpose of this post is to have in the same document the most well-known continuous improvement models and quality assurance (QA) standards. Methodologies that are not only present in software engineering companies specialised in the production of software, but that apply to any business or company, as they require, to a certain extent, software for their operation and development.

## CONTINUOUS IMPROVEMENT MODELS

**Kaizen**
The word Kaizen comes from two Japanese terms: kai, which means “improvement”, and zen, which means “good” or “well-being”, but is more loosely translated in the West as “continuous improvement“. The Kaizen process was popularised in the 1950s after World War II by Japanese manufacturers.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4xunmzljqyuq037siyvl.png)

What sets it apart from other process improvement methods is that it aims to involve the entire organisation, from top management to assembly line workers, in its implementation. Having a Kaizen Culture in your organisation means that every individual, regardless of rank, is empowered to look for improvement opportunities every day, no matter how small.

To apply the Kaizen methodology, the following steps will be followed:

- Plan: for this first step you should be aware of the current situation of your business, analyse the problems and define an action plan. Look at your bottlenecks, the most common incidents, the points you would like to improve.

- Do: the next step is to develop the action plan and put it into action. This action plan should include measures for each of the aspects you have identified during the planning.

- Check: In this third step, the most important thing is to analyse whether your action plan is having results and to compare these with the results obtained before establishing the Kaizen methodology. If you have achieved the results you set out to achieve at the beginning, it means that you are on the right track. If not, you will have to start all over again.

- Act: if you have achieved the objectives you set at the beginning, then it is time to standardise the methodology, but without forgetting that it is a process in which improvement must be continuous.

**LEAN**
At the end of the 19th century, the first Lean thinking emerged in Japan from Sakichi Toyoda, the founder of Toyota. But it was not until the early 1990s that this work philosophy reached the West, thanks to a publication by James Womack, Daniel Jones and Roos entitled “The machine that changed the world”. In it, the characteristics of a new production system that combined efficiency, flexibility and quality were explained, where the concept of Lean Manufacturing appears for the first time.

This is based on the elimination within the production process of everything that does not add value, allowing to work more efficiently and with a lower consumption of resources. The Lean Methodology has evolved to new specific applications such as Lean Health, Lean Construction and Lean Office. The common point among all of them is the joint action of managers, middle management and operators, establishing quality principles to optimise work, improve results and apply Continuous Improvement in all business areas.

The five basic principles of this philosophy are:

1. Specify the value of the product as perceived by the customer.
2. Identify the value chain.
3. Let production and value flow.
4. Enable the customer to get what he/she wants.
5. Pursue perfection.

Lean Management encourages teamwork, everyone who works is an important part of the process and their work is critical to the rest of the employees and ultimately to the company.

In Lean thinking, any capacity in operations that is greater than the amount needed to satisfy customer demand will be considered waste that will not produce value, so all improvement initiatives will focus on eliminating this waste and balancing capacity with demand.

**Six Sigma**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f9jgm497qlgc6v08y3nd.png)

The Six Sigma methodology was a concept created by engineer Bill Smith at Motorola in 1988, as a business and quality improvement strategy. But it was later improved and popularised by General Electric.

It is an improvement methodology that provides a path to follow to continuously improve the quality of the product or service, seeking cost savings, to increase customer satisfaction, to achieve 99.9999% efficiency (ability to achieve the desired or expected effect) and to eliminate variability and waste.

To this end, it focuses on reducing (to almost zero) defects and variations in processes, quality costs, cycle times and increasing productivity and customer satisfaction through the reduction of variations in products and processes, providing organisations with a sustainable competitive advantage over time.

The Six Sigma methodology bases continuous improvement on two main indicators: the speed with which a process is performed (cycle time) and the number of errors that reach the customer (internal/external). It consists of a robust design as well as establishing tolerances to define a standard and to know which products are or are not of sufficient quality to go to market.

The Six Sigma methodology is usually used to improve processes or products that already exist in the company and is based on the DMAIC method: define, measure, analyse, improve and control.

When Six Sigma is applied to processes or products that do not yet exist, it is based on the DMADV method: define, measure, analyse, design and verify.

## TRADITIONAL METHODOLOGIES

**WATERFALL**
In software engineering, the waterfall methodology was named after the position of the development phases that seem to cascade “by gravity” towards the next phases, in a staggered manner.

It is the methodological approach that rigorously orders the stages of the software development process in such a way that the start of each stage must await the completion of the previous stage. At the end of each stage, the model is designed to conduct a final review, which is responsible for determining whether the project is ready to move on to the next phase. This model was the first to originate and is the basis for all other life cycle models.

This model began to be designed in 1966 and was completed around 1970. The main problem with this approach is when changes or modifications arise, as one has to go backwards in the life cycle. In addition, the results cannot be seen until very late in the project, so any change due to an error can mean a long delay as well as a high development cost.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yo51etaplzsc5uri8f8v.jpg)

**V- Model**
The V-Model first appeared at Hughes Aircraft, circa 1982, as part of the pre-proposal effort for the FAA Advanced Automation System (AAS) programme to replace air traffic control system hardware and software, providing new automated capabilities to cope with the increase in air traffic control.

The V-model is an SDLC (Software Development Life-Cycle) model in which the execution of processes occurs sequentially in a V-shape.

It is an extension of the waterfall model and is based on the association of a test phase for each corresponding development stage.

**Prototyping**
A prototype is a preliminary version of an information system for demonstration or evaluation purposes. Requirements prototyping is the creation of a partial implementation of a system, for the explicit purpose of learning about system requirements. A prototype is built as quickly as possible.

**Spiral**
Takes the advantages of the waterfall development model and the prototyping model and adds the concept of risk analysis.

Four activities are defined:

- Planning: where initial requirements or new requirements to be added in this iteration are collected.

- Risk analysis: based on the requirements, we decide whether or not we are capable of developing the software and the decision is made to continue or not to continue.

- Engineering: in which a prototype is developed based on the requirements obtained in the planning phase.

- Customer evaluation: the customer comments on the prototype. If the customer is satisfied with it, the process is finished, if not, new requirements are added in the next iteration.

**Incremental**
Allows the project to be built in incremental stages, where each stage adds functionality. These stages consist of: requirements, design, coding, testing and delivery.

- Allows to deliver a faster product to the customer compared to the waterfall model.
- Reduces risk by providing visibility into the progress of new releases.
- Provides feedback through the functionality shown.
- Allows major risks to be addressed from the outset.
- Partial implementations can be done if sufficient functionality is available.
- Testing and integration is ongoing.
- Progress can be measured over short periods of time.
- It is easier to accommodate changes by shortening the size of increments.
- Can be planned based on the functionality to be delivered first.
- Versatility requires careful planning at both administrative and technical levels.

Frameworks (working environments) have been created to support the development of projects using this model, the two most famous being the Rational Unified Process (RUP) and the Dynamic Systems Development Method (DSDM), which we explain below when we discuss agile methodologies.

Incremental and iterative development is also an essential part of a type of programming known as Extreme Programming and the other rapid software development frameworks.

**RAD**
The development methodology known as Rapid Application Development (RAD), officially introduced by James Martin in 1991, consists of developing applications rapidly through frequent iterations, prototyping and approvals with continuous customer feedback. Because of its speed and agility, RAD is growing in popularity.

The key benefits are:

- Reduced development time and accelerated delivery.
- Improved flexibility and adaptability.
- Better risk management.
- Less manual programming and shorter testing times.
- Constant, relevant and real-time user feedback.

## AGILE METHODOLOGIES
In February 2001, following a meeting held in Utah-USA, the term agile applied to software development was born. This meeting was attended by a group of 17 experts from the software industry, including some of the creators or promoters of software methodologies. Their objective was to outline the values and principles that should enable teams to develop software quickly and in response to changes that may arise during the course of the project.

It was intended to offer an alternative to traditional software development processes, characterised by being rigid and driven by the documentation generated by each of the activities carried out. Following this meeting, The Agile Alliance, was created, a non-profit organisation dedicated to promoting the concepts related to agile software development and helping organisations to adopt these concepts.

**XP (Extreme Programming)**
The main particularity of this methodology is the user stories, which corresponds to a requirements specification technique; these are formats in which the client describes the characteristics and functionalities that the system must possess.

It restricts team members to working only on immediate needs, rather than considering future needs. The aim is to create a simple system that can be easily implemented and then improved as needs arise. The aim is to solve as many small problems as possible before they become bigger problems and affect the delivery date.

In this methodology, the process called Planning game is carried out, which defines the compliance date and the scope of a functional delivery, the client defines the user stories and the developer, based on them, establishes the characteristics of the delivery, implementation costs and number of interactions to complete it.

Small deliveries are made using short development cycles, called iterations, which show the customer a functionality of the finished software and get feedback from him.

In this methodology, there is a very important part: acceptance testing, once a functionality has been developed, it goes into testing by the customer, giving his approval.

**Scrum**
Its main objective is for a team to react quickly, simply and appropriately instead of wasting time in creating/updating outdated work plans. It describes a set of practices for project management:

Sprint units of work, typically 30 days.
Short daily meetings (daily), 15 minutes, by the Scrum Team.
Demos with deliverables that can be delivered on time.
And roles are defined to generate a well-functioning structure:

Scrum Master: person who leads the team and ensures that the rules and processes of the methodology are followed.
Product Owner: representative of the clients who use the software.

The development team: group of professionals in charge of converting the list of requirements or Product Backlog into software functionalities.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1743bdssxt1mdnkymo1u.png)

**DoR y DoD**
Agile Scrum methods use DoR (Definition of Ready) and DoD (Definition of Done) to ensure quality by enforcing transparency and setting the right expectations.

In agile methodologies, Quality Gates are the quality gates that ensure quality throughout the different stages of the project.

DoR is the input criteria to the user stories for the sprint.

DoD is the output criteria to the user stories for the sprint.

**Crystal Clear**
Crystal was created by the anthropologist Alistair Cockburn, based on the analysis of different software development projects and his own experience. It is considered a family of methodologies, because it is subdivided into several types, depending on the number of people involved in the project.

The Crystal family has a colour code to mark the complexity of a methodology, the darker the colour, the heavier the method, the more critical a system is and the more rigour is required.

**Kanban**
Kanban is based on the idea that work in progress should be limited, and we should only start on something new when a previous block of work has been delivered or has moved on to another function further down the chain. The Kanban methodology uses a visual control mechanism to track work as it travels through the value stream.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wanw1scswx2lobkpya9m.png)

Typically, a board with sticky notes or an electronic cardboard is used to manage workflow and assignments. 

**Mobile-D (agile and extreme mobile)**
The goal of this methodology is to achieve very fast development cycles in very small teams. It is based on well-known but strictly applied mobile application development methodologies such as: extreme programming, Crystal Methodologies and Rational Unified Process.

It has different phases and each one has a planning day and a delivery day.

Exploration phase: focuses on planning and the basic concepts of the project. This is where the scope of the project and the functionalities are defined.

Initiation phase: we set up the project by identifying and preparing all the necessary resources, dedicating one day to planning and the rest to work and delivery.

Product phase: the sub-phases are repeated iteratively. Test-driven development (TDD) is used, before starting the development of a functionality there must be a test that verifies its operation. In this phase we can say that the entire implementation is carried out.

Stabilisation phase: the integration actions are carried out in order to hook the possible separate modules into a single application.

Testing phase: once the development has been completely stopped, a testing phase is carried out until a stable version is reached as established in the first phases by the client. If necessary, bugs are fixed, but nothing new is developed.

**Adaptive Project Framework (AFP)**
The adaptive project framework (AFP), also known as adaptive project management (APM), arose from the idea that at any stage of a project, unknown factors may arise and affect the project. This technique is mainly applied for IT projects where other traditional project management techniques do not work.

**Feature Driven Development (FDD)**
Feature Driven Development (FDD) methodology is aligned with agile development methodology. It is a design-oriented process, developed and refined by Jeff De Luca, Peter Coad and other contributors. It is customer-centric and is known for having short iterations and frequent releases.

Like Scrum, FDD requires the customer, also known as the business owner of the project, to attend the initial design meeting and iteration retrospectives.

By releasing new features incrementally, developers can prioritise customer requests, respond to requests in a timely manner, and keep customers satisfied.

**Dynamic Systems Development Method (DSDM)**
The Dynamic Systems Development Method is an agile method that focuses on the entire lifecycle of a project. This is the reason why this method has a more rigid structure and basis, unlike the other agile methods.

The 4 main phases are:

1. Feasibility study of the project and the company.
2. Iteration of the functional model or prototypes.
3. Design and iteration of the structure.
4. Implementation.

**Adaptive Software Development (ASD)**
Adaptive Software Development (ASD) is a methodology created by Jim Highsmith and Sam Bayer in the early 1990s. Its basis states that the normal state is the continuous adaptation of the development process to the actual work.

It has 3 stages:

1. Speculate: time estimates are made in the knowledge that they are subject to deviations.
2. Collaborate: This is the phase where most of the development is focused.
3. Learn: The last stage ends with a series of collaborative cycles, your job is to capture what has been learned, both positive and negative. It is a critical element of effective teams.

**Unified Process (UP)**
The Unified Process (UP) methodology is still being debated as an agile methodology, as it is characterised by being use-case driven, architecture-centric, iterative and incremental.

## Conclusion
There are many quality assurance methodologies and models for managing software development projects, but theory differs from reality.

One of the first challenges facing companies today is to implement the agile models demanded by the market in order to be on time, with the highest quality for the end user and without increasing costs. In this post about [The implementation of Quality in the Digital Transformation](https://www.sipsa.net/en/quality_digital_transformation/) you have the key, for more information contact [here](https://www.sipsa.net/en/#contacto).