Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F00609AF4 for ; Fri, 17 Feb 2012 05:28:57 +0000 (UTC) Received: (qmail 15876 invoked by uid 500); 17 Feb 2012 05:28:57 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 15804 invoked by uid 500); 17 Feb 2012 05:28:56 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 15746 invoked by uid 99); 17 Feb 2012 05:28:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2012 05:28:54 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yanji.yj@gmail.com designates 209.85.212.175 as permitted sender) Received: from [209.85.212.175] (HELO mail-wi0-f175.google.com) (209.85.212.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2012 05:28:47 +0000 Received: by wibhq7 with SMTP id hq7so1385582wib.6 for ; Thu, 16 Feb 2012 21:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ScV8QmfaRZ9B2+I3dkYjVk4uyyYwXYGj55xGz4zSpO0=; b=LWUqUQarVvUtRaywv4EA8l65bzxoGdYc+Ddck1F9bUvERn5ghHpFFd8CnuxJoFGwEC q8HjAFEaBgH65iLhouyEAP+HOghM2jBtHkRZrFsba42ayB/qJ7fW83QgIIf5Zb3UP90v O764RFlLPVnPpPf0yv14q/DOMt7UtvZe1XldY= MIME-Version: 1.0 Received: by 10.216.138.234 with SMTP id a84mr2949828wej.40.1329456507012; Thu, 16 Feb 2012 21:28:27 -0800 (PST) Received: by 10.227.206.148 with HTTP; Thu, 16 Feb 2012 21:28:26 -0800 (PST) In-Reply-To: <4F3A174A.1030303@a-w-f.de> References: <4F3A174A.1030303@a-w-f.de> Date: Fri, 17 Feb 2012 13:28:26 +0800 Message-ID: Subject: Re: Proposal for AOO test tool From: Ji Yan To: ooo-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e6d7755cd846cc04b922368b X-Virus-Checked: Checked by ClamAV on apache.org --0016e6d7755cd846cc04b922368b Content-Type: text/plain; charset=ISO-8859-1 Thanks for all of your response. I like your brilliant idea, but from QA point of view, I'm afraid it couldn't help our work. A formal tester should follow test case to do test, once test is done, tester fills result in a document, we called it as execution record. QA lead will generate test report regularly based on the execution records, and QA manager or PM and others will know the test status. From this procedure we can tell test case is base element of test, and we need to generate test report based on execution record. If we use bugzilla to record test case, where could we put result into? If we put test case to wiki page, where could we put result into? another wiki page? while, how could we generate test report? I don't think bugzilla and wiki page are right approach. So, a powerful test management tool will help us on managing test case, test execution and work procedure. So I strongly recommend using test tool to manage our QA work. Here I bring another question, if I want to install the tool into web server, how to do that? Who will help me on this? 2012/2/14 Andre Fischer > On 13.02.2012 22:17, Rob Weir wrote: > >> On Mon, Feb 13, 2012 at 6:55 AM, 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. >>> >> >> I wonder if Bugzilla would be better than the wiki? >> > > Hm, to me the wiki seems to be a better place. I think of the manual test > cases as some form of documentation (about how and what to test). The wiki > provides better support for organizing and searching. But, not being a QA > engineer, I can easily be mistaken. > > -Andre > > > >> We could create a "product" in BZ for all test cases, with >> "components" under that for different test areas, like "performance >> test", "smoke test", "detailed test", etc. >> >> One BZ issue per test case. >> >> For each test pass, we simply reset each test case/issue back to "New >> state". We then test each issue. If the test case passes, then we >> mark the BZ issue as closed. If the test case fails, then we already >> have a BZ issue for the developers. >> >> Pro: Makes it very easy to make new test cases from existing BZ >> issues, or to make BZ issues from testcases. >> >> Con: Reporting not so good. Does not handle doing multiple test >> passes in parallel. For example, if we wanted to test AOO 4.0 in >> parallel with a maintenance AOO 3.4.1 release. >> >> >> 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 >>> >>> [1] http://testlink.sourceforge.**net/docs/testLink.php >>> -- >>> >> >> I tried their demo site. It was very slow. Does anyone have >> experience with Test Link? >> >> -Rob >> >> >>> Thanks& Best Regards, Yan Ji >>> >> -- Thanks & Best Regards, Yan Ji --0016e6d7755cd846cc04b922368b--