Archive

Archive for July, 2008

The triangle test

July 24, 2008 Leave a comment

The Triangle Test is considered as a classic exercise for devising test cases. This was devised by Glenford Myers whose name should be vaguely familiar to the testers. His name pops up at least once in the tester training material, but he is more known for authoring “The Art of Software Testing.”

Anyway, in this exercise, you are supposed to test a very simple program.

The program reads three integer values from an input dialog. The three values represent the lengths of the sides of a triangle. The program displays a message that states whether the triangle is scalene (no equal sides), isosceles (two equal sides), or equilateral (three equal sides).

So try out listing your test cases. Give it about 30 minutes to an hour.

Read more…

Article: How to report bugs effectively

July 16, 2008 Leave a comment

“… When you report a bug, you are doing so because you want the bug fixed. There is no point in swearing at the programmer or being deliberately unhelpful: it may be their fault and your problem, and you might be right to be angry with them, but the bug will get fixed faster if you help them by supplying all the information they need…”  Read more… How to Report Bugs Effectively.

You can also provide some references to supplement your report. For instance, you can take screenshots using a tool like Gadwin Printscreen. You can also capture the bugs together with the steps to replicate them on video through a tool like CamStudio.

Acknowledgements: Thanks to Roy for sharing the file.

Categories: reads Tags:

5Es of usability

July 14, 2008 Leave a comment

I recently had to revise an existing PowerPoint file on usability for a demo, and I’d like to share some of the key points here. I’d place the references in i:\ but at the moment it’s either full or write-protected. Anyway, the presentation describes 5 qualities — the 5Es — of a usable product:  Effective, Efficient, Engaging, Error tolerant, and Easy to Learn.

Effective. “Capable of producing an effective result.” This addresses whether the product is useful and helps users achieve goals accurately. If this criterion fails, this would definitely frustrate users more than anything else.

Possible design approaches (as listed in the PowerPoint file):
- provide feedback on all critical actions
- eliminate opportunities for error
- provide sufficient information for user decisions

Efficient. “Being effective without wasting time or effort or expense.” This refers to the speed (with accuracy) with which work can be done using the product. Aside from providing a streamlined work flow, we need to avoid things that can interrupt the users’ work or that could slow them down.

Possible design approaches:
- design navigation for ideal and alternate work flows
- provide shortcuts
- use interaction styles and design widgets that support speed
- minimize extraneous elements on the screen

Engaging. “Attracting or delighting.” This concerns how pleasant, satisfying, or interesting an interface is to use. This means your interface can either encourage the use of the system OR can be a turn-off that makes your system painful to use.

Possible design approaches:
- use clear language and appropriate terminology
- set a helpful tone, with a level of conversation suitable for the users
- structure functions to match users’ tasks

Error Tolerant. This involves how well the product prevents errors and helps users recover from any errors that do occur. No one is perfect so making errors cannot be helped. E.g., you select the wrong option, or click the wrong link, or get into the wrong elevator. If the user makes a mistake, the system must be able to help lead the user back to the correct track. Otherwise, this could lead to a lot of support calls for data amendment.

Possible design approaches:
- transform “errors” into alternate paths
- use controls that aid in accurate selection
- be sure actions are easily reversible

Easy to Learn. This concerns how well the product supports both initial orientation and deeper learning. If you are using a product for the first time, it should be easy enough to figure out how to use it. And if you will only be using it after long intervals, it should not take too much effort to relearn how to use it.

Possible Design Approaches:
- make the interface helpful with minimalist prompts and instructions provided where they are needed
- create “guided” interfaces for difficult or infrequent tasks

Main reference: “Balancing the 5Es: Usability”, Cutter IT Journal, Whitney Quesenbery, 2004

Categories: 2 cents Tags:

Discontinuous selection in firefox 3

July 10, 2008 Leave a comment

This is pretty nifty. Using Firefox 3, you can select separate blocks of text from the page (ergo discontinuous selection). First, select some text like you normally do. Then, press the CTRL key, and make another text selection on the page.

Another thing to try out:  Type “about:robots” in Firefox 3′s address bar.

Categories: tools Tags: ,

WordWeb 5.5

July 7, 2008 Leave a comment

I just found out yesterday that WordWeb 5.5 is already available. I haven’t checked what’s new with it though. I just noticed that they have fixed a non-critical, ui bug that’s in the 5.0 version (screen capture shown below).

Hear pronounciation (sic)

Hear pronounciation (sic)

Categories: tools Tags: , ,

SNL and user requirements

July 4, 2008 Leave a comment

I came across a certain blog post while I was tag surfing, and I just want to share it here (unedited) just in case the original post gets lost or something. It offers a comic example of NOT understanding requirements.

Testing Outside Software: SNL

A lot of times I notice things in other industries, mostly entertainment, that can reflect or articulate some testing practices it’s easy to forget.

For example, the other night I saw a Saturday Night Live skit that takes place in the safety center of a nuclear power plant (think Homer Simpson). Before the supervisor leaves, he gives the instructions “Remember, the most important thing is that you can never add too much water.”

The remainder of the skit goes on to have the safety workers debate over what exactly this means:

  • It’s safe to add as much water as you want, so ‘you can never add too much water’
  • The reactor will explode if you add water, and that’s why ‘you can never add too much water’
  • There’s not enough water in the world to make a difference, so since it’s impossible, ‘you can never add too much water’, etc.

I thought this was interesting take on not understanding requirements, especially with a nuclear reactor on the line. With testing, it’s easy to generalize a bug as anything that violates the agreed upon requirements. This shows us that just because we have the requirements given to us or written down somewhere, it doesn’t mean we understand them. And without understanding the requirements, you can’t understand what violates them; before you know it the test plan is thrown off completely.

Subtle tease

July 3, 2008 Leave a comment

Can you find what is odd in this post?

Categories: exercise Tags: ,
Follow

Get every new post delivered to your Inbox.