I am not solely a component tester, but some of what my day to day responsibilities have come across in the past have required the testing of components.
I also don't know how much of how I go about it will be the same as you would consider part of the testing of components, but here it goes -
Any time a component has entered the QA area for testing, I usually spend time with the developer to understand the purpose of the component and how it is going to fit into the "grand scheme" of things to come. This usually leads to working with the developer to construct a test harness around the component that can be interacted with manually and via automatiion tools.
The harness is comprised of go/no-go test results that are testing the basic functionality of the critical path usage of the component. If at any time we wanted to make sur ethe component is running correctly, all that would really need to be done is to access this harness app and click the Test button. Further functionality would be the existance of controls in the harness app allowing the input of other test criteria than the default run of informaiton. This then leads into a data-driven test from an automation tool where more complex and a larger volume of tests can be run on the component for regression purposes.
As more and more components are added to the repositiory, the automated tests are added to the batch run of tests that are usually executed once a month to make sure that everything is running OK.
Insanity: doing the same thing over and over again and expecting different results
I have been working in the QA department for a component vendor for about a year and Iím finding it very difficult to find people and martial that relate to testing actual VB and .NET components/ActiveX controls. Most of the information I find deals with testing applications that are already constructed and do not cover testing techniques for components/controls you have to write code to use. I am very interesting in talking with people who test components, just to get some ideas for what other people are doing.
Thank you for the replay. One of the biggest challenges we face deals with having to do a large porting of our testing in the VS IDE at design time. We try to automate run time tests, but find it very difficult to do so because a lot of what we look for at run time deals with appearance. Automation is something that really hasnít worked out very well for us, but we havenít given up on it.