Other Sources Of Expected Results

Lecture 1 - A Bug or Not a Bug -> Quick Intro -> Three Conditions Of A Bug’s Existence -> The Gist Of Testing -> Spec, Spec, Spec -> Software Bugs And Spec Bugs -> Other Sources Of Expected Results -> Why We Call Them “Bugs”?

Now, let’s look at some other sources of expected results, in addition to the specs:

            – Life experience

            – Common sense

            – Communication

            – Standards

            – Statistics

            – Valuable opinion

            – Other sources


Whatever we learn browsing the Web, reading books, working, studying, communicating, etc. is accumulated into the precious container called “life experience.” Therefore, when there is no spec, we can dig up something from our life experience and give a reason why the expected result should be such and such.


 When there is no spec and the programmer enters text “Error” instead of an informative error message, you can file a bug against him or her, saying that error messages must give details to users about what was wrong and/or what should be done. Why? Because in your experience, it’s very confusing to see only “Error” and have no clue about what you did wrong.

 Of course, the programmer can say: “In my opinion, ‘Error’ is enough,” and here the argument begins…The best way to prevent the argument is to have a spec in the first place. Spec that would give clear, concrete instructions, so everyone knows exactly what should be expected.



This is one of our main allies, even if we have a spec.


 Let’s say you are testing a Web site that enables users to upload their digital photos. The spec says that a user can only upload one photo at a time. But what if our user has 200 photos? Will he or she be happy if we require him or her to go through the boring process of uploading 200 times? I don’t think so! What shall we do? Let’s write an email to product_managers@sharelane.com and ask them about the bulk upload of pictures. We can also file a bug report with this request. This type of bug is called a “Feature Request.”


Even the best spec in the world has room for elaboration. There are also plenty of situations when there is no spec at all. What to do in both cases? Communicate!!! Talk to your colleagues. Don’t be afraid to look dumb or to bother busy people. You, as a test engineer, ARE an important person, and you MUST get ALL the info you need.

Of course, you should always act in a discreet way, so if a person is truly overwhelmed with work, give him or her some time to get back to you.


Each job description for a tester position has a requirement for “excellent communication skills,” and this is absolutely a vital thing for a tester. I myself have a strong foreign accent, English is my second language, and I realize that I have to put forth extra effort to make myself clear.

 “Excellent communication skills” has two main components:

            a. How good you are with people

            b. How clearly you communicate

In order to excel in both ways, you have to stop worrying and just try to do your best. Communication is an essential part of our profession, and needed skills can be learned and mastered.


Here are a couple of examples for illustration.


The industry standard is that a user must receive an email confirming his or her registration at your Web site. So, you can reasonably expect that your Web site would follow this standard.


 Your company might have an internal standard that error messages must be in this format:

          Font “Times New Roman”

           Font Color “#FF0000” (color code for “red”)

           Font size “110%”

so each parameter above (“Times New Roman,” “#FF0000,” and “110%”) can serve as an expected result.


“Four seconds is the maximum length of time an average online shopper will wait for a Web page to load before potentially abandoning a retail site” (http://www.akamai.com). This data can be used for filing bugs about the performance of the Web site.

Always remember that your customer is just one click away from your competitor.


This can be the opinion of your boss.


There can be some other sources depending on your concrete project; e.g., if you test photo sharing Web site (like photobucket.com), you might need to read an article from the magazine for professional photographers. Next ->

Lecture 1 - A Bug or Not a Bug -> Quick Intro -> Three Conditions Of A Bug’s Existence -> The Gist Of Testing -> Spec, Spec, Spec -> Software Bugs And Spec Bugs -> Other Sources Of Expected Results -> Why We Call Them “Bugs”?