|
Ooohh...she loves ice cream. Will have to use that! 
|
|
|
|
|
yup, my coworkers have only joked about it so far. Would be doubly interesting since at least one has kids at the same age as the software we're doing is trying to teach.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Hi, when i was designing security equipment in the 80-90s (assembler, naturally). I would give a working prototype to a salesman to take home for his kids to play with.
It quite often came back with a verbal bug report. (he would ask them how they made it do THAT and reproduce it himself)
If his kids could not get it to I knew I was right for initial production
If you cannot find any bugs, give it to a kid. They will find one.
Fun.
|
|
|
|
|
I've always half jokingly said that the best test is to just smash the keyboard randomly and see what breaks (other than the keyboard). 
Nothing exposes bugs better than an end user. That one in a million combination of keystrokes and data entry sequence that you would swear is impossible will occur within minutes of releasing the app.
Kelly Herald
Software Developer
|
|
|
|
|
Kids and Cats right? LOL Best QA testers!
|
|
|
|
|
I have found bugs when the cat jumped on the keyboard before.
The funny thing is that it is never funny at the time when a joke becomes reality.
Money makes the world go round ... but documentation moves the money.
|
|
|
|
|
Kelly Herald wrote: the best test is to just smash the keyboard randomly
therein lies the following story:
Once upon a time, the company I work for had a small network of Unix boxes devoted to one product line. Machine names were based on the names of the planets in our solar system. The QA guy assigned to this product line, Dick H. Ead, was a jerk. He really liked "keyboard smash" tests because he didn't have to document a detailed test methodology. "HULK SMASH!!" was the bulk of it. After a while Dick insisted on having his own private Unix machine on the network. Take a guess at the machine name he was assigned. I'll wait...
Software Zen: delete this;
|
|
|
|
|
Maybe the name Dick explains it. That was also the director's name in my first development group. We were developing a business phone with multiple function keys, and this director would go into the lab every day and press those keys like crazy, crashing the peripheral device that front-ended the phones. "When is this going to be fixed?", he'd ask. It was a total pain because the system would never have shipped without what was affectionately known as babbling idiot detection, which results in the babbler being ignored. It's just that implementing it early during development isn't a priority.
|
|
|
|
|
When I receive bug reports like this, I always insist on a detailed description of the test circumstances and procedure. Fortunately our bug management system lets me decide what amount of information is sufficient, so I keep turning reports back to the submitter until I'm satisfied I know enough the recreate the problem.Greg Utas wrote: implementing it early during development isn't a priority
Agreed. We've learned some hard lessons over the years about balancing process implementation versus moron avoidance.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: I always insist on a detailed description of the test circumstances and procedure
Also early in my career, a senior colleague received a bug report which read, "During the night, the attached log occurred." This was still in the day of hard-copy bug reports with attached printouts. His fix: "Turn off printer." 
|
|
|
|
|
Software Zen: delete this;
|
|
|
|
|
The guy's name was actually Richard H. Ead?! Oh what a setup!
|
|
|
|
|
The name has been changed to protect the inept.
Software Zen: delete this;
|
|
|
|
|
|
Sounds like you owe your daughter an ice cream cone.
|
|
|
|
|
People who grew up using mice and event queues instead of fingers probably have blind spots around this.
|
|
|
|
|
HappyDotNet wrote: a 5 year old randomly pushing buttons could be a good QA test.
Many users probably have less brain than your 5 years daughter, so yes, she might be a really important QA Tester.
Back then, my first day in new company, I went into the office and a guy was staring at the roof, just randomly moving his fingers through a touch panel of Siemens... when I looked at him with an "what the hell is he doing?" expression in my face, my mentor said: "He is simulating a bored worker"
And it is like this, we unconsciously do things in more or less the way they are designed, we don't think about the order of small processes because for us they are "extremely logical" and mostly "self explanatory" but there are people that will play with the GUI with malice just due to boredom or plain stupidity.
Fast forward 3 years in my career, I inherited an industrial line automation at what was going to be my main customer. 4 years later and a lot of months improving the processes and adding new stuff... I knew almost everything by heart and could solve almost everything just on the phone, without having to look at the code.
I got a call, line was blocked. Aha... Do this, nothing. Do that, nothing. Mmmmhhh... I'll be right there.
Once at the factory, I try this... nothing. I try that... nothing. Mmmmhhhh... I better have a look to the code.
I pack my laptop out, nothing.
I connect my laptop for online diagnose... 1 hour later... bug found.
How the hell did this happen? I had no explanation.
I had to reset the PLC, overwrite some blocks with my fixed versions and manually change the value of some parameters, then I had to move back the robot to home manually and do a restart of some slaves...
The girl / woman operating the line that day was a new one and it was her second day at that position. 2 years without any issue that couldn't be solve with a simple "back to home position" button click and she had found a bug that blocked the line beyond any recoverable point in less than 2 work-shifts.  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 8-Sep-21 2:29am.
|
|
|
|
|
That's awesome!
|
|
|
|
|
I have almost the same story - it involves two buttons and, in my case, a two year old.
In the olden days, when a complete "C" system fitted on a 340k floppy, CP/M ruled and I was working with Z80 based Superbrains, The Superbrain had two red keys, one each end of the keyboard, press them both and the computer reboots.
My daughter came into the lab, saw the computer, saw the two bright red keys and (of course) pressed them simultaneously - Oh Nooooooooo...
Andy
|
|
|
|
|
That's basically the old adage of "devs shall not test themselves and call it a day". As someone who's built that thing, certain assumptions on what it's supposed to do and how are thoroughly burned into our synapses rendering us impossible to see beyond.
|
|
|
|
|
@HappyDotNet
I'll give you a better test that Lord Murphy always gives me. First block some time with someone really high up that you are possibly trying to impress.
Then go on your routine demo.
Then ask him to use it in front of you.
Don't forget to record the screen if its possible to do so.
Nine times out of ten, you will get a big glaring bug, thrown in your face.
It will happen for each thoroughly tested application that is not a POC or low ticket sort of development effort.
And that is the lesson, no matter what you do,
Lord Murphy always gets the last laugh.
-Paras
|
|
|
|
|
I used to develop some apps for the PalmOS, remember those?
You could run an emulator on the desktop,
and there was a auto-test feature that would literally just press the emulated screen randomly for as long as you like.
I think it was called something like Monkey testing or something like that.
Leave it running overnight and check in on it in the morning!
|
|
|
|
|
I lead a small dev team. We had a old mainframe coder here years back, refused to learn anything new (it's a govt job...), so he had zero work. I enlisted him to test our applications before fielding them. Being completely out of the loop on things, he was a valuable tester. He'd come back with things like
"Well, if I press shift, F6, K, and Enter, this happens"
"Why would you do that?"
"I dunno, but this happens"
Found things we'd never test for. Annoying, but hey, it happens.
|
|
|
|
|
Your 5 year-old deserves some sort of treat for teaching you something new about QA. If she were (much) older, I'd say that she deserves a ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
This reminds me:
We had a user, that despite taking the online training for our software, could not get various features to work. (All of them involved F-Keys, in hindsight, but she referred to them by their names, like Refresh, etc).
On a visit, I stopped by her desk, and I asked her to show me. When she was required to press F3 to search, she was PRESSING: F, and then 3
I was ASTOUNDED, until I realized she had never pulled her keyboard drawer fully open.
I pulled it open for her, and she excitedly exclaimed "Oh, do you think THEY meant that F3 key?"
I said "I don't know! Try it!", and, of course, it worked...
The manager overheard this, and as I walked to the other part of the office, TRYING TO PREVENT MY SKULL From exploding... He said "I know you will tell this story in the future, just promise me to NEVER mention the company!"... ROTFLMAO.
Users... They come in all varieties. And it's why engineers/testers fail to find the problems.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
