On test data, sign offs and munging

First, a quick announcement. I was visited today by a census taker. She was friendly and polite, and it was almost a pleasure to have her take my details. Right, now on to the main part of my post.

Suppose you needed to buy something valuable but also costly like, say, a vehicle or new office equipment.
Suppose also you didn’t currently have enough money to buy the item and would only have saved up enough to buy it in several years time, but you needed it now. What would you do? Welcome to the world of Financing.

I’m currently working on an agile project. In an agile project, the software to be delivered is broken down into releases. The additions/modifications for that release are selected and coded, then added to the system. after that it is tested, and any defects found must be fixed before the changes are signed off by the Test Team. We signed off a release with exceptions yesterday. Agile demands a high level of skill from every member of the team.

The system to be delivered is an automated application system for financing. Our client is a Financial Services Provider (FSP for short).

To apply for finance, you need various things: an Identity No (ID, Passport or Company Reg No); a physical address; a postal address if it’s not the same as the physical address; a bank account; and some evidence that you can pay back the FSP. To test the application system, we needed test data. Often, you can make your data up, but this system is also designed to run checks on the applications, so we needed pretty accurate data. Initially, we tried to use made up data, but quickly found that the data checks the system ran made this impossible. The system easily picked up fake ID Numbers and fictitious addresses, so we had to ask for valid data and a fair amount of it. It is possible to use live data, but if the live data are financial records, which are confidential for obvious reasons, then they must first be munged so that they can’t be used to perpetrate a fraud. To do this, you take the transaction history of one account, the number of a different (and possibly even nonexistent) account, the ID of a third account’s accountholder (again, possibly fake) and the address and contact details of a fourth account’s accountholder. That makes it next to impossible to use the data criminally.

The release we signed off added an internal check. If the applicant has a Cheque or Savings Account with the FSP, then the system must access the records and attach an Internal Statement to the application. We had been given account numbers, but no user details. No problem, I thought. I’ll just use the ID Numbers on the application test data.

Big, big problem. When I did this, we got an error message: “The ID Number does not match that of the Account Holder.” I had to ask for account numbers and the corresponding ID Numbers. Finally, it worked, but the data for the internal statements had not been loaded. We had to list it as an exception in our sign off.

I have two things to say. Firstly, when testing a data-dependant system, make sure you have the test data you need, particularly if it needs to pass internal checks. Secondly, if I had to bank with our client, I would be more than satisfied that my money would be safe.

About autismjungle

I am a Software Test Analyst. Shortly before I turned 21 I was officially diagnosed, although I had long suspected I was autistic. Welcome to my blog
This entry was posted in Life, Software, Work. Bookmark the permalink.