Monday, 12 November 2007

Testing - Tool testing vs Application testing

Over the past few weeks I've been in the situation where software testing has become a top issue. This is primariliy around the area of testing a Application vs Tools.

When testing an Application there are normally business users with defined scope of what they want to achieve. This means the scope of testing can be reasonably well defined and the testing applied in a structured manner.

Developing tools to be used as a development tool itself poses another issue, when is a bug truly a bug? To explain further you develop a tool which generates an application for you, and you go a step further and allow users to use a scripting language in the tool. The problem occurs when users find novel, and un-documented ways of using the tool which makes their own applications go wrong. Is it a bug? If you never told users they could do something that way, it's not documented anywhere is it a bug? Some people say yes - the reasoning is that if you don't prevent someone doing it a certain way then it should work. Others will say no - if users want to make use of undocumented features then they do so at their own risk.

I'm not sure there is an easy answer - I would like to think a development tool can be designed to bullet proof and not allow user to do things that will cause them tremendous amounts of grief. The problem is that in doing this you can be very restrictive and lose flexibility in the tool.