Software Quality Assurance

What is Quality?
Quality defines to any measurable characteristics such as correctness, maintainability,
portability, testability, usability, reliability, efficiency, integrity, reusability, and
interoperability.

There are two kinds of Quality:

Quality of Design: Quality of Design refers to the characteristics that designers specify
for an item. The grade of materials, tolerances, and performance specifications that all
contribute to the quality of design.

Quality of conformance: Quality of conformance is the degree to which the design

specifications are followed during manufacturing. Greater the degree of conformance,
the higher is the level of quality of conformance.

Software Quality: Software Quality is defined as the conformance to explicitly state

functional and performance requirements, explicitly documented development
standards, and inherent characteristics that are expected of all professionally developed
software.

Quality Control: Quality Control involves a series of inspections, reviews, and tests used
throughout the software process to ensure each work product meets the requirements
place upon it. Quality control includes a feedback loop to the process that created the
work product.
Quality Assurance: Quality Assurance is the preventive set of activities that provide
greater confidence that the project will be completed successfully.

Quality Assurance focuses on how the engineering and management activity will be
done?

As anyone is interested in the quality of the final product, it should be assured that we
are building the right product.

It can be assured only when we do inspection & review of intermediate products, if

there are any bugs, then it is debugged. This quality can be enhanced.

Importance of Quality
We would expect the quality to be a concern of all producers of goods and services.
However, the distinctive characteristics of software and in particular its intangibility and
complexity, make special demands.

Increasing criticality of software: The final customer or user is naturally concerned

about the general quality of software, especially its reliability. This is increasing in the
case as organizations become more dependent on their computer systems and software
is used more and more in safety-critical areas. For example, to control aircraft.

The intangibility of software: This makes it challenging to know that a particular task
in a project has been completed satisfactorily. The results of these tasks can be made
tangible by demanding that the developers produce 'deliverables' that can be examined
for quality.

Accumulating errors during software development: As computer system

development is made up of several steps where the output from one level is input to the
next, the errors in the earlier ?deliverables? will be added to those in the later stages
leading to accumulated determinable effects. In general the later in a project that an
error is found, the more expensive it will be to fix. In addition, because the number of
errors in the system is unknown, the debugging phases of a project are particularly
challenging to control.

Software Quality Assurance

Software quality assurance is a planned and systematic plan of all actions necessary to
provide adequate confidence that an item or product conforms to establish technical
requirements.
A set of activities designed to calculate the process by which the products are
developed or manufactured.

SQA Encompasses

o A quality management approach

o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
o Measuring and reporting mechanisms.

SQA Activities
Software quality assurance is composed of a variety of functions associated with two
different constituencies ? the software engineers who do technical work and an SQA
group that has responsibility for quality assurance planning, record keeping, analysis,
and reporting.

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project: The program is developed during project
planning and is reviewed by all stakeholders. The plan governs quality assurance
activities performed by the software engineering team and the SQA group. The
plan identifies calculation to be performed, audits and reviews to be performed,
standards that apply to the project, techniques for error reporting and tracking,
documents to be produced by the SQA team, and amount of feedback provided
to the software project team.
2. Participates in the development of the project's software process
description: The software team selects a process for the work to be performed.
The SQA group reviews the process description for compliance with
organizational policy, internal software standards, externally imposed standards
(e.g. ISO-9001), and other parts of the software project plan.
 3. Reviews software engineering activities to verify compliance with the
defined software process: The SQA group identifies, reports, and tracks
deviations from the process and verifies that corrections have been made.
4. Audits designated software work products to verify compliance with those
defined as a part of the software process: The SQA group reviews selected
work products, identifies, documents and tracks deviations, verify that corrections
have been made, and periodically reports the results of its work to the project
manager.
5. Ensures that deviations in software work and work products are
documented and handled according to a documented procedure: Deviations
may be encountered in the project method, process description, applicable
standards, or technical work products.
6. Records any noncompliance and reports to senior management: Non-
compliance items are tracked until they are resolved.

Test Case
The test case is defined as a group of conditions under which a tester determines
whether a software application is working as per the customer's requirements or not.
Test case designing includes preconditions, case name, input conditions, and expected
result. A test case is a first level action and derived from test scenarios.
It is an in-details document that contains all possible inputs (positive as well as negative)
and the navigation steps, which are used for the test execution process. Writing of test
cases is a one-time attempt that can be used in the future at the time of regression
testing.

