Archive for the ‘Whitebox Testing’ category

Non linear paths from Application Code

October 4, 2007
The applications become complex as their code base increases. This has challenges for the testers to determine the nonlinear paths in the application.

Most of the Static Analysis tools over the application code helps us to  identify the  cyclomatic complexity (nonlinear paths) at a method level. These might be helpful to validate those methods and to achieve good code coverage over the same.

But the Code coverage at a Unit Level may not be a big help since most of the end user scenarios won’t run after unit level paths. These paths is an integration of the above unit level paths.

Since the Testers focus on simulating the end user scenarios, it will be good to identify all the possible nonlinear paths around the application code base and capture the code coverage based on these paths.

You might want to go through some discussion around this on Linkedin Answers

In case you have similar experiences over white box testing drop me a mail at

Happy Testing…

Powered by ScribeFire.


Whitebox Testing – Is it really white ?

September 7, 2007

The popular myths around Blackbox & Whitebox Testing are by it’s name. It’s black since we can’t see it (don’t have access to the code) & it’s white since you have access to all the code. But then, With in the code there are many black boxes inside and it’s tough to have access to that code base.

  • We don’t have access to code of a language API. Most of the applications have been built on top of a API & assume that the API works fine
  • Most of the application do integrate some third party tools over it’s API. We don’t have access to that code base.
  • We don’t have access to the code of Compiler
  • We don’t have access to code of rum time engine that executes our application code
  • We don’t have access to the code of Operating System Services on top of which the application runs

The list goes on and there are many black boxes in side our code too. We are just testing the code written for the application and it’s better to call it as Code Based Testing rather than Whitebox Testing

— Happy Testing..

%d bloggers like this: