Community
Participate
Working Groups
update based on requirements group review
http://dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/hyades-home/docs/unapproveddrafts/project%20info/plans/3+/features/hf_74841.html
*** Bug 80395 has been marked as a duplicate of this bug. ***
Deferred per replan.
Downstream products no longer require and have withdrawn request. We should review further to determine if needed in future release.
*** Bug 80741 has been marked as a duplicate of this bug. ***
Using the same black check to indicate a test case has been run in the manual testcase remote application (whether the test status is pass, fail, error, inconclusive) is misleading and not as user-friendly as presenting an icon that matches the committed status of that particular executed test case. For example, a green check for pass, etc, probably would be based on the test execution history for consistency. Some might argue this is duplicating the role of the execution history viewer, but I think it allows someone to sort of get an idea of their test suite progress as they manually complete the sequential test cases.
I recently used the manual test client to perform some manual tests and here’s my feedback: I personally didn’t see the point of having to run a standalone swing application to update my test cases. Instead I was reading instructions from the test editor and performing my test cases. I only executed the swing application to generate the execution history file. I don’t know how much use other users have found with the swing application. I suppose that it would be useful for remote testing. If there are plans to keep it around, I think it would be useful to switch to SWT (for usability issues). What would really be useful to have as a tester is for the editor to make a distinction between “what” a step is and “how” it is performed. Currently, we provide a primitive text area in the test editor for the test case designer to input their instructions for manual testing. As a tester, I would like to read as little as possible when doing a test case. If I have done a test case 40 times in the past, I don’t want the instructions to have to tell me how to do it. It would also be nice to have the ability to use rich text styles (bolding, colouring, etc…) that would make the tester focus on what is important. The trick is to present instructions in a clear and user-friendly way that would give users reasons to use the test perspective as opposed to having instruction stored in a primitive editor such as notepad. Hope my feedback helps a little.
Ali, the Swing application is especially good for remote testing, you start the manual test runner application on a remote machine and then follow the instructions there, it was written in Swing so it can run on all platforms supported by Java AWT (SWT platform coverage list is smaller).
Changing to P1 as per the 4.1 official plan.
Description document: http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_74841.html
*** Bug 92078 has been marked as a duplicate of this bug. ***
*** Bug 76691 has been marked as a duplicate of this bug. ***
Consult the Description Document (http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_74841.htm l) for a full explanation of the requirements/features/design for this enhancement.
*** Bug 76694 has been marked as a duplicate of this bug. ***
*** Bug 76689 has been marked as a duplicate of this bug. ***
I looked in more detail to the design document and I found (after my attention was captured by Bug 91181) that you intend to use the EMF test model (both testcase and execution result) in this new client. My comment is that the runners (including the manual one) should be light-weight, although I agree with the need of better support for attachments and rich text in the description (HTML or XML with XSL might do the trick here, you could reuse the browser on the target machine), I don't think that using the execution result model would be appropriate (even testcase model to some extent). If you'll use the EMF model you'll basically duplicate some functionality from the TPTP Eclipse client and you'll also need a special mode for this case (to send execution results instead of events).
Moving the version of this feature to 4.2 for consideration for the TPTP 4.2 plan for the outstanding work items that will not be completed in 4.1.
Inconsistencies exist between TPTP/AC and SWT support statements for the Manual Test Client. There exists platforms that are supported by TPTP (e.g. Agent Controller) but not supported by SWT/JFace. As such, despite shipping the binaries for the Manual Test Client on these platforms that do not support SWT/JFace, the Manual Test Client is not supported. The Manual Test Client should report an error back to the client workbench when SWT or UIs are not supported on the deployed platform.
Highly desirable and planned for this release, but not stop ship
(In reply to comment #20) > Highly desirable and planned for this release, but not stop ship CORRECTION: P1 Cannot ship without this enhancement
Theme(s) for this enhancement: -Design for Extensibility: Be a Better Platform -Scaling Up -Simple to Use -Appealing to the Broader Community
*** Bug 113605 has been marked as a duplicate of this bug. ***
Expose the description of the manual test invocation in the Manual Test View. The description of the manual test invocation is different than the description of the test itself but should be exposed in the Manual Test View.
proposed to be planned for 4.2 but need to clarify the remaining work and sizing (investigate keyword added)
Target set to 4.2
Fixes checked in to TPTP v4.1 under the associated defects: 105437 105439 105441 105442 105443 110436 111068 See the enhancement's Description Document (see URL property of this enhancement) for a detailed explanation of the completed work items for this enhancement. The remaining work items will be addressed in a future release of TPTP under enhancement https://bugs.eclipse.org/bugs/show_bug.cgi?id=121100.
Verified in TPTP-4.1.0-200511230100B.
