So we got animatic inputs from military-industry (see post) and art.
March 21, 2008
Amazing art/tech: animatic sculptures
Go see this genius in action, building impossible animal-like sculptures.
So we got animatic inputs from military-industry (see post) and art.
So we got animatic inputs from military-industry (see post) and art.
Following last post: the nature of testing
People asked me what I meant about the all-terrain robot being tested. Besides the obvious (lab footage of the robot completing tasks in the lab, such as climbing bricks and jumping over an obstacle), there is a single moment in the video that represent for me an inner truth about testing:
Testing requires certain cruelty...
Look how the tester kicks the robot on 00:35. Let me describe it for you: the team is working on this ingenious invention, a wonderful machine with unbelievable capabilities, they must love it (ok, except the annoying sound). I bet they have a nick name for it. This is a condition in which you want to see your loved one succeeds.
Instead, they take it out to test it in the worst ever conditions - in this case literally walking on thin ice. To top it, this guy just kicks it out of balance, in the most vicious way!
We are required to do the same thing with the software we test: bring it to the limit, then push and observe if it falls gracefully, crashes into ugly crisis or recover brilliantly. Living the sentiments aside - we must kick it hard. If we don't, reality will.
Testing requires certain cruelty...
Look how the tester kicks the robot on 00:35. Let me describe it for you: the team is working on this ingenious invention, a wonderful machine with unbelievable capabilities, they must love it (ok, except the annoying sound). I bet they have a nick name for it. This is a condition in which you want to see your loved one succeeds.
Instead, they take it out to test it in the worst ever conditions - in this case literally walking on thin ice. To top it, this guy just kicks it out of balance, in the most vicious way!
We are required to do the same thing with the software we test: bring it to the limit, then push and observe if it falls gracefully, crashes into ugly crisis or recover brilliantly. Living the sentiments aside - we must kick it hard. If we don't, reality will.
March 19, 2008
Testing an all-terrain robot
Amazing video of military all-terrain robot (looks like a headless donkey). Video also covers tests in lab, interesting to see how it handles different surfaces.
March 17, 2008
feature: www.lexisum.com - quick wiki definitions
Feature only this time....
www.lexisum.com is a simple UI that allows you to type a word or concept and get definitions for it from Wikipedia. I usually use Google's "define:" for that, but this little gadget is nice.
www.lexisum.com is a simple UI that allows you to type a word or concept and get definitions for it from Wikipedia. I usually use Google's "define:" for that, but this little gadget is nice.
March 13, 2008
James Lyndsay: Why Can't Testers Code?
A new testing magazine is accessible online at www.testingexperience.com - congratulations!
James Lyndsay, a British software testing consultant, caught my eye with a challenging short piece called "Why can't testers code?".
The main claim is that there is a growing skills gap between testers and developers, because tester can't code and developers can test. This skills gap pushes testers into manual choirs, while developers write and execute large numbers of high quality test cases, usually on the Unit Test level. Let me add that there is a growing number of sophisticated tools that allow developers to automatically create, run and measure Unit Tests (Agitar, TestNG and Clover are a few examples).
Although in many testing teams this is not the case, I had a live-demo of what James was talking about: a friend called me and said that his management decided to move all test automation activities from the test team to the development team. In James Lyndsay's words:
"this will be a call to arms: your colleagues are doing the interesting parts of your job, and you're rolling over to let them"
I totally agree with James and his call to testers to take back test coding into their own hands. A tester that cannot express himself in code is limited in his capabilities and dependent on others. A tester who cannot code is limited in her understanding of things that can go wrong (and will...) in different application areas. A tester who can't automate will burn-out quickly, repeating again and again the same boring tasks.
We are not a bunch of button-pushers, we are software people, capable of writing testware ourselves.
James Lyndsay, a British software testing consultant, caught my eye with a challenging short piece called "Why can't testers code?".
The main claim is that there is a growing skills gap between testers and developers, because tester can't code and developers can test. This skills gap pushes testers into manual choirs, while developers write and execute large numbers of high quality test cases, usually on the Unit Test level. Let me add that there is a growing number of sophisticated tools that allow developers to automatically create, run and measure Unit Tests (Agitar, TestNG and Clover are a few examples).
Although in many testing teams this is not the case, I had a live-demo of what James was talking about: a friend called me and said that his management decided to move all test automation activities from the test team to the development team. In James Lyndsay's words:
"this will be a call to arms: your colleagues are doing the interesting parts of your job, and you're rolling over to let them"
I totally agree with James and his call to testers to take back test coding into their own hands. A tester that cannot express himself in code is limited in his capabilities and dependent on others. A tester who cannot code is limited in her understanding of things that can go wrong (and will...) in different application areas. A tester who can't automate will burn-out quickly, repeating again and again the same boring tasks.
We are not a bunch of button-pushers, we are software people, capable of writing testware ourselves.
March 08, 2008
bug/feature: Acid3 test, avoiding left-turns
Bug:
I am usually pretty happy with my Firefox 2. Today I ran Acid3 test on it to discover that it scored 51% (failed...). The test includes 100 automated browser spec compatibility tests, that cover DOM structure and functionality, advanced CSS and other browser features that I am not familiar with. Try to run Acid3 on your browser.
What puzzles me is this: if Firefox scored 100% instead of 51%, would I be twice as happy with it?
Image source: http://en.wikipedia.org/wiki/Acid3
Feature:
You know what it feels like waiting for the opposite lane to clear while making a left-turn, right? UPS added a feature to its navigation software to avoid left-turns as much as possible, leading to vast savings in time and money over their huge truck fleet.
I got this one from Slashdot, where the reporter speculated that this feature was probably devised by a grad-student instead of the traditional traveling agent problem...
I am usually pretty happy with my Firefox 2. Today I ran Acid3 test on it to discover that it scored 51% (failed...). The test includes 100 automated browser spec compatibility tests, that cover DOM structure and functionality, advanced CSS and other browser features that I am not familiar with. Try to run Acid3 on your browser.
What puzzles me is this: if Firefox scored 100% instead of 51%, would I be twice as happy with it?
Image source: http://en.wikipedia.org/wiki/Acid3
Feature:
You know what it feels like waiting for the opposite lane to clear while making a left-turn, right? UPS added a feature to its navigation software to avoid left-turns as much as possible, leading to vast savings in time and money over their huge truck fleet.
I got this one from Slashdot, where the reporter speculated that this feature was probably devised by a grad-student instead of the traditional traveling agent problem...
March 06, 2008
bug/feature: crashing voting machines, cool wii 3d
Bug:
Reports on voting machines crashing due to unhandled event: users dragging their fingers on the touch-screens fired-up "drag&drop" event which was not handled. Boom.
Feature:
Genious Johnny Chung Lee presents head tracking for navigation in 3d worlds, based on wii remote. Hackerish, wild and inspiring.
(screen shot from the youtube clip)
Reports on voting machines crashing due to unhandled event: users dragging their fingers on the touch-screens fired-up "drag&drop" event which was not handled. Boom.
Feature:
Genious Johnny Chung Lee presents head tracking for navigation in 3d worlds, based on wii remote. Hackerish, wild and inspiring.
(screen shot from the youtube clip)
bug/feature: Nissan Navara, Nokia Morph
BugNissan Navara was graded poor by NCAP crash tests. Turns out this was due to software failure, firing the airbags too late (see impact on driver's head in NCAP video). This bug was fixed in later versions, says Nissan.
Feature
Nokia presents "Morph" a futuristic combination of cellular technology with nanotech components. Morph can be charged by sunlight energy using nano-scale grass (!), fold into any shape, be worn and even smell. See demo, read more.
Post 1: What's it all about
bug/feature presents pairs of interesting bugs and features that I stumble upon from time to time.
Other posts may suggests test-related ideas or insights.
I am a software test engineer by trade. This is my playing field.
Other posts may suggests test-related ideas or insights.
I am a software test engineer by trade. This is my playing field.
Subscribe to:
Posts (Atom)