Project Organization samples

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!

Thanks Robert, you are always so quick to reply to my questions and your answers are always extremely helpful!  I will present your suggestions to our group and I'm sure they will help.



Tom

Hi There,



I have been working on automation projects since couple of years. Initially I worked on Selenium tool and recently from few months I am working on TestComplete.



The framework I have come up with is similar to what we used in Selenium/C# project in Visual Studio.



I have organized/categorized our project in three different folders. 



Folder 1 -> Controls

Folder 2 -> Functions

Folder 3 -> TestScripts



Folder 1 contains all controls in the application. To demonstrate a little bit in details here for example if you have a login page then get all the controls on login page and store it in LoginPageControls unit.



Folder 2 contains all the functions that need to be simulated for creating test scripts using underlying controls. LoginPageFunctions unit will have a function called LoginFunction which will actually enter username and password in the login page controls and click on Login button. Similarly create other functions that will cover all test scenarios and can be re-used from other units.



Folder 3 contails all test cases for the application by module or page. For example LoginTestScript unit will just call the function LoginFunction and verify the end results. Similarly one can create test scripts for all test cases by first creating controls and functions for each page or module.



The advantage of this frame work is we can create test scripts speedily. Then if any underlying control is changed in future, its easy to make changes in automation code just by locating the control unit and updating the same. All rest functions and test scripts that use this function will keep working properly as usual.



Another advantage of this framework is not much skilled expertise is required for creating scripts.



Let me know your thoughts, comments or suggestions on this!!!



Thanks,

Shrirang Vaze

Thanks Shrirang, I will bring up your suggestions in our group discussions.



Tom