Most of the people who are running into trouble are already working with Kevin, Lee, and myself on getting the issues ironed out but I wanted to just take a minute to explain why you are seeing bugs! Understanding the developer end of things may not make everything better, but it might help give some insight into what is going on.

I’m also going to mention a few of the bugs we’ve seen at the end of this post. One reminder, however…please send us email if you need support. We just can’t do it here in the blog comments!

That said…read on if you want the full story!

So what is so different about eWallet 7 on Windows PC?
The underlying challenge is this…with eWallet 7 we literally rewrote every single piece of the eWallet program. The program you were all using before was over 10 years old and while the original code base was strong, it had some issues. None of that is left in eWallet 7. It’s a brand new application.

But why did you change it?
First, it was rigid, meaning it was exceptionally hard for us to do things that people felt “should be easy to implement.” We needed flexibility so we could remain relevant going forward.

Second, it saw a lot of add-ons over the years. eWallet 6 was a LOT different (feature-wise) from eWallet 1. At some point, all that adding on takes its toll and makes it really expensive (in time and money) to improve the application.

Third, the user interface needed a major face lift. I know a lot of our long term users didn’t mind it (I kind of liked it!) BUT many old customers felt we weren’t keeping up with the times (and said so!) and for new customers it made it hard for us to compete (once they TRIED the apps they chose us, but in a screenshot to screenshot comparison it was tough for us!) Just sprucing up the old version wasn’t an option (see the first and second points!)

Didn’t you test this thing?
Did we ever! We had over 100 people actively using eWallet for around two months straight. In addition, we’ve been using eWallet 7 in-house even longer than that! Plus we did all our usual automated and manual testing that we do with every release. So yes – we tested this – A LOT!

So how did bugs get through?
Remember the part about rewriting the entire application? When you do that, no matter how carefully you test, it is impossible to find all the bugs. With Windows PCs there are literally an infinite number of installation and configuration combinations. There is NO WAY to test every condition. You test as many as you can and catch as much as you can, but you’ll never catch everything. It’s a mathematical impossibility.

Even now, with people helping us work on the bugs that have come up, many of these we can’t even replicate in-house. It is exceptionally difficult BUT we’re working on it and we will work these out. Believe it or not, the last version of eWallet had its problems – we worked through them and the same will be true here. We’ll do everything we can to help you in the meantime.

In the end it’s what we had to do…
We knew we’d be facing challenges like this when we went into this. We had a 7.0.1 update release on the calendar prior to eWallet even going out. If we didn’t do this overhaul now, however, there would have been costs down the road. We had to bite the bullet and make it happen – it took a long time, a ton of work, and we’re working through some challenges now, but in the long run eWallet will be a better app for it and will be poised to serve you for the next decade.

So what is a customer to do?
First, let support know what you saw by sending them an email. LOTS of people want eWallet 7 so we are getting slammed by questions, orders, and requests but we WILL answer you. If you don’t email us, however, we won’t know what is happening.

Second, if you’ve got one of the uglybugs and you decide you want to use eWallet 6 for now, that’s fine – just say so in the email and we’ll send you what you need.

Finally – talk to us! We really do want to make things right and we’ll do everything in our power to do so – so let us know what YOU need and we’ll work with you.

Sincerely, Marc

PS: Here are some things we know folks are seeing right now -

Windows 7 Explorer Crashes: Can’t replicate this in-house but we’re working with some customers to figure out what is happening.

BSOD: Holy crap! A couple of people have seen really bad crashes – again, for the life of us we can’t replicate this but we’re working with some folks and will get this ironed out as well. The strange thing here is that we quite literally aren’t touching anything in Windows that should allow this! It’s nuts but we’ll figure it out!

Blank Text: Can’t see the text? We found that some customers using particularly high DPI settings are running into this. We have a solution we’re testing so hopefully we can get it into the next build.

Error 1010 On Sync: If something goes wonky during install (maybe from other programs running or something like that) it might damage your sync partnership. If that happens just delete the partnership from sync setup and re-add it. You should be all set!

These are a few that I wanted to mention just because they are the most likely to make you nuts if you get them! As I said – most people aren’t having any problems - seriously, we’ve got thousands of people using eWallet 7 now and only a handful see these – these bugs suck – we know – but odds are you won’t see them…and again…IF YOU DO, PLEASE EMAIL US! We can’t do support on the blog. It just isn’t setup for that!

This picture illustrates two things. One is that I have terrible handwriting, especially on a white board. It also gives a glimpse into what software testing is like here at Ilium Software.

I’ve been meaning to talk about testing, but between testing eWallet 5.0, InScribe 2.0 and just finishing up on a Keep Track update, not to mention supporting our existing and new software… there just wasn’t time. If you have some time, read on!

