Qus: What is SQA .What are the objectives and goals of SQA? Explain.

Ans: Software QA involves the entire software development PROCESS - monitoring and
improving the process, making sure that any agreed-upon standards and procedures are
followed, and ensuring that problems are found and dealt with. It is oriented to
'prevention'.
Software quality Assurance (SQA) is a planned and systematic approach to ensure that
software process and products conforms to the established standards, processes, and
procedures. The goals of SQA are to improve software quality by appropriately
monitoring both software and the development process to ensure full compliance with the
established standards and procedures. The first step to establish an SQA programs to get
the top management's agreement on its goal. It then needs to identify SQA issues, to write
SQA plan, to establish standards and SQA functions, to implement the SQA plan and to
evaluate SQA program. For SQA to be effective, they must have good people and full
management support. High quality software product must be able to run correctly and
consistently. The defects should not affect the normal use of the software, will not do any
destructive things to system, and rarely be evident to the users. Before deciding what
measures to use, it is essential to consider the objectives of the measurement program. If
the measures will be used to manage software development, they should be objective,
timely available and controllable.

Definition: SQA is the planned and systematic set of activities that ensure that software
process and products conform to requirements, standards, and procedures. "Processes"
include all activities involved in designing, coding, testing and maintaining;
How can new Software QA processes be introduced in an existing organization?
 A lot depends on the size of the organization and the risks involved. For large
organizations with high-risk (in terms of lives or property) projects, serious
management buy-in is required and a formalized QA process is necessary.
 Where the risk is lower, management and organizational buy-in and QA
implementation may be a slower, step-at-a-time process. QA processes should be
balanced with productivity so as to keep bureaucracy from getting out of hand.
 For small groups or projects, a more ad-hoc process may be appropriate,
depending on the type of customers and projects. A lot will depend on team leads
or managers, feedback to developers, and ensuring adequate communications
among customers, managers, developers, and testers.
 The most value for effort will often be in (a) requirements management processes,
with a goal of clear, complete, testable requirement specifications embodied in
requirements or design documentation (b) design inspections and code
inspections, and (c) retrospectives.

The role of SQA is to give management the assurance that the officially established
process is actually being implemented. It ensures that:

1. An appropriate development methodology is in place.

2. The projects use standards and procedures in their work.
3. Reviews and audits are conducted.
 4. Documentation is produced to support maintenance and enhancement.
5. Software Configuration Management is set up to control change.
6. Testing is performed and passed.

Goals of SQA: The software development is a complex process full risk. There are
technical risks such as software will not perform as intended or be too hard to operate,
modify, and/or maintain; there are programmatic risks such as the project will overrun
cost or schedule. The goals of SQA are to reduce these risks by:

 Appropriately monitoring the software and the development process.

 Ensuring full compliance with standards and procedures for software and process.
 Ensuring that inadequacies in product, process, or standards are brought to
management's attention so that they can be fixed.

SQA is not responsible for producing quality products or for making quality plans. They
are responsible for auditing the quality actions and for alerting management to any
deviations.

Responsibilities of SQA:

To achieve its goals, SQA is responsible for:

1. Review all development and quality plans for completeness.

2. Participate as inspection moderators in design and code inspections.
3. Review all test plans for adherence to standards.
4. Review samples of all test results to determine adherence to plans.
5. Periodically audit SCM performance to determine adherence to standards.

Equivalence Partitioning: Specifications frequently partition the set of possible input

into number of classes that receive equivalent treatment. Such type of partitioning called
“Equivalence partitioning”. A result of this Partitioning is the identification of the finite
set of function associated with their input and output domain.

By identifying and testing a particular member among partition we gain a maximum and
good coverage with small number of test cases.

Testing of one member of a partition should be as good as testing any member of the
partition.

Boundary Value Analysis: A test data selection technique in which values are chosen to
lie along data extremes. Boundary values include maximum, minimum, just
inside/outside boundaries, typical values, and error values. The hope is that, if a systems
works correctly for these special values then it will work correctly for all values in
between. The tester needs to understand what will happen at the boundaries of the
behaviour for each component. For example a field is required to accept amounts of
money between £0 and £10. Does this mean up to and including £10 or £9.99? At the
other end can an amount of £0 be acceptable? Is the boundary set at the pound or penny
level?

The analysts decides the boundary values are £0, £0.01, £9.99 and £10. Once this has
been established the tester can then set his test data.

The following tests are then to be executed.

A negative amount = rejected

0 = accepted (this is on the boundary)
null - rejected
£0.01 = accepted
£9.99 = accepted.
£10 rejected.

Glass box testing: Glass box testing has traditionally been divided up into static and
dynamic analysis.

``Essential functions of static analysis are checking whether representations and

descriptions of software are consistent, noncontradictory or unambiguous''. It aims at
correct descriptions, specifications and representations of software systems and is
therefore a precondition to any further testing exercise. Static analysis covers the lexical
analysis of the program syntax and investigates and checks the structure and usage of the
individual statements.

Some software engineers think that static analysis techniques they can be performed
automatically, i.e.\ with the aid of specific tools such as parsers, data flow analysers,
syntax analysers while others also include manual techniques for testing that do not ask
for an execution of the program.
Syntax parsers, which split the program/document text into individual statements, and
then the consistency of statements can be evaluated.

Dynamic analysis techniques: While static analysis techniques do not necessitate the
execution of the software, dynamic analysis is what is generally considered as
``testing``, i.e. it involves running the system. ``The analysis of the behaviour of a
software system before, during and after its execution in an artificial or real
applicational environment characterises dynamic analysis''

Among the most important dynamic analysis techniques are path and branch testing.
During dynamic analysis path testing involves the execution of the program
during which as many as possible logical paths of a program are exercised.
Branch testing requires that tests be constructed in a way that every branch in a
program is traversed at least once