Nature tester
-
raddevus wrote:
But I still love breaking software.
That's the best attitude a developer can have: because now you think of methods which could break your software and then make it better, then think of more sophisticated approaches to break your software, and so on. Most developers check their code in when a very simple "happy path scenario" seems to work, and that's their definition of "DONE".
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
IMO if you're not doing behavioral or regression testing on your modules throughout development you're doing it wrong. Leaning on code coverage unit tests in place of this is one of my biggest kvetches about the TDD culture.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
I'm - among other things - making a software for the ATMs (for Bitcoins they're called BTMs). Yesterday we've found out that one of our machines has probably a defective touch screen. It was randomly pressing all over the screen. On closer inspection (on site) it turned out to be a branch of a tree randomly waving in the wind and occasionally touching the screen. This branch also managed in this short time to uncover two bugs that two testing teams were unable to find during two years of product lifetime. One was even as simply as touching the screen in a certain time. One was more complex, the branch managed to 'touch' through random screens and created very weird scenarios. One of them was a really obscure bug. The branch became a honorary member of our testing team. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
-
Smart K8 wrote:
The branch became a honorary member of our testing team.
:laugh: Great story. Thanks for sharing. Made me laugh and think about the old days. Back when I worked in QA, I once entered a 10,000 character URL into IE (it is no longer possible) to test a product. The URL not only crashed the program but took down the instance of the Oracle db. I was absolutely psyched. This was so long ago that the term sql injection hadn't reached popularity and I didn't know that my "extensive testing" had a name. It was fun. Later the developer asked me, "What do you want me to do with that bug? It's ridiculous. No one would ever do that." Me: (smiling) "Doesn't matter to me what you do with it. But, at least you know it's there." I like to break stuff. Especially software. Software is soooo breakable. And most software deserves to be broken.:thumbsup: And, yes, I'm a full-time dev and have been for years. But I still love breaking software.
-
"What do you want me to do with that bug? It's ridiculous. No one would ever do that." Not so fast... my cat could do it with one paw!
It took too long. It too soo long.
-
I'm - among other things - making a software for the ATMs (for Bitcoins they're called BTMs). Yesterday we've found out that one of our machines has probably a defective touch screen. It was randomly pressing all over the screen. On closer inspection (on site) it turned out to be a branch of a tree randomly waving in the wind and occasionally touching the screen. This branch also managed in this short time to uncover two bugs that two testing teams were unable to find during two years of product lifetime. One was even as simply as touching the screen in a certain time. One was more complex, the branch managed to 'touch' through random screens and created very weird scenarios. One of them was a really obscure bug. The branch became a honorary member of our testing team. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
No amount of testing can flesh out bugs faster than an end user. Even if it's a tree. I swear some trees are more on the ball anyway.
-
I'm - among other things - making a software for the ATMs (for Bitcoins they're called BTMs). Yesterday we've found out that one of our machines has probably a defective touch screen. It was randomly pressing all over the screen. On closer inspection (on site) it turned out to be a branch of a tree randomly waving in the wind and occasionally touching the screen. This branch also managed in this short time to uncover two bugs that two testing teams were unable to find during two years of product lifetime. One was even as simply as touching the screen in a certain time. One was more complex, the branch managed to 'touch' through random screens and created very weird scenarios. One of them was a really obscure bug. The branch became a honorary member of our testing team. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
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.
-
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 ;P :laugh:
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.
-
Smart K8 wrote:
The branch became a honorary member of our testing team.
:laugh: Great story. Thanks for sharing. Made me laugh and think about the old days. Back when I worked in QA, I once entered a 10,000 character URL into IE (it is no longer possible) to test a product. The URL not only crashed the program but took down the instance of the Oracle db. I was absolutely psyched. This was so long ago that the term sql injection hadn't reached popularity and I didn't know that my "extensive testing" had a name. It was fun. Later the developer asked me, "What do you want me to do with that bug? It's ridiculous. No one would ever do that." Me: (smiling) "Doesn't matter to me what you do with it. But, at least you know it's there." I like to break stuff. Especially software. Software is soooo breakable. And most software deserves to be broken.:thumbsup: And, yes, I'm a full-time dev and have been for years. But I still love breaking software.
raddevus wrote:
Software is soooo breakable.
Civilization I did not "break", regardless of the hours I spent "testing". If you wanted to say that there exists a lot of crappy software, then yes, you're right. But, that is a choice, nothing else - good software need not be "soooo breakable".
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
I'm - among other things - making a software for the ATMs (for Bitcoins they're called BTMs). Yesterday we've found out that one of our machines has probably a defective touch screen. It was randomly pressing all over the screen. On closer inspection (on site) it turned out to be a branch of a tree randomly waving in the wind and occasionally touching the screen. This branch also managed in this short time to uncover two bugs that two testing teams were unable to find during two years of product lifetime. One was even as simply as touching the screen in a certain time. One was more complex, the branch managed to 'touch' through random screens and created very weird scenarios. One of them was a really obscure bug. The branch became a honorary member of our testing team. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
it's because, contrary to testers, the tree is endowed with self consciousness! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
That means the Branch is probably the most experienced member of our testing team. I reckon it will lead the team within few months.
In order to understand stack overflow, you must first understand stack overflow.
there is great potential he could become the next branch manager! :wtf:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I'm - among other things - making a software for the ATMs (for Bitcoins they're called BTMs). Yesterday we've found out that one of our machines has probably a defective touch screen. It was randomly pressing all over the screen. On closer inspection (on site) it turned out to be a branch of a tree randomly waving in the wind and occasionally touching the screen. This branch also managed in this short time to uncover two bugs that two testing teams were unable to find during two years of product lifetime. One was even as simply as touching the screen in a certain time. One was more complex, the branch managed to 'touch' through random screens and created very weird scenarios. One of them was a really obscure bug. The branch became a honorary member of our testing team. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
Gives a whole new meaning to "branching your code" :laugh:
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I'm - among other things - making a software for the ATMs (for Bitcoins they're called BTMs). Yesterday we've found out that one of our machines has probably a defective touch screen. It was randomly pressing all over the screen. On closer inspection (on site) it turned out to be a branch of a tree randomly waving in the wind and occasionally touching the screen. This branch also managed in this short time to uncover two bugs that two testing teams were unable to find during two years of product lifetime. One was even as simply as touching the screen in a certain time. One was more complex, the branch managed to 'touch' through random screens and created very weird scenarios. One of them was a really obscure bug. The branch became a honorary member of our testing team. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
-
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. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
-
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. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
-
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. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
-
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.
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... :sigh: :doh: 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)
-
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... :sigh: :doh: 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 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. :laugh:
In order to understand stack overflow, you must first understand stack overflow.
-
I say let the branch be. :-D
I am not the one who knocks. I never knock. In fact, I hate knocking.
-
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. :-D
In order to understand stack overflow, you must first understand stack overflow.