As the name suggests, we want to know how we can analyze a software before releasing it and find as many issues with it as possible. Basically we want to avoid another Ariane 5 disaster. But this was an unintended issue, issues in software can also be exploited by hackers and such.
Software or Program analysis can be broadly classified into 3 types –
- Dynamic [ execution-time ] – Purify [ Array bounds checking ], Valgrind [ Memory leak detection ], Eraser [ Race conditions ], Daikon [ Find invariants ] etc.
- Static [ before execution-time ] – Lint, FindBugs, Coverity [ Suspicious Error Patterns ], SLAM [ API usage correctness ], FB Infer [ Memory Leak ], ESC/Java [ Invariants in Java ] etc.
- Hybrid [ can you guess? ]
FYI – Static Analysis can be performed on the Source Code or the Binary Code. Coverity claims that Source Code analysis is a better way to perform SA because we can find more issues, and rightly so because you are inspecting the complete literature and not a binary version that can be modified by the compiler. Dynamic Analysis can be only performed on the Binary for obvious reasons and there are 2 ways we can normally do it. Analyzing the runtime using Instrumentation or Path-Exploration using Fuzzing…we will discuss all this!!
“We have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing” – Bill Gates
Implementation is the ‘code’ of a given feature or requirement, Specification is writing test cases to see if inputs generate the expected outputs. Why should Development and Testing be done by different engineers? Because, Developers write the Implementation and Testers write the Specification. If both are written by the same engineer, chances are that the invalid implementation might be tested against invalid output which might validate the test case. Basically if your idea about the feature/requirement is wrong, you will write a wrong implementation and a consistently wrong test specification. So it is better if both these are done by separate resources so the chances of this is reduced.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it” – Brian Kernighan
Computer Science 101 