Is E-mail a defect?

Leave a comment

Does anyone – other than Microsoft – still use ‘e-mail’, with the hyphen in? I know that historically email started out as a contraction of electronic mail, complete with a hyphen, but I think we’re well past the point of email becoming mainstream.

Here are some examples:

Going to googlefight.com shows email as the clear winner

Googling for ‘Apple email’, ‘Google email’ or ‘Yahoo email’ (or ‘e-mail’), the top results for each all show email without a hyphen.

Googling for ‘Microsoft email’ is the only one where the results include ‘e-mail’ – although the results themselves are inconsistent, with some instances of ‘email’ also present.

From this, it seems that the only thing keeping ‘e-mail’ as high in the rankings as it is, is that Outlook uses it, and Outlook is the most popular enterprise solution for e-mail/email. Given Microsoft are themselves inconsistent in their use, then the validity of Outlook’s usage of the word is called into question. Given all the other major tech players seem to use ‘email’, then surely this must now be the commonly accepted term?

What are your thoughts – has email supplanted e-mail yet? If not, is it on course to do so, and by when? What is the tipping point?

The reasoning behind this is to ask a simple question – if an app uses the term ‘e-mail’, is that a defect?

Advertisements

But I Didn’t Order Vanilla! A Rant…

Leave a comment

I’m fed up of being told that a bug or usability issue I’ve found is ‘vanilla functionality’.

Wherever I’ve worked, when this situation has cropped up, the only reason development has been done and testing is needed, is because we didn’t order vanilla!

For those not familiar with the jargon, the term vanilla refers to plain and unaltered, the ‘original’ state of the software before your particular flavour of enhancements and modifications are added.

An example would be some generic software that creates invoices. The first change you’d be likely to make would be to add your own company logo. The rest of the software would then be vanilla. Later on you might want to add a facility to specify a discount, say 5% to apply to resellers.

Now, say I’m testing this software. My focus is on the logo and the presence of the reseller discount when appropriate. I’m not a computer running an automated test though, and if I spot a typo on the terms and conditions, or that the VAT rate isn’t right, then I’m going to flag it up as a defect.

On one hand, I can understand and appreciate the developers’ response; this has nothing to do with the change and so they can’t be held responsible for it. On the other hand, we’re all trying to produce the best work we can, in a usually hyper-competitive environment, so just occasionally I’d like the response to be ‘OK, let me see what I can do’.

We know that the flavour needed to be customised, that our company wanted strawberry ice cream as vanilla didn’t quite cut it. But if, when we taste the results of the strawberry recipe, the flavour is too sharp, we shouldn’t be against the general principle of adding a little more sugar.

One Quadrillion dollars!

Leave a comment

It’s more than Dr Evil ever dared ask, but GRR Airport has no such qualms…

Over the weekend I noticed twitter was buzzing, and in particular I noticed a conversation between @testertested and @jamesmarcusbach in which they were discussing an ever increasing total for car parking. Intrigued, I asked for more info and ended up joining in with testing the boundaries of a car parking calculator for Gerald R Ford International Airport. Go try it for yourself – see what the highest value car parking charge you can get is. As a starter, I’ll tell you that the record is in the quadrillions of dollars (that’s a one with 15 zeroes on the end).

www.grr.org/ParkCalc.php

 I started off gently, getting the charges for 1/1/2000 to 1/1/2030, then going through each of the available types of parking to see which was the most expensive. My first assumption to be challenged was that valet parking would be the most expensive when it turned out that as costs increased, short-term parking was far more expensive and indeed continued to be so until the end.

I then ramped up the end date to 31/12/9999 and watched the figures climb, but they were still nowhere near the numbers I’d seen on twitter, so I carried on.

 My next thought was to set the start date to BC, or rather to enter in a negative value, so I reversed my ‘to’ value and entered in 1/1/-9999 and sure enough this worked, but I was still a way away from the numbers I’d seen achieved by others, so I persevered. This time, I tried adding more 9s to the year, and here was when I ran into my first validation error. Although the field did not restrict how many characters I could add, at a certain point the calculator said that my end date was before my start date. Now that I’d finally exceeded the limit I could fine-tune my numbers to find out what it was. I got to a stage with a certain number of 9s in the year field, and had a charge for that period BC to that period AD. I set the times to 00:00 to 23:59 and looked at my ‘score’ of over $1.8 quadrillion, and was reasonably happy. I tweeted the result – soon after I got the reply:

 “That is about a third of the record”

 A third??! That spurred me on. I quickly realised that I was being too kind to the application and not testing it as I normally would. If the application allowed negative values for the year, then why not the month and the day? Entering -31st of the -12th month improved my score further, and similarly I was able to add negatives in the time field. It then occurred to me that I was sticking to traditional day and month values needlessly, the application obviously wasn’t doing much validation as it was allowing negatives.

 I applied my ‘year’ value to my day and month, and this worked. I tried increasing it, but as with the year this caused a validation error. I then applied the same numbers to my time field, again with positive results and an increasing score. I was now getting closer, but still not close enough. It was then that I realised my second incorrect assumption. I’d assumed that the limitation on the day, month, year etc. was in the number of characters; however I found that I was able to increase the absolute number by one, successfully.

