| Quality
Testing |
| Software Testing
at EZEN is oriented to 'detection of defects in the software'.
Testing is basically concerned with the operation of a system
or application under controlled conditions, and evaluating
the results. |
 |
| Understanding
Business Requirements (customer requirements) |
|
| EZEN's consulting
experience has demonstrated the importance of accurately
capturing business and project-specific requirements. Our
consultants work closely with you to: |
- Understand your Testing Requirements.
- Understand the levels of testing to be carried out, existing
standards and test procedures.
- Review all technical documentation (Requirements specifications,
Change requests, Design documents, Installation manual, User
manuals etc.).
|
|
| After reviewing
and identifying customer requirements and standards, EZEN's
consultants suggest improvements and/or additions to the
existing standards. Once they are approved and signed off
by the customer, they enter the configuration management
process (appropriate version control tools are used). These
standards and templates will be enforced by SQA during all
levels of testing. |
|
| Levels
of Testing |
|
| EZEN has
expertise in testing at all levels. At each test level, the
results are documented, reviewed and signed off. This is
done to ensure that quality testing is carried out according
to Configuration Management (CM) procedures. |
| Each level
of testing is either considered black or white box testing. |
|
| Black
box testing: This is not based on any knowledge of internal design or
code. The Tests are based on requirements and functionality. |
|
| White
box testing: This testing is based on knowledge of the internal logic
of an application's code. Tests are based on coverage of
code statements, branches, paths, and conditions. |
|
| Unit
Testing |
|
| level of dynamic
testing and is first the responsibility of the developers
and then of the testers. |
|
| Parallel/Audit
Testing |
|
| In Parallel
Testing, the user reconciles the output of the new system
to the output of the current system in order to verify that
the new system is operating correctly. |
|
| Functional
Testing |
|
| This is a category
of Black box testing, geared to functional requirements of
an application, performed by the testing team |
|
| Usability
Testing |
|
| Usability Testing
for is performed to check the 'user-friendliness' of the
application. Clearly this is subjective and will depend on
the targeted end user or customer. |
|
| Integration
Testing |
|
| Upon completion
of unit testing, integration testing (basically, white box)
commences. The purpose is to ensure distinct components of
the application still work in accordance to customer requirements. |
|
| System
Testing |
|
| After integration
testing, the Testing Team will begin system testing, which
is a category of black box testing. The complete system is
configured in a controlled environment to validate its accuracy
and completeness in performing the functions as designed. |
|
| End
- to - End Testing |
|
| Similar to
System Testing, End-to-End Testing involves testing of a
complete application in an environment that mimics real-world
use, such as interaction with a database, using network communications,
or interacting with other hardware, applications, or systems
where appropriate. |
|
| Regression
Testing |
|
| The objective
of Regression Testing is to ensure software remains intact.
A baseline set of data and scripts will be maintained and
executed to verify that the changes introduced during the
release have not made any unintended modifications in
the code. |
|
| Sanity
Testing |
|
| Sanity Testing
will be performed whenever cursory testing is sufficient
to prove that the application is functioning according to
specifications. This level of testing is a subset of Regression
Testing. |
|
| Performance
Testing |
|
| Although performance
testing is described as a part of System Testing, it can
be regarded as a distinct level of testing. Performance testing
will verify the load, volume, and response times as defined
by requirements. |
|
| Security
& Penetration
Testing |
|
| Security Testing
verifies as to how well the system protects itself against
unauthorized internal or external access, willful damage,
etc. |
|
| Recovery/Error
Testing |
|
| This testing
is carried out to check how well a system recovers from crashes,
hardware failures, or other catastrophic problems. |
|
| Compatibility
Testing |
|
| Compatibility
Testing is concerned with verifying how well software performs
in a particular hardware/software/operating system/network/etc.
environment. |
|
| Comparison
Testing |
|
| This Testing
compares software weaknesses and strengths to competing products. |
|
| Acceptance
Testing |
|
| Acceptance
Testing, which is black box testing, provides the client
the opportunity to verify the system functionality and usability
prior to the system being moved to production. |
| |
