Spring cleaning your testware

In my family we have a tradition, every Spring we systematically go over all the house cleaning, organizing and mostly getting rid of all the things that we don’t need anymore.
We do this around the Jewish holiday of Passover, that is set to coincide every year with Spring in the Northern Hemisphere.
But from talking to friends who are not Jewish and don’t live in Israel I understood this is more than just a religious-driven tradition.  I even found an entry on Wikipedia about it under Spring Cleaning.

We are better at getting things than getting rid of them

A Universal truth about humans is that we are good at collecting stuff.
We have no problem buying a new t-shirt even if we already have 35 in our closet.  Or getting a stack of 50 blank DVDs to burn, even if we have not yet finished the stack of 15 DVDs we bought a year ago, just because there was a sale in our computer hardware store.
We like getting stuff, it’s in our nature…
On the other hand, we are really bad at getting rid of it.
When we realize the pants we took out of the closet are not our size anymore :-), or that the t-shirt you wanted to wear has been washed so many times it became see-through, we don’t immediately throw them away or given them out to charity.
We place them in our closet in the area of “things that I don’t think I’m gonna wear soon” and forget about them.  Until one day this area of things you are not gonna wear takes up half your shelves!
But don’t worry, you are not alone!  Most of us are just like you.
Nor does this only happen with our clothes/hardware/kitchenware/kids-toys/etc.  This happens with everything, including with our testware.

The art of collecting useless testware

The same thing I just described about t-shirt, DVDs and pants happens also in testware.
When you are looking for a test case to check a feature being updated in your application, you will look for a similar tests for approximately 45 seconds before deciding that you “might as well just write a new test for it”  (without realizing there are 2 tests that could have been slightly modified to cover this change).
Or, when part of your application is completely re-written and many of your tests become useless, you don’t delete them right away because you may “need to release a patch further along the road”.  But 2 years later, when there are no patches in sight and none will be created, you still keep these tests because “they are not harming anyone there”, and plainly you don’t have the time to review them and delete them right now…
If you look into your testware right now, and if you have not done any cleaning lately, it is reasonable to assume that between 10% to 15% of your tests are not relevant anymore, and another 15% to 20% of them need to be updated to match the current state and functionality of your AUT.

But this is not hurting anyone, right?
WRONG!

So you have a lot of useless tests, so what?!
It is not like you are paying more to electric company for them!  You are also not wasting any extra computers to store them!  And as they said countless times lately, storage space is so cheap nowadays that you should not even think about it anymore.
If so, what’s the big deal with having useless tests in my testing repository???
The big deal is that you are not looking at the problem from the correct angle.  The waste is not in computers, or electricity or storage…  these were the expensive resources 10 or 15 years ago.  Today the most expensive resources are the human resources – your team – and by having many useless tests in your repository you are wasting their time!
You are wasting the time it takes them to find the tests they need to run.  You are making it harder for them to understand if they need to create new tests or if they can re-use some the tests that are already in your Test Management System.
And maybe most importantly, by having a mix of good tests and bad tests in your repository you are increasing the chances of a tester that will run a wrong test and miss part of the issues that a good test would have detected quickly.

So what can you do about it?
3 steps to help you clean your testing repository quickly.

OK, so let’s assume you cannot drop what you are doing right now and take 3 days of all your team to go over your testing repository and clean it up.  There are still simple things you can do to start improving your process and make it easier for your team to clean up your tests in the future.

Step 1 – Organize your testing repository
The first step is the one that may provide the biggest immediate impact.
Most times the main problem with your tests is that your testers are not able to find them.
Once this starts happening then they either write duplicate tests (creating more useless stuff in your repository) or choose to run tests informally from their heads (maybe missing part of the things they should be checking).
To stop this from happening you need to organize your tests in a way that will help your testers find them easier and faster.
At the risk of being a little pretentious or immodest, we provide a pretty nice solution for this in PractiTest in the form of our Hierarchical Filter Trees, that let you organize and catalogue your tests in multiple ways at the same time (automatically organizing everything based on your tests’ fields).
One of the coolest things of this feature is that it allows you to “place” tests that check more than one area of your product under each of these areas (e.g. a test that checks your Website and your Reports Console and your User Management Module at the same time) instead of having to choose only one area (or folder) for each of your tests.  But enough of PractiTest for now…
If you are using any other test tool or even Excel to manage your testing you should try to create the most intuitive and simple classification in your test tree, use a convention that will let you manage test cases and the rest of your test ware.
When choosing a convention, the most intuitive one is usually based on your application’s structure.  Start from the products or components, and then go down 2 or 3 levels to Sub-Components, Features and even Screens.
Your convention also needs to take into account cases where one of your tests covers more than one product or components (like the case of end-to-end testing scenario we talked about previously).  You may choose to look for the “main component” for each test and set it under this categorization, and if this is not clear enough to have a number of “central components” where all the integration tests should reside in.
Conventions will never be perfect, and there will always be cases that fall out of it.  But it is better than every tester placing tests where he thinks they should be…

Step 2 – Mark your tests while you are running them
The second step aims at making it easier for you to do your Spring Cleaning once you have the time for it.
Add a new field or parameter to your tests that each of your testers can set when they are either running or reviewing their existing tests as part of their work, and ask them to them to set in this field one of the following 4 values:
Ready – if the test is OK and it can be run as is.
To Review – if you think something can be update in the test to make it better.  In this case you may also want to add a comment with why you set it to it.
To Repaire – when there is something that needs to be changed. In this case too, write down what you think should be fixed.
Obsolete – when the test should simply be discarded.
By having these fields you will be able to review them a lot easier.  You will also be able to see what tests are “abandoned”, by looking for tests that after a couple of cycles still have no value filled on this field.  Abandoned tests are usually useless and should also be discarded.

Step 3 – Set time aside in your schedule before your next “big project”
The last step is the trivial one.  You need to set time aside to clean your tests.
The best time (and often enough the only time) you will have is in the short span between projects.
If you plan this ahead and make sure that no one else has already assigned a task for you and your team, you may be able to review all your tests.  In case you are not able to go over all of them at least start from the most critical areas of your product.

Make it a habit for your testers to work correctly

Once you have a clean repository it will be easier for you as test lead or manager to ask your tester to work in a cleaner and more organized way.
Ask your testers not to write unneeded tests, and to always place tests in their correct are within the test tree.
No team will be perfect and with time your tests will again run into a small or larger level of chaos, but at least when you start from a clean page it takes it a little longer to reach this state.

http://qablog.practitest.com/2013/03/spring-cleaning-your-testware/