Types of software testing.
Continuing on from our previous article, once the terms of reference are identified then within those parameters there are different approaches:
Cleanroom:
Cleanroom is a term borrowed from the scientific arena and refers to sticking to a rigid structured regime where you try to get it right the first time. Kind of testing as you go along. That means more effort is put at the front end which in theory saves time at the nd as you need less time to review.
Dynamic/Static:
Static testing is reviewing the source code while dynamic testing is running each step of the routine and fixing the bugs as they become apparent. Static testing can be done at any stage during the build process and is simply a read through of the code against expected documentation and visually getting it right. A form proofreading done for a newspaper.
Dynamic is done when the programming and the program is loaded on to an environment and put through its paces. This is best form of testing as you can see it in action and compare results with expected benchmarks. It is also useful as the actual users can appreciate how the design is supposed to work and guide programmers into fault finding as they are the ones who will be operating the devices. A form of test driving if you like.
Manual/Automatic:
There are some software tools that can automatically analyse a software for vulnerabilities. Others would need human eyes and a judgement call to best be served.
Fuzz testing:
Fuzzing is also a kind of testing. Indeed, it is a method in trying to get the program to crash or hang (be non-responsive). This is done by feeding the software with random, malformed or errant inputs to determine the systems tolerance level. These sorts of tests determine whether the software is susceptible to buffer overflow, XSS cross site patching or other denial of service issues. The purpose is not necessarily to test for expected outputs as they should already be known. Its what more “what else can it do” scenario. Code may generate an entirely different result given different data. Some of the results maybe desirable. Others not.
The different ways that this can be deployed include “mutation” or dumb fuzzing where the input is totally random. This could include “bit flipping” (reversing the code) or appending string to an existing code. The other is “generational” which has a formal protocol against the code and is built in blocks so that each stage of the code cycle can be tested. Generational fuzzing takes more time to set up but is more directed to an outcome so may avail more information than simply mutation which is flicking paint at the wall.
Patch testing:
Is done when a bug is discovered, usually after release, and a fix is created then distributed to all users. Windows updates would include patches as issues arise from client feedback. Sometimes patches can have unintended side effects, so client IT departments sometimes do further tests before deploying it on their environments to make doubly sure.
Software testing to minimise the attack surface.
The point is to limit the potential for an attacker or a circumstance that could compromise either the program, or the data it contains.
This is called the minimising the attack surface. You may never be able to foresee all eventualities, or highlight every bug, but you may be able to reduce the threat to an acceptable level.
Next in the series the planning stage. Se our related articles on Privacy by design.
