🗣️ Communication

When writing tests, acceptance criteria, requirements, etc, it is very important to communicate as clearly as possible with your audience (Stakeholders, Designers, Developers, other QA Analysts).

Therefore using clear, directional and unambiguous verbiage is an absolute necessity.

The Internet Engineering Task Force considered this issue and came up with Best Current Practices to describe requirements of a specification. At By the Pixel in QA, we use the word "Should" very liberally to orient the team to the desired requirement.

  • SHOULD
    • A requirement of the specification / Acceptance Criteria
  • SHOULD NOT
    • A prohibition of the specification / Acceptance Criteria

✅ Good Example

  • "The dropdown should have a search field"
    • "The search field should validate using fuzzy search"
      • "Fuzzy search validation should present a list of possible results as each character is typed."
  • 👍 The example above makes it clear what is expected in these requirements.

🛑 Bad Example

  • "The button turns grey with onHover event and red with onClick event.
    • "After that the page takes you back to the previous page."
      • "Good job though, but try to do better next time."
  • 👎 It is very difficult to tell in this example what is expected.
    • ❓ Even with prior-knowledge of past requirements, did the stakeholders change their minds?
    • ❓ Is it good that the button turns grey? Is that supposed to happen or not? When clicked should it turn green or is turning green something it was not supposed to do?
    • 🤯 Does "next time" mean "after this passing test" or does "next time" mean the next time the developer tries to fix (did it fail?) the same functionality we are currently testing???
Table of Contents