What different types of requirements have you used?

🙋 Questions
, , , ,
1

Thinking back throughout your career, what are some of the types of requirements you’ve used to support your testing efforts?

What development methodologies typically supported those types of requirements? How did the requirement help and hinder?

What advice would you give to someone new to testing when it comes to the world of requirements?

2 Likes
2

I prefer to call them oracles rather than requirements because an oracle can be anything that helps us assess the behaviours we observe. Some oracles are heuristics, so they may not always be right. On the other hand, documented requirements are always right, by definition, at least until you prove them to be wrong.

Documented requirements are always incomplete - they cannot be otherwise for a non-trivial system - so you need other oracles if you’re going to do good testing. And compliance with some oracles can be mandatory even if they are not included in the requirements.

In my functional testing training course I list the following oracles although I’m sure there are others:

  • Design documentation (specifications, data dictionaries, user journey flows, information architecture diagrams, logical flow charts, page lists, site maps, wireframes, creative designs etc.)
  • Help files, FAQ pages and on-screen instructions
  • Error messages, other status messages and comments in the source code
  • Self-consistency
  • The client’s related websites or products and those of their competitors
  • Previous versions of the website or product
  • Relevant legislation or regulatory bodies
  • Industry standards and specifications
  • Offline collateral (packaging, TV adverts, direct mail etc)
  • Reasonable user expectation

My favourite one ever was when I was working for the design agency who were designing a competition microsite for Tropicana orange juice. The day after I started testing, a one-page flyer dropped through my letterbox, promoting the competition and giving advance notice of dates, prizes etc. This immediately became a vital oracle for my testing and I found several important factual differences between the flyer and the website.

My advice to someone new would include:

  • Don’t feel constrained by the requirements you are given. There are many other oracles you can and probably should use.
  • Ask for any requirements that would be useful if they were not given to you.
  • Push back against anyone who says you can only raise bugs against documented requirements. Sadly, there are a lot of idiots like that.
  • Be aware that the documented requirements can be wrong, incomplete or contradictory, so be ready to raise bugs or queries against the requirements as well as the product. One of the paradoxes we face is that the more complete we try to make our requirements, the greater the risk of internal inconsistency and other errors. Agile development has gone the other way, with documented requirements so vague that almost anything can meet them.
  • The documented requirements are only a subset of the actual requirements, but it is impossible to capture the actual requirements for a non-trivial system, particularly if it has a user interface. There is an ancient Chinese saying; “The Tao that can be told is not the eternal (or true) Tao”. It’s the same for requirements.
6 Likes