Blended testing strategy in agile. Is it really possible to do efficiently?

Question

In a book I have, it says that for agile project, blended test strategy is the best, where it should use:

• Risk based strategy
• Reactive
• Automated regression

So I was about to implement in our project but now I realized - how can our testers verify the requirements? None of these strategies really uses functional specifition (or e.g. stories and their description), unlike classical requirements-based one, which authors mention to have issues with agile approach because requirements change. That makes sense, however, it means testers cannot really verify the functionality. Do I get that right or is there something I cannot see? So far on all projects I have been to, testers in the beginning of the sprint wrote test cases in advance, which does not go with these strategies.

Answer 1

I've never heard of "reactive testing" so I'm not sure what exactly that means. Any idea?

A blended strategy in the sense of using different test techniques and approaches can be a powerful idea but you (and your fellow testers) need to understand when to use them and when not to. Always make the strategic decision based on the context of your test project and your testing mission. For some projects it might make sense to do automation while on others it won't.

Now to answer your questions:

So I was about to implement in our project but now I realized - how can our testers verify the requirements?

Ask yourself what is your testing objective, what is your mission? Do you need to verify requirements, or rather help identify regression issues? This will help you determine your techniques. This might change with each project. Context is key, remember there are no best practices just good practices in context.

None of these strategies really uses functional specifition (or e.g. stories and their description), unlike classical requirements-based one, which authors mention to have issues with agile approach because requirements change.

Are you saying you've never heard of someone automating requirements testing or automating functional testing? Whenever I use a risk based approach to testing I look for all available information including specs. I don't understand your logic here.

That makes sense, however, it means testers cannot really verify the functionality. Do I get that right or is there something I cannot see?

I think you missed something here. Remember techniques overlap as do approaches. You can test functionality while automating it.

So far on all projects I have been to, testers in the beginning of the sprint wrote test cases in advance, which does not go with these strategies.

Now you're talking about a scripted approach to testing as opposed to a more exploratory one. You can use either approach with the techniques listed (note I don't know what book your referring to so I'm only responding to what you've said).

Answer 2

In addition to the other responses:

There is always a "specification" in the form of the software itself. Even if there are no user stories or other formal documents, there is a piece of software that does something.

From that and the knowledge (however vague) of what the users of the software want it to do - the goal - it's possible to build a test strategy using a blended approach.

In that situation, given that the goals for a sprint will not (barring emergency) change during that sprint, the start of sprint test activities can include any of these activities, depending on the technical levels of the testers:

• Adding the previous sprint's functionality to regression automation suites
• Pairing with programmers to assist them in writing good unit tests and get an understanding of the internal limits of the software
• Revising existing test documentation as needed
• Building test charters for the areas that you know will need to be covered, and potentially writing acceptance tests as well
• Working with other team members to perform more detailed risk analysis

Answer 3

That's exactly what we do.

Using our own best guest, we evaluate risk of stories coming through the pipeline, test manually what is most important or we get feedback, or test cases as identified in requirements. In "plentiful spare time" we are building a suite of automated regression tests to cover core functionality.

It is just common sense. What other approach we could use to spend our limited resources? Even if we try to test only the most important, it is still too much work.

Any sufficiently complex system is way too complicated to know all relationships between parts in a deterministic way, take best guess what is risky and/or likely affected by current stories, and hope for the best.

Answer 4

In my view, this approach can be used only for less formal projects. Normally, test cases are required to exist to verify the functionality and to form a regression pack. This cannot be done without requirement-based strategy.

With the suggested blended strategy, testers do not prepare test cases ahead and on most projects, you cannot afford to leave something untested. Even if the requirements are vague or incomplete, they are the test basis.