View source for 5 Obvious Things to Forget When Designing for Testing

From TekiWiki testing [[Business Analysis]] articles...

When designing your application, system or bolt-on, there are items in the design that can make testing a lot easier and quicker. Testing is often the poor relation in the development lifecycle, but the cost of testing is very real and very large. So how can we reduce test costs?


=5 Obvious Things to Forget When Designing for Testing=

Designing your program, system or application to ease testing sounds obvious. We want to test the same code in UAT as we intend to run in Production. Here are some considerations to add to the design to help ease the transition:

==1: Repeatable Input, Measurable Output==

This is the key principle - reduce the effort to create the test data and measure the output. Can the inputs be stored and reused? Perhaps copied before use, or maintained in a separate database and moved in and out?

Could you put in trace and reporting information to help show each stage of the process works as predicted? Can a report be created that shows what has happened to the data?

If the input and output can co exist, this makes retesting easier - as the test data remains intact and reporting and checking easier as both before and after values exist.

==2: Interface Code==

If your system talks to another system, whether it is via REST interfaces, database links, flat files or telepathy, ensure that there is a way to test without the other system being there.

This will enable you to test the underlying code more thoroughly and cheaply. It will not remove the need for end to end testing, but it might reduce the length and number of iterations.


==3: Connectivity of Interfaces==

For the end to end test, the test system needs to be able to connect to the receiving or sending test systems in the same way as Production.

If tests need to occur on a regular basis, these links could be permanent.


==4: Using the system date==

Be wary when using the system date inside a program. Consider it a bit like hard coding - most of the time you will want to use today's date, but there a potentially times that an override is useful:

* To test unusual circumstances such as New Year
* To reproduce a bug
* To allow for this and other system's downtime


==5: Fixed Start Dates==

If an application has a particular start date, it is a great temptation to just hard code this - after all it isn't going to change, is it? It is a one off date, that will be fixed forever. And even if it did, it would be such a massive change to the plan that altering a few constants will not matter. And the code will only be run once, won't it? 

And once we accept that, we know what the first Monday after the start date will be, when the next payroll will be, so we can hard code those too, right?

It sounds basic and obvious, but I have lost count of the number of times I have had to point it out, refactor code or attempt to work around the assumptions associated with a fixed date.

The shortcuts work until testing and cut over are considered. When testing well in advance of the start date, the number of cases of items already in the system with dates after the start date is limited. 

So parameterise dates - even for one off events.

==Next==

[[Business Analysis]]

[[Creating a Test Pack]]