3

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.

2

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).

  • You said you do not understand the logic - that is the issue, authors mention that for risk based approach, you do not need spec and hence it is ideal for agile. Now imagine you are on the project and you want to use this blended approach: you would not use any requirements and hence you could not produce relevant test cases for their verification... – John V Jan 3 '15 at 11:51
  • @user970696 What book are you referring to? In risk-based testing you don't /have to have a spec or requirement doc/ but if you have one it might be useful information that effects our view of risk. I could see many ways to use a requirement document in this blended approach and that's why I don't understand your logic. Also it is possible for the authors to be wrong - ever consider that? Why are you so focused on explicitly testing requirements? – Chris Kenst Jan 3 '15 at 17:31
  • our project is quite formal and it is a must to prove that all requirements have been tested. In general, most projects require traceability which you cannot really provide without using requirements. Do not get me wrong, i fully understand how to use specs in these techniques, i do not get how the author( rex black) can recommend a strategy which is agile but tge agility comes from not relying on specs. – John V Jan 3 '15 at 18:13
1

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
0

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.

  • Well, so you do not write test cases ahead - what do your testers do in the beginning of the sprint? Because suggested strategies do not rely on documentation and advocate exloratory and risk based analysis. I cannot imagine our project without test cases based on the requirements - verification is a crucial aspect of testing. – John V Jan 3 '15 at 8:00
  • 2
    @user970696 verification of requirements can be a crucial aspect but it's not the only thing and it's usually not the most important. In my experience those who focus primarily on requirements don't have a lot of experience in testing. – Chris Kenst Jan 3 '15 at 17:29
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.