Registered: Oct 2003
Location: Sydney, Australia
Aha! One or two of my favorite topics.
I cannot agree with the scope of the role you have assigned to the business analyst. To my way of thinking the role should be constrained to "understand and communicate the business needs regarding the system as they relate to technology solutions." The role requires an ability to both understand and record (model) the business processes that an organisation uses, an ability to synthesize new or changed business processes that take advantage of technological advances implemented in the organization, an ability to understand (and often question) why the organization follows a business process, the ability to understand the environmental conditions that the organization does business in (and/or plans to), etc etc.
In other words the BA role is a lot "higher" than the role you have described. Your role is what I (and RUP) would call the Systems Analyst with the following caveats.
1) Analysts/Designers/Developers make lousy testers! Their roles are driven by the need to abstract a complex business situation into a deliverable partially generic technology solution. Testers on the other hand need to be able to isolate the required number of specific business complexities to prove that the delivered system meets an agreed level of business need. That is, they do the exact opposite of the analyst/designers.
2) Use cases provide only the first level of the test framework In anything but trivial systems the complexities mentioned above do not always lie within the uses cases, very often they lie between them. By way of example consider this. In the futures industry (in Oz at least) clearing a trade between the market and the broker involves three use cases, "accept", "assign" and "split". accept means that the broker removes that parcel of contracts from the clearing pool to assign to one (or more) of their clients. assign means passing a parcel on to another broker and split means splitting a parcel possibly extended by subsequent accept and/or assigns. However, there are different classes of brokers involved in the market - "clearing", "non-clearing", "local" etc. The business rules affect how accepts and assigns may be done between the brokers. These rules result in a mathematically provable set of over 70 pathways that trades could go through in the clearing. Each one of these pathways has to be tested - not just the 3 "functional requirements" represented by the use cases. Further the pathways are "temporal" in that the exact sequence of the transactions is important. UML in general and use cases in particular do not provide a means to model the pathways, nor was there a need to in specifying the system requirements or design - only the testing needed this model as only the testing is concerned with the complete flow of the trade through the system to its final clearance.
For a less challenging analysis, consider the testing needed for these common retail system use cases "cancel credit card transaction" or "process credit purchase return" and the possible variations on that that can exist. If the mental challenge is to high go buy 4 items on your card but do it in two transactions of two items, now go back and return one item from each transaction!!! Now consider what the analyst/ designer is trying to do in this situation - "how can I simplify this to make it workable?" Finally, what does the tester have to think about in designing a test suite - "OK the customer is returning one, or perhaps more than one, item they bought on credit. Lets see, how could we have arrived at the sale of these items? One sale, more than one sale, the return is for the entire set of items sold in the transaction, its for a partial set, does the original transaction(s) exist, is this relevant, was one or more of the original sold items discounted" etc etc etc notice I haven't even started to think about the current transaction i.e. the credit refund and its possible variations yet! and finally note that the refund use case code (usually) does not care about the initiating transaction set.
So IMHO use cases by themselves provide at best a flimsy framework for testing.
Report this post to a moderator | IP: Logged