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.

• Micheal Boltan has brought up interesting view points and also bloged about the same.
• Nigel Cheshire talks about Static Analysis metrics and expressed views on the right metrics
• Andrew Glover calls it as Code Quality’s singular metric

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

• In pursuit of Code Quality series
• How useful are Code Metrics ?

I wish that the info around Code Quality is helpful for my blog readers

Happy Testing…

(more…)

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

• Introducing CRAP4J
  
• The Code C.R.A.P. Metric Hits the Fan – Introducing the crap4j Plug-in
• Junit Factory’s Code C.R.A.P metric

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…)

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…

Software Testing is considered as a Cost for some Stakeholders & an Investment for others in their context of operation. It’s good to know the status in your context. I had this query in LinkedIn Answers & thought of sharing the good discussion to my blog readers.

Do you consider Software Testing as an Investment or a Cost in your Context ?

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

1. Identify the issues have originated from Requirements, Design & Implementation
2. Identify the issues over their category (Functional, Performance, Security, Compatibility, Usability etc)
3. Identify the issues along with their origin & category over the features rather than the modules / components

(more…)

In this post, i will explore different stages of the Bug from it’s inception to closer. The Bug has been found and logged into the Bug Tracking System. It’s my fourth post in the Bug Life Cycle series.

1. The Bug has been found and logged into the Bug Tracking System. It will be treated as New Bug in the System.
2. The Bug will be assigned to the concerned Developer for a Resolution.
3. The developer looks in to the possibilities of the resolution & takes a call on Resolution by fixing it or differing over the information provided.
4. Tester validates the resolved issue in the build & checks for the regression scenarios over the fix.
5. If the issue found fixed, then he choose to Close the issue else he / she will Re-open the same.
6. The Cycle follows again for the re-opened issue till it gets closed.

It worth doing the following activities

1. Capturing the required and re-usable info to the Bug Report at it’s each stage.
2. Check for all the closed bugs of Severity 1 & 2 against final build for the release.

In the next post, I will share my thoughts on the useful metrics over the Bug Tracking Repository.

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..