Project work products of immediate interest in Agile testing typically fall into three categories:

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

Agile projects focus more on delivery of working software than producing huge documentation. However, it should not be misinterpreted that there is no documentation in agile projects. Agile projects still recommend minimal and necessary documentation. However, agile frameworks do not suggest any numbers to say how much documentation is needed. The team may have to make a decision during release and iteration planning on what is the necessary documentation they have to produce for each user story and for each release as a whole.

What are Epics in Agile Testing

Business-oriented work products are categorized into user stories and acceptance criteria. User stories are functional stories that are always written from the point of value of the user. There can be few technical stories also written which indirectly inherit value to the user story. Usually, User stories are vertical slices of small pieces of functionality with acceptance criteria. Collection of complex user stories may be grouped as Epics, which can be broken down further.

Couple of examples of Epics are:

1. As an Amazon customer, I would like to be able to order a new blender and have it shipped to my house because my blender broke.
2. As a customer of ABC auto insurance company, I would like to be able to report the fact that my neighbor’s son hit my truck with their car so that I can get the claim process started.

Looking at the Epics above, they can be easily broken down into user stories by slicing them vertically and they comply to INVEST criteria. Each Epic and user story contains acceptance criteria with necessary business rules and mockups attached to them.

Developer work products in Agile projects mostly involves the code and development tools. The team also creates automated unit tests as a part of development. The developers also produce code review document before the code is checked into the test server. Sometimes developer writes unit test, make it fail first and pass it later and refactor it; typically this approach is called as test driven development, in which test are first level of system design.

Tester work products in Agile project involve, automated tests, test plans, test cases, test strategy document, risk document, defect report and test results. Testers make as simple documentation as they can in agile.

In some regulated agile projects, more inspection of the documentation that is being produced during the project execution may be required.

For example: Federal drug administration (FDA) projects require lot of audit reports, strategy reports and compliance reports that need to be produced during the project execution.

Other popular articles:

• What is Definition of Done? Test Levels in Agile software
• What are Test Levels in Agile methodology?
• What are Testing Techniques in Agile development?
• How Do Software Development Lifecycle Activities & Work Products Affect Testing?
• What are Test Pyramid and Testing Quadrants in Agile Testing Methodology?