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 ResultsLet’s assume that the error message wasn’t displayed. In this case, we have a classic case of a software bug; i.e., a bug born because of a mismatch between the actual behavior of the software and the expected behavior (which is usually specified in the spec).
If you paid a little bit of attention when you read item 2.1., you surely noticed (joke) that it wasn’t clear what kind of error message is expected to be displayed-i.e., the decision on the actual text of error message is up to the programmer, and he can write code that will produce:
– a NONinformative, irritating message: “Error“, leaving the user to wonder what he has done wrong and cultivating a feeling of guilt in him, OR
– an easy-to-understand message: “Oops, error on page. ZIP code should have 5 digits“.
Formally, the programmer will be right in both cases, because the specification doesn’t elaborate about the text of the error message.
BTW
In early days of start-up when software changes very often, there is no need to include precise text of error messages into the spec. The idea about error message will do. For example: “Error message should state that ZIP code should consist of 5 digits”.
Here we have a situation where the spec itself is buggy, because
– we reasonably expect that spec to give us details about the error message, and
– the actual spec doesn’t give us those details.
Let’s call this situation “spec bug.”
Brain positioning
Each found bug (both in software and in specs) must be filed into the bug tracking system. There should be no exceptions. Bug reporting is one of the most important parts of our profession.
We’ll have a separate lecture to talk about bug reporting and tracking.
Brain positioning
From the start, you must understand one very important thing: when you file a bug against someone, it doesn’t mean that you hate or disrespect that person. It simply means: “I have found mismatch between actual and expected. Please, fix the problem.”
If somebody takes a bug personally, you must have the respect and patience to explain to him that there is nothing personal here – this is just a part of your job. 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
