Testing Challenges

I don’t often post about the testing I’m currently working on, but a current project has thrown up some interesting challenges that are worth commenting on.

The new feature I’m testing is a batch update process that replicates the functionality of some existing GUI forms, using another object in the system as the source data. The actual processing is quite complex with a lot of validation and data update rules. The GUI front-end hasn’t yet been built, so I’m starting out by testing the Oracle server-side procedures by calling them through TOAD, populating the temporary tables that drive them through some simple SQL scripts.

We’re not using the main system test environment with its strictly-controlled weekly builds, but a separate environment where the developer can apply changes as soon as required. This means there’s a much swifter turnaround than I’d become accustomed to when it comes to fixing bugs I raise. Sometimes I’ve found an issue, to see it fixed in minutes.

Because none of the code under test has reached the point of a formal build the bugs aren’t going into the bug tracking system. Initially we were just using an email thread between me, the developer and the business analyst to keep track of the bugs, but after a bit that started getting unwieldy so I started recorded them in a simple spreadsheet instead.

I’m still using an exploratory testing approach, with the added advantage that the persistent data in the “temporarily” tables can serve as a record of the test cases I’ve tested. As for the source of those test case, there are very detailed functional specifications, but I’m finding the best “oracle” is actually the equivalent GUI functionality, which I’ve tested and regression tested often enough to have memorised most of the validation rules. Indeed, a significant proportion of the bugs I’ve been finding have turned out to be specification issues rather than coding errors, or edge cases that weren’t covered by the new business rules.

It’s not the usual way I’ve been working on this project, which is very Waterfall, but I’m finding working closely with the developer and seeing bugs turned round far more rapidly is a very productive way of working. Of course, once the GUI front-end is built and it’s all included in the build and spun into the proper system test environment, I’m going to have to test it all over again. But at least we’ll have pre-emptively squashed most of the bugs, and it will take far fewer iterations for it to become stable.

This entry was posted in Testing & Software and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>