How to improve the Software Quality Assurance (SQA) Process

Hello everyone! in this article, I would like to discuss How to improve SQA Process.

Well, here come the questions. What is the SQA process? Why do we need an SQA process?

Let’s find out.

The Big Picture

QA testing is essential in software and web development to verify that the app or the website is working the best it can be. The goal of software QA testing is to ensure that we are delivering a quality product to the customer which is developed according to the quality standards and following a quality process. Mainly, the QA testing is to ensure that the end product is according to the customer requirements

It has been observed that a significant amount of software bugs identified in the testing stage are introduced in the early stages of the Software development life cycle (SDLC), primarily in the requirement analysis or design phase.

Bugs were introduced in the early stages mainly due to the ambiguous requirements and the poor client interaction.

Since software development is time and cost-sensitive, later identified issues are expensive to fix. The developers might have to change a considerable amount of code changes, and sometimes, they might have to change the entire logic and flow to resolve those issues. Thus, in such scenarios, we have to accept more extensive estimates, and as a result, it becomes more expensive to fix those in the later stage in SDLC.

The multiple roles of the software tester

The roles established for software testers vary from organization to organization. Many factors affect the tester’s role. The major factors are,

• People relationships

It is very important to build a relationship with developers. The tester should be able to negotiate and make the necessary time for testing by Communicating with the team and getting managers to understand the testing

• Defining the Scope of testing
• When should testing occur
• How should testing be performed

Some attitudes that have shaped a negative view of testing and testers

• Testers hold up implementation.
• Giving testers less time to test will reduce the chance that they will find defects.
• Letting the testers find problems is an appropriate way to debug.
• Defects found in production are the fault of the testers.
• Testers do not need training; only programmers need training.

Identify the requirement.

The simplest solution is the early start of software quality assurance in the SDLC. It is also one of the software testing principles.

When the product owner(or the business analyst) explains an item from the product backlog at the beginning of the sprint, the entire team should ask questions to clarify the requirement.

Then the SQA team should have review meetings to review the requirement, mainly to identify the eliminate errors or ambiguities in the requirement and design documents.

If found any such scenarios, we should immediately contact the business analyst or the client to clarify those requirements. We can set up meetings if required.

After the requirement is finalized, the business requirements document (BRD) is updated. we can move into the Test design stage

Design test scenarios

When the developers develop a user story, QA engineers should start designing the test scenarios for that requirement. There should be clear communication between both teams.

Using flow charts, the QA team can identify the test scenarios for a given requirement.

Moreover, there are a few test design techniques that the QA team can use to determine the requirements.

Test design techniques

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Diagrams
• Use Case Testing
• Error Guessing
• Mind map

When writing test cases, we should follow a proper template.

A test case should mainly include

• Test Case ID
• Use Case/ Requirement No.
• Main Category/ Title
• Test Case Description
• Pre-requisite procedure(s)
• Test Procedure
• Input Data
• Expected Results
• Actual Results
• Test Result
• Priority
• Comments

Once complete the test case identification, it is important to get those test Cases reviewed by Business Analysts and Business Users since it is always good to get inputs from subject matter experts. It is better to get review comments from Business Analysts and Business Users before testing starts rather than pointing out the deficiencies of your test cases during acceptance testing or Post-implementation.

Update the Requirement Traceability Matrix

While writing test cases, we should update the requirement traceability matrix (RTM) to identify the set of test cases associated with a particular requirement. Therefore, when we get a change request in the later part of the SDLC, we can identify the affected areas and test cases by looking at the RTM.

Maintaining an RTM is crucial to provide significant estimates for those change requests, eliminating the risk of missing test cases.

Identify Test cases for the Regression suite.

When we are writing test cases, we should identify the regression scenarios as well.

Those identified regression scenarios should include in the regression suite. Then we can create a comprehensive regression coverage when we are finalizing the test case writing stage.

Assign priority to test cases

It is vital to assign a priority to a test case when we write that test case.

