VTK/SoftwareQuality/GerritTestFailures: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
No edit summary
No edit summary
Line 29: Line 29:
Initial analysis revealed:
Initial analysis revealed:
* Python tests accounted for 15 of the defects. Note that only the Ubuntu system has python enabled.
* Python tests accounted for 15 of the defects. Note that only the Ubuntu system has python enabled.
* One of the tests, TestSplitViewportStereoHorizontal, was failing on all three systems. It also was failing on many other nightly builds.
* One of the tests, ''TestSplitViewportStereoHorizontal'', was failing on all three systems. It also was failing on many other nightly builds.
* One of the python tests, TestTemplates, was failing on every VTK build that had python enabled, including the Gerrit Ubuntu build.
* One of the python tests, ''TestTemplates'', was failing on every VTK build that had python enabled, including the Gerrit Ubuntu build.
* Seven tests were timing out on the Ubuntu system.
* Seven tests were timing out on the Ubuntu system.
* The remaining tests required further analysis and individual attention.
* The remaining tests required further analysis and individual attention.

Revision as of 20:08, 5 February 2013

Gerrit provides a powerful code review tool to the VTK and ITK open source communities. For each submitted topic, Gerrit builds and tests the topic on three typical configurations: Ubuntu, Mac and Windows. The goal of these builds is to catch compile errors and test failures introduced by the topic, before the topic is merged into VTK or ITK.

Recurring test failures on the Gerrit builds can easily mask new defects introduced by a topic. Recently, the number of recurring failures for VTK was:

  • Ubuntu - 28
  • Mac - 4
  • Windows - 3

This experiment seeks to reduce VTK Gerrit recurring test failures to 0 and keep them at 0.

This experiment uses the DMAIC methodology of the Six Sigma management process to "Define", "Measure", "Analyze", "Improve" and "Control" to resolve these issues.

The basic methodology (from Wikipedia) consists of the following five steps:

  • Define process goals that are consistent with customer demands and VTK's strategy.
  • Measure key aspects of the current process and collect relevant data.
  • Analyze the data to verify cause-and-effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered.
  • Improve or optimize the process.
  • Control to ensure that any deviations from target are corrected before they result in defects. Set up pilot runs to establish software quality, move on to production, set up control mechanisms and continuously monitor the process.

Define

Keep the number of VTK Gerrit recurring test failures(defects) to 0. When the defects are above 0, developers find it difficult to see if their changes have increased the number of defects.

Measure

As of January 26, 2013, there were 34 defects on the three VTK Gerrit builds:

  • Ubuntu - 26
  • Mac - 4
  • Windows - 4

Analyze

Initial analysis revealed:

  • Python tests accounted for 15 of the defects. Note that only the Ubuntu system has python enabled.
  • One of the tests, TestSplitViewportStereoHorizontal, was failing on all three systems. It also was failing on many other nightly builds.
  • One of the python tests, TestTemplates, was failing on every VTK build that had python enabled, including the Gerrit Ubuntu build.
  • Seven tests were timing out on the Ubuntu system.
  • The remaining tests required further analysis and individual attention.

Improve

Control

As of February 3, the 6 defects remain:

  • Ubuntu - 2 defects
    • TestTemplates
    • TestSplitViewportStereoHorizontal
  • Mac - 1 defect
    • TestSplitViewportStereoHorizontal
  • Windows - 3 defects
    • TestSplitViewportStereoHorizontal
    • TestTilingCxx
    • TestInteractorStyleTreeMapHover

Once reduced to 0, developer diligence is needed to keep the defects to 0. The burden is on the Gerrit reviewers.