Differences between Software Quality Assurance (SQA) and Software Quality

Control (SQC):
Many people still use the term Quality Assurance (QA) and Quality Control (QC)
interchangeably but this should be discouraged.

Software Quality Control

Criteria Software Quality Assurance (SQA)
(SQC)

SQA is a set of activities for ensuring SQC is a set of activities for

quality in software engineering
Definitio processes (that ultimately result in
n quality in software products). The
activities establish and evaluate the
processes that produce products.
ensuring quality in software
products. The activities
focus on identifying defects
in the actual products
produced.

Focus Process focused Product focused

Orientat
Prevention oriented Detection oriented
ion

Breadth Organization wide Product/project specific

Relates to all products that will ever be

Scope Relates to specific product
created by a process

Process Definition and

Activitie Implementation Reviews
s Audits Testing
Training

evel Summary

A level of the software testing process where individual

Unit
units/components of a software/system are tested. The purpose is
Testing
to validate that each unit of the software performs as designed.

Integratio A level of the software testing process where individual units are
n Testing combined and tested as a group. The purpose of this level of testing
 is to expose faults in the interaction between integrated units.

A level of the software testing process where a complete, integrated

System
system/software is tested. The purpose of this test is to evaluate the
Testing
systems compliance with the specified requirements.

A level of the software testing process where a system is tested for

Acceptanc acceptability. The purpose of this test is to evaluate the systems
e Testing compliance with the business requirements and assess whether it is
acceptable for delivery.

Software Test Manager Sample Job Description

Designation
Software Test Manager
Department
Quality Control
Line Manager
Software Test Director
Job Aim
To manage Software Testing projects and resources
Responsibilities
Formulation and implementation of Software Testing strategies
Resource management (allocation, monitoring, motivating etc)
Preparation/review of test plans
Preparation/review of test reports
Training and Mentoring
Essential Skills
Advanced knowledge of Software Testing theories and practices
Advanced knowledge of computers
Proficiency in written and spoken English
Leadership
Patience
Desired Skills
Programming knowledge [This depends on whether a Black Box or a White
Box testing methodology is used.]
UNIT TESTING Fundamentals
DEFINITION
Unit Testing is a level of software testing where individual units/ components of a
software are tested. The purpose is to validate that each unit of the software
performs as designed
A unit is the smallest testable part of software. It usually has one or a few inputs
and usually a single output. In procedural programming a unit may be an
individual program, function, procedure, etc. In object-oriented programming,
the smallest unit is a method, which may belong to a base/ super class, abstract
class or derived/ child class. (Some treat a module of an application as a unit. This
is to be discouraged as there will probably be many individual units within that
module.)
Unit testing frameworks, drivers, stubs, and mock/ fake objects are used to assist
in unit testing.
Definition by ISTQB
unit testing: See component testing.
component testing: The testing of individual software components.
METHOD
Unit Testing is performed by using the White Box Testing method.
When is it performed?
Unit Testing is the first level of testing and is performed prior to Integration
Testing.
Who performs it?
Unit Testing is normally performed by software developers themselves or their
peers. In rare cases it may also be performed by independent software testers.
TASKS
Unit Test Plan
Prepare
Review
Rework
Baseline
Unit Test Cases/Scripts
Prepare
Review
Rework
Baseline
Unit Test
 Perform
BENEFITS
Unit testing increases confidence in changing/ maintaining code. If good
unit tests are written and if they are run every time any code is changed, we
will be able to promptly catch any defects introduced due to the change.
Also, if codes are already made less interdependent to make unit testing
possible, the unintended impact of changes to any code is less.
Codes are more reusable. In order to make unit testing possible, codes
need to be modular. This means that codes are easier to reuse.
Development is faster. How? If you do not have unit testing in place, you
write your code and perform that fuzzy developer test (You set some
breakpoints, fire up the GUI, provide a few inputs that hopefully hit your
code and hope that you are all set.) If you have unit testing in place, you
write the test, write the code and run the test. Writing tests takes time but
the time is compensated by the less amount of time it takes to run the tests;
You need not fire up the GUI and provide all those inputs. And, of course,
unit tests are more reliable than developer tests. Development is faster in
the long run too. How? The effort required to find and fix defects found
during unit testing is very less in comparison to the effort required to fix
defects found during system testing or acceptance testing.
The cost of fixing a defect detected during unit testing is lesser in
comparison to that of defects detected at higher levels. Compare the cost
(time, effort, destruction, humiliation) of a defect detected during
acceptance testing or when the software is live.
Debugging is easy. When a test fails, only the latest changes need to be
debugged. With testing at higher levels, changes made over the span of
several days/ weeks/ months need to be scanned.
Codes are more reliable. Why? I think there is no need to explain this to a
sane person.
TIPS
Find a tool/ framework for your language.
Do not create test cases for everything. Instead, focus on the tests that
impact the behavior of the system.
Isolate the development environment from the test environment.
Use test data that is close to that of production.
Before fixing a defect, write a test that exposes the defect. Why? First, you
 will later be able to catch the defect if you do not fix it properly. Second,
your test suite is now more comprehensive. Third, you will most probably be
too lazy to write the test after you have already fixed the defect.
Write test cases that are independent of each other. For example if a class
depends on a database, do not write a case that interacts with the database
to test the class. Instead, create an abstract interface around that database
connection and implement that interface with mock object.
Aim at covering all paths through the unit. Pay particular attention to loop
conditions.
Make sure you are using a version control system to keep track of your test
scripts.
In addition to writing cases to verify the behavior, write cases to ensure
performance of the code.
Perform unit tests continuously and frequently.
ONE MORE REASON
Lets say you have a program comprising of two units and the only test you
perform is system testing. [You skip unit and integration testing.] During testing,
you find a bug. Now, how will you determine the cause of the problem?
Is the bug due to an error in unit 1?
Is the bug due to an error in unit 2?
Is the bug due to errors in both units?
Is the bug due to an error in the interface between the units?
Is the bug due to an error in the test or test case?
Unit testing is often neglected but it is, in fact, the most important level of testing.
Integration Testing Fundamentals
DEFINITION
Integration Testing is a level of software testing where individual units are
combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between
integrated units. Test drivers and test stubs are used to assist in Integration
Testing.
Definition by ISTQB
integration testing: Testing performed to expose defects in the interfaces
and in the
interactions between integrated components or systems. See also
component integration
 testing, system integration testing.
