Requirements sometimes are like pilars...
If requirements meet the ISO norms, the laws and rules, then the software program wil survive, your project will survive and/or the company will survive. Whatever is at hand.
The pilars are important. But in software testing manytimes the requirements are interdependent. They are related to eachother.
I've thought about a schematic respresentation.
This is what I've came up with:
In this example it's clear to see that the most upper pilars are the strongest.
But wait. That's probably not the way you'd like to build your software, right?
So, where do you start testing?
Exactly at the foundation, at the base. So you need to think hard on what the most important requirements are.
Many times I see people work hard, but they are not focused on the most important things. Selling a product 999x is nice, but would you like to sell a product which is wobbly and doesn't meet the requirements?, of course not!
Well, with this in mind you might want to read the great Twitter post of a highly appreciated expert in the field :
In essence: of course you want to test the most important requirements, the lowest pilars hypothetical spoken in this case. But in order to be sure all the base requirements are tested well... you must have a sharp eye on a couple of important things.
Remember in software testing,
paradoxes always lurk!
Blog pictures and text (c)opyrights by Ing. Valentijn Peters.
120 unieke bezoekers per week.
Uw banner ook hier?
Dat kan voor weinig.
Tweet naar @testensoftware
This website uses marketing and tracking technologies. Opting out of this will opt you out of all cookies, except for those needed to run the website. Note that some products may not work as well without tracking cookies.Opt Out of Cookies