Test Engineering
Close-knit collaboration in the Software Development Life Cycle (SDLC), specifically
for quality control – testing partnerships is based on effective and quick knowledge
transfer. The QC team will need thorough footing on the product, its intended usage,
the environment, the installation process, the design elements, standards and other
specific areas that form the quality benchmarks.
QC life cycle at RediSolve is close aligned to the software development model and
the definition of quality. In rapid development models, where foundation documentations
to design a QC process are not available, RediSolve QC teams are proficient in efficient
reverse engineering. RediSolve has homegrown code crawlers that help in creation
of reference artifacts.
Specifically, for a product builds, it is highly recommended to build a solid SQA
layer with optimum automation and tool based testing.
RediSolve QA team will be working on a global hybrid model. RediSolve has the best
of breed infrastructure and communication tools available to support the team.
Workflow
|
Define Test Completion Criteria or Test Case Design
|
The test effort has specific, quantifiable goals. Testing is completed only when
the goals have been reached. For example, testing is complete when the tests that
address 100% functional coverage of the system have executed successfully.
The test completion criteria can be made available to the development team so that
there is clear understanding on the definition of the bug. One of the common problems
between the QC team and the Development team is ‘what is a bug – what is a feature’.
An agreement on the test case design through a detailed review and sign-off sets
the foundation for smooth QC.
|
|
Design Test Cases
|
Logical test cases are defined by four characteristics: the initial state of the
system prior to executing the test, data, input and the expected results.
Test cases (automated or manual) can also be made available for the Development
team. This would encourage stronger unit testing and lesser amount of effort on
regression cycles.
It is an established fact that a bug spotted earlier is fixed easier.
|
Workflow
|
Build Test Cases
|
There are two parts needed to build test cases from logical test cases: creating
the necessary data and building the components to support testing. For example,
build the navigation to get to the portion of the program being tested.
In such situations a, small software development team can be made available to work
with the QC team to develop testing tools that fit the need. This team can also
be used to enable an automated testing layer tailored to the QC objectives of the
product – project.
|
|
Execute Tests
|
Execute the test case steps against the system being tested and document the results.
The documented output would be the QC report or the bug list. This can be deployed
in an intranet[1] environment for tracking and fixing. This would be followed by
regression testing. Automated testing comes in handy when the expecte iterations
are high. There are time savings on QC iterations.
This can also be automated testing where the test scripts are either converted into
a focused test tool for that product – project or, a bunch of test cases are tied
together for automatic execution using a PERL script or a Batch process. Automated
testing can also be based on third party tools available in the market to achieve
specific QC objectives.
Automated testing is described in detail in the following section.
|
|
Verify Test Results
|
Testers are responsible for verifying two different types of test results: results
as expected, and do the test cases meet the test completion criteria (or test case
design).
|
|
Verify Test Coverage
|
Track the amount of functional coverage achieved by the successful execution of
each test.
|
|
Manage the Test Library
|
The test manager maintains the relationship between the test cases and the programs
being tested. The test manager keeps track of what tests have/have not been executed,
and whether the executed tests have passed or failed.
|
|