Aside from technical support, I do a lot of the software testing for Ilium Software. I don’t do all of it because that would be impossible. Not just figuratively impossible, but literally impossible. Thanks to math – which I absolutely hate and am terrible at – 100% ‘test coverage’ of a product is intractable.

Digression warning: 100% test coverage for something like a full PC operating system such as Microsoft Windows XP requires some insanely large number of test cases. I could try to explain why this is, but I’d fail miserably as my computer science math knowledge has trickled out of my brain. I think it involves a lot of factorials. 100% complete testing requires exponentially larger numbers of test cases for even a small increase in the number of variables, until it becomes impossible to test completely before entropy makes everything the same anyway.

More digression: I’m going to harp on the possible magnitude of test cases for just a moment, for a little scale. Here’s a micro-lesson in binary math: computers store data in binary format, meaning there is just 0 or 1. You make larger numbers by increasing the number of bits. For a 2-bit binary number, you have 4 numbers you can represent: 0, 1, 2, 3. For a 3-bit number, you have 8 numbers you can represent. For a 4 bit number, you have 16 numbers. Every time you add one ‘bit’ of information to the length of the number, you double the number of possible numbers. The same is true of test cases. If you have 4 variables you’re testing, that means there are twice as many test cases as with three variables. This quickly gets out of hand if you consider all possible test cases, not just likely ones.

So, I don’t test everything. No tester ever tests everything unless “everything” is ten different cases, period. What I do test usually falls into two categories:

• Verification testing
• Exploratory testing

Verification testing is the often very repetitive and frankly boring task of making sure that a function does what it’s supposed to do, a bug is fixed, etc. This involves lots of checklists and tasks like creating every possible card in eWallet and filling up every possible field, or manually forcing a trial version to expire after 30 days. It’s not very fun and exciting. It isn’t supposed to be fun and exciting. It’s just required.

Exploratory testing is almost self-explanatory. You explore a product and hopefully find bugs. You do weird things, such as entering in 10000000000000000000000000000000000000 into the number of minutes to wait; you set your coffee cup down on your keyboard to enter in letters into an eWallet card; you try to drag a program file where a picture’s supposed to go; you open up a data file in a text editor and change one character to see if the program notices; you pretend to be The User Who Manages To Do Everything And Break All Software and throw the book at the product. [Exploratory testing is often 'black box' testing, where the tester doesn't have any knowledge of how a particular item is implemented or exactly what it should do.]

Like verification testing, this can be really boring, especially if you aren’t finding any bugs. There’s a very awful feeling when you do everything you can imagine and nothing bad happens. There’s an even more awful feeling when you send the supposedly-well-tested and bug-free product out to users, and within ten minutes get a report of some glaring and awful bug that internal testing didn’t find (that’s what beta testers are for!)

However, exploratory testing can also be exciting, especially with alpha software. [Alpha software is completely unusable by the public, whereas beta software is usable but could have some big bugs still. Then you have Release Candidates, which theoretically can become the released product if no more bugs are found.]

For example, I might get an alpha release that crashes every time you click on a menu item, or crashes when run on my testing PC but not my main PC.

Don’t panic - there’s a reason we don’t let the public use alpha software! I don’t want to horrify any users with tales of eWallet lighting my PC on fire and making my cat’s fur stick up all over, I’m just being transparent about what it’s like to be on the inside of software testing. If you think you’ve found a bug, we’ve found thousands. That’s what software testing is for. The upside of horrifying failures in testing is that they make life exciting.

Another aspect of being a tester is that I get to see things before anyone else does. I get to see what’s in the next version of ListPro, for example. As a tester, I know a lot, but as a support person, I have to ‘know’ only some things. This puts me in the odd support position of taking a request for a Feature That Will Make Your Kitten Cute and Fluffy even though I know it will be in the next version. Or worse, I get to take a request for a feature that won’t be in the next version, but I still can’t say anything. We’ve had features removed right before release for various reasons, and it’s no fun finding out that the super cool feature you always dreamed of (and that a person told you would be in the next version) is nowhere to be seen.

Testing is also more than the actual tests – there’s maintenance of the test cases that we re-use, all kinds of upkeep of bug information in our bug tracking software, research into new ways to test, and keeping an eye on customer support issues for possible bugs.

In fact, one of the things I like about doing both technical support and testing is that it removes the intermediary between a user with a problem and the person in charge of writing it up as a bug: if you tell me about a bug, I’ll try it out, look it up in our bug tracking system, and enter it if it’s not there. I know there’s a problem because I’ve seen it myself. I field user requests and feedback, so it’s always fresh in my mind when I’m trying out some new or changed feature to see how it works.

Hopefully, this gives more of an idea as to what it’s like to do software testing for a PDA software company. If anyone has any specific requests for things you’d like you know about, just leave a comment and we’ll see what the blog post fairy brings!