| <!-- |
| This document is provided as a template along with some guidance for creating |
| your project proposal. This is just a template. Feel free to change it as |
| you see fit (add sections, remove section). We feel, however, that the |
| suggestions represented in this document represent the reasonable minimum |
| amount of information to move forward. |
| |
| Please keep the formatting in this document simple. Please do not edit |
| this document in Microsoft Word as it adds huge piles of markup that make |
| it difficult to restyle. |
| |
| More information is available here: |
| |
| http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase |
| |
| Direct any questions about this template to emo@eclipse.org |
| --> |
| |
| <html> |
| <head> |
| |
| <!-- |
| Include the title here. We will parse it out of here and include it on the |
| rendered webpage. Do not duplicate the title within the text of your page. |
| --> |
| |
| <title>Jubula Functional Testing Tool</title> |
| </head> |
| |
| <!-- |
| We make use of the 'classic' HTML Definition List (dl) tag to specify |
| committers. I know... you haven't seen this tag in a long while... |
| --> |
| |
| <style> |
| dt { |
| display: list-item; |
| list-style-position:outside; |
| list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif); |
| margin-left:16px; |
| } |
| dd { |
| margin-left:25px; |
| margin-bottom:5px; |
| } |
| </style> |
| |
| <body> |
| <p>The <b>Jubula Functional Testing Tool</b> project is a proposed open source project under the <a |
| href="http://www.eclipse.org/projects/project_summary.php?projectid=technology">Eclipse Technology Project</a>.</p> |
| |
| <!-- |
| The communication channel must be specified. Typically, this is a forum |
| that is available from http://www.eclipse.org/forums with a URL using the |
| project's short name; it will be something along the lines of |
| of http://www.eclipse.org/forums/eclipse.woolsey. EMO can (and will) |
| provide assistance if you're not sure what to put here. |
| --> |
| <p>This proposal is in the Project Proposal Phase (as defined in the |
| Eclipse Development Process) and is written to declare its intent and |
| scope. We solicit additional participation and input from the Eclipse |
| community. Please send all feedback to the <a href="http://www.eclipse.org/forums/index.php?t=thread&frm_id=202">Eclipse Proposals</a> |
| Forum.</p> |
| |
| <h2>Background</h2> |
| |
| <!-- |
| Optionally provide the background that has lead you to creating this project. |
| --> |
| Existing functional testing tools work on the premise that test scripts are saved and managed in the form of code. |
| Depending on the approach, the test automation may involve recording, generation or straight writing of code. |
| <p> |
| However, the introduction of code to acceptance testing has various negative side-effects: |
| </p> |
| <ol> |
| <li> |
| Recorded code is full of duplications and redundancies, as well as being closely linked to the implementation details. |
| A recorded script cannot be used as a flexible, maintainable automated test until it has been refactored. |
| This refactoring work (parameterization, abstraction, removal of duplications) must be done by someone who is an |
| accomplished programmer. |
| </li> |
| <li> |
| The work involved with writing or adapting code to be fit for automated testing is often underestimated. |
| Ensuring that the test code is maintainable, understandable and flexible for all scenarios (on multiple systems) is |
| painstaking work which benefits neither the testing nor the development directly. |
| </li> |
| <li> |
| If the test base is code, then many testers will not be able to work with it. This removes the control |
| over the tests from the testers and places it in the development team, where it must be dealt with alongside |
| other high priority tasks. This introduces unnecessary delays in testing and hinders the test team in |
| writing tests completely from the user perspective. |
| </li> |
| <li> |
| Recording code involves the presence of a working application, but waiting until an application is ready |
| and functional means that the tests lag behind the development and so errors are present in the software |
| for longer before they can be found and resolved. |
| </li> |
| <li> |
| The dependency on a working application means that recorded tests cannot be meaningfully used in agile processes, |
| where acceptance testing must happen in parallel to development, or even beforehand if the development is being |
| acceptance-test-driven. |
| </li> |
| </ol> |
| <p> |
| The Jubula functional testing tool is based on the premise that automated acceptance tests are just as important |
| as the project code, and should adhere to the same best practices (modularity, reusability, and readability) |
| without requiring that any code be produced. This places the power of testing in the hands of the testers and |
| improves accessibility for customers who may want to monitor the tests. The code-free approach keeps test |
| maintenance to a minimum and allows acceptance tests to be written from the user perspective. By focusing |
| on how the user will see the software (as a black-box) , the team can gain valuable quality information |
| which often slips through when only JUnit tests are executed. |
| </p> |
| <p> |
| Test creation in Jubula is achieved using a library of actions which can be combined using drag and drop. |
| This library has been successfully used in diverse projects and already consists of the vast majority |
| of actions necessary to write acceptance tests. |
| </p> |
| <p> |
| The Jubula library is platform and application independent, which means that test creation can begin before |
| the software is available. This is a must for agile processes, where acceptance tests must be created |
| alongside or even before development. Traditional processes also benefit from the earlier involvement |
| of the test team to clear up misunderstandings more quickly. Working with the Jubula library means that |
| tests can be executed as soon as code is committed reducing the time spent between introducing an error |
| and catching it via the tests. |
| </p> |
| <h2>Scope</h2> |
| |
| <!-- |
| All projects must have a well-defined scope. Describe, concisely, what |
| is in-scope and (optionally) what is out-of-scope. An Eclipse project |
| cannot have an open-ended scope. |
| --> |
| <p> |
| Objectives of the Jubula project: |
| </p> |
| <li>Provide tooling for testers and developers to do automated GUI testing on Java and HTML based applications.</li> |
| <li>Specify and maintain a model for test specifications and a persistance layer for the model elements.</li> |
| <li>Provide API for interested projects to generate test scenarios, execute automated tests and get results from these tests.</li> |
| <li>Integrate with other projects to get information to create test scenarios and submit results. This includes tracing changes made |
| by other projects to their data and mirroring these changes back to the test scenarios.</li> |
| |
| <h2>Description</h2> |
| |
| <!-- |
| Describe the project here. Be concise, but provide enough information that |
| somebody who doesn't already know very much about your project idea or domain |
| has at least a fighting chance of understanding its purpose. |
| --> |
| <p> |
| Jubula will provide functional GUI testing support for Java and HTML applications. It will further try to be |
| an anchor point for a broader testing scope including requirements analysis, code coverage of Java applications |
| and test metrics. |
| </p> |
| The initial components will be |
| <ul> |
| <li>Plug-ins which provide the GUI for specifying and maintaining test scenarios.</li> |
| <li>Plug-ins which will provide a persistance layer for the models defined above.</li> |
| <li>Plug-ins for executing automated tests based on the defined scenarios.</li> |
| <li>Plug-ins to test Swing, SWT, RCP, GEF and HTML based applications</li> |
| <li>Server to control test targets on remote platforms.</li> |
| <li>Java agents to control the test targets and provide the test environment.</li> |
| <li>Integration in the JDT and WDT project to enable developers to define and use automated tests.</li> |
| <li>Wrapping the plug-ins into a standalone application to enable testers to define and use automated tests.</li> |
| <li>Tools to use test in batch builds.</li> |
| <li>Extensive online help and external documentation for the tool user.</li> |
| <li>Documentation on extending various parts of the tool.</li> |
| </ul> |
| |
| <h2>Relationship with other Eclipse projects</h2> |
| <p> |
| Jubala will use EclipseLink as a persistance layer. |
| </p> |
| <p> |
| It will integrate with JDT and WDT. |
| </p> |
| <p> |
| It integrates with Mylyn. |
| </p> |
| <p> |
| It supports testing of SWT, RCP and GEF components. Testing RAP is currently under evaluation. |
| </p> |
| <p> |
| We will check on how TPTP and Jubula might benefit from each other. |
| There are areas, for instance code coverage, where the tools complement |
| each other. To our knowledge there is no current development in TPTP on |
| GUI tests or other funtional tests. |
| </p |
| ><p> |
| SWTbot is aiming at programmed jUnit tests and will probably be |
| used mostly by programmers. |
| Jubula on the other hand is focused on non-programmers specifying |
| test scenarios. |
| </p> |
| |
| <h2>Initial Contribution</h2> |
| <p> |
| BREDEX GmbH is offering code from their commercial tool GUIdancer as the intial contribution. |
| This offering consists of the core functionality of the GUIdancer testing tool owned by BREDEX. |
| The code base consists of 2000+ Java classes with 350,000+ lines of code. |
| Some code developed using third-party libraries or developed under a NDA will be removed prior to the contribution. |
| </p> |
| <!-- |
| Describe any existing code that will be contributed to the project. |
| --> |
| |
| <!-- <h2>Legal Issues</h2> --> |
| |
| <!-- |
| Please describe any potential legal issues in this section. Does somebody else |
| own the trademark to the project name? Is there some issue that prevents you |
| from licensing the project under the Eclipse Public License? Are parts of the |
| code available under some other license? Are there any LGPL/GPL bits that you |
| absolutely require? |
| --> |
| |
| <h2>Committers</h2> |
| <p> |
| BREDEX will continue working on the project. The current development team of the product |
| version will continue working on the Jubula project. |
| </p> |
| <!-- |
| List any initial committers that should be provisioned along with the |
| new project. Include affiliation, but do not include email addresses at |
| this point. |
| --> |
| |
| <p>The following individuals are proposed as initial committers to the project:</p> |
| |
| <dl> |
| <dt>Achim Lörke, BREDEX GmbH, Project lead</dt> |
| <dt>Oussama Bouchhioua, BREDEX GmbH</dt> |
| <dt>Zeb Ford-Reitz, BREDEX GmbH</dt> |
| <dt>Dennis Grabow, BREDEX GmbH</dt> |
| <dt>Alexandra Imrie, BREDEX GmbH</dt> |
| <dt>Tim Winselmann, BREDEX GmbH</dt> |
| <dt>Markus Tiede, BREDEX GmbH</dt> |
| </dl> |
| |
| <p>We welcome additional committers and contributions.</p> |
| |
| <!-- |
| Describe any initial contributions of code that will be brought to the |
| project. If there is no existing code, just remove this section. |
| --> |
| |
| <h2>Mentors</h2> |
| |
| <!-- |
| New Eclipse projects require a minimum of two mentors from the Architecture |
| Council. You need to identify two mentors before the project is created. The |
| proposal can be posted before this section is filled in (it's a little easier |
| to find a mentor when the proposal itself is public). |
| --> |
| |
| <p>The following Architecture Council members will mentor this |
| project:</p> |
| |
| <ul> |
| <li>Bernd Kolb</li> |
| <li>Tom Schindl</li> |
| </ul> |
| |
| <h2>Interested Parties</h2> |
| |
| <!-- |
| Provide a list of individuals, organisations, companies, and other Eclipse |
| projects that are interested in this project. This list will provide some |
| insight into who your project's community will ultimately include. Where |
| possible, include affiliations. Do not include email addresses. |
| --> |
| |
| <p>The following individuals, organisations, companies and projects have |
| expressed interest in this project:</p> |
| |
| <ul> |
| <li>Prof. Dr. Karin Vosseberg, Hochschule Bremerhaven (University), Department of Computer Science</li> |
| <li>Björn Schindler, TU Clausthal (Technical University), Department of Informatics</li> |
| <li>Stefan Kastigen, novaObjects GmbH</li> |
| <li>Dr. Frank Gerhardt, Gerhardt Informatics Kft.</li> |
| <li>Holger Staudacher, EclipseSource</li> |
| <li>Werner Keil, emergn</li> |
| <li>Benjamin Muskalla, Tasktop Technologies</li> |
| <li>Ashitha MS, SAP</li> |
| </ul> |
| |
| <h2>Project Scheduling</h2> |
| <table> |
| <tr> |
| <th>Scheduled for</th> |
| <th>Action</th> |
| </tr> |
| <tr> |
| <td>Q4 2010</td> |
| <td>Working on internal changes to make the code base fit for the initial contibution.</td> |
| </tr> |
| <tr> |
| <td>Q1 2011</td> |
| <td>Initial Contribution, Parallel IP, Build</td> |
| </tr> |
| <tr> |
| <td></td> |
| <td></td> |
| </tr> |
| </table> |
| <!-- |
| Describe, in rough terms, what the basic scheduling of the project will |
| be. You might, for example, include an indication of when an initial contribution |
| should be expected, when your first build will be ready, etc. Exact |
| dates are not required. |
| --> |
| |
| <h2>Changes to this Document</h2> |
| |
| <!-- |
| List any changes that have occurred in the document here. |
| You only need to document changes that have occurred after the document |
| has been posted live for the community to view and comment. |
| --> |
| |
| <table> |
| <tr> |
| <th>Date</th> |
| <th>Change</th> |
| </tr> |
| <tr> |
| <td>14-October-2010</td> |
| <td>Document created</td> |
| </tr> |
| <tr> |
| <td>20-October-2010</td> |
| <td>Added mentor, fixed typos</td> |
| </tr> |
| <tr> |
| <td>21-October-2010</td> |
| <td>Final mentors</td> |
| </tr> |
| <tr> |
| <td>26-October-2010</td> |
| <td>added some interested parties, mentioned consideration for RAP testing</td> |
| </tr> |
| <tr> |
| <td>05-November-2010</td> |
| <td>added interested parties</td> |
| </tr> |
| </table> |
| </body> |
| </html> |