QA team should discuss with developers to identify the areas which have complex logic and code segments. Test cases based on those areas should include more priority.

Furthermore, the QA team should discuss with Business Analyst to identify the customers’ most commonly used user interfaces. Similar to the above, Test cases based on those areas should include more priority.

Why do we prioritise test cases?

Suppose a scenario, the client came with a change request in the middle of the sprint, and the Integrated change control board(ICC) approved that change request after reviewing it.

In such scenarios, there is a high possibility of a lack of time running a full regression coverage before the sprint end date. In such cases, it’s essential to run the most priority test cases 1st and move into more minor priority test cases. Therefore it is crucial to identify the priority of a test case when designing.

Test Environment Setup

QA team should not depend on or block due to certain development activities. Thus, the QA team should have a different environment to conduct their testing. We usually call it the ‘QA environment.’

Test Execution

Start with a Smoke test

Once the developers are provided a QA build (deploy the code into the QA environment from the development environment), the QA team should run a Smoke test to ensure the basic functionalities are working fine.

If the smoke test fails, QA should reject the build and request to provide another build after fixing the issues with the initial build. In the meantime, QA should add related defects and assign them to the relevant developer to fix.

During smoke testing, the team’s focus is to validate the main functionality of the application and not detailed testing.

If the smoke test is passed, QA should accept the build and move into the Sanity testing.

Why do we need a sanity test?

QA team should provide quick feedback to developers regarding the test status of the particular user story which the testing team started to test.

Hence QA team uses Sanity testing and ensures the high-level flow of that particular user story is working as expected.

During sanity testing, the team’s focus is to validate the main functionality of the particular user story and not detailed testing.

The QA team executes the functional test cases identified during the test design stage if the sanity testing is passed.

When do we need the Regression?

The regression test is one of the famous and pivotal testing types in software quality assurance. Regression testing is to verify the new code segment (Bug fix, enhancement, new feature) won’t affect the smooth running system. As a general rule, a Regression test execution occurs in every Sprint end. To make it easier to maintain and run, usually, the Regression test scenarios are automated. Before the regression, it is always vital to have a code freeze.

Some key points

• Treat web application UI testing with a cross-browser
• Treat mobile applications UI test with a cross-platform test

Always maintain checklists

It is very important to maintain a QA checklist to track the QA progress during a sprint. Then the tester won’t miss out on the tasks since there is a checklist. We can maintain checklists on the below stages

During sprint

Sprint planning

Feature Release

End of sprint

Maintain a separate checklist for UI testing

User Interface testing is one of the crucial testing activities in software quality assurance. It validates the usability aspect and the look and feel of the product. Hence, to make it more specific, it is vital to maintain a UI checklist in Software Quality Assurance.

Use Heuristic Evaluation Checklist to validate the UI and the usability of the system.

Defect Management

Why do we need defect management?

Important Metrics to share with the Management

As part of the test reporting, it is important to prepare software quality metrics. Those metrics give a clear picture to the project leadership regarding the quality aspect of the product.

Sample quality metrics include,

Defect Severity Index

Provides a direct measurement of the quality of the product — specifically, reliability, fault tolerance and stability

Using 3 steps, we can generate the defect severity of the project

Step 1
Assign a number to each severity as :
Critical=5
Major=3
Minor=2
Trivial=1

Step 2
Multiply the number of issues in each category by the assigned number as:

(Number of Critical issues* 5) + (Number of Major issue * 3) etc..

Step3
Divide by the Total issue count

ex: ((Number of Critical issue * 5) + (Number of Major issue *3) + (Minor issue count * 2) + (Trivial issue count * 1) ) /Total issue count

Defect Density

Defect Density is the number of confirmed defects detected in software/component during a defined period of development/operation divided by the size of the software/component.

Defect Density = No of defects/ Size (Function Points or Lines of code

It is important to share at least one test metric data with the management at the end of each sprint

Please check the Defect Management article for more information.

To conclude, If we streamline the software quality assurance process, according to the above guidelines, we can establish an improved SQA process