|
Reminds me of an old testing method we had thirty years ago: The five-year-old test.
This was in the pre-GUI-days, with keyboard input and ASCII output only, when the final test before release was to put your five year old at the keyboard, telling him: Do whatever you want!
Daddy will give you an ice cream cone for every time you make the program stop, and can show daddy how you did it!
I wouldn't say we used that test method regulary, but we did catch a few bugs that way.
|
|
|
|
|
People without children use the cat for it  
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.
|
|
|
|
|
The other excellent "random" test for software is to demo it to a prospective purchaser, or better still let them use it during a public demonstration. Boy, does that reveal the bugs...  
I recall an IBM presenter showing off the latest release of OS/2 at a primarily Windows-based trade show. He had a 20-foot screen behind him and was walking us through the latest and greatest addition to the OS. Standing to one side of the PC he hit "enter" with a flourish to complete his walkthrough, and was delighted when the crowd erupted with cheers and a standing ovation. Until he turned around and saw a "fatal" error message filling the screen. (Can't remember the text now but it was very appropriate and entirely met the expectations of the watching Microsoft devotees)
|
|
|
|
|
Or, if you are still a student: Giving a demo to your professor.
In my student days, the last semester before we started our Master Thesis work we spend half of the time on a major team project - 6-8 students doing a design and implementation together. The final product was presented for assessment and judgement by several professors and graduate students, both through verbal descriptions of the design, and a practical demo.
Our demo went... sh*t. So we had to fall back on a reserve solution. Which went sh*it. But we had a third alternative, which went... Even our fifth and last alternative demo failed.
Yet we were awarded top grades (equivalent to an A) for our project work. I guess that part of the reason was that we had prepared so well with four backup solutions. (And also, we could explain what went wrong when something failed, how it could be corrected.)
My favorite error message could earlier be seen quite often at all the info screens at our local airport: The Tandem non-stop computer system is down.
|
|
|
|
|
it's because, contrary to testers, the tree is endowed with self consciousness!
|
|
|
|
|
Gives a whole new meaning to "branching your code"
|
|
|
|
|
Unbelievable story … please promise that it was not made up for our amusement … 
|
|
|
|
|
It really happened. Moreover, it's still happening. Because we can't cut the branch without permission from some town official. So far no new crashes. The application is pretty robust and can recover even from unhandled exceptions. This branch randomly found a way. 
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
Good story about "expect the unexpected.." Thanks for sharing …
BR
|
|
|
|
|
If the branch is hitting the screen hard enough to register, I'm not sure I'd want to be a customer standing there anyway... next thing your tree will become a mugger!
|
|
|
|
|
It's a small town (10k population). I don't really think anyone is buying BTCs there, but that's on our client to decide. We're just making a software. It's a spruce tree and it's just gently brushing the screen in a wind sometimes (about once a few minutes). It would be just very annoying for a potential customer (this BTM has to see one yet), but it can be stopped quite easily. 
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
I say let the branch be.
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
It's unfortunately not our BTM, but our client's. We have no say in that. 
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
Reminds me of a user I was helping some 20 years ago.
He told me that whenever he pressed a certain key on his keyboard his machine would restart.
So he demonstrated and the machine did indeed restart.
I also noticed that he had a ring binder folder on the desk and every time he would lean forwards to press the key, the binder would move forwards and the right corner of it would press the restart button on the box.
I really should have just kept my mouth shut and not pointed out to him what was going on
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 3-Aug-18 3:15am.
|
|
|
|
|
Poor guy
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
Very similar situation: A lady at church complained that every time she started Word, it opened dozens of windows; on observation, I noticed that the heel of her palm was pressing the Enter key on the keypad.
Also, in the early days of PCs, the highest score on a simple game in our office was held by the office stapler which was leant against the space bar.
|
|
|
|
|
I like it! Nothing uncovers weirdness like random inputs. I have never had a tree available so I used to ask the cleaning lady to try things if I was working really late. She was practically random in her inputs and her testing did help us robustify things. I'm not sure if that's actually a word. What ever.
|
|
|
|
|
Rule #1: If the cleaning lady cannot crash it, release it.
... such stuff as dreams are made on
|
|
|
|
|
It has worked me quite well. Actually, I find it very useful to have someone test software who has virtually no knowledge of it because they do the most unexpected things.
|
|
|
|
|
|
Hahahaha...
And it's the first time you encounter such code hey?
Welcome to the club!
It seems to me that most code written by junior has such silly "exception handling"...
|
|
|
|
|
i have dealt with many madness in engineering. But this ticked me off. I cordially asked the engineer to fix. But he does not see the issue. but One good thing is he agreed to change the way i think it is okay
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
maybe he doesn't know about "return" statement or "finally" clause?
|
|
|
|
|
But do you know about the "fault" clause?
It's like "finally", but only executes when an Exception was thrown.
It's basically like:
catch
{
throw;
}But faster since the Exception isn't actually caught and rethrown.
I guess it would look like:
fault
{
}The compiled MSIL code supports it, C# does not (which doesn't mean you can't use it[^]  ) 
|
|
|
|
|
wow, you got me there pal! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
