The rhythm of software testing

Mainly, the moment when testing should stop is based on the situation if end criteria are met or the deadline is reached.

And sometimes you come into a situation were you want to give advice to continue testing; only there is too less information to support this. It is just a feeling of discontent and you don't have the time to prove it. Perhaps you have the idea that it doesn't sound right to continue going towards production. That sound can be explained by the rhythm you act in over the last days.

If the situation is such, that while new complex functionality is delivered and you only find minor issues and almost all test cases are executed you tending to say that the acceptance criteria are met. At least project management is happy as they only see those criteria are met and they trust you did the right thing because you did your job.

Only did is sound right? Imagine that a testing process is like a song. You have several couplets and refrains. The couplets are deliverance of new functionality and the refrains are compared as regression testing. What happens if in the last iteration new functionality is delivered that initially was planned for earlier deliverance? You have lesser time to play the song in the order you intended to. If you are looking closely you might notice that you are playing a couplet and refrain on the same time.

Just pick one song you love the best and figure out how that song would sound like if you sing a couplet and refrain the same time. I think it won't make you happy.
You even get distracted and missing some of your own notes. And perhaps that was happening during testing also, you didn't find any serious issues.

Don't we say mistakes are of human nature? Don't we sometimes not trust the developer to give us bug-free code?

Perhaps we can convince project management although the number of serious issues didn't raised, that based on the rhythm of the testing process we should get some time to investigate what the impact of this sound is on the environment. Let us get some time to make it sound right. And check if we did the right things. Check if we really did test as we intended to.

In certain situations it might become more urgent to review our test process and not rely only on measurable figures like number of open issues and executed test cases. You have to check if the advice you tending to give is reliable.