I continued increasing and realised that I could keep all of the 9s that I had, and then add a 7 at the front. Once I replaced all my numbers with this seemingly limiting value, then my score was much higher, at $4.985 quadrillion. The record is $5.124 quadrillion, so I was within 4%.

 At this point I’d used up my half hour, which was the limit that most people seemed to be using, so I stopped, reasonably content. Over the next couple of days I had a few more thoughts about it, and again realised that my biggest mistake was in being too kind to the application and playing by rules that it wasn’t necessarily following, e.g.

  • I was putting in a day, month and year – I hadn’t tried with more or less than three values.
  • I was putting in a time – the time may have had too many characters, but there was still a ‘:’ in the middle
  • I had restricted myself to numbers – which I wouldn’t have done if I was trying to break the app rather than achieving a high score, however it turned out that the letter ‘e’ is present in the parameters for the best score.

 Thanks to @jamesmarcusbach and @testertested for the inspiration and link, and for those of you that want to see the high score, here’s the link: http://bit.ly/faltVH

Getting Involved Early

Leave a comment

I recently read a blog here talking about the need to get testing involved earlier. I was particularly taken with this quote:

“Good test managers try to accentuate the advantages of early participation and working at the same time with development…”

Is this solely the preserve of the Test Manager, or can any tester accentuate these advantages – and just what are they anyway? As we seek to improve our craft we all need to think about what we’re doing, how we can do it better, and most importantly, what we need in order to achieve those aims. It may be that this needs to be escalated to the Test Manager, but often problems can be solved and improvements suggested much earlier on and without escalation.

Before we get onto the advantages, let me briefly outline what normally happens.

Testing is usually the final stage of the process before the users get their hands on the application, whether that is by going live, or by UAT. Ideally, testing and development should have proceeded so well that very few issues will be found (of course no application can ever be certified as bug free as complete testing is impossible)

As the final stage of the process, there are numerous associated issues.

First and foremost is that projects often have inflexible end-dates, and so as a project hits any delays, testing is the obvious candidate for being shortened – and if no phase is explicitly shortened, then testing is hit implicitly. That’s a well-discussed topic for another day though.

Second, is that testers are often late to the party. Documentation testing isn’t considered a part of the process, and the time devoted to gathering requirements, designing code followed by the actual development of that code is considered to be a lot of time for testers to be sat around ‘doing nothing’. The argument goes that testers can get involved later when all the documentation is finalised, or after development has started.

The issue with this is that most developers do not know how to test that requirements and design are accurate and complete, and that there’s no independent observer to cross-reference the two and ensure that the requirements are properly and fully covered by the design.

So, to try and mitigate against some of these issues, there is a concerted move to try and get the tester involved earlier. The benefits include:

a)      Testers by nature have an eye for detail. Getting them involved in reviewing requirement and design documentation is more likely to expose issues and get them addressed before they ever make it into code.

b)      If the testers are involved when the requirements are being written, then they’re likely to better understand them, leading to fewer questions later on, and better scripts written more quickly.

c)       By reviewing both the requirements documentation and the design documentation, testers are uniquely placed to ensure that the two line up, and that interpretations are consistent.

When presenting these points, draw on experience where possible too. I’ve written before about two developers next to each other coding a new ‘Priority’ field to be applied to two applications. One went for the values Low, Medium, High and Critical and the other went for 1, 2, 3 and 4. A lack of communication and reading each others’ work led to this error, but a tester working with them before the designs are committed to code, would have picked this up too.

Getting back to the original quote, these may well be points that a good Test Manager would make, but there’s no reason that any tester can’t suggest them initially. Remember that we’re not just trying to find bugs, but to contribute to the overall solution and increase the value that we add. So go on, think about what improvements you could make by being part of the project earlier on, then push for it to happen!

Ugly Babies

1 Comment

One of the earliest phrases I learnt in testing, and one of my favourites is that nobody likes being told that their baby is ugly. To put it another way, you’re going to spend a lot of your time as a tester criticising others’ work and you’re going to have to find a way to do that, that doesn’t just end up ticking them off.

There are two main areas where you’re going to come across this. The first is when you’re raising defects. I’ve blogged earlier about picking on every minute detail and raising defects for every ‘i’ not dotted, but it’s worth considering here that raising a hundred defects for typos and spelling mistakes isn’t going to win you any friends. These defects are going to show up on reports and are going to look bad, when the impact of them is probably minimal, and the time taken to fix them is likely to be minimal too.

I usually try and solve the problem by grouping these into one defect, or several defects grouped by page/section/functional area. This way you still get everything reported but you’re not repeatedly distracting the developer and project manager with what they see as minor issues.

Another technique (that can be combined with the above) is to do more than just raise the defect, by offering a suggestion on how to fix it. For spellings and typos it’s usually easy to supply the correct version as well. Be very careful here though not to be seen to be dictating a particular solution. Be clear that the solution is a potential one, or quote from the original specification to back up your claim.

