Get certified - Transform your world of work today


PURIFF: Scoping the Sprint Tests

1 June 2012

Mahfoud AMIOUR
SOFTENIA Solutions


In Scrum, each sprint produces an increment, which is a partial and potentially releasable product. To be releasable, the increment must meet all acceptance criteria and pass different categories of tests. Consequently, each sprint should consider all testing activities required for a releasable product. Unfortunately, during my work on different projects, I have observed that many teams focus only on a subset of testing activities during the sprint.

In this article, I introduce the acronym PURIFF as a concept containing all test categories to be conducted during the sprint. The Scrum team can use the PURIFF acronym as a checklist to determine which categories of tests are relevant in the given context.

Each element of the PURIFF acronym represents a category of tests:

  • P stands for performance testing.
  • U covers unitary testing.
  • R deals with non-regression tests.
  • I represents integration testing.
  • F is for functional tests.
  • F covers non-functional tests.


PURIFF testing scope

The scope of PURIFF includes the following categories of tests:

  • Performance tests. Performance tests ensure that the system response time is acceptable for the users. The tests consist of measuring the applicationís reaction time to the different requests. There are different tools (commercial and open source) that can be used for performance tests: HP LoadRunner, IBM Rational Performance Tester, and Apache JMeter are examples of performance testing tools.
  • Unitary tests. Unitary tests are written by developers to test individual classes. They fall into the test-driven development, or TDD, strategy. Different solutions exist to write and run unitary tests automatically. JUnit and NUnit are among the most popular tools for unit testing.
  • Non-regression tests. The objective of non-regression tests is to ensure that new defects haven't been introduced after the modification of the code. Indeed, each code change is likely to introduce regression on the existing system, so retesting the already-tested system becomes necessary. Regression tests are a tedious activity, especially in an Agile context, which is characterized by continuous changes and frequent deliveries. They are also time-consuming when done manually. I strongly recommend automating them. Even if automation has a cost, the return on investment for the project is high. FitNesse, Selenium, Microsoft Test Manager, and HP Application Lifecycle Management (ALM) are examples of tools that the team can use to automate non-regression tests.
  • Integration tests. Integration tests allow us to verify that the modules (a set of classes) work well when put together. They are usually run automatically on the continuous integration environment.
  • Functional tests. The scope of functional tests is to check that the system behaves according to what has been specified through the elements of the product backlog (the acceptance criteria). The tests consist of testing each new feature of the increment against the corresponding acceptance tests. These tests can be run manually or automatically.
  • Non-functional tests. Non-functional tests cover the non-functional aspects of the application. These aspects are often defined as non-functional requirements (technical user stories). For example: scalability, robustness, security, portability, stress testing, and so on.


In working with teams, I've found that using the acronym PURIFF is highly useful. It functions as a concept that contains all the testing activities that have to be considered in a sprint (iteration). Even if all the increments are not intended to be deployed on production, the Scrum team can use PURIFF as a checklist to determine which categories of tests are relevant to the context at hand.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (1 ratings)


Amit Kajgikar, CSM, 6/7/2012 11:45:08 PM
Yes , you are correct regression test is major worry in scrum implementation and tedious too when the sprints are quicker.
Jim Evans, CSPO, 6/15/2012 8:58:08 AM
We are early in our scrum implementation and have struggled with the concept of the work from a sprint being potentially ship able and testing is usuallyvwherethings breakdown. We had automation in our previous waterfall methods and it certainly helps but it was always a function of QA and now we are working to get all teams to understand and incorporate the testing methods described above so that we can ship at the end of an iteration if need be. We are not even close to doing so yet, but teams are thinking about it and the above acronym is helpful. Thanks for sharing it.
Ganesh Doddi, CSM,CSPO, 1/8/2014 7:41:59 PM
Good acronym to remind types of testing to be considered. Slight confusion on non-regression and regression. I think it is suffix to remember as regression tests.
Amita Pandey, CSM, 4/13/2014 11:04:54 AM
What about the regression testing? When should we do the regression to check that the new code we introduced is not affected the existing functionality?
I think we should do the regression testing for the impacted area as a part of sprint.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up