This post is work-related, and is designed to capture something of the madness of what I do for a living (Orwell’s intellectuals passionately arguing about whether the full-stop should go in or outside the closing bracket has nothing on this).
Imagine this. To get an idea all you need be familiar with are the columns in a spreadsheet. So: if column A has an ID that starts with an R (as against the other things it could start with), then multiply column B with Column C (but only if Column C has a number less than a 1000), and add the difference between Column F and Column G (but only if Column F is greater than Column G), then represent as a percentage in Column J (but only if Column J is unpopulated, and the month has 30 days in it).
Now imagine warnings (“validations”) can be set to pop up if one, some, or all of these criteria aren’t met. To test this, you must ensure that the validation has been turned on (otherwise it’s not going to fire, right?) and that the criteria for the validation to fire have been met. So off you go to a screen of validations with tick-boxes (so you can tick the one you want, hmm?). A minor catch is that all the validations are similarly worded and may do something only slightly different to the validation you want to test. For example, you might have a validation that does exactly the same thing as above, except only for months that have 31 days in them. Make sure you get the RIGHT validation (and untick the others), or you’re going to look like a silly Billy (and you don’t want that, do you?)
The validation warning will read something like this: “No percentage written to Column J. Some or all of the criteria have not been qualified, or Column J is previously populated”. Clear, succinct, and to the point. Your boss told you this would be straightforward.
So, to our test data (bullet points, please).
- ID for Column A: R something or other, say R001. Remember, you will need to test the negative: a serial number starting with something other than an R in this case.
- Column C has a number less than a thousand (1-999). Again, remember the negative.
- Column F number = 20 (Column G needs to be less than this). Er… remember the negative (I — probably — won’t say this again).
- Column G number = 10 (so is less than Column F). See above. Our difference is 10, which will be added to the output of Column B times Column C.
- Column J (currently) has nothing in it (Err…).
For a quick (negative) hit, you meet all the criteria except for the ID in Column A which you start with a P. You run the test. No validation. Uh? You check the validation page (which you have open in another tab) and, sure enough, your validation’s ticked. You refresh. Still ticked. Hmm. You check you’re in the right environment (you’ve been caught by this before, haven’t you?). You are. You run the test again. Same result. Huh! Well, you could just fail the ticket… but maybe you’re missing something. First, let’s see if you can get the validation to fire at all. You put 1001 in Column C and re-run the test.
Eureka: “No percentage written to Column J. Some or all of the criteria have not been qualified, or Column J is previously populated”. Progress. You can get the validation to fire. It’s not firing on the wrong ID, though, and the ticket says it should. Or does it? It suggests it should. Implies it, anyway. Shit, are you over-thinking this? Err… You talk to your boss.
“Ticket V64, you say. Validation’s not firing when Column A ID starts with something other than an R.”
He looks blank. As well he might. But you sit together and look at the ticket. “What’s the problem?” he asks finally.
“The validation’s not firing when the ID in Column A doesn’t start with an R. I thought it had to start with an R.”
He says, “All IDs start with an R. The ticket’s just stating the position.”
“So the ID’s not relevant at all?” you ask. “The fact the validation didn’t fire on a row with a Column A ID that starts with something other than an R suggests it’s happy with the data row, right?”
“All IDs start with an R,” he says patiently. “The ticket’s just stating the position.”
“Right.” Pause. “Except I entered an ID that didn’t start with an R.”
“It would be an R in the database,” he says. “So the validation didn’t run because you’d met all the criteria.”
“So what if it isn’t — an R in the database, I mean? What I’m really asking, then, is why wasn’t my non-R ID entered in the database? Since the lack of a validation suggests it processed successfully. Or did it?” Should have checked that.
“Only numbers that start with an R can be entered in that column in the database.” His tone suggests this is patently obvious. “There’s a restriction in place to stop other numbers.”
“Right…” I say dubiously. “So, just be clear, my row of data was entered in the database. Or it wasn’t? I mean it didn’t fire the validation.”
“It might have been,” he said. “But maybe not. If the system sees an ID in Column A in the spreadsheet that doesn’t start with an R, or the column’s blank, it looks for a company name in the row and then a location. If it finds both, it changes the non-R ID to something that begins with an R and enters it in the database. If it can’t find a matching company and location, it rejects it and throws an error-warning.” Pause. “But that’s another validation. Beyond the scope of this ticket.”
“Okay. Right. So I shouldn’t be entering non-R IDs for this test. Sorry, the ticket suggested it mattered. Who wrote the ticket?”
“I did,” he says, smiling.
“Well… good. Excellent. Well, I’ll get on and test the rest of the criteria. I have got the validation to fire, so at least we know it’s working.” I smile gamely.
“Maybe we need more training on this,” he says, standing up. “Not just you,” he assures me; “the team.”