Concordion
1. Who (company or individual) developed the tool? What is the cost to the tool user? How do you acquire it?
Concordion was developed by David Peterson, an agile consultant from London, UK. While working at Easynet in 2006, the idea was formed with testers and developers Nat Pryce and Steve Freeman. Concordion was then later ported and improved upon by several developers, specifically Nigel Charman, the designer of the Concordion Extensions API. The Concordion tool is available for free at concordion.org/Download.html.
2. What testing purpose does the tool serve? (i.e., what problem does it attempt to solve? How does it improve productivity?)
Concordion is an open source tool that is used for the automation of Specification by Example. Using simple HTML, developers can create concrete examples in any specifications with certain commands. This allows for Concordion to check the examples against a real-life system. The specifications allow for complete cover of any behavior important to a customer. Based on this, specifications can be used as unit tests. Concordion specifications are also clear and readable so they can also serve as system documentation. This means a project’s specifications can be easy to understand for the development team, as well as anyone outside it. This would ultimately allow for a better maintenance of software quality as the software can be reviewed as a group effort.
5. What do you need to do in order to use the tool?
There is ample documentation provided on the Concordion website to guide you through the install and configuration process. Concordion requires JDK5.0 and the following JARs in the classpath:
• concordion-1.4.7.jar
• junit-4.12.jar (or junit-3.8.2.jar)
• hamcrest-core-1.3.jar (required for JUnit 4.11 or later)
• ognl-2.6.9.jar
• xom-1.2.5.jar
These are all included in the download that Concordion provides. In order to configure Concordion, acceptance tests should be placed in a folder named ‘specs’ and a .html file should be created that shares the same base name as the JUnit test. Finally, a stylesheet named ‘concordion.css’ is a stylesheet to make the specs look nice while you’re writing them.
The Concordion commands use a “concordion” namespace defined at the top of each document. A example of how Concordion would be used is provided.
1. Create a Java package called "example".
2. Create a file "HelloWorld.html" inside the package containing:

Hello World!

3. Now instrument the file as follows:

Hello World!

4. In the same example package, create a Java file "HelloWorldFixture.java" containing: package example; import org.concordion.integration.junit4.ConcordionRunner; import org.junit.runner.RunWith;

@RunWith(ConcordionRunner.class) public class HelloWorldFixture { public String getGreeting() { return "Hello World!"; }
}
5. Now run the HelloWorldFixture class using JUnit.

6. What are the strengths and limitations of the tool?
Tests can become truly useful documentation Concordion specifications are so readable they can double up as system documentation. They are written in HTML, so can be easily hyperlinked into a navigable structure. And, since the automated acceptance tests run against the system, you can be confident the documentation is always up-to-date.
Helps you to separate "what?" from "how?" Tests that include a lot of implementation detail lock you into that implementation. Concordion helps you to document the logic and behaviour of your system in a way that gives you the flexibility to change the implementation later on.
Purposely small command-set is simple to learn Concordion based on specification by example has been designed with a short learning-curve as a top priority. Automated tests are integrated with JUnit, which makes them easy to run and easy to include in an existing project build.
One of the limitations is of Concordion is that because of the small command set there isn’t much versatility in what it does or how it functions. Another limitation is that Concordion is not suitable for testers who don't have access to developers or development skills. The test specs can be written by non-developers, but the instrumentation and fixture code require Java programming ability.

FindBugs
1. Who (company or individual) developed the tool? What is the cost to the tool user? How do you acquire it?
FindBugs was founded by David Hovemeyer who now works as an Associate Professor of CS at York College. Hovemeyer did a Ph.D. thesis on FindBugs at the University of Maryland. However, he is not currently an active member of the development team. The current team consists of Bill Pugh (project lead and primary developer), Andrey Loskutov (worked on Eclipse plugin), and Keith Lea (web cloud). The software is available on its own and as a plugin for free under the terms of the Lesser GNU Public License. It can be downloaded online at findbugs.sourceforge.net/downloads.html.
2. What testing purpose does the tool serve? (i.e., what problem does it attempt to solve? How does it improve productivity?)
The FindBugs tool utilizes static analysis to review Java bytecode and see if any bug patterns occur. Using static program analysis, an analysis of a program can be done without executing the program. Since it analyzes Java bytecode, a program’s source code is not necessary for analysis. FindBugs also implements a plugin architecture which allows for anyone to add new bug detectors. By classifying errors into one of four ranks, FindBugs gives hints to developers about the severity of the errors of their programs. All these features make FindBugs very easy and simple to use.
5. What do you need to do in order to use the tool?
To use FindBugs, you need a runtime environment compatible with Java 2 Standard Edition, version 1.5 or later. FindBugs is platform independent, and is known to run on GNU/Linux, Windows, and MacOS X platforms. The easiest way to install FindBugs is to download a binary distribution. Binary distributions are available in gzipped tar format and zip format. Once you have downloaded a binary distribution, extract it into a directory of your choice.
Extracting a gzipped tar format distribution:
$ gunzip -c findbugs-3.0.0.tar.gz | tar xvf -
Extracting a zip format distribution:
C:\Software>unzip findbugs-3.0.0.zip
Usually, extracting a binary distribution will create a directory ending in findbugs-3.0.0. For example, if you extracted the binary distribution from the C:\Software directory, then the FindBugs software will be extracted into the directory C:\Software\findbugs-3.0.0. This directory is the FindBugs home directory.
If you are running FindBugs on a Windows system, double-click on the file %FINDBUGS_HOME%\lib\findbugs.jar to start the FindBugs GUI.
On a Unix, Linux, or Mac OS X system, run the $FINDBUGS_HOME/bin/findbugs script, or run the command: java -jar $FINDBUGS_HOME/lib/findbugs.jar

to run the FindBugs GUI.
After you have started FindBugs using the findbugs command, choose the File → New Project menu item. Use the "Add" button next to "Classpath to analyze" to select a Java archive file (zip, jar, ear, or war file) or directory containing java classes to analyze for bugs. You may add multiple archives/directories. You can also add the source directories which contain the source code for the Java archives you are analyzing. This will enable FindBugs to highlight the source code which contains a possible error. Once you have added all of the archives, directories, and source directories, click the "Analyze" button to analyze the classes contained in the Jar files.
6. What are the strengths and limitations of the tool?
One of the strengths of FindBugs is that it uses static analysis to inspect Java bytecode for occurrences of bug patterns. Static analysis means that FindBugs can find bugs by simply inspecting a program's code: executing the program is not necessary. This makes FindBugs very easy to use: in general, you should be able to use it to look for bugs in your code within a few minutes of downloading it. FindBugs also supports a plugin architecture allowing anyone to add new bug detectors.
The main weakness of FindBugs is that because its analysis is sometimes imprecise, FindBugs can report false warnings, which are warnings that do not indicate real errors. In practice, the rate of false warnings reported by FindBugs is less than 50%.