component integration testing: Testing performed to expose defects in the
interfaces and
interaction between integrated components.
system integration testing: Testing the integration of systems and
packages; testing
interfaces to external organizations (e.g. Electronic Data Interchange,
Internet).
ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail
and clip, the ink cartridge and the ballpoint are produced separately and unit
tested separately. When two or more units are ready, they are assembled and
Integration Testing is performed. For example, whether the cap fits into the body
or not.
METHOD
Any of Black Box Testing, White Box Testing, and Gray Box Testing methods can be
used. Normally, the method depends on your definition of unit.
TASKS
Integration Test Plan
Prepare
Review
Rework
Baseline
Integration Test Cases/Scripts
Prepare
Review
Rework
Baseline
Integration Test
Perform
When is Integration Testing performed?
Integration Testing is performed after Unit Testing and before System Testing.
Who performs Integration Testing?
Either Developers themselves or independent Testers perform Integration Testing.
APPROACHES
Big Bang is an approach to Integration Testing where all or most of the units
 are combined together and tested at one go. This approach is taken when
the testing team receives the entire software in a bundle. So what is the
difference between Big Bang Integration Testing and System Testing? Well,
the former tests only the interactions between the units while the latter tests
the entire system.
Top Down is an approach to Integration Testing where top level units are
tested first and lower level units are tested step by step after that. This
approach is taken when top down development approach is followed. Test
Stubs are needed to simulate lower level units which may not be available
during the initial phases.
Bottom Up is an approach to Integration Testing where bottom level units
are tested first and upper level units step by step after that. This approach is
taken when bottom up development approach is followed. Test Drivers are
needed to simulate higher level units which may not be available during the
initial phases.
Sandwich/Hybrid is an approach to Integration Testing which is a
combination of Top Down and Bottom Up approaches.
TIPS
Ensure that you have a proper Detail Design document where interactions
between each unit are clearly defined. In fact, you will not be able to
perform Integration Testing without this information.
Ensure that you have a robust Software Configuration Management system
in place. Or else, you will have a tough time tracking the right version of
each unit, especially if the number of units to be integrated is huge.
Make sure that each unit is first unit tested before you start Integration
Testing.
As far as possible, automate your tests, especially when you use the Top
Down or Bottom Up approach, since regression testing is important each
time you integrate a unit, and manual regression testing can be inefficient.
LACK OF INTEGRATION TEST

SYSTEM TESTING Fundamentals

DEFINITION
System Testing is a level of the software testing where a complete and integrated
software is tested.
The purpose of this test is to evaluate the systems compliance with the specified
requirements.
Definition by ISTQB
system testing: The process of testing an integrated system to verify that it
meets specified
requirements.

ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail,
the ink cartridge and the ballpoint are produced separately and unit tested
separately. When two or more units are ready, they are assembled and Integration
Testing is performed. When the complete pen is integrated, System Testing is
performed.
METHOD
Usually, Black Box Testing method is used.
TASKS
System Test Plan
Prepare
Review
Rework
Baseline
System Test Cases
Prepare
Review
Rework
Baseline
System Test
Perform
When is it performed?
System Testing is performed after Integration Testing and before Acceptance
Testing.
Who performs it?
Normally, independent Testers perform System Testing.
ACCEPTANCE TESTING Fundamentals
DEFINITION
Acceptance Testing is a level of the software testing where a system is tested for
acceptability.
The purpose of this test is to evaluate the systems compliance with the business
requirements and assess whether it is acceptable for delivery.
Definition by ISTQB
acceptance testing: Formal testing with respect to user needs,
requirements, and business processes conducted to determine whether or
not a system satisfies the acceptance criteria and to enable the user,
customers or other authorized entity to determine whether or not to accept
the system.

ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail
and clip, the ink cartridge and the ballpoint are produced separately and unit
tested separately. When two or more units are ready, they are assembled and
Integration Testing is performed. When the complete pen is integrated, System
Testing is performed. Once System Testing is complete, Acceptance Testing is
performed so as to confirm that the ballpoint pen is ready to be made available to
the end-users.
METHOD
Usually, Black Box Testing method is used in Acceptance Testing. Testing does not
normally follow a strict procedure and is not scripted but is rather ad-hoc.
TASKS
Acceptance Test Plan
Prepare
Review
Rework
Baseline
Acceptance Test Cases/Checklist
Prepare
Review
Rework
Baseline
Acceptance Test
Perform
When is it performed?
Acceptance Testing is performed after System Testing and before making the
system available for actual use.
Who performs it?
Internal Acceptance Testing (Also known as Alpha Testing) is performed by
members of the organization that developed the software but who are not
directly involved in the project (Development or Testing). Usually, it is the
members of Product Management, Sales and/or Customer Support.
External Acceptance Testing is performed by people who are not employees
of the organization that developed the software.
Customer Acceptance Testing is performed by the customers of the
organization that developed the software. They are the ones who
asked the organization to develop the software. [This is in the case of
the software not being owned by the organization that developed it.]
User Acceptance Testing (Also known as Beta Testing) is performed by
the end users of the software. They can be the customers themselves
or the customers customers.