Why (& how) do Static and Dynamic testing complement each other.
Not much more, simple question.
|
Why (& how) do Static and Dynamic testing complement each other. Not much more, simple question. |
|||
|
|
|
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. |
|||
|
|
|
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 |
|||
|
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. |
|||
|
|
|
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. |
|||
|
|
|
Static testing is reviewing the program code without executing it. Its focus is mostly on the following:
While static testing only is insufficient, it is a great technique to prevent bugs early in development cycle. |
|||||||
|