Finally, ensure that you have a ‘Rejected’ option on your defect status list. We’re just as fallible as those that write the specifications and the code, and it’s to be expected that a proportion of the defects we raise will be invalid due to misunderstandings or not having access to all the information. As a counter to that, don’t be afraid to challenge a rejected defect, but accept that there will always be some.

Secondly is when reporting. You’re going to have graphs and charts that show failed tests and defects raised, and you’re going to have to comment on them. Choose your words carefully; assign blame to systems and applications rather than individuals and stick to the facts. Equally, emphasise the positives, and the efforts made to correct issues; this time ignore the systems and applications and focus on the individuals who got the defects fixed.

Have a separate section in your report for issues and recommendations. Identify the issues you came across, again avoiding assigning blame, and then provide suggestions on how those issues could be avoided in future. Crucially, always end on a positive note.

 The aim is to be seen as someone trying to contribute to the overall solution, not just someone who finds bugs.

Testing before the Test Phase

Leave a comment

I love documenting things – quite possibly a little too much if I’m honest. I’m not though, a fan of bureaucracy, of having to fill out endless forms and reams of unnecessary documentation. Now I know that sounds more than a bit contradictory, let me explain.

There are two positives that I like about documentation. First is that it allows me to pass information onto someone else, or multiple someones at the same time. It forces me to be clear, with no ‘um’s or ‘err’s and allows me the time to think through what I’m saying before having to say it. I usually find that just the process of writing down how I’m going to test an application or change, helps me to understand it better.

Second is that for documents as deliverables, once read they can be approved. An approval (should) indicate that the recipient has read and understood what you have written and that they either accept or agree with what you’ve said.

Earlier in my career I was introduced to these documents as something to ‘cover my back’, an insurance policy against things going wrong. If and when a bug escaped testing I could theoretically point to my Test Plan, or my reviewed Test Scripts and say that as everyone had read and approved what I was going to do, and no-one had pointed out the omission at the time, then I couldn’t be held at fault by those same people for the omission.

Nowadays I have more confidence in my work. Through experience I miss less (although there will always be bugs that slip through the net – no software application can ever be certified as completely bug free). Now I find that my documentation serves a slightly different purpose.

Technically it still works as an insurance policy, but I’m less worried about having to use it as such. Now I use my Test Plan and Scripts to ensure that other members of the team have interpreted the requirements and specifications of the application, in the same way that I have. The documentation is a test in itself, but a test that allows me to prevent some defects before they arise. This not only saves time and money but actually reduces bureaucracy as these defects which are not raised, no longer have to be tracked, resolved, retested and reported on.

As with everything else, documentation and approvals have to be treated in context. I find that for small changes requiring a day or two of testing, that a single A4 sheet can capture all the information needed, with detailed scripts attached as an Excel sheet if necessary. Larger projects have a Test Plan that is formally approved before Scripts are written (which are then usually approved verbally as part of a short meeting with the developer).

 As for who needs to give that approval, I follow the same guidelines as with processes in my earlier post. At the minimum you need an approval from the developer providing their deliverable (the code) to you, and one from the user, to whom you are eventually delivering a tested application to. That list might be expanded or slightly altered depending on the context, but it’s where I start.

Get the Process Right

Leave a comment

From the minute detail, up to the bigger picture.

Communication is key with any project, and knowing what each of the other team members is thinking and doing is the aim of that communication. To that end, agreeing on a common process helps to avoid misunderstandings and gives everyone a good idea of what should be happening and when.

 I’ve had experiences where two people sitting opposite each other have developed applications in completely incompatible ways due to a lack of communication. One coded his application to accept priority values of 1, 2, 3 and 4, while the other coded it to accept the values Low, Medium, High and Critical. Either would have worked, but they didn’t work together. If they’d spoken to each other more, or had it in their process to review what the other one was doing, then the problem could have been avoided, or at least spotted much earlier.

 Hopefully you’ve already got a high level process agreed for your team – if not, then think about creating one. Focus it on your own responsibilities, and then map out what you need to deliver, and what you need delivered to you from other people in order to get those done.

Most importantly, get those who deliver to you, and those who receive your deliverables, to agree to that process; only then can you be sure that it’s right. Resistance to the process will be expected to a degree, but it can also mean that the process needs to change. Remember the following:

a)      Encourage feedback, and develop your process accordingly.

b)      Don’t set it in stone; allow it to change as business procedures, roles and responsibilities do.

c)       Allow some flexibility. Projects rarely go completely according to plan, and your ability to react and adapt will determine how well the project copes when things go wrong.

d)      Remember to use the process once you’ve got it. Pin it on a wall or keep it on your desk. Don’t go to the effort of setting it up and then forgetting about it. Once people have agreed to deliver or receive, then hold them to it.

Again, keep all the above in context. Processes for a simple update to the news page of a website aren’t as critical as those that control the next major product launch.

 As you go on, you’ll find that there are many activities that benefit from having a documented process. The overall project is the obvious one; however further down you will have processes for the testing approach, and then the defect management process, the test reporting process etc. Having these defined and documented saves time that can be better spent on finding more defects!

Older Entries