Test case gives detailed information about testing strategy, testing process,
preconditions, and expected output. These are executed during the testing process to
check whether the software application is performing the task for that it was developed
or not.

Test case helps the tester in defect reporting by linking defect with test case ID. Detailed
test case documentation works as a full proof guard for the testing team because if
developer missed something, then it can be caught during execution of these full-proof
test cases.

To write the test case, we must have the requirements to derive the inputs, and the test
scenarios must be written so that we do not miss out on any features for testing. Then
we should have the test case template to maintain the uniformity, or every test engineer
follows the same approach to prepare the test document.

Generally, we will write the test case whenever the developer is busy in writing the code.

When do we write a test case?

We will write the test case when we get the following:
 o When the customer gives the business needs then, the developer starts developing and
says that they need 3.5 months to build this product.
o And In the meantime, the testing team will start writing the test cases.
o Once it is done, it will send it to the Test Lead for the review process.
o And when the developers finish developing the product, it is handed over to the testing
team.
o The test engineers never look at the requirement while testing the product document
because testing is constant and does not depends on the mood of the person rather
than the quality of the test engineer.

Why we write the test cases?

We will write the test for the following reasons:

o To require consistency in the test case execution

o To make sure a better test coverage
o It depends on the process rather than on a person
o To avoid training for every new test engineer on the product

To require consistency in the test case execution: we will see the test case and start
testing the application.

To make sure a better test coverage: for this, we should cover all possible scenarios
and document it, so that we need not remember all the scenarios again and again.

It depends on the process rather than on a person: A test engineer has tested an
application during the first release, second release, and left the company at the time of
third release. As the test engineer understood a module and tested the application
thoroughly by deriving many values. If the person is not there for the third release, it
becomes difficult for the new person. Hence all the derived values are documented so
that it can be used in the future.
To avoid giving training for every new test engineer on the product: When the test
engineer leaves, he/she leaves with a lot of knowledge and scenarios. Those scenarios
should be documented so that the new test engineer can test with the given scenarios
and also can write the new scenarios.

Types of test cases

We have a different kind of test cases, which are as follows:

o Function test cases

o Integration test cases
o System test cases

The functional test cases

Firstly, we check for which field we will write test cases and then describe accordingly.

In functional testing or if the application is data-driven, we require the input column

else; it is a bit time-consuming.

Rules to write functional test cases:

o In the expected results column, try to use should be or must be.

o Highlight the Object names.
o We have to describe only those steps which we required the most; otherwise, we do not
need to define all the steps.
o To reduce the excess execution time, we will write steps correctly.
o Write a generic test case; do not try to hard code it.

Let say it is the amount transfer module, so we are writing the functional test cases for it
and then also specifies that it is not a login feature.
The functional test case for amount transfer module is in the below Excel file:
Integration test case
In this, we should not write something which we already covered in the functional test
cases, and something we have written in the integration test case should not be written
in the system test case again.

Rules to write integration test cases

o Firstly, understand the product

 o Identify the possible scenarios
o Write the test case based on the priority

When the test engineer writing the test cases, they may need to consider the following
aspects:

If the test cases are in details:

o They will try to achieve maximum test coverage.

o All test case values or scenarios are correctly described.
o They will try to think about the execution point of view.
o The template which is used to write the test case must be unique.

Note: when we involve fewer numbers of steps or coverage is more, it should be the best
test case, and when these test cases are given to anyone, they will understand easily.

System test cases

We will write the system test cases for the end-to-end business flows. And we have the
entire modules ready to write the system test cases.

The process to write test cases

The method of writing a test case can be completed into the following steps, which are
as below:
System study
In this, we will understand the application by looking at the requirements or the SRS,
which is given by the customer.

Identify all scenarios:

o When the product is launched, what are the possible ways the end-user may use the
software to identify all the possible ways.
o I have documented all possible scenarios in a document, which is called test
design/high-level design.
o The test design is a record having all the possible scenarios.

Write test cases

