Modem fault prevents me getting coffee

[mudskipper]

Oh dear, what can the matter be?
k2p2's flushed down the lavatory.
Paid to pee not assault & battery,
The sensor didn't know she was there.

Went in, unlocked, sat down too hastily:
Reading council's upgraded them latterly
I do hope it wasn't too splattery!
Shame that the queue didn't care.

Next time, k2p2 wants to do a pee,
Or do number twos and sit quiet for minutes three:
Number one, lock the damn door behind thee...
Or take towels and go in bare!

I've never been serenaded before - I think I'm in love.

[Mich the Tester]

You'd think, that the sensors to operate the flush and sink might have given it a clue that someone was in there, but I guess the use cases didn't cover failure to lock the door properly.

You have hit the nail on the head in respect to frustrations with problematic systems, crap helpdesks and bureaucratic organisations that can't actually help customers.

The impression I get from 15 years of administering and testing systems is that systems and processes are designed with the following false assumptions;
- the input into the system (locking the bog door or inserting customer data) is correct, and as soon as it is stored in the system it becomes an unassailable truth
- if a process or procedure is followed correctly, there will be no problems
- following the process in the same way time and time again will always produce the same results

Let's examine these assumptions and their consequences. Firsty, input into a system is less predictable than we think; users are humans, humans make mistakes, humans don't always immediately understand what is being asked of them, and different users interpret questions differently. My bank is convinced that I am two different people, because when I opened a second account, the account manager filled my name in incorrectly; there is no possibility in their system to alter the name once it is connected to an account. There may be very good reasons for this, but nobody thought to set up a means of solving the problem. (Similar to Bill/William Bryson's problem earlier in the thread). Consequence can be serious, both in terms of the bank's admin(which is a mess anyway) and in terms of customer dissatisfaction. Imagine the consequence when interlinked databases belonging to banks, the tax man, the police, or worse still, dna databases and criminal databases continually exchange faulty data; clearing up the fault can be impossible because no individual organisation accepts that their data may be incorrect.

Secondly, any process or procedure exists in the context of its surroundings; the people, the systems, the regulatory environment. Any automated process exists in an environment of networks, OS changes, changes in other parts of an application, changes to metadata etc etc. That means that any process or procedure is liable to give unpredictable results at some time; not a problem if you've accepted the first point and are prepared to correct data and assist the user.

Third issue is actually the same as the second but worded differently.


Unfortunately, the testing fraternity seems to get stuck in just measuring the extent to which a system meets requirements; organisations which are a little more developed ask testers to review requirements, but only to see if they are clear and unambiguous. The real talent of an experienced tester is to think of and explore many different ways in which things can go wrong, whether by human or automated actions and interactions, and a tester should be able to advise on how to circumvent the silliness; but of course, testers need the skills to analyse more than just code or designs, and organisations need to listen.

On the bright side, this provides opportunities for testers, analysts, designers and coders who can think further than the bobbified consultancies and thereby justify decent rates way above the 10 dollar per day plenty cheapness.

[NotAllThere]

You have hit the nail on the head in respect to frustrations with problematic systems, crap helpdesks and bureaucratic organisations that can't actually help ...e bobbified consultancies and thereby justify decent rates way above the 10 dollar per day plenty cheapness.

Far too lazy to read it all the way through, but are you basically saying it's your fault?

[Mich the Tester]

Far too lazy to read it all the way through, but are you basically saying it's your fault?

Partly, yes; some problems are my fault for taking a simplistic view to testing in the past; just taking the 'requirements' for granted and checking for compliance, where I can really help the client (if he wants it) by looking beyond requirements to the real environment in which a system works.