Systems testing
The simplest software process is "code and fix". This works on the smallest one-man projects, but as the system grows, bugs become harder to fix. A typical sign of such a system is a long test phase after the system is "feature complete". Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.
Testing needs to be planned from the start and built into the project plan. The ideal time to write your test plan is right after you've written the requirements; every requirement is a test of the systems acceptability.
Systems testing is a subject of it's own; too large for a single webpage, but here are some test methods used at OCC.
- White box testing: in this process the system is opened up for review. Engineers can inspect the code either statically ("on the page") or dynamically, as it runs. About the simplest form of white box testing is simply to take the code and ask the engineer to explain it.
- Black box testing: this is classic behavioural testing. You select inputs and check the outputs. You endeavour to craft inputs that will exercise the different situations the code needs to handle. Often it is also important to test how well a system copes with volume of input (scalability as well as correctness).
- Security was always an important part of testing, but with the arrival of web applications it became central. Now anyone can have a go at hacking the system. In this context security system testing is known as penetration testing.
The list goes on, the methods are numerous; test driven development, regression testing, verification and validation, acceptance testing, stress testing, standards compliance testing. At OCC we have our own testing team.