Convert all the identified scenarios to test claims and group the scenarios related to
their features, prioritize the module, and write test cases by applying test case design
techniques and use the standard test case template, which means that the one which is
decided for the project.

Review the test cases

Review the test case by giving it to the head of the team and, after that, fix the review
feedback given by the reviewer.

Test case approval

After fixing the test case based on the feedback, send it again for the approval.

Store in the test case repository

After the approval of the particular test case, store in the familiar place that is known as
the test case repository.

Test Execution For Software Testing

The term Test Execution tells that the testing for the product or application needs to be
executed in order to obtain the expected result. After the development phase, the testing
phase will take place where the various levels of testing techniques will be carried out
and the creation and execution of test cases will be taken place. The article focuses on
discussing test execution.
What is Test Execution?

Test Execution is the process of executing the tests written by the tester to check whether
the developed code or functions or modules are providing the expected result as per the
client requirement or business requirement. Test Execution comes under one of the
phases of the Software Testing Life Cycle (STLC).
In the test execution process, the tester will usually write or execute a certain number of
test cases, and test scripts or do automated testing. If it creates any errors then it will be
informed to the respective development team to correct the issues in the code. If the text
execution process shows successful results then it will be ready for the deployment phase
after the proper setup for the deployment environment.
Importance of Test Execution:
 The project runs efficiently: Test execution ensures that the project runs smoothly
and efficiently.
 Application competency: It also helps to make sure the application’s competency in
the global market.
 Requirements are correctly collected: Test executions make sure that the
requirements are collected correctly and incorporated correctly in design and
architecture.
 Application built in accordance with requirements: It also checks whether the
software application is built in accordance with the requirements or not.

Activities for Test Execution

The following are the 5 main activities that should be carried out during the test
execution.
1. Defect Finding and Reporting: Defect finding is the process of identifying the bugs
or errors raised while executing the test cases on the developed code or modules. If
any error appears or any of the test cases failed then it will be recorded and the same
will be reported to the respective development team. Sometimes, during the user
acceptance testing also end users may find the error and report it to the team. All the
recorded details will be reported to the respective team and they will work on the
recorded errors or bugs.
2. Defect Mapping: After the error has been detected and reported to the development
team, the development team will work on those errors and fix them as per the
requirement. Once the development team has done its job, the tester team will again
map the test cases or test scripts to that developed module or code to run the entire
tests to ensure the correct output.
3. Re-Testing: From the name itself, we can easily understand that Re-Testing is the
process of testing the modules or entire product again to ensure the smooth release of
 the module or product. In some cases, the new module or functionality will be
developed after the product release. In this case, all the modules will be re-tested for a
smooth release. So that it cannot cause any other defects after the release of the
product or application.
4. Regression Testing: Regression Testing is software testing that ensures that the
newly made changes to the code or newly developed modules or functions should not
affect the normal processing of the application or product.
5. System Integration Testing: System Integration Testing is a type of testing
technique that will be used to check the entire component or modules of the system in
a single run. It ensures that the whole system will be checked in a single test
environment instead of checking each module or function separately.

Test Execution Process

The test Execution technique consists of three different phases which will be carried out
to process the test result and ensure the correctness of the required results. In each phase,
various activities or work will be carried out by various team members. The three main
phases of test execution are the creation of test cases, test case execution, and validation
of test results. Let us discuss each phase.
1. Creation of Test Cases: The first phase is to create suitable test cases for each module
or function. Here, the tester with good domain knowledge must be required to create
suitable test cases. It is always preferable to create simple test cases and the creation of
test cases should not be delayed else it will cause excess time to release the product. The
created test cases should not be repeated again. It should cover all the possible scenarios
raised in the application.
2. Test Cases Execution: After test cases have been created, execution of test cases will
take place. Here, the Quality Analyst team will either do automated or manual testing
depending upon the test case scenario. It is always preferable to do both automated as
well as manual testing to have 100% assurance of correctness. The selection of testing
tools is also important to execute the test cases.
3. Validating Test Results: After executing the test cases, note down the results of each
test case in a separate file or report. Check whether the executed test cases achieved the
expected result and record the time required to complete each test case i.e., measure the
performance of each test case. If any of the test cases is failed or not satisfied the
condition then report it to the development team for validating the code.

