A loose definition of a tester, albeit a very narrow one, is someone who finds problems, and plays a part in their resolution. Don’t get me wrong, I don’t have such a small view of our profession, but to think in such terms has its advantages. But let’s state from the outset: “testers do lots of other things as well as finding bugs”.
Having set the record straight, I DO want to concentrate on the bug-finding aspects of our work. Here I am thinking about a project to load data into a warehouse, where input files are processed daily. Each file may be present or not, being spreadsheets or text files all with a ‘header’ line. Many of the eleven feed were used by other processes, so our use ‘piggy-backed’ off the pre-existing files. For only two of the feeds were empty files created when there was no data that met the creation selection criteria – the other instances would have created no file at all, rather than a file with a header line and no detail. Test cases for the two empty-file situations were written, and (eventually) these passed.
For six of the feeds, loading into the data warehouse is dependent upon the data values – some lines are not required. Four of these six (hoping that you still follow me – there are a total of eleven feeds to start with, right?) are cumulative throughout the month, with only new records to be loaded. Here, special processing is required, to compare the current file of this type with that last loaded, and discard those that are were on the previous input, and this performs correctly over the end of the logical month-end – which may not be the actual month-end. It was quickly realised that the two non-cumulative selective loads could result in no records being selected – nothing matched the inclusion criteria. Test cases for this situation were written, and the software was seen to perform correctly here too.
Two of the cumulative feeds were well established files, and several different (genuine) files were very useful in testing, but the other two were relatively new and initially there were no real sample files available. There were, however, manufactured files for use in testing. The real files for the first two mentioned had significant data volumes, even on the first day of a new month. When real files for the second two cumulative files became available, each had data, but one of these had all data filtered out (i.e. it was not required to be loaded into the warehouse). This file failed to load, encountering an unexpected situation. The problem was found just before implementation, so the other data feeds were implemented, but not this one.
A fix was quick to design, code and test. At this stage, as a tester, it was obvious to me that the same fix needed to be made available to the other three cumulative feeds – “just in case”. These too were straightforward to code and test. At the same time as the one that was wrong was implemented, the others entered into PROD. Bear in mind that this was a conceptual problem for the other three feeds that had not been seen to happen (in five months’ data for the two well established data feeds).
It was therefore quite gratifying to find that the ‘problem’ actually happened, not for one of these three feeds, but for two of them. It all depended on where the end of the actual month occurred in respect of the weekend, and which days around month end were working days.Six months later there was the correct combination of working days and weekends (and some other, as yet unknown circumstances). It would have been a bug – but because it was already solved, the software performed as expected.
It was a bug that never was. Or even better, two bugs that never were!!
Peter Morgan, Freelance software tester @MorganpPeter