Project Organization samples
Hello, I was wondering if someone could send me screen shots of examples of good ways to organize projects in TestComplete? My test team hasn't done much with TestComplete yet, but we are tryi...
Forum Discussion
Actually, I prefer a framework approach to automated testing where you create a set of library code units/keyword tests, data-driven objects and loops, and other such things. That way you're not worrying about how many projects you have, who updated which project, which projects tests what, etc. It's probably a very idealistic view but, with a well constructed framework, you could easily run any number of sets of test cases with a single TestComplete project simply by dropping in a different set of data files. I recently wrote an article for SmartBear outlining what I've done and how it works. Automation Framework - A New Table Driven Technique Using TestComplete In that article are links to several other articles talking about how, for maintainability, flexibility, and so on, framework approaches are better for automation than a structure that consists of a number of atomic tests as distinct functions or units of code, whether they are written by hand or by record/playback.
That said, what I've done in the past, even when using a framework approach, is organize projects based upon application module. For example, if your project is an order entry system, you might want to have one project for the operational functions for entering, creating, processing, and fulfilling orders. You might want another project to test some of the back end maintenance tasks like updating and editing customers and contacts, updating product databases, etc. There may then be a third project for reporting functions. And so on. Behind the scenes of this, you would have common folders for different types of code units that those units may be shared between multiple projects. After all, if it's all the same application, you would only need one unit for running the application and/or logging in through the security screens rather than re-writing the same code multiple times.
Keep in mind that, in highly complex systems, things that may seem like distinct modules have some inter-relation. For example, if something is not functioning well in the data entry of customer records, this may impact the ability to create orders and so on.
One more thing: Get and use a source control application like Mercurial or other similar item. That way you can all have the same source base on your local hard drives without having to worry about who saved what to which file when. Mecurial's merge functions, the ability to branch code trees and so on make it easier for different automation developers to work on the same units of code without stepping on each other's toes.
The key thing to remember is that writing test automation IS writing software, just a different kind of software so any best practices that work for general software development are well suited for test automation development.
Happy automating!
That said, what I've done in the past, even when using a framework approach, is organize projects based upon application module. For example, if your project is an order entry system, you might want to have one project for the operational functions for entering, creating, processing, and fulfilling orders. You might want another project to test some of the back end maintenance tasks like updating and editing customers and contacts, updating product databases, etc. There may then be a third project for reporting functions. And so on. Behind the scenes of this, you would have common folders for different types of code units that those units may be shared between multiple projects. After all, if it's all the same application, you would only need one unit for running the application and/or logging in through the security screens rather than re-writing the same code multiple times.
Keep in mind that, in highly complex systems, things that may seem like distinct modules have some inter-relation. For example, if something is not functioning well in the data entry of customer records, this may impact the ability to create orders and so on.
One more thing: Get and use a source control application like Mercurial or other similar item. That way you can all have the same source base on your local hard drives without having to worry about who saved what to which file when. Mecurial's merge functions, the ability to branch code trees and so on make it easier for different automation developers to work on the same units of code without stepping on each other's toes.
The key thing to remember is that writing test automation IS writing software, just a different kind of software so any best practices that work for general software development are well suited for test automation development.
Happy automating!
