How to make testing in projects with a non-waterfall approach as smooth as possible? In these projects, I first found it difficult to time my testing activities – start too early and retest a lot, or start too late and run out of time.

The difficulty by testing in scrum projects is that testing takes place while development is still in progress. So, how do we ensure that we do not have to test everything (again) when development (thinks to be) finished? Below, I will distinguish between 5 testing aspects and their timing. For each of these aspects there are certain criteria, which help to decide when to start testing.

 The five key aspects of testing an application

When testing a solution there are the following important aspects to be tested:

  1. UI-testing:

    Usually we need the UI from the beginning e.g. to be able to click through the flow. As the application is developed, the UI should also be perfected further. Regarding the UI-testing one should go from a pragmatic approach to a more strict evaluation as the application matures.
  2. Flow-testing:

    Whatever the status of the application, all flows should be clickable from beginning to end of the development cycle. During the development, the flows may grow longer and get more complicated, for example by introducing more and more alternative paths.
  3. Functionality:

    The functionality in this case refers to e.g. calculations, decision trees. Functionality could be developed in blocks or in iterations. However, they should be tested when available, even if the complexity will be increased and retesting may be necessary. The functionality is the core of the application – although without the other components it will be useless.
  4. Integration:

    The integration with other systems, often to acquire data or provide it, is essential for the success of the application. Test the use of data is soon as possible, with stubs or preferably (and if possible) with real interfaces. If the integration is not working properly, the application will most likely be useless for production.
  5. Usability:

    Usability is not intended in the strict sense; it comprises elements like browser-compatibility, stability and everything a user requires to conveniently make use of the application. This does not merely require testing on different browser, platforms and so on. Use your common sense and try to imagine how an average user would go through the application, what he would love and what could make him leave the application prematurely.

To conclude, it is quite an art to get the timing right, it depends on a variety of events/stages of the development process which hint at the moment to start testing a certain aspect. These criteria and some experience should help getting the timing right.

Above I provided some tools to support the timing and testing decisions. But there are not only test execution tasks for the test role during a sprint. One also has to reserve some time for preparation and documentation.
It is wise to prepare for testing as soon as possible and execute tests when the time has come. The test documentation can best be done immediately after the test execution to prevent delays.

Jessica Otto - Senior Tester at BPM Company

About Jessica

Jessica Otto Senior BPM Test BPMCompanyI'm a BPM consultant focussing on QA and testing. I have been involved in several projects in the financial sector. Until recently I worked for some software companies. Having experienced diverging project approaches and software in different environments, I decided to become a BPM consultant.
In addition to my technical experience, I have a legal background and perform research in legal knowledge management.