I guess I have posted a lot of technical stuff in my blog. However, I would like to go into a more theoritical side of things about software testing today – how to write a regression test.
So, what is regression test? Everyone knows that it is a set of test to make sure that existing functionality still works after new functionalities are added.
But how to write a good regression test? Most would think that the more tests you add into a regression test suite the better it is. This is a wrong view about regression test.
There are rules to follow in order to write an effective and efficient regression test suite. These rules are:
- Test all the core functions of the system (not the little help screen)
- Test the happy path and user would follow (not edge cases)
- Partition it logically based on system or core modules so that it is easily readable and accessible
- Partition a set of tests that will be run before every release (very important core modules) and others that will only be run when necessary (changes occur)
- Keep it as simple and short as possible
- Avoid repetitive steps
However, please bear in mind that I am not trying to say we do not want to test more in regression test. I simply mean that most edge cases and low level tests should be in the unit test level instead of functional regression test.
The mechanism I use to regression test web services is the same as the mechanism I test API, which is by using:
Curl is main tool to call the web services and it sits inside the Ruby script which is used to do other functions such as checking the output, etc.
For example, the Curl command below will pass the XML file to the JobSource web service and pipe the output to another XML file:
f=IO.popen(“curl –request POST –header ‘Content-type: text/xml’ –data @jobSource2.xml -s -v -D – http://webservices.pageup.com.au/JobSourceWS/JobSourceWS.asmx?op=UpdateJobSource 2>/dev/null>result.xml”).readlines