TCM Integration to QUASTe

From Apache OpenOffice Wiki
Jump to: navigation, search


The development of the Test Case Management (TCM) site is stalled.

Thus we plan to integrate the TCM to the Test Case Specification (TCS) tool
which will be hosted on productive server Quality Assurance Status Page (QUASTe).

Testing and development takes place on current staging server only.

On the current page you will find details about the team in charge of this integration,
the meeting minutes and the progress status of the whole project.

The "code name" of the project is: TCM@QUASTe (i.e. "TCM at QUASTe").

The Team

Name Role E-mail
Rafaella Braconi Program Manager
Joost Andrae Program Manager
Helge Delfs QUASTe Development
Éric Savary Quality Assurance

Meeting Minutes

For the meeting minutes, click here

Road Map

Phase Stackholder(s) Start date*** End Date*** Progress
Phase 1: Unicode Support on QUASTe.This implies:
  • an update of the QUASTe system.
  • a test phase of the QUASTe Unicode support
TCM@QUASTe Team August 2010 August 2010 Done
Phase 2: Alpha Test TCS/TCM server.
  • This server offers basic features compared to the former TCM tool. It is just a minimal start to get feedback from the community!
  • This server is an alpha test version, and not a productivity environment. All data submitted to this server will be lost when Phase 4 begins!
TCM@QUASTe Team + IT October 2010 October 2010 done
Phase 3: Alpha and Beta Testing and Community Feedback.
  • The big picture: what does the L10n community need as main features? What should we absolutely implement? Keyword: "work flow".
  • The smaller picture: what does not work, should and why? Keyword: "obvious bugs"
  • The small picture: cosmetic details, convenience features: keyword: "looking for a 'perfect' tool"

Note: this phase might include many smaller ones depending of the feedback amount and our resources: Beta 1, Beta 2, Beta 3... 0.1, 0.2, 0.3... we plan to work "agile" with the community

TCM@QUASTe Team + Community October 2010 TBD Ongoing
Phase 3a: Alpha 1 TCM@QUASTe Team + Community 27. Oct. 2010 13. Nov. 2010 Done
Phase 3b: Alpha 2 TCM@QUASTe Team + Community TBD TBD Ongoing
Phase 3c: Alpha 3 TCM@QUASTe Team + Community TBD - To do
Phase 3d: Beta 1 TCM@QUASTe Team + Community TBD - To do
Phase 4: Migration from the TCM tool DB to QUASTe and Launch of the productivity version of TCM@QUASTe.

Version 1.0 is finalized! You can work with it!

TCM@QUASTe Team + Community TBD TBD To do

*** About dates:

Q: Does that mean it is useless to work on TCM now/TCM is dead an I have no way to work on L10n test cases?

A: No. As long as we are not finished with Phase 4, please go on working on TCM! We will migrate your work when the new TCM is available.

Q: When will be the new TCM available?

A: frankly said: we don't know. We are working hard on achieving that it works ASAP ("As Soon As Possible") and we are committed to do it. But we chose to not announce deadlines in order to not get useless pressure on this project, So please be patient and contribute!

Work Flow Design and Features (draft)

Alpha 1 Features

  • Ability to clone an existing TCS and start a L10n TCS
    • Keep a link between parent TCS and child L10n TCS
  • Show already available L10n children in the parent TCS
  • Display/Search L10n tests by language



  • the main feature wish was a localized UI for the TCM@QUASTe.
    • -> it is not the suiting moment to implement this because the UI is still in alpha state
    • -> we are not eager to invest time in this because most people using the TCM
      have or should know English enough to translate the tests and file issues when tests fails.

Alpha 2... TBD

  • Implement accepted features and bug fixes from Alpha.
  • Ability to start a L10n TCS from scratch


  • User list and roles


  • Ability to create L10n test categories test

Tool Enhancements RFEs

The following sections present Requests For Enhancement (RFE) against the TCM as they have been published here.

4.1 General

  • Option to hide outdated test cycles in test assignment and test result update
    → YES
  • Implementation of test types (e.g. release test, feature test)
    → YES
  • It should be possible to localize the interface.
    → YES
  • There should be some more explanations.
    → Incomplete. Which explanations about what? Tutorial in progress
  • Anonymous access to Test Cases as well as Summary / Detail Report
    → NO. There won’t be privileges and rights to write and change the tests anymore so that
    the minimum is to know who makes what in order to make changes trackable and avoid low level sabotage.
  • Ability to log-in with the OOo log-in
    → YES

4.2 test case maintenance

  • Community should be able to change English test descriptions.
    If English description is changed, translated descriptions should be marked as "translation needs update".
    This marker can be removed if translated test case is updated

    → YES
  • It should be easy to add new tests samples and to update them when needed
    → YES (As the TCS is already working now)
  • It would be nice to be able to maintain the test cases through our translation tools
    and use Pootle as a repository so we are able to see when original test cases are changed

    → LATER

4.3 test reports

  • Summary of passed / failed / skipped test cases per category
    (would help to identify untested or only partial tested categories)


4.4 test assignments

  • It should be possible to assign test cases to more than one tester.
    ->YES (like the CC field in IZ?)
  • Balance detail in the Operating Systems: we now have one Linux and five versions of Windows;
    we should have "Linux - RedHat/Fedora", "Linux - Debian/Ubuntu", "Linux - SUSE", "Linux - Mandriva", "Linux - Other";
    then two read-only categories, Linux and Windows, could be created to quickly see assignments.

    → NO. On the contrary, we will reduce the number on OS like in the automation results on QUASTe:
    Linux, Mac, Solaris, Windows.
    But one could think about a Comment field where the tester can freely mention the flavor of his OS.
    Furthermore, one could imagine non mandatory and freely writable (no anarchic list boxes!) fields which can explain a difference in results:
    - Architecture: Ex: 32/64bits
    - Window manager: Ex: Gnome, KDE
    Note: in a perfect world and in order to be able to compare (and find regressions) results from one release to an other,
    testers "should" run the tests on the same OS (platform, environment)

4.5 test result updates

  • First-time testers need guidance with this...
    → Duplicate of " There should be some more explanations " above
  • ...a My tests menu option would be better.
    → YES: As in QUASTe.


During the integration process of a new TCM into QUASTe, you will find a documentation here.

After the integration is achieved, the documentation will be integrated to the QUASTe documentation.

Technical background

TCM@QUASTe must have Joomla 1.5.x as a base. All components/modules that worked under Joomla 1.0.X (current stable version running QUASTe) were modified to be able running in Legacy mode of Joomla 1.5.x

Special adaptions to Joomla 1.5.x framework:

  • To have tabpage pre-selection working the following patch had to be applied:

Be sure to check/review this when updating/upgrading/patching Joomla sources to a newer release ! It seems it would not be integrated before Joomla 1.6

Personal tools