The term quality might mean different things to different people based on their context of operation and it’s tough to have universal definition for the same.My experiments with software development started over a decade ago & exploring the ways the helps to build & deliver good quality code.The quest towards Code Quality Metrics started with the above objectives.
The discussion around Useful Code Quality Metrics at Linkedin started two months ago. I am excited over the response around the internet to this thread & there are some excellent articles around subject.
In the recent past Agitar comes up with CRAP4J as a code quality metric by combining Cyclomatic Complexity and Code Coverage.
In the process, we do use Static Analysis and Dynamic Analysis to derive the above mentioned metrics. Some more good articles around Code Quality are here
I wish that the info around Code Quality is helpful for my blog readers
Happy Testing…
(more…)
As a Tester & Developer, it’s pretty common to see NoClassDefFoundError. It’s not that easy always to figureout the required jars for the application.
Whatjar comes with a lot of search capabilities to identify and download the required jars.
Whatjar is a high-performance, search engine written using Java and MySQL to index and search Java JAR contents. Its primary goal is to provide a tool to help the developer find the JAR file required when faced with a class not found exception. In addtion to act as searchable resource of open source java jars.
Whatjar is free, there is no cost to upload a jar or to search our existing database of JARS.
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 venkatreddyc@gmail.com
Happy Testing…
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..
