Continuation of Testing Levels in SDLC
5) System Testing:
After unit testing and integration testing, the development
team releases the initial build to the separate testing team.
Initially the testing team performs stability test on
released build.
If the build is stable à
testing team starts testing the functionality
of the application,
If the build is stable à
testing team rejects the build and requests for the patch file,
The testing team validates the whole system based on the
client requirements and expectations are called System Testing.
In
system testing, the test engineer concentrates on the validation of application
functionalities, performance, compatibility, user friendliness, security, Installation,
etc… Based on the factor going to validate entire system testing technique is
divided into 2 Categories.
They are
a. a. Functionality Testing/ Requirements Testing:
Validating the business transactions on
application based on client requirements is called functionality testing. This
functionality can be performed either manually or by automation testing.
Test engineers consider the following
factors while performing functionality testing,
I.
Objects properties coverage: Validates whether the application object
property values are changing or not based on the operations performed.
Example: (Scenario) Verify “OK”
should enabled in the window when we enter the value in the edit box related to
it: It means the object property should change from disable to enable.
II.
Error Handling Coverage: The test engineer
checks for the meaningful error handling mechanism when the end user performs
invalid operations on the system, like pop –up messages, error messages,
warning messages, etc…
Example: (Scenario) suppose there
is a text field which allows numerical values, but user entered alphabetical
values and tried to make transaction , then system should throw error message
/pop-up on the screen with correct explanation and details.
III.
Input-Domain Coverage: The test engineer verifies
whether the system allows the data as per the client expected data or not.
Example: Edit box should allow alphanumeric characters in between 4-9
range. So engineer tests for this expected data.
IV.
Calculation/ Output Coverage: Test engineer verifies the generated output
based on the given input values/data.
Example: 2+3 =5 as per that
condition system should generate output as 5 when we perform addition operation
on 2 and 3.
V.
Back end/ Database Coverage: Test engineer
verifies the transfer of data between front end and database storage along with
database content with respect to the operations performed on applications like
insert update and delete …
VI.
Links Coverage: Checks the specified links in
the application are navigating properly to their respective pages.
b. b. Non-Functionality Testing: The test engineer
verifies all the possible non –functionality factors like performance,
compatibility, security, installation , etc… Following are the
non-functionality testing techniques:
I.
GUI Testing: The test engineer verifies the look
and feel of the application based on different factors like availability of
components, alignment, spelling mistakes, font size/style, background color,
controls, clarity of text and images.
II.
Usability Testing: The test engineer checks for
the user friendliness of the application to perform operations and mostly
concentrates on error handling mechanism , tab and functional key
implementation , shortcut navigations, etc…
III.
Performance Testing: In general performance
testing is conducted with performance testing tools available in the
market.
Performance testing is conducted by separate testing
team and concentrates on speed, scalability and stability. But this testing is
conducted using different techniques.
A.
Load/ Scalability Testing: Within the limit,
engineer checks the applications allows customer expected load or not.
B.
Stress Testing:
Beyond the load limit, test engineer checks the behavior of the
application.
C.
Soak/Endurance Testing: Verifies the stable
functioning of the application with respect to time.
D.
Spike Testing: Verifies the stability of the application
under varying loads.
E.
Data Volume Testing: Verifies how much data
transfers in a specified time in the form of kbps or records.
IV.
Security Testing: Verifies the privacy of the
transactions in terms of authentication, access control, sessions and clearance
of cookies after closing the application.
V.
Recovery/Reliability Testing: verifies how the
system is capable to recover from abnormal state to normal state.
VI.
Compatibility/ Portability Testing: Verifies
whether the application supports customer expected environment or not with
forward versions and backward versions.
VII.
Configuration Testing: Verifies application
supports customer expected configuration systems or not.
VIII.
Installation Testing: Verifies the installation
process of the application as per the guidelines and instructions mentioned in
the user manuals.
IX.
Sanitation Testing/ Garbage Testing: Verifies
for the extra added features which were not mentioned in the client
requirements.
X.
Comparative/Parallel Testing: Verifies the
existing competitive products or lower versions of application in order to
identify the strengths and weakness of the application.
6) User Acceptance Testing (UAT): Acceptance Testing is a level of
the software testing process where a system is tested for acceptability. There
are 2 types of UAT.
Alpha
Test: The client participates in the testing at the developer’s site, if any
defects are identified within a short period resolved and gets approval for the
installation at client’s place.
Beta
Test: After installation of the
application at client place the client runs the application with real time data
, if any defects are identified recorded and sent to developers to fix it.
