Software Testing Tools Blog – Testertools

Today automated software testing plays a vital role in many software development and web application projects.  At XBOSoft, we specifically developed XBO ONE™ Test Automation methodology to deliver cost-effective automated testing for small companies.

It begins with our common sense approach of where and when to use automation. For example, tests that are run many times, such as build verification tests, regression tests, and tests that include many simple and repetitive steps are classic candidates for web application automated testing and software automated testing.  However, if an application or software is not yet stable, then it may make sense to postpone any automated testing efforts.  Automated testing should not be considered a replacement for manual testing, but rather an enhancement.

XBO ONE™ Test Automation Benefits

• Proven methodology that delivers significant cost savings for small companies.

• XBOSoft can quickly determine which parts of the application to automate and which are best suited to manual testing.

• Test automation expertise and proficiency for Windows, .NET, Java, web pages, web servers, web applications and web services.

• Proven experience working with a variety of tools, such as Rational Robot, Borland’s SilkTest, HP’s WinRunner and QuickTest Pro, Compuware, etc.

• Experience in testing multiple operating systems, databases, and application servers with automated test harnesses to rapidly switch platforms for maximum coverage.

XBO ONE™ Test Automation Methodology

XBO’s software automation methodology was developed with small companies in mind and an objective to significantly boost testing productivity while keeping costs and implementation efforts to a minimum. Key elements of our methodology are:

1. Ascertain software‘s suitability for automation.

2. Review Automation Checklist; such as:

a. Can the test sequence of actions be defined?

b. Is it necessary to repeat the sequence of actions many times?

c. Is it possible to automate the sequence of actions?

d. Are you testing non-UI aspects of the program?

e. Do you need to run the same tests on multiple hardware configurations?

3. Assign & Organize Testing Team .When multiple team members are automating tests, develop common scripting architecture, code, and objects for maximum productivity.

4. Utilize test script modularity framework where appropriate (ie. Create small, independent scripts that represent modules, sections, and functions of the application-under-test).

5. Manage automation process:

• Share and maintain test assets in XBO’s central application repository.

• Propagate script changes to all testers through XBO’s application repository.

• Track which test cases are automated and which are manual, and prioritize which cases get automated first for maximum results.

• Manage script scheduling and execution.

• Optimize the Test > Fix > Verify process to automatically push new defects into the defect tracking workflow.

• Compare versions of scripts for differences, merge changes, and store scripts with other development assets, such as requirements documents, test data, design documents, and source code.

View TesterTools dedicated page for this tool.

Size is one of the most important attributes of a software product. It is not only the key indicator of software cost and time but also a base unit to derive other metrics for project status and software quality measurement. Size metric is used as an essential input for most of cost estimation models such as COCOMO, SLIM, SEER-SEM and Price-S.

Although source lines of code or SLOC is a widely accepted sizing metric, there is a lack of standard that enforces a consistency of what and how to count SLOC. Ensuring consistency across independent organizations in the rules used to count software cost code is often difficult to achieve. To that end, the USC Center for Systems and Software Engineering (CSSE) has developed and released a code counting toolset called CodeCount to support sizing software code for historical data collection and reporting purposes. This toolset is a collection of tools designed to automate the collection of source code sizing information. It implements the popular code counting standards published by the Software Engineering Institute (SEI) and adapted by COCOMO. Logical and physical SLOC are among the metrics generated by the toolset.

Direct download link click here

For more info on this product  click here.

DrJava is a lightweight programming environment for Java designed to foster test-driven software development. It includes an intelligent program editor, an interactions pane for evaluating program text, a source level debugger, and a unit testing tool.

View TesterTools dedicated page for this tool.

Jlint will check your Java code and find bugs, inconsistencies and synchronization problems by doing data flow analysis and building the lock graph.

Jlint is extremely fast – even on large projects, it requires only one second to check all classes! It is easy to learn and requires no changes in the class files.  Jlint has been used in an industrial environment and successfully uncovered faults with little effort! This version of Jlint is the extended version featuring some improved synchronization checks.  The original version has been written by Konstantin Knizhnik.

View TesterTools dedicated page for this tool.

R-JVV is a random test generation tool for Java virtual machines. Other JVM testing tools are not sufficient for testing a modern Java virtual machine.  This is because a modern Java virtual machine is performing some of the most aggressive optimizations available in compiler technology, such as global code motions, inter-method optimizations, profile-driven optimization, and speculative optimizations that get undone with dynamic class loading.  While other Java test suites cover the basic semantics of the language, with some tricky edge cases, we have found that they do not produce enough cases with enough diversity to ensure the correctness of the JVM’s optimizations.  This is not just paranoia – we have found that some of the leading JVMs fail our tests.

R-JVV is a tool that supplements other test suites for testing JVMs, including our own R-JIT.  R-JVV generates volumes of complex random self-checking Java test cases that stress the optimizations in the JVM.  While the coverage of any tool cannot be complete, using R-JVV to complement other Java test suites can substantially improve quality and reliability.

R-JVV helps you bring the testing of your JVM closer to the testing level that a hardware platform typically gets.  For example, a mainframe server receives extensive tests and includes extra hardware such as parity and ECC checking, which is partly what gives the mainframe its price premium.  The complexity of a modern JVM can be much greater than that of hardware.  For a mission-critical Java-based server, R-JVV helps to bring the dependability level of the JVM toward that of server hardware.

R-JVV is useful to the following classes of users:

Developers of proprietary and open source JVMs.  R-JVV can substantially supplement the dependability provided by other test suites.

Developers of devices and systems that include a JVM.  R-JVV will subject their system to a higher level of testing intensity to help avoid expensive device recalls or embarrassing crashes.

Integrators and web site developers seeking to qualify the components that they provide to their business customers.  R-JVV’s results can provide criteria that indicate the highest quality JVM to provide to customers.

Users of JVMs for mission critical applications, such as J2EE servers.  R-JVV testing intensity can help ensure that the JVM supplied by their vendor is of the highest quality, to avoid costly downtime.

View TesterTools dedicated page for this tool.

Macker is a build-time architectural rule checking utility for Java developers.

View the rules file

It’s meant to model the architectural ideals programmers always dream up for their projects, and then break — it helps keep code clean and consistent. Users can tailor a rules file to suit a specific project’s structure, or write some general “good practice” rules for your code. Macker is flexible, and writing a rules file is part of the development process for each unique project.

For more details go here