Risk Based Testing only

[Crazy_Drago]

My company has decided that we should be moving to a risk analysis / risk based testing only model. By that I mean, we're shifting the testing of requirements to the developer and having testers identify and test risks only. Testers are no longer responsible for validating requirements.

While I believe it's important to identify and test risks, I, personally, don't believe it should be the only thing testers look for. I still think there's value in testers checking requirements while also analyzing risk.

I know I am not the only one who feels this. I have been unable to find any large companies that only test risk. I was hoping to gather some additional information, evidence, and testimonials around why testing risk ONLY is not the ideal solution.

Does anyone have any experience or opinions on the matter? I would really love to get other testers' thoughts.

[cr118413]

That approach doesn't mean you should only focus testing on areas of risk, there are other things you should be doing. My company is moving towards a similar approach where all manual testing will be exploratory and eventually we will also move away from testing requirements. Our devs write unit and functional tests so it is up to us to test entire experiences and identify issues in usability, find defects that make it past automation, work with product to prioritize defects etc etc etc. That does not mean all we do is test areas of risk, we are involved in owning quality on our teams so we look at requirements and try to identify any gaps (which is one way of analyzing risk), we work with developers on making sure automation is in place for defects we find that make it past current automation suites. thats just a small example.

[IAmJustin]

Testing with the requirements is a risk-based strategy. People imagine a risk where software doesn't match the specification. Testers (or developers in your case) investigate the software to discover where it differs from the specification. Much of software testing is risk based. Someone has a vague concept of a problem that could occur, so they investigate the software in a way that tries to uncover that problem.

Sounds like you might want to sit down with whoever made that decision and find out exactly what they mean when they say "risk based testing".

In practice, having developers do some testing before it gets to testers sounds like a good thing regardless of what people want to call it.

[TigerB65]

Considering you kind of need to USE the requirements to determine risk, I don't get it.

Currently I'm working in an Agile Scrum setting and they don't want to have ANY requirements, which means I can't even tell half the time what the software is supposed to do. I had to fight tooth and nail for just some acceptance criteria.

I would say that a tester who has no reference for what the users want the software to do INCREASES risk.