From: xia zhao <[email protected]> Subject: Re: Proposal for AOO test tool Date: Tue, 14 Feb 2012 11:32:15 +0800
> I give 1+ for test tools usage for AOO 4.0 based on below points: +1. > 1. For community product, we don't know if same resoruce will be there for > next release. right. > 2. We sould follow the strategy that automtic more and more test cases, but > for these automated test cases, as one experienced QA who have worked > on this area for nearly 10 years, many automatic test cases comes from > manual test cases, that is, bettter structuring the cases first and > selecting some to automatic, considering that not all of cases can be > automaticed. YES. > 3. Form quality view, it's better have one tool to track QA effort. > > But one easy and simple to maintance testing tool should be proposed. > > Besides, Rob's transfering bugzilla issues to test cases is one good idea. > > 2012/2/14 Rob Weir <[email protected]> > >> On Mon, Feb 13, 2012 at 6:55 AM, Ji Yan <[email protected]> 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? >> >> 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? >> >> The above link should be only one sample. The performance depends on the > where to host it and the network speed. I care more about even TestLink is > one good tool to community to use, is it possible ASF host it? > >> -Rob >> >> > >> > Thanks & Best Regards, Yan Ji >>
