On 2/13/12 2:21 PM, Raphael Bircher wrote:
Am 13.02.12 13:53, schrieb Jürgen Schmidt:
On 2/13/12 12:55 PM, Ji Yan wrote:
Hi all,

Recently, I'm thinking about how testing work should be done and what
the
procedure should followed under Apache OO structure. Before OO goes into
ASF, testing work was controlled by QUASTe and manual test cases
stored in
TCM but both tools were disconnected once Oracle donated OO to
Apache. Now,
it's time for us to think about how can we move on for testing.
While within AOO 3.4, we store the manual scripts in wiki page, it's
good
place at this time, but should not be permanent. As it's hard to tell
test
status and collect testing data, also it has no connection with
automation
test tool.
After review some tools, I find the "Test Link"[1], maybe the proper
tool
for us to manage testing work. If anyone has any suggestion on other
tools,
please let me know. The target is to customize and deploy it to OO
website. I'll move forward with this tool with no objection

I took a quick first look on the demo deployment and I think it looks
promising.

I would definitely support such an approach and think it can be very
useful to track our QA efforts more efficient in the future.

It is probably a good idea to collect more information how this can be
used for AOO and ideally we can collect some experience on a test
installation.

When we are sure that TestLink will be the best choice we have to work
together with the infra structure team on a official deployment. We
have to ensure that we have enough volunteers to maintain this
software and the deployment (e.g. maintenance in general, security
updates).
As I know, The ASF has no testcase management system at all. So maybe
there is a interest from other projects too. So it could be possible,
that Infra will roll out this (or a other tool) for all ASF projects,
like Pootle. So Infra should be involved here.
indeed that is for later, first of all we should be sure if would help our project


But the Question at all is, who use this tool. A tool alone brings
nothing, if you have no people who use it. For my point of view you
can't reflect the quality of AOO in such a tool. Because you can't cover
the functionality of Apache OpenOffice with manual tests.
ideally volunteers from the community who are interested in this. It should be simply seen as too helping to track our QA efforts. And from my point of view it is good to have test cases documented and the status can be easy requested. The more we can automate the better it is. We will always appreciate if users will simply play around with the office and will test new features but we should also appreciate if others would prefer a more structured way.

The project us huge and providing a good quality and stability is a key element for the future success. Our requirement should be to provide professional and well tested software. Or do you think something different?



For my point of view, it's better to tell the testers for each
millestone were the changes are, and wich functionality they should
check for bug. A serios tester write then a small test report. And this
we can manage over a wiki.
and where is the difference to put exactly this into a more structured way with the help of some tooling? Where I agree is that it should be no huge overhead and should be easy to use. But I think we would benefit from well formatted test reports based on a test case.


so I tend to give a -1 for this tool, because I fear that we have at the
and a tool, but not a sensefull testcase set, or we hav a big testcase
set and no one work on it.

I think it is not an either or, again we can only benefit from such a structured approach. Sure we have to provide a good and complete set of test cases and everybody is invited to help here ;-) It's better to share the used test cases that other can use them as well. Who knows if the same resources can do the test for the next release.

Juergen


But this is my personal option.

Greetings Raphael


Reply via email to