testing and QA in object and component based development

Objects and components are pluggable

A principal feature of both object and component based design is pluggability or  'polymorphism': the ability of one component (or object) to work with a variety of others. For example, a drawing editor should be able to work with a variety of classes handling a different shapes; a distributed program should be able to work with components driving different communications protocols. In each case, one component only knows the interface of the other --- not the details of how it works or what it does. The drawing editor can tell all its shapes to paint themselves on the screen, without knowing whether they are circles, triangles, or a mixture; the distributed system sends material to its counterparts through the communications line without being affected by the choice of protocol. We can extend or change such programs by adding or substituting new classes (of objects or components), and without altering the rest.

An essential in such schemes is the definition of the interface: one object doesn't care how the other works, or what it does in detail; but it does have to know what requests it can send.

Polymorphism is one of the most powerful principles of software engineering, allowing us to create very extensible and flexible systems. We can make kits of components that can be configured in ways not envisaged by the kit's designer (rather like Lego).

But how do you test such systems? How do you test the components? One feature of CBD is that, as the designer of a component, you do not know what other components yours will be coupled to at run time: that is determined by another designer, who takes your component as a black box and assembles it with others. (The distinction between the two designers is like the designer of a Lego brick and the designer who makes a house from them.)

Verification for pluggable components

Two sets of software developer deal with each component: its designer, and its clients, who assemble systems or larger components within which it is used.

Building reliable components is a much tougher job than building a conventionally modular system. In the latter, if there is any question about the interfaces of your module to another, you can peer over the partition and have an informal chat about it with the other module's designer. But if you're designing components, you don't know who that other designer might be; and they might be in another company; and the other component might not have been thought of yet.

This separation also presents an obstacle to testing. It's difficult to do exhaustive tests if you don't know what components it will be used with. For example, the drawing editor could be tested with some basic shapes like squares and circles; but we can't be sure that it will work with any new class of shape that might be invented next week. The distributed system might appear to work atop RMI, but will it still work if COM is substituted?

Because the clients do not see its internal workings, they are restricted to black-box tests.

complete solutions for object oriented analysis and design (OOAD)
or
complete solutions for component-based development (CBD)
or
complete solutions for process definition (that includes testing)

(consultancy, courses, workshops, mentoring, seminars, development)