7

As per ISTQB - CTFL Typo errors/spelling mistakes are not bugs. My question is that, when there are typo errors in the software/application under test then how to address and get them resolved from the development team. Just only by discussion?

4
  • 9
    I agree with the current answers and don't have a better one. The ISTQB is wrong on this. They generally like to stay confined to "functionality" and we know quality is more than just about functionality. Also, typos cost a business money. Just Google search "costly typos!"
    – Lee Jensen
    Jan 22 at 19:12
  • 2
    Just to be clear, we're talking about a user-facing typo, not one in a location that the user does not care about (such as a CSS class or an API endpoint route)?
    – Flater
    Jan 24 at 0:36
  • What do they mean by a "typo"? Like any typo, including those that would cause a program to behave differently from expected (like flipping Yes and No), or do they limit it to typos that're more like subtle misspellings?
    – Nat
    Jan 24 at 14:50
  • Can you point to where they say that?
    – jcaron
    Jan 25 at 15:35

4 Answers 4

24

Well... ISTQB - CTFL is then wrong on this one.

We test to uncover risks that threat the value of the product (to someone who matters).

A bug is a characteristic of the product of the threats its value.

If you look to the Heuristic Test Strategy Model, you can see several Quality Criteria that can be affected negatively by typos and spelling mistakes.

enter image description here

Now, about "how to address and get them resolved from the development team", you may want to highlight how it affects the user: what makes the user feel, what type of mistakes the typo/error can lead the user to, how other products show superiority in this regard. Additionally, you may want to highlight how this typo/error may make testing hard, confusing, etc. In summary, you may want to improve your testing story.

enter image description here

2
  • 1
    Quick question - were the typos/mis-spellings/grammar errors in this answer on purpose based on the topic of the question?
    – user121330
    Jan 23 at 20:35
  • 1
    Surely all of usability is affected. When learning the system, they're more likely to learn a wrong conclusion if unnecessarily confused. Of course they may not even be working in (one of) their first language(s). As accessibility includes screen readers, typos will lead to a form of uncontrolled behaviour in those.
    – Chris H
    Jan 24 at 12:17
22

Like João Farias, I also think the the ISTQB is wrong on this.

Let's not use the term "bug". That's a colloquial term. Instead, let's use the more formal and well defined terms:

  • failure: an event in which a system or system component does not perform a required function within specified limits (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (INCOSE Systems Engineering Handbook, 4th ed.)
  • fault: manifestation of an error in software (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
  • error: discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.5)
  • defect: imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced (ISO/IEC 23531:2020, Systems and software engineering Capabilities of issue management tools, 3.1)

The term "bug" is usually taken to mean "fault". It's the visible result, whether it's poor performance or incorrect operations or something else, the fault or bug is what the user sees. In some cases, the fault may cause a failure. In most cases, I wouldn't expect a typo or spelling mistake in, for example, a user interface element to cause a failure, but I can see a few rare situations where it could.

I would very easily consider typos to be errors. There is a discrepency between the observed text and the true and correct spelling and grammar of the language. I would also consider it a defect. Although you may not have an explicit requirement that all text have correct spelling and grammar, I do think that's a safe implicit requirement, and a change to the system is necessary to resolve it.

When you talk about tracking and resolving "bugs" in a system, you are most likely really talking about resolving errors or defects that led to reported failures. You want to track the existence and resolution of defects and errors in a system. And since typos, spelling errors, and grammar errors are errors (or defects), I would track them and resolve them just like any other defect or error.

2
  • 1
    I've always liked the word defect: as well as chiming with your point, it lacks the overloaded connotations that "error", "failure" have to my ears Jan 25 at 7:11
  • @Robominister: I agree. It's easy to think of failure or error as functional or technical issues of the product itself. Defect doesn't seem to carry this connotation, and thus seems the perfect term to refer to tangential issues such as documentation, translation issues, etc... Jan 25 at 10:18
3

Two answers so far point out that spelling mistakes are bugs and that ISTQB is wrong. Well. They are (in my opinion) partly right ...

  • A spelling mistake in the source code only, like a configrure()-method, is not a bug unless the project requirements specified spell checking on the sources. It is, however, bad style. Is it the job of software testers to raise bugs over bad style, or should that be caught elsewhere?
  • A spelling mistake in places visible to admins or internal support staff, like a configruration error in the log, is not a bug when an the system under test is developed by the organization for internal use. It is probably a bug if the system is for an external customer.
  • A spelling mistake which invites the user to click the configrure-button is a bug even if the name of the button was not specified by the requirements, which it may well have been.

Background: My developing career was almost exclusively on software projects for single customers, who would then run the systems to be used by end users. As my first boss put it, decades ago: "You are too expensive to proof-read internal documents for typos if they do not distort the meaning."

2
  • 2
    If the configrure() method is called more than once, it's almost-certain to result in a bug, though, as subsequent programmers will not make the same spelling error.
    – Stef
    Jan 24 at 12:44
  • 2
    @Stef, in a merge request, I would reject such a method name. But a merge request is no bug report.
    – o.m.
    Jan 24 at 16:55
-1

I think that developer who is unable write without spelling mistakes in his own native language (english is not my native language) cannot reach level of a true expert developer. It is all related. In order to become an expert you have to read A LOT.

1
  • 1
    I would say developers need to be able to write error-free English, too. Plenty of documentation is English, and they need to be able to read that without misunderstandings (like the differences of may, must, and should in specs). If they reach that level, they can write error-free, too.
    – o.m.
    Jan 25 at 5:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.