OpenOffice.org is seeking beta testers for the OpenOffice 3 release. See the announcement.
One of the features mentioned in the announcement is partial support for DOCX, Microsoft's new document format and a direct competitor to the OpenOffice ODF format. According to the announcement, OpenOffice 3 will open DOCX files but not save to that format. Saving to the old DOC binary format will continue to be supported.
I'm glad to see that OpenOffice is providing limited, but only limited support for this format. Recently my wife got an email from a friend with a DOCX file attached. Our OpenOffice 2 doesn't open it. Nor can the vast majority of Windows and Office users.
Apparently Word 2007 saves to DOCX by default. Users who want friends to be able to actually open their files have to change it to DOC manually. What a cynical way for Microsoft to use novice users who don't know any better to spread its new file format around and waste people's time.
There are some solutions for Office 2003 users and even OpenOffice 2 users, but none of them are doable by novice users.
Kudos to OpenOffice.org for providing a light at the end of the tunnel for OpenOffice users whose friends unknowingly inflict these DOCX files upon them, without adding to their further proliferation.
Thursday, May 15, 2008
Thursday, April 24, 2008
The end of free webmail
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.
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.
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.
Friday, February 22, 2008
Web Testing Framework released
This week I released my first open source testing project.
Hanno is a test automation framework in Java for dynamic model-based exploratory testing of web applications. It can be used to develop an automated testing tool for most web applications.
Hanno is built on several open standards and tools:
Hanno implements a model-based test automation approach. To test a web application with Hanno, an SCXML model is created to describe the application behavior. A Java class is created with methods for each event or state in the model. Each method calls Watij code to execute the event in Internet Explorer, or to verify that the browser is in the correct state. The Java class is run by an engine with a simple algorithm to determine which event to execute next. The order of test execution is not predetermined.
Modeling a web application in SCXML is not difficult, but does require familiarity with state charts or finite state machines. I found SCXML quite easy to learn and understand. Hanno includes a simple example application to help get started.
Debugging a Hanno test tool can be a complex process, however, because it requires getting the SCXML model and the Java code that the model executes to work together and both be correct at the same time.
I recommend starting small, by modeling a simple behavior of your web application, testing it, getting it to work, then adding behavior incrementally.
I have used Hanno to test several web applications. With experience, a simple model of a web application's navigation can be built in a day or two. A more complex model with hundreds of events and states may require several weeks or a month. The end result can be a test tool than can do the work of hundreds of hand-crafted automated tests, run continuously, and find new bugs because new test sequences are executed on each run.
I developed Hanno primarily to meet my own needs and to implement my own concepts for how a model-based testing tool should work. It can certainly be improved, especially in the area of debugging and error handling. Java developers interested in test automation are welcome to join the project.
I encourage the software testing community to download Hanno and kick the tires. Please use the Hanno forums for any detailed questions or feedback.
Hanno is a test automation framework in Java for dynamic model-based exploratory testing of web applications. It can be used to develop an automated testing tool for most web applications.
Hanno is built on several open standards and tools:
- SCXML, an XML language based on Harel state charts.
- Apache Commons SCXML, an SCXML implementation in Java.
- Watij, a web application testing tool in Java.
Hanno implements a model-based test automation approach. To test a web application with Hanno, an SCXML model is created to describe the application behavior. A Java class is created with methods for each event or state in the model. Each method calls Watij code to execute the event in Internet Explorer, or to verify that the browser is in the correct state. The Java class is run by an engine with a simple algorithm to determine which event to execute next. The order of test execution is not predetermined.
Modeling a web application in SCXML is not difficult, but does require familiarity with state charts or finite state machines. I found SCXML quite easy to learn and understand. Hanno includes a simple example application to help get started.
Debugging a Hanno test tool can be a complex process, however, because it requires getting the SCXML model and the Java code that the model executes to work together and both be correct at the same time.
I recommend starting small, by modeling a simple behavior of your web application, testing it, getting it to work, then adding behavior incrementally.
I have used Hanno to test several web applications. With experience, a simple model of a web application's navigation can be built in a day or two. A more complex model with hundreds of events and states may require several weeks or a month. The end result can be a test tool than can do the work of hundreds of hand-crafted automated tests, run continuously, and find new bugs because new test sequences are executed on each run.
I developed Hanno primarily to meet my own needs and to implement my own concepts for how a model-based testing tool should work. It can certainly be improved, especially in the area of debugging and error handling. Java developers interested in test automation are welcome to join the project.
I encourage the software testing community to download Hanno and kick the tires. Please use the Hanno forums for any detailed questions or feedback.
Wednesday, February 13, 2008
The human context of quality
Recently the universe decided to test me to see how strong my commitment to software quality really was.
Last September my previous employer laid off its entire engineering staff. I interviewed with several companies, and was quickly hired as a senior test engineer at an Internet commerce company that sells publicly available personal information online. I had some concerns about working for a company that enables "spying on people", as one friend of mine put it. I also knew from prior experience that many public records contain outdated or inaccurate information. But it seemed on the surface to be a good opportunity to use my experience to help build a software quality department from the ground up.
After arriving, I learned that this company did software development very differently than any company I had worked for. The software development, quality assurance, and release cycle seemed deeply flawed to me. New features were released almost every day, with only minimal testing by developers, and no time for QA to plan thorough testing before release.
I had previously worked in Agile environments with release cycles measured in weeks, and on hot fix releases that had to go out in a day or two, but only to specific customers for whom the benefit of a quick fix outweighed the risk of a quick release. Working at this company was like doing a patch release to everyone in the world, every day.
I have a lot of experience testing web applications, and realized that in such an environment, I would be unable to catch most of the defects before release. To be fair, defects found in production were fixed quickly. Still, I saw no way to be successful as I usually define it. Still I did the best I could for as long as I could.
Was this company wrong to develop software this way? Some would say no. For example, in the context-driven approach to software testing, there are no best practices that apply to the entire software industry. QA exists to provide information to the development team, nothing more. QA must use processes that are appropriate to the business and the practices of a company, whatever they are. Releasing lightly tested code would be criminal in the aerospace or medical industries, but for an e-commerce company selling public information, it might not be.
I still thought it was wrong. Even when a company has good customer support, and the worst consequence of a customer getting charged for bad information is a refund, the software has still wasted the customer's time and created unnecessary confusion and stress in their lives. The corporate context is not the only context that matters. Software that interacts with human beings should treat them humanely.
I saw little chance of convincing the company of that view. After all, they had been doing this for years, and their company was growing and seemed to be doing well financially. Some of the people I would have to convince to change the development process had designed that process in the first place. These same folks owned a lot of stock in the company, and were set to make millions when the company went public. Why should they listen to me?
I did some testing of my own. I proposed various small changes to the software process that were well justified and should have been relatively uncontroversial. I couldn't get my development manager to approve any of them.
The conflict between the company's values and my own began to create more and more stress for me. I finally reached a point where the stress of having to find a new job seemed less terrible than what I was experiencing every day. Three months after I started, after a particularly bad day, I resigned.
I don't blame the employer for the mismatch. It's hard to see a values conflict coming until you experience it. Still, there were signs in the interview that I should have paid more attention to, and questions that I could have asked but did not. The experience has helped me to a deeper understanding of what type of work environment I need, and what types of companies I would consider working for in the future.
Last September my previous employer laid off its entire engineering staff. I interviewed with several companies, and was quickly hired as a senior test engineer at an Internet commerce company that sells publicly available personal information online. I had some concerns about working for a company that enables "spying on people", as one friend of mine put it. I also knew from prior experience that many public records contain outdated or inaccurate information. But it seemed on the surface to be a good opportunity to use my experience to help build a software quality department from the ground up.
After arriving, I learned that this company did software development very differently than any company I had worked for. The software development, quality assurance, and release cycle seemed deeply flawed to me. New features were released almost every day, with only minimal testing by developers, and no time for QA to plan thorough testing before release.
I had previously worked in Agile environments with release cycles measured in weeks, and on hot fix releases that had to go out in a day or two, but only to specific customers for whom the benefit of a quick fix outweighed the risk of a quick release. Working at this company was like doing a patch release to everyone in the world, every day.
I have a lot of experience testing web applications, and realized that in such an environment, I would be unable to catch most of the defects before release. To be fair, defects found in production were fixed quickly. Still, I saw no way to be successful as I usually define it. Still I did the best I could for as long as I could.
Was this company wrong to develop software this way? Some would say no. For example, in the context-driven approach to software testing, there are no best practices that apply to the entire software industry. QA exists to provide information to the development team, nothing more. QA must use processes that are appropriate to the business and the practices of a company, whatever they are. Releasing lightly tested code would be criminal in the aerospace or medical industries, but for an e-commerce company selling public information, it might not be.
I still thought it was wrong. Even when a company has good customer support, and the worst consequence of a customer getting charged for bad information is a refund, the software has still wasted the customer's time and created unnecessary confusion and stress in their lives. The corporate context is not the only context that matters. Software that interacts with human beings should treat them humanely.
I saw little chance of convincing the company of that view. After all, they had been doing this for years, and their company was growing and seemed to be doing well financially. Some of the people I would have to convince to change the development process had designed that process in the first place. These same folks owned a lot of stock in the company, and were set to make millions when the company went public. Why should they listen to me?
I did some testing of my own. I proposed various small changes to the software process that were well justified and should have been relatively uncontroversial. I couldn't get my development manager to approve any of them.
The conflict between the company's values and my own began to create more and more stress for me. I finally reached a point where the stress of having to find a new job seemed less terrible than what I was experiencing every day. Three months after I started, after a particularly bad day, I resigned.
I don't blame the employer for the mismatch. It's hard to see a values conflict coming until you experience it. Still, there were signs in the interview that I should have paid more attention to, and questions that I could have asked but did not. The experience has helped me to a deeper understanding of what type of work environment I need, and what types of companies I would consider working for in the future.