Why (& how) do Static and Dynamic testing complement each other?
Take this requirement example for a calculator program -
Calculator should accurately do division of two numbers.
After static analysis (testing) you might say - requirements are incomplete as it does not clearly states that up to what decimal points calculation is to be done. How round off is to take place. What should happen in case of division by 0 scenarios etc etc
But only after dynamic testing you could say, if program actually -
Computes division till expected decimal points If round off operations works right If appropriate prompt is really displayed for division by zero scenarios.
Did you see how static and dynamic testing complemented each other in this scenario?
By and large I see both static and dynamic testing to work towards early defect detection in software life cycle.
Static testing is reviewing the program code without executing it. Its focus is mostly on the following:
- Code maintainability, ie making code more readable by humans;
- Finding out typos and other silly mistakes in code (like typos in variable names, off-by-one errors, etc);
- Reviewing algorithms used by programmer.
While static testing only is insufficient, it is a great technique to prevent bugs early in development cycle.
Static testing from the developers viewpoint is testing that is done on code without running the application or the code itself. Common ways to perform static testing on code is to run code analysis tools (Wikipedia list of commercial products) or security analysis tools.
In the wider testing context, static testing is any form of testing where the application is not used, and this takes the common form of requirements review.
The key benefit that static testing provides over dynamic testing is that the bugs that it uncovers are commonly much cheaper to fix, and it can be performed early in the SDLC before the application can actually be run.
Once the application has progressed far enough in the development cycle, static testing normally takes precedence.
I would also expect that projects where the testers are only engaged late, after development is well underway, static testing will probably not even be considered.
Dynamic testing is usually related to tools testing some common dynamic aspects of the software, for example- detect memory leaks, thread deadlocks, monitor resources usage etc. Basically those tools get a build tree (source files, makefiles) and work on them independently- no one needs to define the tests themselves.
Static and dynamic testing complement each other since they both test objective, common aspects of software irrelevant of your implementation, but each uses a different approach.
There is also another description of Dynamic testing, Dynamic Flow Analysis. This is a hybrid of static analysis (looking for patterns) and run time analysis (what happens when I actually run this thing).
To give a couple of examples: 1/ You capture an exception and do some error handling. You allow a variable to remain set to null, and continue processing. This in itself is not an error, and would not be picked up by static analysis. Dynamic flow analysis looks at what would happen after the exception is processed, and see if this null variable is used, and whether it would then cause a null pointer exception - definitely a bug.
2/ Divide x by y, and get a result. Not a problem, unless y is zero. As this relates to the test data, static analysis would not pick up on it. A good Dynamic flow analysis engine would.
For more details please see the Parasoft 'Test' suite, this includes both static and dynamic flow analysis engines: http://www.parasoft.com/jsp/products.jsp
Static analysis can be effectively used for ‘Finding Bugs’. Good static analysis tools are inter-procedural, flow-sensitive, and context-sensitive. They yield results with a low level of false positives. While static analysis is able to find errors in code, dynamic testing processing can help identify ways in which software does not do what it is meant to do. Static analysis and dynamic testing utilize entirely different techniques therefore they should be regarded as ‘Complementing’ methods that help make software better.
Several of the answers here imply that static testing is reviewing of the code base. Many sites would completely agree with this point of view. However, this term actually has a more general meaning. Static testing goes beyond just the code base. Reviewing all parts of the test basis, specifications, oracles, etc is static testing. Reviews should be completed on:
- Requirement documentation
- High Level and Detailed Software Design specifications
- Interface Control Documents
- Arhitectural Design Documents
Reviewing any piece of documentation that gives an expectation of how the software is expected to behave is considered static testing. This is a great way to vet out issues inexpensively. All stakeholders can come together and iron out grey areas and conditions that were not previously thought about or conflict.
Dynamic testing is executing the code to determine if it functions properly. Although Static Testing is a great tool, you can only go so far with document/code review. To ensure the requirements are met and the software is performing as expected executing the software [Dynamic Testing] is required.