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?

  • 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 Jensen
    Sep 20 at 19:57

1 Answer 1


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.

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