testing for product teams - tests reconciliation for non-technicals

I get asked this question often and have noticed the same curiosity out of many non technical teams. It is one that comes up so often, very hard to not wave hands at but a key part of making sure product teams have shared understanding on how and why tests matter. Question: How can the tests pass and we still have issues with the software. Do you know that question, especially when tests are treated like highly important gate keepers, how is it that all these green checkmarks and we still have to call about a user every 5 minutes. (Hopefully that's not the case) It all starts with understanding what a software is. At its core, a piece of software is a set of rules joined together using many different words, potentially from different languages to achieve one or many end results. Just like any lexical structure, changing one character or word or statement…, could mean the difference in what message you are sending across or if at all any message. So to the non-technicals reading this, think of it as a very long book that needs to tell a story, you'd want to make sure no one randomly ripped a chapter off at any point or made a part in all CAPS unnecessarily. That's what tests are for, in such a delicate context. as software. So what are tests really? Now that the sprint is over, all the new features have been written, questions arise: Does the book contain all chapters we asked for? Does the book stick to its fundamental ideology? In a nutshell that's what tests start off aiming at. The existence of tests is to assert that every case and requirement that was defined through the cause of building a software, hold to the values defined, but certainly there would be cases that were not defined or ideologies the writers did not bother to elaborate on but that a reader might want to indulge in… You must forgive the amount of analogies I used in here. The Reconciliation The real question teams can look at from this is; how much are we defining as requirements. If the tests are confirming what we asked for is delivered, but yet we find other things wanting, then we need to ask more, how do we make sure we ask in full. There are many solutions for this, passing from Agile workflows principles to HR initiatives. At the core though, is willingness of the technical teams to incorporate testing in their workflows from point 0 to 100 and take time to practice and communicate quality assurance principles on the product. So the next time you find issues even after the tests tell you it has no missing pieces, I hope this gets you asking answering the right questions onwards. What do we want it to do. I hope you find this helpful, I write short pieces like this on the internet and try to keep it in a conversational format, so if you have any comments, I'm always happy to discuss. All the best to you.

Mar 7, 2025 - 11:07

testing for product teams - tests reconciliation for non-technicals

I get asked this question often and have noticed the same curiosity out of many non technical teams. It is one that comes up so often, very hard to not wave hands at but a key part of making sure product teams have shared understanding on how and why tests matter.

Question:
How can the tests pass and we still have issues with the software.

Do you know that question, especially when tests are treated like highly important gate keepers, how is it that all these green checkmarks and we still have to call about a user every 5 minutes. (Hopefully that's not the case)

It all starts with understanding what a software is.
At its core, a piece of software is a set of rules joined together using many different words, potentially from different languages to achieve one or many end results. Just like any lexical structure, changing one character or word or statement…, could mean the difference in what message you are sending across or if at all any message.

So to the non-technicals reading this, think of it as a very long book that needs to tell a story, you'd want to make sure no one randomly ripped a chapter off at any point or made a part in all CAPS unnecessarily. That's what tests are for, in such a delicate context. as software.

So what are tests really?
Now that the sprint is over, all the new features have been written, questions arise:

Does the book contain all chapters we asked for?
Does the book stick to its fundamental ideology?

In a nutshell that's what tests start off aiming at. The existence of tests is to assert that every case and requirement that was defined through the cause of building a software, hold to the values defined, but certainly there would be cases that were not defined or ideologies the writers did not bother to elaborate on but that a reader might want to indulge in…

You must forgive the amount of analogies I used in here.

The Reconciliation
The real question teams can look at from this is; how much are we defining as requirements. If the tests are confirming what we asked for is delivered, but yet we find other things wanting, then we need to ask more, how do we make sure we ask in full.

There are many solutions for this, passing from Agile workflows principles to HR initiatives. At the core though, is willingness of the technical teams to incorporate testing in their workflows from point 0 to 100 and take time to practice and communicate quality assurance principles on the product.

So the next time you find issues even after the tests tell you it has no missing pieces, I hope this gets you asking answering the right questions onwards. What do we want it to do.

I hope you find this helpful, I write short pieces like this on the internet and try to keep it in a conversational format, so if you have any comments, I'm always happy to discuss. All the best to you.