Reports in recent weeks like this and this that software programs are now able to crack those annoying CAPTCHA character recognition tests on major free webmail sites like Yahoo, GMail, and Windows Live are a big deal.
Some of the spammers now have very fast and accurate character recognition programs, while others may be using the obvious solution of paying humans to recognize the human-readable characters.
The prove-you-are-a-human strategy is fundamentally flawed, because it cannot tell the difference between a human who wants to use free email to send a few personal messages a day, and a desparately poor human in a developing country paid a few dollars a day to set up an account for a spammer to send a million messages a day. It will never be cost-effective to stop such activity.
The webmail providers will eventually have to accept the fact that they cannot prevent spammers from setting up accounts. That leaves them with few options. One option would be to severely limit the number of email recipients per day on free email to the point where such accounts would be unattractive to spammers, but still attractive to most users. But is there such a limit? That remains to be seen. Perhaps the only way to stop spammers is to charge per email recipient for all email sent from an account. That would put an end to free email entirely.
Such a move would not necessarily put an end to GMail and other webmail services. Having a personal email address that stays the same when you change ISPs is worth paying for. Now it's up to the IT industry to figure out how to make it pay off.
Thursday, April 24, 2008
Friday, April 18, 2008
Before and after
In my new job, one of the features I'm testing is a web-based installer on Windows. One type of tool that can be very helpful for installer testing is a system snapshot tool. Tools of this type take a "snapshot" of the system before or after an install or uninstall and compare the two for differences. This type of snapshot is not a backup. The purpose is not to restore the system at a later time, but to determine what has changed and whether the actual changes match the expected changes.
After looking at several free and commercial snapshot tools, I settled on an open source tool called SupermonX. SupermonX snapshots can track the state of files, registry settings, and services, generate comparison reports across specific file or registry folders, and verify if a report matches an expected result. Output is stored in text format, and optionally, XML format. SupermonX also includes an Explorer-like user interface for viewing snapshot files, and command line options for running the snapshots and reports via batch script.
These features make SupermonX a good candidate for use in automated testing of the installation process. As time permits, I plan to build some tools around it to automatically snapshot before and after installs and verify that expected files, registries, and services are as expected.
Even without automation, a snapshot tool like SupermonX (I pronounce it "super monks" as in Chinese martial arts film) can help in quickly understanding what an installer is doing. That can help to generate good questions for your developers about what the installer should be doing.
With automated installer testing you can ask another class of questions, such as "I noticed that the whatever.htm file is no longer getting installed in today's build, is that intentional?" If it is intentional, your developer will probably be impressed that you are paying such close attention that you could catch a change that he didn't bother to tell you about. If it wasn't intentional, you may have a bug. Even better.
After looking at several free and commercial snapshot tools, I settled on an open source tool called SupermonX. SupermonX snapshots can track the state of files, registry settings, and services, generate comparison reports across specific file or registry folders, and verify if a report matches an expected result. Output is stored in text format, and optionally, XML format. SupermonX also includes an Explorer-like user interface for viewing snapshot files, and command line options for running the snapshots and reports via batch script.
These features make SupermonX a good candidate for use in automated testing of the installation process. As time permits, I plan to build some tools around it to automatically snapshot before and after installs and verify that expected files, registries, and services are as expected.
Even without automation, a snapshot tool like SupermonX (I pronounce it "super monks" as in Chinese martial arts film) can help in quickly understanding what an installer is doing. That can help to generate good questions for your developers about what the installer should be doing.
With automated installer testing you can ask another class of questions, such as "I noticed that the whatever.htm file is no longer getting installed in today's build, is that intentional?" If it is intentional, your developer will probably be impressed that you are paying such close attention that you could catch a change that he didn't bother to tell you about. If it wasn't intentional, you may have a bug. Even better.
Thursday, April 3, 2008
Java MBT implementation
More and more implementations of the Model-Based Testing approach seem to be appearing. Here's another open source implementation I found recently: mbt.tigris.org.
This implementation is in Java and uses GraphML, an XML format for drawing graphs, as a modeling language.
GraphML is an interesting choice for a language. The example models have a lot of graphical drawing information in them that isn't needed for behavioral modeling. However, being able to create the models in a graphical tool is a nice feature.
Overall, a welcome contribution to the growing list of model-based testing tools and worth a look for anyone interested in such tools.
Update: My initial impression that this tool does not have support for variables or guard conditions was incorrect. That's what I get for commenting on a tool that I haven't taken the time to download and play around with yet. See the comments by Kristian, the tool's author.
This implementation is in Java and uses GraphML, an XML format for drawing graphs, as a modeling language.
GraphML is an interesting choice for a language. The example models have a lot of graphical drawing information in them that isn't needed for behavioral modeling. However, being able to create the models in a graphical tool is a nice feature.
Overall, a welcome contribution to the growing list of model-based testing tools and worth a look for anyone interested in such tools.
Update: My initial impression that this tool does not have support for variables or guard conditions was incorrect. That's what I get for commenting on a tool that I haven't taken the time to download and play around with yet. See the comments by Kristian, the tool's author.