Becky’s Quality and Testing headings
2.2.4.2. Acceptable Tests
The following test tables are to determine if the project meets client objectives. The tables will be completed
during the testing stages of the SmartPosition project. Table 2.2.4.2.1 is a matrix to show the status of
acceptance testing. Table 2.2.4.2.2 is an explanatory template for the consecutive acceptance tests. For the
SmartPosition project the unique identifier for each Acceptance Criteria Test will have the suffix AC
followed by three digits starting from 001.
The acceptance matrix requires an ID from the acceptance test case and a short description or title of the test.
The criticality of the test needs to be determined, for example, if it requires being redone for acceptance.
Finally the acceptance matrix needs to note if the text reached the specified acceptable level and the dated. It
is currently organised in order of ID number but also could be sorted by date completed.
2.2.4.2.1
Acceptance Matrix
General
Acceptance
Criterion
Summary
Acceptance Brief summary
identifier
about the
AC000
acceptance test
Identifier
Critical
Test Results
Yes
Accepted
Yes
No
Rejected
Accepted
Date
dd/mm/yy
2.2.4.2.2
Acceptance Criteria
Information:
Test title:
Title of the test case
Test ID:
Test case identifier
Identifier:
Unique Acceptance Criteria identifier AC000
Acceptance Details:
Description:
Description of test
Pass/Fail
Criteria:
Description of acceptance criteria
Critical:
Date:
dd/mm/yy
Yes
Results:
Y
No
Accepted
Accepted
N
N/A
Rejected
Rejected
N/A
Notes:
An explanation on why it was accepted or rejected.
Accepted by:
Tester:
Name of staff conducting the test
Date:
dd/mm/yy
Test Manager:
Name of manager overseeing the test
Date:
dd/mm/yy
2.2.4.3. Classes of Tests
Classes of tests for his project will be sourced from IEEE Standard 9.1.5. The following table is a break
down of test classes and a description of each.
Description
Identifier Test Type
2.2.4.3.1 Unit
2.2.4.3.2 Component
Individual unit testing tests the raw parts of the project.
Integration
Determines the functionality of a section (component) of the project.
Tests that each component functions with the other components and/or as a
whole.
2.2.4.3.4
Function
Similar to system testing, it tests the functionality of components in the
system.
2.2.4.3.5
2.2.4.3.6
System
Performance
2.2.4.3.7
Acceptance
2.2.4.3.3
Tests that the system functionality performs to SRS requirements. It determines
the success of the system performance.
Tests the system output corresponds to performance requirements.
Tests that determine if the SmartPosition reaches an level of ‘acceptance’
by the client.
2.3.1.4. Test Item Transmittal Report
The Test Item Transmittal Report for the SmartPosition is to record the progress of testing phases. It requires
a record of transmitted item’s test case identifier, title and the tester and test manager for traceability. The
transmittal plays an important part in making sure that testing and implementation happens in chronological
order. The following table is an example of how they will be filled in for each test. For the SmartPosition
project the unique identifier for each Transmittal Report will have the suffix TR followed by three digits
starting from 001.
Test Item Transmittal Report
Information:
Test title: Test case title
Identifier:
Transmitted Items:
Unique Transmittal ID: TR000
Date:
dd/mm/yy
ID:
Title:
Tester:
Test Manager:
Test case identifier
Test case title
Staff Tester
Manager
Status:
Description
Notes on current status
Deviations
Notes on any deviations
Incident reports
Notes on any incidents and corresponding incident report identifiers
Accepted by:
Tester:
Test Manager:
Tester signature
Test manager signature
Date:
Date:
dd/mm/yy
dd/mm/yy
2.3.1.5. Test Log
The following test log table is designed to be filled in during the testing phases of the project. It is a record
overview of all the tests conducted. It includes the order of testing, the tester, a brief description of the test,
recording which tests cases were run, who ran them, in what order, and whether each test passed or failed.
Rows can be added as the scope of the testing expands. The test log is used for test plan auditing,
referencing and tractability.
Test Log
Log:
ID
Unique
identification
number from
traceability
matrix/test
case.
Test
Title
Description
Brief test
title that Brief
describes description
the test of test.
type.
Test Date
Test Class
Pass
(P)
Fail
(F)
Completion
date
Which test class it
falls under. Refer
to section 2.2.4.3
Pass
Fail
0
0
Summary:
TOTAL
(Pass/Fail)
2.3.1.6. Test Incident Report
The Test Incident Report is subject to IEEE standard 829-1998 ‘Standard for Software Test Documentation’.
It is completed for any test that fails its set pass criteria. It is designed to determine how and why the test
failed. It consists of a description of intended results and actual results, for comparative reasons, and a
traceability matrix so you can determine other tests that may be affected by the incident. For the
SmartPosition project the unique identifier for each Incident Report will have the suffix IR followed by three
digits starting from 001.
Test Incident Report
Information:
Test title:
Test case title
Incident Identifier:
Unique incident identifier: IR000
Date:
dd/mm/yy
Incident Details:
Test ID
Test case identifier
Summary
Describe the incident and reference any relevant procedures.
Links to identifiers for test log should be submitted. Any further
notes.
Describe the incident in full and give reason why it may have
gone wrong and areas that may have contributed to the incident.
The following areas can be included the expected results versus
Incident description the actual results. The time and environment of the test and the
name of the tester and test manager. Any information that leads
to the discovery of what caused the incident should also be
included.
Impact
Indicate any areas that might be affected by the failing of this test
and any repercussions that may occur as a result.
Accepted by:
Tester:
Signature of tester
Date:
dd/mm/yy
Test Manager:
Signature of test manager.
Date:
dd/mm/yy
2.3.1.7. Test Summary Report
The test summary report is a document collaborating conclusions after testing. This includes all testing
documentation on the specific test case, even incident reports and repeated tests. The document is meant to
be provided to management who want to read only the essential details of the testing phases. The test
summary report includes a summary of the acceptance criteria, quality testing, testing conditions and gives
indications on if and where improvements could be made. For the SmartPosition project the unique
identifier for each Summary Report will have the suffix SR followed by three digits starting from 001.
Test Summary Report
Information:
Test title: Test case title
Test ID: Original test case identifier
Identifier: Unique Summary Report Identifier: SR000
Date:
dd/mm/yy
Test Details:
Summary:
Reference all documentation related to this test case
including incident report, acceptance criteria,
transmittal report and test log.
Variances:
Note any changes to the test case, for example, a
retest or changes to testing environment.
Assessment:
Give a response to testing outcomes and the effects
they may have.
Results:
Provide results from the testing procedures. Pin point
any circumstances that require attention. Discuss any
solutions to incidents and any recommendations for
test improvements.
Evaluation:
Make comments on the success or failure of the
testes. Give suggestions on the following steps to
take.
Corrective Action Plan
(CAP):
If there are any unresolved issues or items identified
in an incident report a corrective plan needs to be
made and referenced here.
Accepted by:
Tester:
Signature of tester.
Date:
dd/mm/yy
Test Manager:
Signature of test manager.
Date:
dd/mm/yy