> Hi Arran,
> For the long answer question part 3, I received the comment "3) reasoning very weak, shows poor understanding. It's impossible to have "ISP testing with RACC coverage". 0/5"
That looks correct to me. "RACC" is a type of coverage used for logic-based testing, so it cannot apply to ISP. Possible levels of choice for ISP include "base choice", "all combinations". (There are also a few other ISP coverage levels mentioned in the Amman and Offutt textbook, such as "Each choice" and "Pairwise", but we don't cover those.)
> I was under the impression that ISP could subsume RACC coverage if the logic is not too complicated , from week 6 logic-based testing – solutions, for question 4 (b), attached.
Unfortunately, we can only mark what you actually write. If you meant "RACC coverage can subsume [some levels of] ISP coverage", then you have to actually write that. If you write "ISP testing with RACC coverage" then the only conclusion we can draw is that you don't understand what the possible ISP coverage levels are. Answers that display a misunderstanding of basic concepts like this typically can only achieve low marks, and if there are additional errors, they might be awarded no marks at all.
Regarding the week 6 lab: the solution you refer to is talking about the following scenario:
Suppose you are part of a team developing a website called “RateMyVeterinarian”, where people can log in and provide anonymous reviews of the veterinarian services they use.
Requirements for the site are currently being finalised, and one requirement is stated as follows:
When a user enters a user ID and password into the login page and hits the “log in” button, then if that user ID is listed in the “users” database, and the password matches against the password in the record for that user, and the user record does not state that the account has been disabled, a “Welcome” page should be displayed.
In the context of that scenario, the requirement spells out in detail a condition which needs to be met for the "Welcome" page to be displayed. Think about how you might do ISP testing for some component that implements this requirement. What characteristics would you use, and what partitions? In all likelihood, your characteristics would include exactly the things that are mentioned in the requirement: Is the user listed in the "users" database? Does the password (actually, more likely a password hash) match the one stored? Is the account disabled?
The solution sheet notes that once you've done ISP testing for a component like this, you probably will have already achieved the RACC level of coverage. Can you see why this is so? It's not because base choice coverage subsumes RACC. It's because in all likelihood, every single clause that the component needs to make use of is already "exposed" in the requirements, and in the interface to the component. (I'd probably be a bit cautious about using the word "subsumes" here, because the 2 are assessing very different sorts of coverage.)
Now consider a requirement for, say, a timetabling system that says "No student shall be allocated to clashing classes" (and then goes on to specify exactly what "clashing" means). The internal structure of a timetabling system is likely to be fiendishly complex. (So complex, in fact, that we might in fact outsource much of the logic to something like a SAT solver, or a more complex constraint solver, and rely on the provider of that component to have done thorough testing. Though they too can have bugs – I've reported a defect in one open source constraint solver I used.) Even if we look at individual procedures/methods, there are likely to be many "internal" Boolean conditions that aren't necessarily reflected in the interface, and so RACC is much less likely to be satisfied once we have a set of tests in place that meet base choice coverage.
I hope that helps. If you think that, aside from the reference to "ISP testing with RACC coverage", your answer showed clear reasoning and explained the assumptions being made, feel free to email me and let me know.
cheers,
Arran
