This afternoon, my wife (who is a Dentist) was looking for information on the BDA (British Dental Association) website (www.bda.org) . She called me over when she realised that somebody working on that site didn’t seem to know their own domain name. One of the links to previous articles sent users to www.bda.org.uk (The British Deaf Association).
Doing the responsible thing, she laughed about the problem and sent a bug report (in the form of an email) to the BDA. They’ve promised to fix the problem, so no harm done (apart from some slight reputational damage).
This brings one thing to mind for me….
If you want to avoid this kind of embarrassing incident, you should employ “real testers” to find these sorts of bugs before your customers do.
I’m a member of a LinkedIn group called “Performance Testing“. This morning a member of the group from BlazeMeter posted a link to their blog article about how much detail to put into a performance test report.
Historically I’ve always put large amounts of detail into performance test reports, but over the last 12 months or so I’ve started to reduce the amount of content. This allows me to produce what the customer generally wants in a shorter time frame.
In most performance tests customers tend to want to know the answer to one question: Will my application perform well under expected user load?
This can generally be answered with “yes” or “no”, although occasionally the answer is “maybe”. (I tend to use traffic lights to show this at a high level.)
Often much more information than this is simply wasting time. In the last year or so I’ve started to produce reports in Powerpoint that can be easily referred to in conference calls or webinars, be presented to clients at their site and can be re-used internally by my client’s project managers when they want to pass on information to their own internal customers.
I have found that by including less high-level detail and including embedded spreadsheets, charts or other documents allowing technical readers to “drill down” to the detail; I can keep all the potential readers of my reports happy.
I’ve attached a PDF “mock up” of a performance test report based on a test that I ran for a client earlier this year. I’d be interested to hear any comments from other testers about what works for them.
