Check the following video to learn more about the tool.

Technorati Tags: Code Quality Metrics, Java, Static Analysis, Code Quality.

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

Today, i have come across an interesting issue with BSNL Portal. I have been using this site for online billing and payments for about an year.

Followed the usual steps and my objective is too see the bill and pay it online. To my surprise, the system says

This error message ” Invalid object name ‘RECEIPT_MASTER’ “ is strange and there is no information for me on how do i proceed further. The application might be unable to get the specified object from the Database.

In case if this happens on the last day of the payment, on line users are liable for late payment charges due to this issue.

Users are familiar with the messages like, Unable to process the information as of now & please check back after some time.

The error messages must be meaningful to the business users and we need to make sure that the technology related terms / phrases are not part of the same.

Happy Testing…

Context driven information is the need of the hour and there is a huge value associated with the same. It’s good to capture the context driven information in the bug reports. My initial experiences with bug reports way back in early 2000 have taught many lessons to improve upon.

Bug reports used to capture what is the problem with the system familiar to the user (tester) who reported the same. People spend very less time to capture all the details required and there are many reasons for the same. I hope some of the upcoming testers will also be in the similar situations.

Some of the Reasons people quote here

• We need to test more and less time to capture & write more information in the Bug Reports
• It’s tough to capture all the information required
• System is complex & It’s tough for the novice users to understand the bug reports
• You know capturing all the info is process driven & it may not be worth of efforts
• It some times boring activity to collate the info & push it
• I can reproduce it on my machine if developer needs it.

This list can go on…

I hope you have come across this situation at least once in your career.

This is my third post in the Bug Life Cycle Series and it’s good to know the different users of your Bugs and their context with them. The mission of your bug report is to provide details and context of the problem and convey the importance of it with a user driven stories.

Your bug report must be the voice of customer and it need play the role of an advocate against the problem. Bug Advocacy from Cem Kaner is an excellent source to begin with. If the bug report unable to specify the need of the context, then it’s better not to write any report

It’s good to explore & capture some of the following problems

• Productivity
• Performance
• Usability
• Migration
• Stability etc

Try to link your issues with most suited functions listed above. It may not be obvious to other users in the system to explore & analyze the issues in that fashion.

There is another context associated with Bug Reports. That’s with the stake holders of the project. The Bug Tracking system must give the right trends and identify the hot spots. Testers must capture the right kind of data to derive better valuable metrics over the bug repository.

Care must be taken to capture

• Capture all the Test Environment details
• Detailed classification on the feature. Classify to the maximum possible sub feature/component of the system
• Clarity on Severity & Priority
• Versions and Build Numbers (Affected & Fixed)
• Bug Classification (Requirements / Design / Implementation etc)
• Bug Types (Functional, Performance, Usability, Security etc)
• It can go on…

The above info helps a lot to identify the trends in bugs and focus on the unstable components / environments.

Final Thoughts
Push the entire context driven information to the bug repository at least for a release cycle and observe the results. Check back with your repository to identify the trends and risk associated with the release and I am sure that it will be in the similar lines of end user feedback.

Happy Testing…

It’s almost a month since my last post on this blog and busy with my upcoming release of QuickRules BRMS. I have been talking to the people around on the Software Testing and felt that it’s not communicated well. Though there is enough information on this subject, i would like to describe my own version of the same here.

Testing is about making things better by providing constructive criticism based on the context (we can also say qualitative information and not being nice) at the right time and in the right direction too.

I like the phrase, “Testers, you are the headlights of the project” from the book Lessons Learned in Software Testing.

I have been thinking about this concept helped for the individuals. This revealed lot of crucial information and i hope this helps my fellow testers to motivate them & their teams.

There are many real life testers (incase if we need to list all of them) who contributed & still contributing a lot for us in every phase of life to grow and improve upon (fix the imp bugs among ourselves).Let’s explore some of them below.

My Parents are the first testers in my life. They contributed invaluable information at each stage (Milestone release) of my life. Instead of saying “Sshhhhhh you can’t do that, they used to tell me further implications that might arise”. An insight into this tells us that it’s not an order, but there is context based information for informed decisions.This helped me to stop for a while, analyze the information and work on the required steps to improve upon the current state.

My teachers helped me a lot by providing the constant feedback (just not being nice) through assignments, tests and covey the areas which are good and bad for me in the respective subjects. They are the best testers because they are the ones who taught the concepts and observed my execution towards the same.

There is a tremendous scope for the improvement, incase if we have acted upon the feedback at the right times.

My Boss at work used to evaluate (Test the Tester) me & provide the feedback on the tasks performed by me. This information helps to analyze to identify the next set of steps to be taken for the improvement.

If we look back, there are many testers around us providing the qualitative information to make things better and improve upon.

The Value of this information is tremendous since it came from people who are more experienced and passed through the current stage where we stand. The value lies in the fact that most of the successful people around, learnt a lot from others (learn from others mistakes too rather than your own) and they have become experts in their own fields.

How does this helps Software Testing

Software testing too comes under the similar lines and its role is to provide context driven information for the stake holders to make informed decisions over the application under test (AUT).

So as being testers, we need to provide the constructive criticism at each stage of the Development. If we look back at the above scenarios, the value addition is more because the people involved there have better skills over the context.

That being said, the current industry lacks skilled testers. The true value addition in Software Testing will be more, if and only if the people involved there have better skills over the context they working with.

Do share your views here or send them to me at venkatreddyc@gmail.com

Happy Testing…