No-one is qualified to test software. No-one.
The users know what they do from day to day and so can test in that way. This might spot common mistakes but will miss most unusual situations, like long rounding errors, etc.
A scientist or mathematician can test based on statistical models designed for defect seeding, error distribution, etc. But this will miss textual errors.
So-called testing experts can produce reams of test plans, but will miss many, many possible errors (for example, even a simple 4-step switch, a very common programming tool, will require 16 individual test cases, which in themselves can contain errors).
Automated systems can test with stress testing, etc. But will miss 'similar expression duplication' errors, be stumped by connection errors and often just don't work correctly with the given development/ deployment software.
So how should you test? By not allowing the errors to be produced in the first place. Our requirements development, peer review and staged delivery model allow for vast amounts of defects to be caught.
But what if you've had a system developed by someone else? In that case, we will start by understanding your business and documenting it. No-one can test a system without having something to test against. We have vast experience in distilling a client's business processes into a concise post-delivery requirements document. Then we will use the correct combination of strategies to test your system and ultimately produce a plan to fix the errors.
Unfortunately, we have seen many defect-ridden systems. Unfortunately for those clients, that is.
But for you, this is good news.
We have been called in to fix literally hundreds of defects in many systems and so have built up a huge working knowledge of the kinds of mistakes found in poor quality software.
If you are in this bad position contact us now for help.