A Review of Error Messages

What Does a Good Error Message Look Like?
A well-constructed error message

should identify the program that is posting the error message
should alert the customer to the specific problem
should provide some specific indication as to how the problem may be solved
should suggest where the customer may obtain further help
should provide extra information to the person who is helping the customer
should not suggest an action that will fail to solve the problem and thus waste the customer’s time
should not contain information that is unhelpful, redundant, incomplete, or inaccurate
should provide an identifying code to distinguish it from other, similar messages


Want to read more about error messages...visit
http://www.developsense.com/essays/AReviewOfErrorMessages.html

Thanks to MICHAEL

No User Would Ever Do That

"No user would ever do that!"
"No user would ever try that!"
"No user would ever need that feature!"
"That's a cool idea, but no user would ever want it."

When developers say, "No user would ever do that," what they really mean is "No user that I've thought of, and that I like, would do that on purpose. In the Rapid Software Testing course, James and I have been encouraging testers to probe that statement for users that the developer didn't think of, for users that the developer doesn't like (like hackers or inexperienced users), or for things that legitimate, likable users might do by accident.

It recently occurred to me, though, that developers often say this after a tester has done something that has surprised the developer. "No user would ever do that!" "Well, I'm a user, and I just did it." "Yeah, but... you're not a real user."

One implication from this exchange is that testers aren't real users. Another is that testers' questions, actions, requirements, needs, and tactics don't matter. Fair enough--but let's keep that idea in mind, and maybe revisit it, when we hear another common software development question: "Why did it take you so long to find that bug?"


Posted by MICHAEL in his BLOG....Thanks to him

Ten Commandments of Software Testing

Testing is harder than living. There are 15:

1.Stay alert
2.Run the tests as written
3.Keep an activity log
4.Document any problems encountered
5.Re-run the tests as they should have been written
6.Understand the system.
7.Understand the people.
8.Understand the tests.
9.Understand the requirement.
10.Understand the dependencies
11.Hope for the best
12.Prepare for the worst
13.Expect the unexpected.
14.Don't fake any results.
15.Agitate for improvement


Thanks to David Smiles

Tips on Writing Bug ReportsHow to Write a Bug Report

1. Be very specific when describing the bug. Don’t let there be any room
for interpretation. More concise means less ambiguous, so less clarification
will be needed later on.

2. Calling windows by their correct names (by the name displayed on the
title bar) will eliminate some ambiguity.

3. Don’t be repetitive. Don’t repeat yourself. Also, don’t say things
twice or three times.

4. Try to limit the number of steps to recreate the problem. A bug that is
written with 7 or more steps can usually become hard to read. It is usually
possible to shorten that list.

5. Start describing with where the bug begins, not before. For example,
you don't have to describe how to load and launch the application if the
application crashes on exit.

6. Proofreading the bug report is very important. Send it through a spell
checker before submitting it.

6. Make sure that all step numbers are sequenced. (No missing step numbers
and no duplicates.)

8. Please make sure that you use sentences. This is a sentence. This not
sentence.

9. Don’t use a condescending or negative tone in your bug reports. Don’t
say things like "It's still broken", or “It is completely wrong”.

10. Don’t use vague terms like “It doesn’t work” or “not working properly”

11. If there is an error message involved, be sure to include the exact wording
of the text in the bug report. If there is a GPF (General Protection Fault) be
sure to include the name of the module and address of the crash.

12. Once the text of the report is entered, you don’t know whose eyes will see
it. You might think that it will go to your manager and the developer and
that’s it, but it could show up in other documents that you are not aware of,
such as reports to senior management or clients, to the company intranet, to
future test scripts or test plans. The point is that the bug report is your
work product, and you should take pride in your work.

Thanks to Bernie Berger

Xtreem Programming or Xtreem Testing

At STAREast 2007, James Bach told a story of a project he once worked on. The project’s methodology was somewhat traditional, in the sense that developers wrote code and testers then performed inspective testing of the application. James found numerous bugs, reporting them back. This seemed to cause the programmer some frustration. James told of the programmer complaining… “why don’t you just tell me what tests you’re going to do and I’ll make sure that the code passes them before I give it to you?”

I liked the story… I now use it to explain something to the teams I work with.

After telling the story, I ask “What if we could tell the developer what tests we’re going to do in advance”?

This is exactly the opportunity presented in the development element of extreme programming where implementation is driven by Acceptance Tests. The key difference is that the process of ‘telling the programmer what tests the code needs to pass’ is a collaborative activity. The Acceptance Tests are arrived at in collaboration between tester, programmer and the customer.

This way, when we get the code, we know that all ‘reasonable’ tests that we can think of are accounted for in advance and (ideally) automated.

Because we are human and time is limited, there will always be tests that we simply can’t be expected to think of in advance. This is where Exploratory Testing comes in handy. By interacting with the application we realise what previously unaccounted for behaviours have been enabled by our development efforts.

Sometimes the outcome of these behaviours is highly undesirable… i.e. bugs. I simply think of these bugs as ‘gaps in our collective thinking’… gaps that we identify as additional tests that reveal a new User Story - that we implement soon after in a subsequent iteration. If it is urgent enough, ‘the team’ (programmers, testers etc) and ‘the customer’ may decide to implement it immediately, instead of work we’ve already planned in the current iteration. With short 1-2 week iterations, it’s gotta be pretty darn urgent before that happens.

An wonderful article on Manual and Automation Testing

Thoughts on the Coexistence of Full Test Automation and Manual Testing

Published: April 3, 2007

by Colin Armitage

http://www.itjungle.com/fhs/fhs040307-story03.html

New kind of web testin - Web Service Testing

Dear Friends,

This is the very latest thing in Web Testing....
Web Service Testing. To do this you r inneed of very good
web service knowledge and some good tool...here is an rare
tool of a kind...

"http://www.stylusstudio.com/ws_tester.html"

Surfe and Enjoy

- jerry

Web Page Stress test using Microsoft WAS

Hi Friends,

Here is the link to learn, do web (stress) test using
Microsoft's Web Applicaiton Stress....

"http://www.west-wind.com/presentations/webstress/webstress.htm"

Thanks to west-wind.

Enjoy and Explore...

- jerry

Basic Guidelines and Checklist for Website Testing

Hi Friends.
Here is an intresting PPT for a good web testing...

http://www.authorstream.com/presentation.aspx?pun=pawan-357-basic-guidelines-and-checklist-for-website-testing-PowerPoint

Enjoy and Learn