On Tuesday February 24th, we organized an open tool demonstration event at the University of Antwerp.
At this event, open to all companies and software teams interested in state-of-the-art tooling, we have demonstrated the chance-centric quality assurance tools developed by the Cha-Q consortium.

Press coverage

University of Antwerp press release
Data News article

Cha-Q Tools 

Quality software has long been synonymous with software “without bugs”. Today, however, quality software has come to mean “easy to adapt” because of the constant pressure to change. Software teams seek for a delicate balance between two opposing forces: striving for reliability and striving for agility. In the former, teams optimize for perfection; in the latter they optimize for ease of change.

The ANSYMO (University of Antwerp) and SOFT (University of Brussels) research groups are investigating ways to reduce this tension between reliability and agility.  Together, we seek to make changes the primary unit of analysis during quality assurance and as such we expect to speed up the release process without sacrificing the safety net of quality assurance.

The following are examples of the problems addressed by our change-centric quality assurance tools:

• Monitoring the test process. Determine the impact of changes on both the test and production code, to persuade team members to increase test activities. Demonstrate that the test process itself meets quality guidelines (e.g., every bug fix is covered by a regression test).

• Deciding what to re-test. Instead of running all tests for a given release, run only those tests that are potentially affected by a given change. This allows for instant feedback on the changes that cause tests to fail, saving valuable time in identifying the precise location of a defect.

• Monitoring the bug database. Verify whether anomalies occur in the bug database (e.g., wrong severity, assigned to wrong product or component). Assure that all severe bugs have been fixed before a release.

• Deciding bug assignment. Once bugs have been reported, determine who is the best person in the team to handle the request. Use historical information to reliably estimate the time it will take to fix the bug.

• Monitoring code changes. Monitor changes as they are made in the editor or as they are committed to the version repository. Use documented traceability links and past co-change information to recommend related code that should be changed accordingly (e.g., XML configuration files).

• 

   Automating code changes. Release a new API version with patches that automatically update all existing client code, reducing the number of API versions in the field. Replay code changes that were successful for a given branch on a variant branch, reducing manual branch synchronization.

We refer the Cha-Q info brochure for more details. 

 Agenda

The open tool demonstration event takes place on Tuesday, February 24, 2015 from 13:00 till 17:30 at the University of Antwerp Campus Middelheim.

13:00 - 13:30 — Welcome
13:30 - 15:30 — Tool Demonstrations

• Introduction to the project (presentation)
• Cha-Q tooling infrastructure (presentation, poster)
• Maintaining Traceability Changes (presentation, poster)
• Program Transformation: Advanced search-and-replace (presentation, poster)
• Predicting Bug Fixing Time (presentation, poster)
• Assessing Test Quality: Mutation Testing (presentation)
• Deciding What to Retest (presentation)
• Change Analysis: Maintenance of Selenium Tests (presentation)
• The Cha-Q steering board (presentation, poster)

15:30 - 16:30 — Invited Speaker — Jurgen Vinju — Software Engineering: the war against complexity (presentation)

• Abstract: Software complexity, whether accidental or on purpose, is the enemy of all software quality factors: efficiency, correctness, changeability. It is both a technical and a human factor. On the one hand, in complex software every part depends on every other part, making new features expensive, as well as hard to test and hard to optimize. On the other hand, how can we even manipulate software that we do not understand? On a societal level, overly complex software widens the gaps between producers and consumers of software, with profound consequences. What do we do against software complexity? Can it be prevented a priori? Can it be remedied, a posteriori? Can the war against complexity be won by public/private collaboration? In this talk we highlight a number of examples where new tools produced by research efforts can make or do make a difference. We distinguish constructive methods (preventing complexity) from analytical methods (mitigating complexity). The examples in this talk are mostly from the results of the SWAT research group at CWI in Amsterdam.
• Bio: Jurgen Vinju is the leader of the Software Analysis and Transformation (SWAT) research group at Centrum Wiskunde & Informatica (CWI) in Amsterdam. He is part-time professor Automated Software Analysis at TU Eindhoven and team leader of INRIA Lille’s ATEAMS. His research is characterized by a strong emphasis on design and construction of new tools; programming languages, reverse engineering tools, code generators, software analysis.
• URL: http://homepages.cwi.nl/~jurgenv/#_about

16:30 - 17:30 — Networking drink

Photos