Browse Prior Art Database

Automatic Test Bucket Creation Based on FilesThat Have Changed in Code Tree Disclosure Number: IPCOM000119073D
Original Publication Date: 2005-Apr-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 1 page(s) / 27K

Publishing Venue



Many times we in the test community are told we 'overtest' certain releases and that we dont focus enough on primary areas of the release that has changed from the previous release. Currently the way we build a test bucket is usually based on some common regression bucket along with additional testing for problem areas. While this usually ensures enough coverage it also means testing areas that havent changed which is wasteful and takes additional time. My method is to have an agent that would take a list of files that have been changed for a release and build a test bucket based on correlating flags between files and testcases that would test only the functions/interactions associated with those files.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 100% of the total text.

Page 1 of 1

Automatic Test Bucket Creation Based on FilesThat Have Changed in Code Tree

First off a list would be built from an application that is used to store your files.

Each one of these files will also have 3 additional fields in the list for Component, Function and sub-Function. (setting this up on an already existing codebase may be time consuming based on size but if you do this from the beginning of a project it would be best)

So you may end up with a list like: File Component Function Subfunction /somepath/File1 Client Communication Failover /somepath2/File2 Client Communication Caching /somepath/File3 Client Logging Logfile


Next a list would be built from the application that houses all the testcases. This list would also include the same 3 fields that were added in the files list. Example list:

Name Component Function Subfunction Testcase1 Client Initialize Startup Testcase2 Client Communication Connection Testcase3 Client Comminucation Failover Testcase4 Client Communication Caching Testcase5 Client Communication Logfile

Finally when it was time to build the test bucket, a list of files that were changed would be given to an agent which would then correlate the 3 fields on the first list to the 3 fields of the second list, picking up only the test cases needed to cover the functions of the files in the list.

So from the 2 example lists above the agent would select testcases 3,4 and 5 to cover the 3 files in the list.