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 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?


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!

Its all about the detail

Leave a comment

Spotted it yet? Go back to the beginning and take a second. Find the mistake.

The use of an apostrophe within “it’s” and “its” is a very common mistake but also very easy to miss. The rule is straightforward; use the apostrophe for a contraction (it is), and lose it if it’s possessive (belonging to it). This post isn’t about a grammar lesson though, but rather about attending to the details.

A large focus within testing is on functionality, or trying to break the application. It is my belief that we should also spend some time looking at the fine detail; field labels, ‘About’ paragraphs, instructions etc. There is often considerable pressure to focus on the larger issues and while I wouldn’t disagree with that, I caution against forgetting the detail by doing so.

From our point of view quite literally every ‘i’ should be dotted and every ‘t’ should be crossed. An important point about context here though is that defects found should then be prioritised accordingly. If this is an external-facing website, then typos and poor grammar could be harmful to the brand; whereas if this is an application for dealing with employees’ timecards, then a typo is going to have minimal impact unless it materially changes the perception of what the user is expected to do. That doesn’t make it any less valid a defect to raise, but does determine how hard you need to push to ensure it’s fixed.

In short, look for any errors in the detail and raise them all. Worry about the prioritisation, or whether the defect really needs to be addressed, later – ultimately it’s a business decision, not a test one. Any change from what was specified is a valid error, and it’s a tester’s job to raise them.