QA Software Integration

100% test coverage is a target that is often set,
but rarely, if ever, achieved. Many projects start off
with this intention, but as the timeline becomes
compressed and as quality issues are identified,
testing coverage is reduced to accommodate the
new schedule. Functionality that is perceived as less
important is reduced or dropped off the list entirely.
This on-the-fly coverage adjustment leads to wasted
test preparation effort and in its haste often leads to
quality issues slipping through QA.
A more systematic approach – carefully allocating
testing effort up-front based on technology risk and
business criticality – generally delivers the same or
better resultsfor lesstime and money. Risk-based
testing is a technique to prioritise each business
and system requirement and helps to determine the
appropriate level of testing for each area, based on
system complexity and risk. High risk items, those
that are subject to regulatory oversight for example,
receive proportionally more testing effort than low
risk items.
Risk-based testing can also be used to continuously
improve the testing process. Once underway,
you can use the results of testing to decide if the
coverage should be reduced or expanded. If a
significant number of defects are slipping into
production, more comprehensive testing is probably
needed. But if quality is good, you might be able to
safely scale back your efforts further.
 Sample risk based testing priority chart
Risk Coverage Risk Factors
High 100% • Supportsregulatory requirements
• External or client-facing
• Supports financial transactions or their reference
• Functionality cannot be supported by manual/workaround process
• Supports externalsystem connectivity (real-time transactional)
• Subjected to high volume of transactions
Medium 75% • Internal employee-facing
• Supports externalsystem connectivity (batch)
• Functionality supportsreference data (e.g. product lists)
Low 50% • Functionality is not essential to the financial management
• Functionality could be manually duplicated
• Supportssmall number of transactions
Checklist
• Can you accurately estimate the required
number of test scripts based on your
requirements, or does the number grow
and grow during test planning?
• Does your processfor requesting changes
to a project reflect the effort required to
update test plans and test scripts?
• Has a testing strategy been defined to
determine the right breadth and depth,
or does testing always seem to require
too much time and money?
Myth 8
Bigger is better - more scripts
mean better testing.12
Reality
Business analysts and developers are central to an
effective overall quality assurance approach.
Software development traditionally has followed
a sequential model. Business analysts define
and document business requirements, then
pass those requirements along to the software
developers. Developers write programs to satisfy
the requirements, and then throw the code over the
wall to the testing group. Testers develop and run
tests based on the business requirements, then send
defective code back upstream for rework.
That sequential approach might have been good
enough in the past, but in today’s agile world, there
are much better ways to manage and test software
quality.
Continuous integration makes QA an integral part of
the software development process, with involvement
from QA staff throughout the development lifecycle.
This requires an up-front investment in tools and
training, but quickly pays for itself through improved
quality and efficiency.
Quality should be a top priority from day one –
starting with scoping, estimating and planning.
This enables you to identify potential defects early,
while they are still relatively cheap to fix. It also
provides integrated unit testing and source code
management.
Automated unit tests
Comprehensive automated
unit tests to validate codebase
Integration scheduler
Scheduler that will call
scripts to continuously
produce builds and
generate reports
Common code
repository
Safe and central location
where developers can
retrieve and check in
source code
Automated
build scripts
Automation scripts that
follow procedures to
compile and deploy apps
Frequent cycle
of check in,
build, unit test
and reporting
Checklist
• Are a significant percentage of your defects
classified as “unknown requirements” that
result in change requests and rework?
Offshore testing presents many of the same
challenges as other offshore development activities
and should be evaluated as part of the overall
delivery approach.
As organisations look for ways to reduce the overall
cost of system development, more and more are
moving key development functions offshore.
Offshoring can provide significant cost savings, as
well as other valuable benefits such as overnight
turnaround on testing and defect logging. However,
it is ultimately a delivery model, not just a staffing
model, and must be evaluated as part of the overall
delivery approach.
Time zone differences between onshore and
offshore resources can be a real problem, particularly
for business analysts and QA analysts who often
require heavy interaction. Offshoring also bucks
the trend of co-locating development and testing
resources to shorten the cycle for validating and
resolving defects.
The decision about what QA activities to move
offshore – and how – should be made at the project
level, and depends on what other project activities
will be performed offshore.
One proven approach is to offshore the activities
associated with selected system components, but
keeping development and testing together.
Checklist
• Does your organisation have experience with
outsourcing or offshoring other development
functions?
• Is QA/testing currently a standalone unit or
function within your organisation?
• Are your business users or business analysts
heavily involved in the testing cycle?
• Are your requirements documented well
enough that detailed testing specifications
could be effectively transferred to an offshore
The myths that surround testing and quality
assurance make it hard for the QA function to do its
job. Even worse, they silently undermine software
quality and drive development and support costs
through the roof.
Studies show that one hour invested in quality
assurance generally saves 3 to 10 hours in
downstream costs. Moreover, defects introduced
during the requirements phase – if not found until
final testing – cost 50 to 200 times more to correct
than detecting and resolving them immediately.
Testing - by itself - cannot deliver a high level of
quality. To be effective, quality assurance must be
integrated into the entire software delivery proces