Filed under Software Development, Software Metrics by Venkat Reddy Chintalapudi on October 20, 2009 at 6:20 am
2 comments
Overview
Open Source testing tools are being used aggressively and there are many tools over the web for Java Applications. These tools are great asset to the development teams and provides many features / services over the quality of applications under development. We can use this as the starting point and focus more efforts on the uncovered areas for better quality.
It’s very important to know the context of development and the right tools for quick benefits. However, heavy usages of these tools lead to misleading data and metrics too. So think twice on what is required for the project and which tools might provide the required data / services.
Services Offered
The following services / features are offered from most of the open source tools
- Continuous Integration for the builds
- Unit Testing
- Code Coverage
- Source Code Metrics (like size, Complexity, design, dependency)
- Static Analysis for various bug patterns
- Test Automation
- Performance Testing
List of Open Source Tools
Quick Benefits from Static Analysis
It’s very easy to integrate static analysis tool(s) with builds and there quick benefits. The following issues can be uncovered
- Null Pointer Exceptions
- Other un handled exceptions
- Infinite Loops
- Dead code
- Compliance with Java Coding standards
- Code Coverage data
- Trends / history on the above checks against previous builds
- Validations against Java coding guidelines from Sun
The following Metrics can be captured
- Source Code Metrics
- Coverage Metrics
- Dependencies with the Design
- Code complexity metrics
The Resources listed below helps in implementing the same.
Filed under Software Development, Software Testing by Venkat Reddy Chintalapudi on May 7, 2008 at 6:29 pm
no comments
Interesting trends are happening around Static Analysis and Code Quality. The tools vendors closely looking at each of the code quality metrics and merging them to have a better metric. We can see the pattern from Agitar by coming up with CRAP4J. Here is one more vendor coming up with the tools on Code Quality and Static Analysis.
The AppPerfect comes with a suite of products around code quality metrics and improvements. DevTest4J is a suite of products designed to help you build and test high-performance applications during the development phase of the product life-cycle.
Filed under Software Development, Software Metrics by Venkat Reddy Chintalapudi on May 7, 2008 at 6:22 pm
no comments
I have come across yet another static analysis tool for Java programs. ENERGY is a free static analysis tool to measure code quality & presents overall status on the health of source code. Energy comes with a code quality metric by combining the bug patterns on the source code and rates it between 1 to 10. The tool tries to identify the symptoms via static analysis and then publish a rating. How it works is an interesting insight.
Check the following video to learn more about the tool.
Technorati Tags: Code Quality Metrics, Java, Static Analysis, Code Quality.

Filed under Software Development, Software Metrics by Venkat Reddy Chintalapudi on October 22, 2007 at 8:31 am
6 comments
I have been talking about Code Quality through Static Analysis for a while here, here & here. The quality for any application development must begin from it’s gross roots and the Application Code is one of it’s starting point to begin with.Static Analysis techniques help us to identify some metrics over the application code base
- Cyclomatic Complexity
- Application Design & Dependency Metrics
- Exception Handling
- Infinite Loops
- Dead Code
- Performance Issues
- Programming Language guidelines & best practices in their context
The above information will be useful and it’s easy to get the same via Test Framework with a single click.
Code Coverage along with a bunch of unit tests is one widely used technique to help regression testing for the dev & test teams.
Now it’s good to see that Agitar combines Code Coverage & Cyclomatic Complexity to derive risk metrics for Java Code Base. They call it as a code Change Risk Analyzer and Predictor (i.e. CRAP) for Java.
Though it’s a prototype and see how the industry receives the same, i see it as a good initiative on the code quality front and might be a metric going forward for white box testing.
Some useful links for CRAP4J
Update on Oct 23rd
Now we have a dedicated site for CRAP4J. This contains latest news, forum discussions and many more. I would say that this a good resource for Code Quality lovers & the good news is that they are designed to be open source tools.
Crap4j is a Java implementation of the CRAP (Change Risk Analysis and Predictions) software metric – a mildly offensive metric name to help protect you from truly offensive code.
The CRAP metric combines cyclomatic complexity and code coverage from automated tests (e.g. JUnit tests) to help you identify code that might be particularly difficult to understand, test, or maintain – the kind of code that makes developers say: “This is crap!” or, if they are stuck maintaining it, “Oh, crap!”.
The best way to learn more about CRAP and Crap4j is to check the various articles, newsgroups and blogs about them.
(more…)
Filed under Software Development, Software Testing by Venkat Reddy Chintalapudi on October 22, 2007 at 5:48 am
8 comments
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.
Filed under Software Development, Software Metrics by Venkat Reddy Chintalapudi on October 4, 2007 at 2:49 pm
2 comments
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…
Filed under Software Metrics, Software Testing by Venkat Reddy Chintalapudi on September 24, 2007 at 1:15 pm
no comments
Bug Database for the products might have thousands of issues over a period of time against various builds and releases. Though these issues fixed over a period of time, it might be hard to derive meaningful metrics over the release.
We need to support these releases over the production systems & it might be helpful to capture the hot spots / risk elements with the release. Most of the issues here to deal with the respective features, compatibility with other features / technologies & performance related issues.
The usual metrics of number of issues against a module and their severity levels may not be of help always.
How easy is it to derive the following from the Bug Database for a given release
- Identify the issues have originated from Requirements, Design & Implementation
- Identify the issues over their category (Functional, Performance, Security, Compatibility, Usability etc)
- Identify the issues along with their origin & category over the features rather than the modules / components
(more…)