jubula/proposal.html - www.eclipse.org/proposals - Git at Google

 <!--
 	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&ouml;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&ouml;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>
	<!--
	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>