[[PageOutline(2-5,Contents,pullout)]] = Test Manager plugin for Trac = Jump to the [http://trac-hacks.org/wiki/TestManagerForTracPlugin#RecentChanges list of the latest changes]. '''Follow this [wiki:TestManagerForTracPluginQuickSetup Quick setup guide]''' to get you going quickly. '''Note:''' !TestManager release 1.4.3 requires XmlRpcPlugin to run. I've removed this hard dependency with 1.4.4. == Description == A Trac plugin to create '''[http://trac-hacks.org/wiki/TestManagerForTracPlugin#TestCases Test Cases]''', organize them in '''[http://trac-hacks.org/wiki/TestManagerForTracPlugin#TestCatalogs Catalogs]''', generate '''[http://trac-hacks.org/wiki/TestManagerForTracPlugin#TestPlans Test Plans]''' and track their execution status and outcome. Differently from other test management plugins for Trac that use Tickets as test case holders, this one uses Wiki pages and an additional proprietary data model to store Test Cases. This allows you to not pollute your ticket lists with something that is not a ticket, and at the same time is powered by the Trac search engine and formatting syntax for Wiki pages. A set of plugins intercept requests for Wiki pages that are test cases and decorate the page with title, breadcrumbs, tree view, type-ahead search inside the catalogs, test case status semaphore and icons and buttons that allow you to create new test cases, sub-catalogs, copy and paste test cases around different catalogs and change a test case status. Multiple Test Plans can be associated to any Test Catalog, in order to keep track of the execution of the corresponding Test Cases in a particular testing context. A '''[wiki:TestManagerForTracPluginApi Programmatic API]''' is available to interact with the test management environment with three types of interfaces: * '''[wiki:TestManagerForTracPluginRPCApi XML-RPC]''', * '''[wiki:TestManagerForTracPluginRestfulApi HTTP RESTful]''' and * '''[wiki:TestManagerForTracPluginPythonApi Python classes]'''. The plugin has been made modular: * A generic, customizable '''[wiki:TestManagerForTracPluginWorkflow Workflow Engine]''' is provided as a separate plugin in the package, which allows you to associate custom workflows to any Resource in Trac, including Wiki pages and any custom object handled through a Resource Manager. This can be done very easily by adding as little as [wiki:TestManagerForTracPluginWorkflow a few lines of code] to the component which manages the User interface. * All the data manipulation layer has been extracted into a '''[wiki:TestManagerForTracPluginGenericClass Generic Persistent Class framework]''' plugin, which can be easily used by any other plugin developer to provide persistence, security, change history, custom properties, pattern matching search, and other features to their basic data model with a handful lines of code. All of the test objects, i.e. catalogs, test cases, test plans and test cases in a plan (i.e. with a status and a status change history), support: * '''[http://trac-hacks.org/wiki/TestManagerForTracPlugin#Customfields Custom properties]''', which can be declared in the trac.ini file and will be available to the User for change, stored in the database and available to change listeners. * Change history * Listener interface to be notified of object creation, modification and deletion * '''[http://trac-hacks.org/wiki/TestManagerForTracPluginWorkflow Customizable Workflow]''' state machine, declared in the trac.ini file, with the same syntax as for Ticket workflows (I may have reused some existing code here :-) * '''[http://trac-hacks.org/wiki/TestManagerForTracPluginWorkflow#Howtoprovidecustomoperations Customizable Workflow Operations]''', via a plugin api so that any component can provide its custom operations to be performed upon any workflow action, as defined in the trac.ini file. * Workflow also supports a listener API for components interested in state transitions and actions performed * Workflow states also support custom properties, so to be able to convey additional context information on a workflow state and use it in listeners or directly from the database. The developed workflow engine is able to work on any Trac Resource, it is not confined to this plugin ones. You can then define a workflow on any Trac resource, including Wiki pages, declaratively in the trac.ini file. You will then add a handful of custom code (for example in an ITemplateStreamFilter) to add the markup that the workflow engine generates for you to your desired Trac web page. See [wiki:TestManagerForTracPluginWorkflow#Extendworkflowsupporttoanyofyourartifacts this page] for further details. The '''programmatic''' and the '''RESTful API''' are documented in details in this page TestManagerForTracPluginApi. Here follows an overview of the plugin functionalities. For a brief [wiki:TestManagerForTracPlugin#Tutorialaspowerpointpresentation tutorial], refer to the powerpoint presentations attached below. Note, anyway that the tutorial was developed for release 1.0.0 and so does not cover Test Plans, Workflows and Custom properties. [[BR]] [[BR]] == Test Catalogs == Test catalogs contain sub-catalogs or Test Cases. A Javascript tree view displays a catalog node and its sub-tree, including all of the test cases contained. Next to each catalog (or sub-catalog) a number in brackets shows the number of test cases it contains. Notice at the top of the page breadcrumbs to easily navigate up in the catalogs tree. You can '''choose between a tree-like and a tabular representation''' of the catalog and all of its contained sub-catalogs and test cases, as shown in The former is useful to actually work on the Test Catalog, adding sub-catalogs and new test cases, or modifying them. The latter, which also reports a printout of all the Test Case descriptions, may be useful for a Test Engineer to save or print as a handout to actually run the test cases in the catalog. You can add sub-catalogs or Test Cases simply by entering a name (blanks and case are supported) and click the appropriate button. A new wiki page is generated, with a naming convention allowing the plugin code to position it correctly in the catalogs tree, and opened for browsing. If you wish to edit the title or add some textual contents to the (sub-)catalog, click on "Edit Page" at the bottom of the screen. '''Be careful''' that the first line (the one surrounded by '==') will always be taken as the title of the catalog (the same stands for test cases, read below), so do not remove this line. You can edit this line to change the test catalog title, anyway. Just save the page ("Submit Changes") to save your textual changes to the (sub-)catalog. To '''delete a Test Catalog''' you must delete the corresponding Wiki page. Notice that this operation does not delete all of the Test Cases contained in the Catalog. You must either delete each Test Case individually, or first move them into a different catalog first. If you '''mistakenly deleted''' a Test Catalog, you can save the day by recreating a Wiki page with the exact name. To do so, enter the desired name directly in the browser's URL, after the /wiki/ part. Trac will show you an empty page for the catalog, but already populated with all of your existing test cases and sub-catalogs. Click on "Create this page", give it a title (surrounded by '==') and submit your changes. The new (old) catalog is in place. [[BR]] [[BR]] [[Image(screen2.JPG)]] [[BR]] '''Tree View of the Test Catalog''' [[BR]] [[BR]] [[Image(screen13.png)]] [[BR]] '''Tabular view of the Test Catalog''' [[BR]] [[BR]] === Importing Test Cases from a CSV file into a Test Catalog === If you already have Test Cases defined elsewhere you can import them into the Test Manager. While browsing a Test Catalog, click on "Import Test Cases" at the bottom of the page. The dialog box shown in the following figure will pop-up. Browse for the CSV (comma-separated values) file containing your Test Cases, specify the value separator (default is the comma character) and click "Import". The CSV file must have the following format. The first row will have column names. Use lowercase identifiers, with no blanks, for them. The data must start from the second row. There must be at least the following '''required columns''': * title * description Any subsequent columns are optional, and will generate [wiki:TestManagerForTracPlugin#Customfields custom test case fields]. To fully appreciate custom fields, switch to the Test Catalog Tabular view. A sample CSV file may be the following: {{{ title,description,platform,greetings First Test Case,This is the long description for the first test case,linux,bye bye Second Test Case,This is the long description for the second test case,windows,ciao Third Test Case,This is the long description for the third test case,macosx,hasta la vista }}} [[BR]] [[BR]] [[Image(screen18.png)]] [[BR]] '''Import Test Cases dialog''' [[BR]] [[BR]] == Test Cases == Test Cases are the smallest units of test execution. They are implemented again as wiki pages, with a naming convention that allows the plugin code to recognize them and treat them appropriately. To add Test Cases into a Test Catalog, open the catalog, go to the bottom of the page and enter a name for the new Test Case to be created into the appropriate text box (blanks and case are supported). Then click the button "Add a Test Case". A new wiki page is generated, with a naming convention allowing the plugin code to position it correctly in the catalogs tree, and opened for editing. '''Be careful''' that the first line (the one surrounded by '==') will always be taken as the title of the Test Case, so do not remove this line. You can edit this line to change the test case title, anyway. You can then add the Test §Case description just below the first line (i.e. title), using WikiFormatting, adding attachments and everything else is supported for Wiki pages. When you are done, save the page ("Submit Changes") to save your new Test Case. To '''delete a Test Case''' you must delete the corresponding Wiki page. Again, notice the breadcrumbs at the top, useful to go back to the enclosing catalog or any catalog up the hierarchy. [[BR]] [[BR]] [[Image(screen3.JPG)]] [[BR]] [[BR]] == Moving or Copying Test Cases from one catalog to another == It is also possible to move a single Test Case, or copy multiple Test Cases into a different catalog, with an experience similar to cut&paste. === Moving a single Test Case === To move a single Test Case from one catalog into a nother, you: 1. Open the Test Case 2. Click on the "Move the Test Case into another catalog" button. This is similar to a "cut" operation. 3. Navigate and open the destination catalog 4. Click on "Move the copied Test Case here" button (which only appears if a Test Case has been cut first). It is also possible to cancel the operation at any time by clicking the "Cancel" button in a Gmail-type of yellow message at the top of the page. [[BR]] [[BR]] [[Image(screen6.JPG)]] [[BR]] '''Moving a single Test Case''' [[BR]] === Copying multiple Test Cases === To copy one or more Test Cases, even from different catalogs, and paste them all together into a destination (sub-)catalog, you: 1. Open the Catalog. Expand the tree nodes as you like. 2. Click on the "Select Multiple Test Cases" button. A checkbox appears next to every Test Case in the catalog and the sub-catalogs. See the next figure. 3. Select the Test Cases you wish to copy into another catalog. 4. Click on the "Copy the Selected Test Cases" button. This is similar to the usual "Copy" operation. 5. Navigate and open the destination catalog, or create a new one. 6. Click on "Paste the copied Test Cases here" button (which only appears if Test Cases have been copied first). Note that the test execution statuses (i.e. successful, failed, etc...) associated to the original Test Cases in any Test Plan are not copied along with them. [[BR]] [[BR]] [[Image(screen17.png)]] [[BR]] '''Copying multiple Test Cases''' [[BR]] == Test Plans == '''Since: 1.1.0''' A Test Plan represents a plan for a particular execution of all the Test Cases in a Test Catalog (or sub-catalog). Think for example at the build verification test following a nightly build, or, for traditional projects, Technical Test and eventually Client Test. Thus a Test Plan is associated to one Test Catalog, or sub-catalog. You can have any number of Test Plans for one Test Catalog, anyway. The list of Test Plans you generated for a Test Catalog is displayd in a table at the bottom of the same catalog, as shown in the following figure. [[BR]] [[BR]] [[Image(screen9.JPG)]] [[BR]] [[BR]] To create a Test Plan for a catalog, open the desired Test Catalog (or sub-catalog), enter the name of the new Test Plan in the appropriate test box and click "Generate a new Test Plan". The new Test Plan will be opened for display, showing all of the Test Cases in the catalog, in the "Untested" status. As with Test Catalogs, you can '''choose between tree-like and a tabular representation''' of the Test Plan, as shown in the figures below. The former is useful to actually work on the Test Plan and to view test cases before actually going and executing them. The latter, which indicates for each Test Case the latest status modification and its author, may be useful to keep as the documentation of a just run test plan. [[BR]] [[BR]] [[Image(screen7.JPG)]] [[BR]] '''Tree View of the Test Plan''' [[BR]] [[BR]] [[Image(screen14.png)]] [[BR]] '''Tabular view of the Test Plan''' [[BR]] [[BR]] To track the execution status of a Test Case in a particular Test Plan, open it by clicking on the Test Case name from the Test Plan tree. Then simply click on the corresponding light in the semaphore at the bottom of the page, as shown in the following figure. You don't need to save anything, the change is immediately recorded in the database by means of an Ajax call (this API will be documented asap, to allow for setting test case execution status from external applications). The change is immediately reflected in the Test Plan. [[BR]] [[BR]] [[Image(screen8.JPG)]] [[BR]] [[BR]] === Custom Test Case Outcomes (i.e. states, verdicts) === '''Since: 1.4.1''' You can customize the Test Case outcomes (i.e. states, verdicts) to match your internal quality process. The default outcomes are configured in trac.ini at plugin installation (or upgrade) time as follows: {{{ [test-outcomes] green.successful = Successful red.failed = Failed yellow.to_be_tested = Untested default = to_be_tested }}} You can '''customize the outcomes''' at any moment by adding new outcomes, or modify the descriptions of the current ones. Do not delete previous outcomes if you have already assigned them to any of your test cases. For example, to add a new outcome named "It's a Mess!!!" to the failures, add a line like the following, in trac.ini: {{{ red.bigmess = It's a Mess!!! }}} You will now be able to choose it when assigning a test case status (using the semaphore). See the following figure. [[BR]] [[BR]] [[Image(screen15.png)]] [[BR]] [[BR]] === Linking a Ticket to a Test Case === When viewing a Test Case, you can open a new Ticket by means of the "Open Ticket on this Test Case" button. The new ticket will contain a link back to the corresponding Test Case and, if you were viewing it in the context of a particular Test Plan, of the Test Plan as well. Additionally, a '''[wiki:TestManagerForTracPluginApi#GettingalltheTicketsrelatedtoaTestCase programmatic Python API]''' is provided to retrieve all of the Tickets opened against a Test Case, in all or in a specific Test Plan. This plugin also supports the TracTicketTemplatePlugin to fill a ticket template with this information. In this case, you can use the following parameters in the template to receive the information: * testCaseNumber: The wiki page for the corresponding Test Case * planId: The ID of the Test Plan * planName: The name of the Test Plan For example, to get the test case number, you template will have something like: {{{ bleah bleah Test Case: %(testCaseNumber)s bleah bleah }}} === Showing Tickets related to a Test Case === While browsing a Test Case, either inside or outside of a Test Plan, you can show all of its related Tickets - i.e. Tickets that were opened using the above "Open a Ticket on this Test Case" button. To do this, just browse the Test Case and '''click on the "Show Related Tickets" button'''. If you are browsing a Test Case "definition", i.e. from a Test Catalog, you will be shown all of the Tickets opened against the Test Case '''in any Test Plan'''. If you are instead browsing a Test Case in a specific Test Plan, you will be shown all of the Tickets opened against the Test Case '''in that specific Test Plan'''. See the following figure for what happens when you click on the "Show Related Tickets" button from the Test Case shown at the previous section. [[BR]] [[BR]] [[Image(screen16.png)]] [[BR]] [[BR]] == Custom fields == '''Since: 1.2.0''' Custom fields can be added to the four test objects and to the [wiki:TestManagerForTracPluginWorkflow workflow] state object, by declaring them in the trac.ini file. The syntax is the same used for custom Ticket properties, only the name of the ini file sections are specific: you must use the test artifact type name followed by "-tm_custom". The test artifacts type names are the following: * testcatalog * testcase * testplan * testcaseinplan For example, the following sections in the trac.ini file define one custom property for each of the above artifacts. {{{ [testcatalog-tm_custom] prop1 = text prop1.value = Default value [testcaseinplan-tm_custom] prop_strange = text prop_strange.value = windows [testcase-tm_custom] nice_prop = text nice_prop.value = My friend [testplan-tm_custom] good_prop = text good_prop.value = linux }}} '''Note: Only text property types are currently supported.''' Once defined in the trac.ini file as above, custom fields will be available to the User for browse and for editing in the Web page, as shown next. '''Note: Editing custom properties requires the TEST_MODIFY permission.''' The following screenshot shows a custom "platform" field added to the Test Case artifact, and how it is presented to the User for editing. The value is initially displayed read-only, as a label. Clicking on the pencil icon turns the label into an edit box, allowing the User to edit the value and also displays a "Save" button. Clicking the button immediately saves the new value into the database. [[BR]] [[BR]] [[Image(screen11.png)]] [[BR]] [[BR]] [[BR]] == Customizable Workflow == '''Since: 1.2.0''' The following figure shows a sample [wiki:TestManagerForTracPluginWorkflow workflow] added to Test Cases with custom sample operations. No built-in operation is currently implemented but the sample one shown here, named 'sample_operation', which logs a debug message with the text input by the User. Every object which has a workflow defined is created in a "new" state, so every transition should consider this as the first state in the state machine. This is a sample content of the trac.ini file to associate a workflow to the Test Case object. [[BR]] {{{ [testcase-resource_workflow] sleep = new -> asleep sleep.permissions = TEST_MODIFY sing = new -> singing sing.permissions = TEST_MODIFY sing.operations = sample_operation calmdown = singing -> calm calmdown.permissions = TEST_MODIFY kill = asleep,calm -> dead kill.permissions = TEST_MODIFY }}} [[BR]] Refer to the [wiki:TestManagerForTracPluginWorkflow Workflow Engine] description page for more details. [[BR]] [[BR]] [[Image(screen12.png)]] [[BR]] [[BR]] [[BR]] == Searching and filtering Test Cases in the tree view == A type-ahead, browser-side filtering feature allows for easily locating Test Cases matching a particular naming convention in the title, and/or a particular execution status. This is available both in the context of a Test Catalog and in Test Plans. Multiple words (or parts of) separated by blanks are supported, in AND condition. In the case of a Test Plan, you can also add a test case status to filter by this criterion. The supported statuses are (even substrings of): * untested * successful * failed [[BR]] [[BR]] [[Image(screen4.JPG)]] [[BR]] [[BR]] [[BR]] == Test Management and Execution Statistics == '''Since: 1.1.1''' Charting capabilities allow for tracking the evolution of the test suites and the corresponding test plans. To access the test management statistics, click on '''Test Stats''' in the Trac toolbar on the upper right corner of the page. As shown in the next figure, a chart will be displayed with statistics about all the test cases in the system and a default period of time. By means of the filtering criteria at the bottom of the chart, you can select the desired period of time, the chart resolution (in terms of time between different samples) and the Test Plan for your chart. You can bookmark the URL named "Static URL" at the bottom of the page in order to go directly with the current selected filtering criteria. '''Note:''' You will need internet connection from your client machine to be able to display this charts, since it leverages Yahoo remote charting services. [[BR]] [[BR]] [[Image(screen10.png)]] [[BR]][[BR]] == Security == The following new permissions are available to manage the Test Manager security: * TEST_VIEW - Ability to view test catalogs and test cases * TEST_MODIFY - Ability to create and edit test catalogs and test cases * TEST_EXECUTE - Ability to change the status of a test case in a test plan * TEST_DELETE - Ability to delete test cases * TEST_PLAN_ADMIN - Ability to generate and delete test plans * TEST_STATS_VIEW - Ability to view test management statistics [[BR]][[BR]] == Programmatic API == The '''programmatic RESTful API''' is documented in details in this page TestManagerForTracPluginApi. [[BR]][[BR]] == Tutorial (as powerpoint presentation) == '''TODO:''' These tutorials document release 1.0.3 and so need to be updated with the Test Plan and other recent features. * attachment:"UserGuide_part_1.ppt" * attachment:"UserGuide_part_2.ppt" * attachment:"UserGuide_part_3.ppt" [[BR]][[BR]] == Project site == Project site: http://sourceforge.net/projects/testman4trac/ The project is also on Pypi: http://pypi.python.org/pypi/TestManager [[BR]][[BR]] == Bugs/Feature Requests == If you have any issues, create a [http://trac-hacks.org/newticket?component=TestManagerForTracPlugin&owner=seccanj new ticket]. Existing bugs and feature requests for TestManagerForTracPlugin are [report:9?COMPONENT=TestManagerForTracPlugin here]. [[TicketQuery(component=TestManagerForTracPlugin,format=table,col=summary|status|severity|priority|milestone|type|owner|time|description)]] [[BR]][[BR]] == Download == Download the egg files, ready to be installed, from the project site [http://sourceforge.net/projects/testman4trac/files here]. [[BR]][[BR]] == Source == You can download the source code from [https://sourceforge.net/projects/testman4trac/files here]. [[BR]][[BR]] == Installation == Both '''Trac 0.11 and 0.12 are supported''', and also both '''Python 2.5 and 2.6'''. There are '''known issues on Trac 0.11 with MySQL and PosgreSQL''', caused by lack of Trac support to the "int64" database column type. If you plan to work with MySQL or PosgreSQL '''you will need to run Trac 0.12.''' Hint: The database user (MySQL or PosgreSQL) must have read access to the trac.ini! The plugin can be installed as usual, from the Trac administration panel, and requires a database upgrade. You can follow the instructions in the INSTALL.txt file contained in the binary packages. The functionalities are divided in three plugins, which must be installed in this order: 1) Trac Generic Class 2) Trac Generic Workflow 3) Test Manager An additional plugin is only useful for debugging and should not be installed in a production environment. * SQL Executor With the latter plugin, you can perform arbitrary SQL queries on the Trac database from a web browser. Just type on the URL: !http://yourserver/yourenvironment/sqlexec?sql=any SQL statement For example: !http://localhost/sampleproject/sqlexec?sql=select * from testcatalog Follow the tutorial presentation that you can download from the project site to start. The tutorial is actually very old and needs to be updated to the new Test Plans and other features, but it will get you started. [[BR]][[BR]] == Troubleshooting == === Is setuptools properly installed? === Try this from the command line: {{{ $ python -c "import pkg_resources" }}} If you get no output, setuptools is installed. Otherwise, you'll need to install it before plugins will work in Trac. === Did you get the correct version of the Python egg? === Python eggs have the Python version encoded in their filename. For example, MyPlugin-1.0-py2.4.egg is an egg for Python 2.5, and will not be loaded if you're running a different Python version (such as 2.6 or 2.7). Also, verify that the egg file you downloaded is indeed a ZIP archive and not the HTML preview page instead. === Is the plugin enabled? === If you install a plugin globally (i.e. not inside the plugins directory of the Trac project environment) you will have to explicitly enable it in trac.ini. Make sure that: * you actually added the necessary line(s) to the [components] section * the package/module names are correct * the value is “enabled", not e.g. “enable” === Check the permissions on the egg file and on the trac.ini file === The user user to run Trac (either tracd or Apache) must be able to read the egg files. Also, it's been reported that for PosgreSQL also its user must be able to read trac.ini. === Check the log files === Open the Trac Admin tab, enable logging and set the log level to DEBUG, then watch the log file for messages about loading plugins. === Verify you have proper permissions === Some plugins, including the Test Manager ones, require you have special permissions in order to use them. See [wiki:TestManagerForTracPlugin#Security] for a description of the available/required permissions. === Is the wrong version of the plugin loading? === If you put your plugins inside plugins directories, and certainly if you have more than one project, you need to make sure that the correct version of the plugin is loading. Here are some basic rules: Only one version of the plugin can be loaded for each running Trac server (ie. each Python process). The Python namespaces and module list will be shared, and it cannot handle duplicates. Whether a plugin is enabled or disabled makes no difference. A globally installed plugin (typically setup.py install) will override any version in global or project plugins directories. A plugin from the global plugins directory will be located before any project plugins directory. '''If your Trac server hosts more than one project''' (as with TRAC_ENV_PARENT_DIR setups), then having two versions of a plugin in two different projects will give uncertain results. Only one of them will load, and the one loaded will be shared by both projects. Trac will load the first found - basically from the project that receives the first request. Having more than one version listed inside Python site-packages is fine (ie. installed with setup.py install) - setuptools will make sure you get the version installed most recently. However, '''don't store more than one version inside a global or project plugins directory''' - neither version number nor installed date will matter at all. There is no way to determine which one will be located first when Trac searches the directory for plugins. === Have you restarted Apache? === For Apache to sense a plugin upgrade (and sometimes even installation), it must be restarted. === If all of the above failed === OK, so the logs don't mention plugins, the egg is readable, the python version is correct and the egg has been installed globally (and is enabled in the trac.ini), you restarted Apache and it still doesn't work or give any error messages or any other indication as to why? Open a ticket here. The plugins maintainers (yes, it's me :-)) watch ticket notifications continuously. [[BR]][[BR]] == Recent Changes == Note: you can '''subscribe to the [https://sourceforge.net/projects/testman4trac/forums/forum/1200598 Forum]''' to be updated on new releases. [[BR]] [[BR]] '''During the last months:''' [[BR]] '''Release 1.4.5''' (2011-05-21): o Enhancement #8825 (Track-Hacks): Ability to import test cases from Excel (CSV) file[[BR]] '''Release 1.4.4''' (2011-03-11): o Fixed Ticket #8567 (Track-Hacks): Javascript error when deleting test plans[[BR]] o Enhancement #8596 (Track-Hacks): Remove hard dependency on XML RPC plugin for Trac 0.11[[BR]] o Enhancement #8761 (Track-Hacks): Copy multiple test cases into another catalog[[BR]] Added wiki documentation for '''copying multiple test cases into another catalog'''. '''Release 1.4.3''' (2011-01-20): o Enhancement #8427 (Track-Hacks): Add XML-RPC complete interface for remote management of test objects[[BR]] Added wiki documentation for '''[wiki:TestManagerForTracPluginRPCApi the new XML-RPC API]'''. '''Release 1.4.2''' (2011-01-09): o Fixed Ticket #8378 (Track-Hacks): Set date and time format correctly in Test Stats page[[BR]] Also added support for custom test case outcomes in the Test Stats page[[BR]] Added Wiki documentation on the ability to customize the test case outcomes (i.e. states, verdicts) and to link Tickets to Test Cases. '''Release 1.4.1''' (2010-12-27): o Enhancement #7486 (Track-Hacks): Customizable test case outcomes (aka verdicts)[[BR]] o Enhancement #7570 (Track-Hacks): Add a relationship table between tickets and test cases in plan, and corresponding API[[BR]] o Added wiki documentation on the '''[wiki:TestManagerForTracPluginGenericClass Generic Persistent Class framework]'''[[BR]] '''Release 1.3.12''' (2010-12-19): o Enhancement #8321 (Track-Hacks): Add standard internationalization support (i18n)[[BR]] o Enhancement #8322 (Track-Hacks): Show timestamps according to User's locale[[BR]] o Fixed Ticket #8323 (Track-Hacks): Unable to expand Available plans and Test case status change history collapsable sections[[BR]] '''Release 1.3.11''' (2010-12-02): o Added out of the box operation to workflow engine: set_owner and set_owner_to_self[[BR]] o Enhancement #8259 (Track-Hacks): Add navigation from a test case to its related tickets[[BR]] '''Release 1.3.10''' (2010-11-28): o Fixed Ticket #8154 (Track-Hacks): LookupError: unknown encoding: cp0[[BR]] '''Release 1.3.9''' (2010-11-23): o Fixed Ticket #8144 (Track-Hacks): Test statistical charts don't show successful and failed figures[[BR]] '''Release 1.3.8''' (2010-11-23): o Fixed Ticket #8121 (Track-Hacks): Catalog Wiki Page not added[[BR]] o Fixed Ticket #8123 (Track-Hacks): Can't move testcase more than one time into different catalog[[BR]] o Fixed Ticket #8124 (Track-Hacks): AttributeError: 'NoneType' object has no attribute 'splitlines'[[BR]] o Fixed Ticket #8125 (Track-Hacks): "duplicate test case" does not work for previously moved test case[[BR]] '''Release 1.3.7''' (2010-11-20): o Enhancement #7704 (Track-Hacks): Add ability to delete a Test Plan[[BR]] o Fixed Ticket #8084 (Track-Hacks): Ordering issue[[BR]] '''Release 1.3.6''' (2010-11-09): o Fixed Ticket #8004 (Track-Hacks): Cannot search if an admin[[BR]] '''Release 1.3.5''' (2010-10-17): o Restored compatibility with Trac 0.11. Now again both 0.11 and 0.12 are supported.[[BR]] [[BR]][[BR]] == Author/Contributors == '''Author:''' [wiki:seccanj] [[BR]] '''Maintainer:''' [wiki:seccanj] [[BR]] '''Contributors:'''