It is a question in istqb exam. I don't know what is the MASPAR case study and what it is about. Could anyone please summarise the learnings from this study?
1
-
Welcome to the community! It seems people want to close this question as "not enough clarity or details." I get it. But it seems like most people may not have heard of this case study to provide an answer?– Lee JensenSep 20 at 19:57
Add a comment
|
1 Answer
I've been involved in tech -- computer science education and career -- for nearly 25 years, with a majority of this time in testing and QA! I've never heard of this case study and I've studied a lot of the history of the industry!
With that said, some quick Google searching led me to the following conclusion.
This case study might be available for purchase or behind a login on both the Standford Business website from 1994 and the IEEE website from 1990. Honestly, I don't think these are the right case studies, but just case studies about the MasPar company and hardware designs! Unless they are thinking about "maspar" - a company that sells bedding and quilts? Unlikely, hahaha! I can't find any other references to "MASPAR, "maspar," or "MasPar." Even Google search and Google Scholar is light on clarity and details about this!
MasPar was a company that stands for "Massive Parallel Computers," which essentially means "supercomputers" made during the 1990s! They are a defunct company.
Why ISTQB is asking about a defunct hardware company from the 1990s doesn't make a lot of sense to me. However, the question is phrased like this:
In the MASPAR case study:
- A. Security failures were the result of untested parts of code.
- B. The development team achieved complete statement and branch coverage but missed a serious bug in the MASPAR operating system.
- C. An error in the code was so obscure that you had to test the function with almost every input value to find its two special case failures.
- D. All of the above.
Any of these can be the right answer from a testing/quality perspective. But unless you've read the case study, it's a big guess here. The answer I found was "C," which I've bolded above.
So if this is the correct answer and really the outcome of a case study in failure that can't be referenced anywhere, then it seems to go against the standardized techniques and principles of "Boundary Value Analysis" and "Equivalence Partitions/Classes," since these allow you to cut down on the number of test cases needed to gain confidence in a working system in a shorter amount of time!
Is "Boundary Value Analysis" and "Equivalence Partitions/Classes" a standard technique today? Yes!
Can using them still not account for all test cases, which end up leading to bugs? Yes! But using them is a trade-off of speed versus accuracy, or the use of the Pareto Principle aka, the 80/20 rule!
for many outcomes, roughly 80% of consequences come from 20% of causes
Or for test cases to bugs: "roughly 80% of bugs come from 20% of test cases!"
Does "Boundary Value Analysis" and "Equivalence Partitions/Classes" account for every corner case? No. You should still find boundaries that create corner cases: often found at integrations or intersections of code!
In actual reality, it's hard to find obscure bugs/errors in code during the development and testing phases of the SDLC. In my experience, these are often found by accident in production, reviewing logs, random exploratory testing, etc.
