Manual
Testing Concepts
Technical
Factors:
Meet
customer requirements in terms of Functionality
Meet
customer expectations in terms of Performance, Usability, Security,
etc…
Non-Technical
Factors:
Reasonable
cost to purchase.
Time
to release.
1.1 Software
Quality Assurance (SQA):
The
Monitoring and Measuring the strength of development process is
called Software Quality Testing. Ex: Life Cycle Testing.
1.2 Software
Quality Control (SQC):
The
validation of final product before releasing to the customer is
called as SQC.
2. Software
Development process:
Fish
model software development: Upper angle is life cycle development and
lower angle is life cycle testing.
BRS:
Business requirement specification defines the requirement the
customer to be developed as software. This document is also known as
Customer Requirement Specification (CRS) or User Requirement
Specification (URS).
SRS:
Software
requirement specification defines functional requirements to be
developed and system requirement to be used (Hardware and Software).
Example:BRS
defines addition (Customer requirement).
SRS
defines how to solve customer requirement.
Review:
It is a static testing technique. In this review responsible people
will estimate
completeness and correctness of corresponding
documents.
HLD:
High Level Design document defines the overall architecture of the
system from root functionalities to leaf functionalities. This HLD is
also known as Architectural Design or External Design.
LLD:
Low Level Design document defines the internal logic of corresponding
module (or) functionality. The LLD is also known as Internal Logic
Design document.
Prototype:
A sample model of an application without functionality is called
prototype.
Program:
A set of execute statements is called a Program.
Module:
A set of programs is called as a Module or Unit.
Build:
The set of modules is called as Software Build or Product.
White
Box Testing:
It is a coding level testing technique to verify the completeness and
correctness of program structure. Programmers will follow this
technique. It is also known as Glass Box Testing (or) Clear Box
Testing (or) Open Box Testing.
Black
Box Testing:
It
is a build level testing technique. In this testing test engineers
will validate every feature depending on external interface.
Software
Testing:
The Verification and Validation of a software application is called
software testing.
Verification:
Are we building the product right?
Validation:
Are we building the right product?
3.1
V model
V
stands for Verification and Validation. This model defines mapping
between development process and testing process.
The
real V-model is expensive to follow for small and medium scale
organizations. Due to this reason, small and medium scale
organizations maintains separate testing team for System Testing
phase.
3.2
Reviews
during Analysis
In
general the software development process starts with requirements
gathering and analysis. In this phase business analyst category
people will develop BRS and SRS. After development of the documents
the same business analyst category people will conduct review
meetings to estimate completeness and correctness of the documents.
In this review meeting, the same business analyst category people
will concentrate on below checklist. BRS è SRS.
Are
the requirements correct?
Are
the requirements complete?
Are
they achievable (w.r.t Technology)?
Are
they reasonable (w.r.t Time)?
Are
they testable?
3.3Reviews
during Design
After
completion of analysis and then reviews the design category people
will develop HLD’s and LLD’s. The same design category people
will conduct review meetings to estimate completeness and correctness
of the design documents. In the review the same design category
people will concentrate on below checklist HLD è LLD.
Does
the design understandable?
Are
the correct requirements met?
Does
the design complete?
Does
the design follow able (w.r.t Coding)?
Do
they handle errors?
3.4
Unit Testing
After
completion of design and their reviews, programmers will concentrate
on coding to construct software physically. In this phase programmers
will test every program through a set of white box testing techniques
w.r.t LLD.
3.4.1Basis
Path Testing
In
this coverage programmers will verify the execution of program
without any syntax and run time errors. In this coverage programmers
will execute a program more than one time to cover all areas of that
program coding while running.
3.4.2Control
Structure Testing
In
this coverage programmers will concentrate on correctness of the
program functionality. In this coverage programmers will check
statements in the program including variables declaration, IF
conditions, Loops, etc….
3.4.3Program
Technique Coverage
In
this coverage programmers will verify the execution time of program
to improve speed in processing. If the execution time is not
reasonable then the programmers will change the structure of the
program without disturbing functionality.
3.4.4Mutation
Testing
After
completion of a program testing, the corresponding programs will
review the completeness and correctness of the program testing.
Mutation means that a change in coding of the program, in this
Mutation testing programmers will perform changes in various areas in
the program and repeat previously completed tests. If all the tests
are passed on the changed program, then the program will continue
testing on some program. If any one of the tests is failed on the
change in program, then the program will concentrate on further
coding.
Note:
in
white box Testing techniques, the first 3 techniques will test
program code and the mutation testing will estimate the completeness
and correctness of the test on the program.
3.5Integration
Testing
After
completion of dependent programs development and unit testing,
programmers will inter connect the programs to construct a complete
software build. In this stage programmers will verify integration of
programs in four types of approaches.
Top
Down Approach.
Bottom
Up Approach.
Hybrid
Approach.
System
Approach.
3.5.1Top
Down Approach
In
this approach the programmers will inter connect main models to some
of the modules in the place of remaining sub modules programmers will
use temporary programs called Stubs.
3.5.2Bottom
up Approach
In
this approach the programmers will inter connect sub modules without
connection to the main module. Programmers will use a temporary
program instead of main module called Driver.
3.5.3Hybrid
Approach
It
is a combined approach of Top Down and Bottom Up approaches. This
approach is also known as Sandwich approach.
3.5.4
System
Approach
It
is also known as Final Integration (or) Big Bang Approach. In this
integration programmers will inter connect programs after completion
of total development.
Note:
In general the programmers will inter connect programs through any
one of the above methods depending on circumstances.
3.6
System
Testing
After
completion of Integration Testing, and receiving the build from
development team, the testing team will concentrate on system testing
to conduct using Black Box Testing techniques.
System
Testing is divided into 3 sub stages.
Usability
Testing.
Functional
Testing
Non-Functional
Testing.
3.6.1 Usability
Testing
After
receiving software build from development team, the testing team will
conduct usability testing. In this test the testing team will
estimate “User Friendly ness” of all screens in the software
build. There are two sub tests.
3.6.1.1User
Interface Testing or UI Testing
In
this test, the testing team will apply below 3 factors on every
screen of the software build.
·Ease
of use: To estimate understandability of screen.
·Look
and Feel: To estimate attractiveness of screen.
·Speed
in Interface: To estimate length of navigation as short.
3.6.1.2
Manual
Support Testing
During
this test the testing team will validate the correctness and
completeness of help documents. These help documents are also known
as User Manuals.
3.6.2
Functional
Testing
It
is a mandatory testing level in testing team responsibilities. During
this test, testing team will concentrate on “Meet customer
Requirements” through below sub tests.
Requirement
Testing.
Sanitation
Testing.
3.6.2.1
Requirements
Testing
It
is also known as Functionality Testing. During this test the
responsible testing team will apply different coverage techniques as
discussed below on the functionalities of software build.
·GUI
Coverage / Behavioral Coverage: Changes in properties of objects in
screens while operating.
·Error
Handling Coverage: To prevent wrong operation on screens.
·Input
Domain Coverage: Testing correct type and size of input values
·Manipulations
Coverage: Returning correct output values.
·Back
End Coverage: Valid impact of screens operations on back end data
base tables.
·Functionalities
Order Coverage: The arrangements of screens in the software build
with respect to order of functionalities.
3.6.2.2Sanitation
Testing
During
this test the testing team will concentrate on extra functionalities
with respect to requirements of the customer. This testing is also
known as garbage testing.
3.6.3Non-Functional
Testing
After
completion of user interface and functional testing, the testing team
will concentrate on Non-Functional Testing to validate quality
characteristics of software build Like Security and Performance.
3.6.3.1
Recovery
Testing
This
testing is also known as Reliability Testing. During this test, the
testing team will validate that whether the software build is
changing from abnormal state to normal state.
3.6.3.2
Compatibility
Testing
It
is also known as Portability Testing. During this test, the testing
team will validate that whether the software build is running on the
customer expected platforms or not?.
3.6.3.3
Configuration
Testing
It
is also known as hardware compatibility testing. During this test the
testing team will validate that whether the software build is
supporting different technology hardware devices or not?
Example:Different
technology printers.
Different
topology networks, etc….
3.6.3.4
Inter
Systems Testing
It
is also known as End-to-End Testing. During this test the testing
team will validate that whether the software build co-exists with
other software applications to share common resources.
Example:Sharing
data, sharing hardware devices, printers, speakers, sharing memory,
etc….
3.6.3.5
Installation
Testing
During
this test, the testing team will establish customer site like
configured environment. The testing team is practice installation of
software build in to that environment.
3.6.3.6Load
Testing
The
execution of the software build under customer expected configuration
and customer expected load to estimate speed of processing is called
as load testing. Here, load means that the no of concurrent users
working on the software. This is also known as scalability testing.
3.6.3.7
Stress
Testing
The
execution of the software build under customer expected configuration
and various load levels from low to peak is called stress testing. In
this testing, testing team will concentrate on load handling by the
software build.
3.6.3.8
Storage
Testing
Testing
whether the system meets its specified storage objectives.
Testing
the data of different formats and in different devices. Verifying the
efficiency of data storage in devices and proper retrieval of the
data.
3.6.3.9
Data Volume
Testing
Volume
testing refers to testing a software application with a certain
amount of data. This amount can, in generic terms, be the database
size or it could also be the size of an interface file that is the
subject of volume testing. For example, if you want to volume test
your application with a specific database size, you will expand your
database to that size and then test the application’s performance
on
it.
Example:MS
Access technology support 2GB of database as maximum.
3.6.3.10
Parallel
Testing
It
is also known as Comparative Testing. During this test, the testing
team will compare the software build with other competitive software
in market or with old version of same software build to estimate
completeness. This is applicable only for software product but not on
software applications.
3.7
User
Acceptance Testing (UAT)
After
completion of all possible Functional and Non-Functional tests, the
project manager will concentrate on user acceptance testing to
collect feedback from customer site people. There are two approaches
to conduct UAT, such as a-Test
and b-Test.
a-Test
|
b-Test
|
1.Software
applications.
2.At
development site.
3.By real
customers.
|
1.Software
products.
2.In
customer site like environment.
3.By
customers site like people.
|
Collect
Feedback
|
3.8
Testing
during maintenance
After
completion of user acceptance test and their modifications, project
management concentrate on release team formation with few developers,
few testers and few hardware engineers. This release team is coming
to customers site and conduct port testing.
During
this port testing release team concentrate on below factors in
customers site.
Compact
installation
Overall
functionality
Input
devices handling
Output
devices handling
Secondary
storage devices handling
Co-existence
with other software to share common resources
Operating
system error handling
After
completion of port testing, release team provides training sessions
to customer site people.
During
utilization of the software, customer site people are sending change
request to our organization. There are two types of change request to
be solved.
4.Testing terminology
Monkey
Testing:
A
Test Engineer conducting a test on application build through the
coverage of main activities only is called monkey testing or
chimpanzee testing.
Exploratory
Testing:
A
Tester conducts testing on an application build through the coverage
of activities in level by level.
Ad-Hoc
Testing:
A
Tester conducts a test on application build with respect to pre
determined ideas is called ad-hoc testing.
Big
bang Testing:
An
organization conducting a single stage of testing after
completion of entire modules development is called big bang testing
or informal testing.
Incremental
Testing:
An
organization follows the multiple stages of testing process from
document level to system level is called incremental testing or
formal testing.
Example:
LCT
(life cycle testing).
Sanity
Testing
Whether
the build released by the development team is stable for complete
testing to be applied or not?
This
observation is called sanity testing or tester acceptance testing
(TAT) or build verification testing (BVT).
Smoke
Testing:
An
extra shake-up in sanity testing is called smoke testing. In this
phase test engineer will try to find the reason when the build is not
working before start working.
Static
versus Dynamic Testing:
A
tester conduct a test on application build without running during
testing is called static testing.
Example:Usability,
Alignment, Font, Style …..Etc.
A
tester conduct a test through the execution of our application build
is called dynamic testing.
Example:Functional,
Performance and Security Testing.
Manual
Vs Automation Testing
- A
Test Engineer conducts a test on application build without using any
third party testing tool is called Manual Testing.
- A
Test impact indicates test repetition with multiple test data.
Example:functionality
testing.
- A
Tester conducts a test on application build with the help of a
testing tool is called test Automation Testing.
- A
Test criticality indicates that complexity to execute the test
manually.
Example:load
testing.
Re-Testing
The
re-execution of a test on same application build with multiple test
data is called re-testing.
Ex:multiple
Regression
Testing
The
re-execution of selected test on modified build to ensure bug fix
work and occurrences of side effects is called regression testing.
Error:A
mistake in coding is called Error.
Defect:A
test engineer found mismatch due to mistakes in coding during testing
is called
Defect
or issue.
Bug:A
defect accepted by developers to be solved is called Bug.
REFERENCES AND RESOURCES:
1.
http://www2.sas.com/proceedings/sugi30/141-30.pdf
2.
http://www.softwaretestingclass.com/category/testing-concepts/
