Project work products

Project work products of immediate interest to Agile testers typically fall into three categories:

Business-oriented work products that describe what is needed (e.g., requirements specifications) and how to use it (e.g., user documentation)
Development work products that describe how the system is built (e.g., database entity relationship diagrams), that implement the system (e.g., code), or that evaluate individual pieces of code (e.g., automated unit tests)
Test work products that describe how the system is tested (e.g., test strategies and plans), that test the system (e.g., manual and automated tests), or that present test results

Lightweight documentation

In a typical Agile project, it is a common practice to avoid producing vast amounts of documentation.

Instead, focus is more on having working software, together with automated tests that demonstrate conformance to requirements. This encouragement to reduce documentation applies only to documentation that does not deliver value to the customer.

In a successful Agile project, a balance is struck between increasing efficiency by reducing documentation and providing sufficient documentation to support business, testing, development, and maintenance activities.

The team must decide during release planning about which work products are required and what level of work product documentation is needed.

Business-orientated work products

Typical business-oriented work products on Agile projects include user stories and acceptance criteria. User stories are the Agile form of requirements specifications and should explain how the system should behave with respect to a single, coherent feature or function.

A user story should define a feature small enough to be completed in a single iteration. Larger collections of related features, or a collection of sub-features that make up a single complex feature, may be referred to as ‘epics’.

Epics may include user stories for different development teams. For example, one user story can describe what is required at the API-level (middleware) while another story describes what is needed at the UI-level (application). These collections may be developed over a series of sprints. Each epic and its user stories should have associated acceptance criteria.

A diagram in the shape of a pyramid. Epics are at the top of the pyramid, themes in the middle, and stories at the bottom.

Figure 1: The test pyramid

Developer work products

Typical developer work products on Agile projects include code.

Agile developers also often create automated unit tests. These tests might be created after the development of code. In some cases, though, developers create tests incrementally, before each portion of the code is written, to provide a way of verifying, once that portion of code is written, whether it works as expected.

While this approach is referred to as test first or test-driven development, the tests are more a form of executable low-level design specifications rather than tests.

Tester work products

Typical tester work products on Agile projects include automated tests, as well as documents such as test plans, quality risk catalogues, manual tests, defect reports, and test results logs.

The documents are captured in as lightweight a fashion as possible, which is often also true of these documents in traditional lifecycles.

Testers will also produce test metrics from defect reports and test results logs, and again there is an emphasis on a lightweight approach.

Formal document for regulated projects

In some Agile implementations, especially regulated, safety critical, distributed, or highly complex projects and products, further formalisation of these work products is required.

For example, some teams transform user stories and acceptance criteria into more formal requirements specifications.

Vertical and horizontal traceability reports may be prepared to satisfy auditors, regulations, and other requirements.

When you are ready, select Next to continue.