Business
requirements
requirements
This is the expression of what the business needs the solution to deliver. It should focus on establishing the available inputs, required outcomes and key business and operational constraints that must be observed.
System
requirement test
requirement test
The test team works with the business subject matter experts to verify that the delivered system meets the original business requirement. Testing is typically driven by operational scenarios that describe the end to end business processes that the new functionality is part off.
Functional
requirements
requirements
This document will typically describe the user experience, business process logic and detailed functional logic that the solution will need to provide in order to deliver the required business capability, within the constraints of the existing the system design.
Functional
test script
test script
The test team use the Functional Requirements document to build formal testing scripts that explore positive and negative manual testing scenarios for the new functionality and any other parts of the system affected by the changes (as identified in the Test Impact Analysis). Where appropriate automated testing and/or performance testing may be included within the scope of this testing. Changes to the planned functionality applied during the development are reflected in the final test scripts. All defects are raised in the project tracking system and resolved prior to the system being made available for the system requirement test.
Design
document
document
This is the technical expression of the changes required to build the functionality. This may include changes to the architectural design, database design as well as the structure of the coded functions. Typically the design decisions will comply with the established design patterns of the current system.
Peer code
review
review
The completed code is made available for visual inspection by another member of the development team. All code is subjected to a review against the relevant project coding standards. Any issues and recommendations are documented and raised as defects in the project tracking system.
Test impact
analysis
analysis
Developers and testers collaborate to identify the direct and indirect impact of the changes proposed. Understanding the overall functional process helps identify potential knock-on effects of business logic changes. Understanding where changes are being made to existing code helps identify potential knock-on effects related to object orientated code re-use.
Test
handover
handover
Upon completion of all the planned changes, the developer(s) take the test team through the functionality to explain how the new dialogs and business logic operate and to identify any areas of particular complexity that should be particularly focused on during the formal test cycle.
Development
Each functional requirement is broken down into a logical sequence of development tasks that might be undertaken by multiple developers. Development is undertaken in compliance with appropriate code standards using a range of tools to assist in first time quality and code management.
Dirty
testing
testing
Towards the end of development the developer will make their changes available to the tester for a brief sanity test focussing on the ‘happy path’ use of the new functionality. This one to two hour test eliminates many of the minor issues that might be missed by a developer in their own test cycles.
Unit
testing
testing
Developers apply automated and manual unit testing as an intrinsic part of the development task in order to improve first time code quality, usually guided by the project coding standards and the outcome of the test impact analysis.
