[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Re: TAG Proposal on weak predicates
Hi Jacques, I have talked with Woo about this matter. We agreed that your suggestion would be yes or no depending on the scope of TA. In other words, we can ask ourselves why test assertions are necessary, or under what circumstances the TA writer composes test assertions. If test assertions are just the reflection of spec requirements, that is, test assertions can be used for different purposes later on, we are not supposed to say "testability" of test assertions. If test assertions are used solely for the purpose of testing, we can say "testability" of test assertions, given a particular testing environment. Although a particular test assertions is not testable under current automated test framework, it could be testable via manual interactions among SUTs. What do you think? Woo, could you add more comments? -Cho -----Original Message----- From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: Tuesday, July 15, 2008 11:34 AM To: stephen.green@documentengineeringservices.com Cc: Patrick.Curran@sun.com; OASIS TAG TC Subject: RE: [tag] Re: TAG Proposal on weak predicates Stephen: That reinforces my opinion we need to define better what "testability" means, as this term seems central to all TA definitions I know of. >The 'other side of the coin' of this opinion is that the TA is *not* a proper place > for such opinions because 1) they are opinions (whereas a TA is otherwise to be a statement > of fact following on from the spec) Don't these opinions become facts when testability limits are known? (I am not talking of That's why I suspect there are two major contexts to consider in writing TAs: (a)- situations where no testing constraints are known nor need be assumed. Here it is expected that every TA will have a predicate that always matches the normative statement. (b)- situations where "testability" is defined by a set of testing constraints that are known up front. In such cases it is expected that some normative statements will not be testable, some will be partially testable. The ideal case is (a) but my experience is that (b) is quite common. And in (b) case many people see value in writing TAs that do not ignore these testing constraints. Can we convince them they should write their TAs like in (a)? I am afraid not. I'd think twice before telling them that our guideline is not for them... Jacques -----Original Message----- From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green Sent: Saturday, July 12, 2008 2:42 PM To: Durand, Jacques R. Cc: Patrick.Curran@sun.com; OASIS TAG TC Subject: Re: [tag] Re: TAG Proposal on weak predicates Comment/question below 2008/7/12 Durand, Jacques R. > I suggest we add a > "Testability" section (~1 page) in our guideline. > This section would deal with all the fuzziness behind the notion of > "testability" , which is precisely what a guideline is about, i.e. > best practices rather than exact science). Because testability is a > relative concept dependent on what test constraints are assumed, I > suspect that our guideline might have to consider a few cases: > (a) the TA writer assumes that it is always possible to derive test > case(s) from the TA, given the right test environment. In other words, > it is assumed there is no restriction on the execution of test cases. > (b) the TA writer works under "testability" constraint, and writes TA > with these testing constraints in mind. > I suspect that neither (a) nor (b) is wrong... > A TA writer will doubtless have in mind (to a greater or lesser extent) some expectation of a set of test constraints (else how will they consider what it means that their TAs are 'testable'). They will doubtless be able and likely to form opinions, as they write the assertions, about how testable the assertions are and how testable the corresponding spec statements are. I think there is no disagreement that such thoughts could be captured and should, when useful, be captured. What we seem to have a split of opinion on (interestingly) is *how* those thoughts may or should be used and associated at all with the corresponding TA. A few of us are thinking that the proper place for them is ultimately in metadata to be associated with test suites/cases. The 'other side of the coin' of this opinion is that the TA is *not* a proper place for such opinions because 1) they are opinions (whereas a TA is otherwise to be a statement of fact following on from the spec) an 2) including them with the TA risks diluting the logic of the spec (even if that logic is already considered by the TA writer to be flawed or weak in some way). Against this opinion, on the other side as it were, what reason would there be for including opinions about expectations of test constraints and/or opinions about corresponding testability of a TA in the TA itself? -- Stephen D. Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 Associate Director Document Engineering Services http://www.documentengineeringservices.com http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]