Testing Process: Test Closure
Testing Process: Test Closure
Testing Process: Test Closure
Test closure
Test initiation
Test execution
Test planning Test design
Test reporting
Test initiation
System testing is starting with test initiation. In this stage
project manger category people are selecting reasonable
test to be applied.
After selecting reasonable test, the project manager is
preparing test strategy document. This document is also
known as “test methodology”.
Risks
Test strategy document
Identify risks
Development Test plan(s)
documents
Prepare test plan(s)
Development
plan Review test plan(s)
Team formation: the test planning process is
starting with testing ream formation. In this
phase ,the test lead is depending in below factor:
Project size
Availability of test engineers
Test duration
Availability of test environment
resources
Identify risks: after completion of reasonable testing team
formation the test lead is concentrating on risks at that
team level.
Risks:
Lack of knowledge on domain of testing team
Lack of time
Lack of resources
Lack of documentation
Delay in delivery
Lack of development process rigor
Lack of communication
Prepare test plans: after the testing formation and
risk analysis, the test lead is preparing test plan
documents.
The test plan will give what to test, how to test,
who to test, when to test.
Test plan document
HLD/LLD Ru n
Coding(build)
From the above diagram test engineers are preparing test
cases depending on SRS through below approach:
1. Collect responsible functional and system specifications
including dependencies.
2. Select one specification from the collected list.
3. Study that specification in terms of base state, inputs,
outputs, normal flow , end state, alternative flows and
exceptions.
4. Prepare test case title/test scenarios with respect to above
studied information.
5. Review test case titles for completeness and correctness.
6. Prepare test case documents.
7. Got step2 until all responsible specifications studied.
Test case documentation
After the completion of reasonable test scenarios or titles,
the test engineers are documenting that test cases. In this
phase test engineers are following a standard format:
1. Test case Id : Unique number or name for future reference.
( Tc_module_name_date_number)
2. Test case name : the title of test case
3. Feature: the name of corresponding module
4. Test suite – Id: the name of test batch, this case is a
member in that batch.
5. Priority: the importance of test case in terms of
functionality. P0 basic functionality test case
P1 General functionality
P3Cosmetic functionality
6. Test effort: persons/hour: (Avg. 20 min to execute
one test case)
7. Test environment: required hardware and
software to execute this case.
8.Test duration: date and time to execute this case
on built.
9.Test setup/pre-condition : the necessary tasks to
do before start this case execution on build.
10.Test procedure./ Data matrix:
Test Procedure:
Step Actio I/p expect Actu result Defec comm
No. n required ed al t ID ents
Data Matrix:
ECP (type) BVA (size/range)
Input object
Valid invalid Min Max
11.Test case pass or fail criteria: the final result of
test case after execution.
Environ
ment Customer
Test environment site
From the above model the testing people are downloading
build from configuration repository in server with
permission.
In this repository development people are maintaining
old build coding and modified build coding in this
repository to distinguish old build and modified build
development people are assigning unique version number
to that build. For this build version control and
development team is using version control tools.
Development team will send release note for testing team
for every modified build. This release note is providing
information about changes in build.
Levels of Test Execution
DEVELOPMENT TESTING
INITIAL BUILD LEVEL-0(SANITY)
STABLE BUILD
LEVEL-1
FIXING DEFECT REPORT (COMPREHENSIVE
TESTING OR REAL
TESTING)
RESOLVING MODIFIED BUILD LEVEL-2
(REGRESSION)
(High/medium/low)
11.Status: new/reopen
new: reporting first time
reopen: re-reporting
12.Detected by: the name of test engineer
13.Detected on: date of defect detection and reporting
14.Assigned to : the responsible person at development site to receive the
defect.
15.Suggested fix (optional): suggestion to developers to accept and resolve
that defect.
Defect submission process
PM
Test Engineer
Large Scale organizations
PM
New
deferred
Open Rejected
closed Reopen
Possibilities:
New – Open—Closed
New– Rejected—Closed
New—Open—Reopen- - - - - - - Closed
New – Rejected– Reopen - - - - - - Closed
New – Deferred
Defect Age: the time gap in between defect
reporting and defect closing or deferring
Defect Density: The average number of defects
detected in on module or function is called defect
density
Defect resolution Type: After receiving defect
report from testing team development people are
conducting review and then send a reply to testers
this reply is called “defect resolution type”.
Test closure
After the completion of all reasonable cycles of
test execution and defects closing, the test lead is
conduction a review meeting to estimate
completeness and correctness of testing process.