www.answers.com defines a component in this way: “In general, a thing’s components are its parts; the things that compose it. Components are those identifiable, differentiable and autonomous elements that compose a system.” Basically, components are parts of a test case. Think of them as building blocks. A test case is broken down into its logical steps or components which can be made generic and reuseable.
I like to think of the example of Legos. Perhaps you also have purchased a Lego dinosaur or plane kit for your kids and they take it apart and make a space ship or car. The Legos are designed in such a way that they can be connected to any other Lego and make many different things. The only limit is the imagination of the user.
As I continue to post, I will go into more detail on how these building blocks are used in this approach.
Friday, February 15, 2008
Background
Although the idea of component-based software engineering was first proposed in the late 1960's and came into common use in the 1990's, the concept did not transfer to software testing. Automated testing began to utilize this approach but manual testing still used the common document-centric approach. Typically a test case was a document or spreadsheet containing the steps necessary to verify or validate defined requirements. This approach let to extensive manual effort both to create and maintain these test cases. A regression test suite for a mature software product could become a large drain on resources to maintain and execute it.
The component-based testing approach borrows the idea of reusability from its software engineering predecessor. If test cases are broken down into common, reusable pieces, then they can be shared among many test cases. This reduces the effort of creating and updating test cases. It also reduces the effort of automating those test cases, since this is the format used.
Since I started presenting this concept at conferences in 2006, I have seen other companies adopt this or similar approaches with great success. We have used it internally since 2002 and have seen the benefits provided by this approach.
The component-based testing approach borrows the idea of reusability from its software engineering predecessor. If test cases are broken down into common, reusable pieces, then they can be shared among many test cases. This reduces the effort of creating and updating test cases. It also reduces the effort of automating those test cases, since this is the format used.
Since I started presenting this concept at conferences in 2006, I have seen other companies adopt this or similar approaches with great success. We have used it internally since 2002 and have seen the benefits provided by this approach.
Subscribe to:
Posts (Atom)