Ways to Perform Test Execution

Testers can choose from the below list of preferred methods to carry out test execution:
1. Run test cases: It is a simple and easiest approach to run test cases on the local
machine and it can be coupled with other artifacts like test plans, test suites, test
environments, etc.
2. Run test suites: A test suite is a collection of manual and automated test cases and
the test cases can be executed sequentially or in parallel. Sequential execution is
useful in cases where the result of the last test case depends on the success of the
current test case.
3. Run test case execution and test suite execution records: Recording test case
execution and test suite execution is a key activity in the test process and helps to
reduce errors, making the testing process more efficient.
4. Generate test results without execution: Generating test results from non-executed
test cases can be helpful in achieving comprehensive test coverage.
5. Modify execution variables: Execution variables can be modified in the test scripts
for particular test runs.
6. Run automated and manual tests: Test execution can be done manually or can be
automated.
7. Schedule test artifacts: Test artifacts include video, screenshots, data reports, etc.
These are very helpful as they document the results of the past test execution and
provide information about what needs to be done in future test execution.
8. Defect tracking: Without defect tracking test execution is not possible, as during
testing one should be able to track the defects and identify what when wrong and
where.

Test Execution States

The tester or the Quality Analyst team reports or notices the result of each test case and
records it in their documentation or file. There are various results raised when executing
the test cases. They are
 Pass: It tells that the test cases executed for the module or function are successful.
 Fail: It tells that the test cases executed for the module or function are not successful
and resulted in different outputs.
 Not Run: It tells that the test cases are yet to be executed.
 Partially Executed: It tells that only a certain number of test cases are passed and
others aren’t met the given requirement.
 Inconclusive: It tells that the test cases are executed but it requires further analysis
before the final submission.
 In Progress: It tells that the test cases are currently executed.
 Unexpected Result: It tells that all the test cases are executed successfully but
provide different unexpected results.
Test Execution Cycle

A test execution cycle is an iterative approach that will be helpful in detecting errors. The
test execution cycle includes various processes. These are:
1. Requirement Analysis: In which, the QA team will gather all the necessary
requirements needed for test execution. For example, how many testers are needed,
what automation test tools are needed, what testing covers under the given budget,
etc., the QA team will also plan depending upon the client or business requirement.
2. Test Planning: In this phase, the QA team will plan when to start and complete the
testing. Choosing of correct automation test tool, and testers needed for executing the
test plan. They further plan who should develop the test cases for which
module/function, who should execute the test cases, how many test cases needed to be
executed, etc.,
3. Test Cases Development: This is the phase in which the QA team assigned a group
of testers to write or generate the test cases for each module. A tester with good
domain knowledge will easily write the best test cases or test scripts. Prioritizing the
developed test cases is also the main factor.
4. Test Environment Setup: Test Environment Setup usually differs from project to
project. In some cases, it is created by the team itself and it is also created by clients
or customers. Test Environment Setup is nothing but testing the entire developed
product with suitable software or hardware components or with both by executing all
the tests on it. It is essential and it is sometimes carried out along with the test case
development process.
5. Test Execution: This stage involves test execution by the team and all the detected
bugs are recorded and reported for remediation and rectification.
6. Test Closure: This is the final stage and here it records the entire details of the test
execution process. It also contains the end-users testing details. It again modifies the
testing process if any defects are found during the testing. Hence, it is a repetitive
process.

Test Execution Report

The Test Execution Report is nothing but a document that contains all the information
about the test execution process. It is documentation that will be recorded and updated by
the QA team. In that, they just record all the processes happening in the day-to-day test
execution activities. The test execution activities are nothing but executing the task
related to testing. The documentation or the report contains various information. They
are:
 Who all are going to execute the test cases?
 Who is doing the unit testing, integration testing, system testing, etc.,
 Who is going to write test cases?
 The number of test cases executed successfully.
 The number of test cases failed during the testing.
 The number of test cases executed today.
 The number of test cases yet to be executed.
 What are the automation test tools used for today’s test execution?
 What are the modules/functions testing today?
 Recording the issues while executing the test cases.
 What is today’s testing plan?
 What is tomorrow’s testing plan?
 Recording the pending plans.
 Overall success rate.
 Overall failure rate.