What types of unspoken assumptions have led to problems in software?

Hi all, I would love to hear about unspoken and incorrect assumptions baked into user stories or design (or even test plans, yikes) that led to problems down the road.

  • Have you ever seen this happen, and watched the fallout?
  • Did anyone on any of your teams ever catch a “broken” unspoken assumption before it could cause trouble?

This will bolster the content in MoT’s junior tester course, God willing.


I am currently working on a new version of a website that has a lot of promise. They understand their user groups decently, but are missing some data about them. They are assuming that they understand user needs and user journeys and pain points well enough, but they don’t graph anything out. User journeys are not figured out on paper, nor are work flows. People just talk it out, make a few notes, and hand things to the designer who is stuck using an outdated UI design. User stories/scenarios are not written down either…I think the designer takes notes but does not share them. Only a few requirements are written down.

This has caused me to miss some test cases and a few bugs got through to production that should not have. The more I work on the product the more I am learning about all the requirements from just playing with the software and understanding how the features work together. Thus, I am catching more things before it gets pushed to production.

I have caught a number of work flows issues, but most of the time they are being dismissed. More often than not that comes back to haunt management when trail users complain about the exact thing I was pointing out. I plain out said that the features are cool, but the UI design/information architecture does not allow the features to work together in smooth and beautiful work flows. That the planning stage of the SDLC needs more time and way more documentation so things are not missed such as use cases. But, management does not want to do this so the problems are not getting solved.

I need to mention that I am sometimes part of requirement discussions, but it is sometimes unclear what exactly the developer will code out since no one said this is the final decision. And sometimes dev changes things.


That sounds like a frustrating situation, and it’s a shame that management is not taking reasonable suggestions for improving the product. Unfortunately that’s the way it is at a lost of organizations these days, and we end users can see it. People can be very heedless.

However, you’re certainly doing your bit to make this not be so for the product you’re testing. We’re not responsible for the outcomes of decisions that are made by other people. However, I believe we ARE responsible for giving the kind of feedback you mention here.

Kudos to you and thank you for this detailed response; it will likely inform the upcoming junior tester curriculum (and you will be credited with this quote unless you tell us you don’t want that).


Thanks. It has been frustrating, but more sad than anything. To bad these kinds of things are common these days. Hopefully, only for now. I am learning to remove myself emotionally from the job now and repeating to myself that sometimes you need to let things fail. I am going job hunting for something better…half way because we are all horribly underpaid.

There is no need to give me credit. You can say that someone posted this response, but I ask that you keep my name out of it. Thanks.


@builder_of_things has one problem, but get this:
We have user stories written with detailed test cases in a separate document and yet we have a group of devs who, while working on a story, say “Yeah we built it a bit differently because “we” think it should be this way” :man_shrugging:t2:

Have you already gone through the books available? like:
Lessons Learned in Software Testing by Kaner, Bach, Pettichord

Almost any assumption can lead to problems in software.
One tester needs to be vigilant and consistently question them.

Hi Stefan, I’m asking this question for community input on specific cases.