Software Quality Assurance (SQA) — Introduction

As we know, Software is developed, maintained, and used by various people in a wide variety of situations. Many Students create software in their classes, enthusiasts become members of open-source development teams, and professionals develop software for diverse business fields from finance to aerospace. All these individual groups will have to address quality problems that arise in the software they are working with. This blog will provide definitions for terminology and discuss the source of software errors and the choice of different software engineering practices depending on an organization’s sector of business.

Each and every profession has a body of knowledge made up of generally accepted principles. In order to obtain more specific knowledge about a profession, one must either: (a) have completed a recognized curriculum or (b) have experience in the domain. For most software engineers, software quality knowledge and expertise are acquired in a hands-on fashion in various organizations. The Guide to the Software Engineering Body of Knowledge (SWEBOK) [SWE 14] constitutes the first international consensus developed on the fundamental knowledge required by all software engineers.

Figure 1.1 Software Quality in the SWEBOK® Guide [SWE 14].

Chapter 10 of SWEBOK is dedicated to software quality (see Figure 1.1) and its first topic is labelled “fundamentals” and introduces the concepts and terminology that form the underlying basis for understanding the role and scope of software quality activities. The second topic refers to the management processes and highlights the importance of software quality across the life cycle of a software project. The third topic presents practical considerations where various factors that influence planning, management, and selection of software quality activities and techniques are discussed. Last, software quality-related tools are presented.

1.2 DEFINING SOFTWARE QUALITY

Before explaining the components of software quality assurance (SQA), it is important to consider the basic concepts of software quality. Once you have completed this section, you will be able to:

— define the terms “software,” “software quality,” and “software quality assurance”;

— differentiate between a software “error,” a software “defect,” and a software “failure.”

Intuitively, we see software simply as a set of instructions that make up a program. These instructions are also called the software’s source code. A set of programs forms an application or a software component of a system with hardware components. An information system is an interaction between the software application and the information technology (IT) infrastructure of the organization. It is the information system or the system (e.g., digital camera) that clients use.

Is ensuring the quality of the source code sufficient for the client to be able to obtain a quality system? Of course not; a system is far more complex than a single program. Therefore, we must identify all components and their interactions to ensure that the information system is one of quality. An initial response to the challenge regarding software quality can be found in the following definition of the term “software.”

When we consider this definition, it is clear that the programs are only one part of a set of other products (also called intermediary products or software deliverables) and activities that are part of the software life cycle.

Let us look at each part of this definition of the term “software” in more detail:

— Programs: the instructions that have been translated into source code, which have been specified, designed, reviewed, unit tested, and accepted by the clients;

— Procedures: the user procedures and other processes that have been described (before and after automation), studied, and optimized;

— Rules: the rules, such as business rules or chemical process rules, that had to be understood, described, validated, implemented, and tested;

— Associated documentation: all types of documentation that are useful to customers, software users, developers, auditors, and maintainers. Documentation enables different members of a team to better communicate, review, test, and maintain software. Documentation is defined and produced throughout the key stages of the software life cycle;

— Data: information that is inventoried, modelled, standardized, and created in order to operate the computer system.

The software found in embedded systems is sometimes called microcode or firmware. Firmware is present in commercial mass-market products and controls machines and devices used in our daily lives.

--

--

--

I am here to share.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Publication Test

Google Cloud Run — Best bet to host Shiny application

Data science and notebooks = databooks: a love story — by Murilo Cunha

There are no experts

Algorithmic Trading with Stochastic Oscillator in Python

RSpec-Rails, Part 1

My Impact as a Summer Intern at Optimizely

KingDeFi Weekly Development Update — 19

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chadani Acharya

Chadani Acharya

I am here to share.

More from Medium

Choosing and managing examples in your tests

Behavior Driven Development, Cucumber, BDD with Cucumber.

Testing Payments: Not just the Test Cases

THE TRANSFORMATION JOURNEY OF TEST