Why should I be interested in this process?

In 2002, the Software Testing Institute conducted a survey of software testers to reflect the nature and state of the software testing industry. This survey can be found at
http://www.softwaretestinginstitute.com/2002IndustrySurveyResults/STI2002IndustrySurveyResults_frame.htm . Among other things, the survey found:
1) A majority of the responders (78.32%) stated that they only spend 26% to 75% of their day actually conducting tests.
2) Over 30% of their day is spent writing test plans or change requests. This would also include the artifacts known as test plans/test scripts/test cases.
3) 55.79% of the responders stated that the most likely reasons for an increase in software defects are shorter development and testing cycles or larger amounts of functionality being delivered in a release.
4) 25.45% of the responders stated that the most likely reasons for a decrease in software defects are more tests conducted on functionality or better coverage of the functionality by existing tests.

The results of this survey state that more tests or tests with better coverage would decrease software defects. However, the results also state that two of the main reasons for an increase in software defects are shorter development & test cycles and an increasing amount of functionality being delivered each release.

These results present us with two dilemmas. First, how can more tests be planned during shorter test cycles? Second, how can we ensure that the test cases are of good quality and code coverage?

These points are a fact of life in today's Agile development world. Customers need more functionality in shorter amounts of time. In order for them to be competitive, they need to be able to do what they want to do now. If you can't deliver, they will find someone who can.

In addition to this, we now live in a global business community. Every day, more U.S. companies are looking to other countries for technical labor. We have seen India become an economic giant in a matter of a few years due to their highly educated labor pool. We are now seeing companies dip into the labor pools in Eastern Europe, Central and South America, the Phillipines, and China. Having a multi-national labor force adds complications. First and foremost are communication issues. If you have testing artifacts written in standard American English, they may not be straight-forward for someone who learned English in a formal, British manner. Even in India where English is spoken by a large percentage of the population, they have their own way of saying things that is completely different from how an American would say it. So, take a large number of test plans/test scripts/test cases written by Americans and assign them to a testing team in India or Brazil and see how much confusion will result.

The Component-Based Testing Approach allows a company's subject matter experts ("SMEs") to compose a set of accurate, clear, and current steps for a test case. These steps can then be used by the general testing team within their test cases. This helps in composing better quality test cases and with the time saved by not re-creating a step each time that a test case is written, more test cases.

What is a "Component"?

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.

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.

Conference Presentations of the Component-Based Testing Approach

I have given presentations for this approach at three venues for software professionals:

The Software Testing Audit and Review ("STAREAST") conference at the Rosen Centre in Orlando, Florida, on May 18, 2006 (STAREAST and STARWEST are the world's largest software testing conferences sponsored by the Software Quality Engineering organization. Software Quality Engineering delivers training, support, research, and publications to software managers, developers, test professionals, and quality engineers worldwide).
http://www.sqe.com/Events/Archive/SE2006/sessionsbydayt.html

The Practical Software Quality and Testing ("PSQT-North") conference at the Raddison Hotel and Conference Centre in Minneapolis, Minnesota, on September 12, 2007 (PSQT is the fastest growing conference that focuses on practical software quality techniques and is sponsored by Software Dimensions Consulting and Training, Inc. Software Dimensions offers training on disciplined software engineering practices and provides some of the most respected certifications in the industry).
http://www.psqtconference.com/2007north/display.php?id=Jeff_Roberts_The_Component-Based_Testing_Approach

The Practical Software Quality and Testing ("PSQT-West") conference at the Flamingo in Las Vegas, Nevada, on May 8, 2008 (PSQT is the fastest growing conference that focuses on practical software quality techniques and is sponsored by Software Dimensions Consulting and Training, Inc. Software Dimensions offers training on disciplined software engineering practices and provides some of the most respected certifications in the industry).
http://www.psqtconference.com/2008west/display.php?id=Jeff_Roberts_The_Component_Based_Testing

Welcome to the CBTA blog!

The pupose of this blogspot is to share processes and tools that allow the modularization of software testing. The modularized testing approach that I co-authored with my associate Phillip Nguyen is called the "Component-Based Testing Approach". We originated this process in December of 2002 and the testing organizations for our employer, Convergys, have been using it ever since.

The goal of this blog is to share best practices. I will share with you what we have learned and developed and hope to receive the same from you. Please feel free to ask questions also. My hope is that we can help one another by improving upon what we have already developed.