Talking testing, agility and automation... and anything else.

Nov 11

Organizing Your Automated Tests

Over the last year I have been working on various products and projects, during which time, I had also been experimenting with new testing tools. All this experimentation had led to some nice epiphanies but had also left behind some serious organizational collateral damage. Honestly, I’d never given test organization all that much love (and it showed). So I decided to look at this as a learning opportunity and see how others were organizing their code. And when Google proved to be less than forthcoming on the subject, I turned to some of my QA brethren. My coworker Jason and I paired up to hash out a structure.

This discussion turned out to be extremely interesting as Jason and I work on different products, use different tools and program in different languages. Test organization is something all testers must tackle, thus the goal was to keep everything product, tool and language agnostic. We came up with the following…

The basic structure is:

Product > Project > (Domain) > Tests > Steps

Imagine each of part of the structure as being a bucket that holds the next… in my case they’re folders but they could easily be classes and methods or what-have-you. With that in mind, let me explain some of these “buckets”…


My team works on multiple products so this is the hightest level of my test hierarchy. If you work on only one product, this might not be your uber-bucket… or maybe you work with multiple companies and “Company” would make more sense for you… whatever works. For my example, each Product can have many Projects.


A project equates to a software release. ‘Nuff said.


This is an optional bucket that can also take many forms. It’s primary purpose is to organize individual tests. For example you might separate tests based on which web page they’re found on. They could be broken down by user story, etc…. It depends on the situation at hand.


For me, these are actual test files that test specific functionality. These could–as in Jason’s case–also easily be classes. Each of these files/classes can then be bundled together and run as a larger suite of tests, or included in any number of instances as required.


These are the actual steps take to accomplish the test. Often times these are functions or methods.

Obviously this is not rocket surgery but it’s something that all testers deal with. My example is working for me currently but I could see how it might shift in the future. As always… YMMV.