When choosing a software developer to build your latest project one of the most telling questions you can ask your supplier is 'How do you test your software'? This should elicit a considered and reasonable argument from quality provider, whereas the hacker or fly by nighter will quickly resort to a lot of evasive mumblings.
So what do we do at Source Shaper? Being the consummate professionals we are I can outline the 3 techniques we apply to every system we ship.
The first, and in our opinion the indispensable method, is automated integration testing. This is the creation of test software that automates the use of the customer's system from the outside (or as far outside as possible) and verifies its behaviour against a set of expectations. In other words, it operates the system in the same way that we expect the customer to and assures us that it works. These integrations tests can be executed every time the software is deployed, so we always know it works.
Next up is unit testing, also know as Test Driven Development (TDD). With this technique developers will create automated tests around individual units of code. Again these test can be run every time the code is deployed to avoid any regressions. This is a fantastic technique to avoid bugs, especially in complicated sections of code and around algorithms. The disadvantage is that there is no guarantee that the overall system behaves correctly as a whole, which is why we need integration tests as well.
Our third and final line of defence against the embarrassment of shipping defective code to a customer is User Testing. Unlike the first 2 methods user testing is not completed by the developer but is conducted by a dedicated professional. Here the tester will write a Test Plan based on the Requirements Document, they will then manually verify that the finished software works as expected. This method is always necessary as it is the only way the verify that 1. the developer has built what they were supposed to, and 2. that the system works in ways the developer did not think about when they wrote the code. Any errors found at this stage will have integrations tests written around them to ensure they are fixed and don't happen again.
So that is it, there are other ways to do it, but we find the above approach allows us to consistently deliver quality code to our customers.