Prologue – Testing Application(s) from Scratch
I’ve been watching James Bach and Michael Bolton’s blog threads on their testing of IMVU. They have uncovered some things I find very interesting. Most of the items pointed out in IMVUs software turned out to be not important by IMVU’s standards and their impression of what end users want (and I got the impression that it wasn’t important to IMVU as a business either).
One thing I would like to see James and Michael blog about is how they could provide information to IMVU that was useful and important to them. What is that IMVU actually cares about in regards to its software? How does one go about discovering this information?
I decided I could demonstrate my process for discovering this type of information. I’ve been heavily influenced by James and Michael throughout my career and this seems like a great way to showcase those learnings applied to products most people can access.
What I will be posting over the next few days is my interpretation of the heuristic test strategy model and the principles of Rapid Software Testing applied to two applications I have been exploring. The first one is called TinEye from Idee and the second one is a product called Rypple
I’m still forming notes – so stay tuned for my findings.
P.S – Thanks to those who wrote to give me a kick in the butt to remind me to write
March 11th, 2009 at 5:04 AM
Whether or not the issues we found mattered to IMVU is beside the point. If you drive a car with a blindfold on, and you run over a trash can, you can’t expect to convince a police officer that you were in fact driving safely because you don’t personally mind knocking over a few trash cans. From a public safety point of view, that can might have been a child.
We were making a point about negligence, that’s all.
As for finding information relevant to IMVU, what we did was a reasonable first step toward doing that. A next step would be to interview IMVU and see what they thought of what we found.