When Testing Changed My Mind
People often think software testing is about finding bugs.
Of course, bugs matter.
If the software crashes or produces the wrong result, that's something every developer expects to fix.
But over the years I've found that the most valuable testing reveals something quite different.
It reveals assumptions I didn't even know I had made.
During the final testing of SecurityNet, I discovered several examples of this.
None of them were programming errors.
The software was behaving exactly as I had designed it.
The problem was that the design itself needed another look.
One example involved ordinary file transfers.
If someone sent me a document called ABC.docx, SecurityNet decrypted it and saved it with that name.
That seemed perfectly reasonable.
Then, a few days later, the sender transmitted an updated version of the same document.
Again, called ABC.docx.
The software faithfully decrypted it.
And quietly overwrote the original.
Nothing had gone wrong.
The software had simply done exactly what I had told it to do.
The problem was that I hadn't thought about document history.
So I changed the design.
Instead of overwriting the earlier version, SecurityNet now renames the older document to include its original date before saving the new one.
The user can then decide which versions to keep.
Testing hadn't revealed a bug.
It had revealed a missing idea.
Another example was Group Chat.
Originally, ordinary chat messages could be sent to multiple people.
Technically, it worked.
During testing, however, I realised that what I had actually built wasn't Group Chat at all.
It was simply the same message sent to several independent conversations.
Again, the software behaved perfectly.
The design did not.
So I removed the feature and built something different.
The same thing happened with archived chat messages.
Recovering them required users to understand internal filenames and folder structures.
That might have been technically possible.
It wasn't something I wanted people to have to learn.
So that feature disappeared too.
None of these changes came from better programming.
They came from better understanding.
The software wasn't teaching me about code.
It was teaching me about people.
Perhaps that's the real purpose of testing.
Not simply to prove that software works.
But to discover whether it behaves the way people naturally expect it to.
Sometimes those are very different things.
One lesson from my banking career reinforced this for me.
At Kleinwort Hambros we were implementing Expected Credit Loss reporting.
Everyone agreed on the requirement.
The calculations were correct.
Then testing uncovered something nobody had considered.
When certain loans matured and rolled over, the core banking system issued a completely new contract number.
The calculation wasn't wrong.
Our assumption about identity was.
Once we recognised that, the solution became clear.
The requirement hadn't changed.
Our understanding of the problem had.
That lesson stayed with me while building SecurityNet.
I've learned not to become too attached to my first design.
If testing teaches me something new, I would rather improve the design than defend my original idea.
Perhaps good testing doesn't simply verify software.
Perhaps it teaches the engineer something they didn't know before.
To me, that's where some of the best design decisions come from.
