[Libreoffice-qa] about moztrap attachment missing :(

Thomas Hackert thackert at nexgo.de
Wed Mar 27 11:02:02 PDT 2013


Hello Yifan, *,
On Wed, Mar 27, 2013 at 04:34:06PM +0800, Yifan Jiang wrote:
> On Tue, Mar 26, 2013 at 07:00:24PM +0100, Thomas Hackert wrote:
[Version 0 in Moztrap]
> > Hm ... Does this "base version" relate to the version of the test case?
> > 
> > Say: If I write a new test case e.g. for Base (no pun intended ... ;) ),
> > then this would be version 0 (or base version) of this test?
> 
> Yes it is.

O.K.

> > And other versions would be an enhancement to this test? Or a
> > translation? Or ...  ?
> 
> Other versions of test cases could be a direct copy to the 'version 0'
> test case or an enhancement. As you may already notice, currently the
> translation of a test case is embedded inside the test case
> instructions, of course they may be different in different versions
> for a same test case. Except for that we do not leverage versions
> specifically here.

O.K.

> > > When we create a test run for testing, we have to specify a VERSION,
> > > which means exactly only the cases in that VERSION will be shown in
> > > the target test run.
> > 
> > O.K. I think (after logging in Moztrap and clicking through the different
> > menus ... ;) ), I am understanding it now (I hope ... ;) ):
> > 
> > 1. You write the test, which is not LO version specific.
> > 2. Moztrap will assign version 0 to it.
> 
> Yes.
> 
> > 3. After saving the test and clicking on "Editing $Name of the test" you
> > can assign it as an new test (does this the "+1 (add this version)"
> > mean?) or to any existing test case (now only 3.6 and 4.0 are available
> > in the menu).
> > 
> > Am I right? If not, please correct me ... ;)
> 
> You are right and the situation can be more than that. Say we have
> three "Versions" as 0, 3.5, 4.0:
> 
>     1. When creating a new test case:
> 
>         - Select "0" in the Version field
> 
>         - Check on "And Later Versions" box besides "Version" field
> 
>             => this case will be saved for EVERY VERSIONs that LATER
>             than 0, which are 3.5 and 4.0 here.
> 
>             This is why 0 is a proper "base version", that Moztrap is
>             smart to internally identify different versions
>             chronologically: 4.0 is later than 3.5, 0 is ealier than
>             $everything.

But how do you write a test, if you just want it to be used for new
functions – e.g. for the upcoming version 4.1 and later?

>     2. And as you said, in the the situation that the box above
>        is not checked when adding a case, there's still a chance to add
>        the case into other versions one by one by clicking the "+x
>        (add this version)" button.

Do you have to assign the test manually to every version then?

> > > All the above reveals the VERSION importance when we managing test
> > > cases. Moztrap has a solution for how to correctly manage versions. I
> > > am not gonna be verbose here,
> > 
> > Not ;? I think, you are verbose (but in a positive way) ... ;)
> 
> I really hope I could read more Shakespeare to write more elegantly ^^

"G"

> > > but the reason we want to at least
> > > update everything generic in "Version 0" is we want a consistent case
> > > version management. As a result:
> > > 
> > >     - we have a community "agreement" that each case's Version 0 is
> > >       the latest edited version of the test case
> > 
> > Why do you put "agreement" in quotation marks? Is it not an official
> > agreement?
> 
> Well, I simply felt the word agreement is somewhat strong...  :)

O.K.

> > >     - every new version is "branched" from Version 0, so that they can
> > >       include the latest update of the test cases
> > 
> > But how do you "branch" it?
> 
> The "branch" in practice is when we creating a new VERSION, "Copy
> environments and cases from optional" field would do the trick.

O.K.

> > > This is the way how we are gonna manage versions in a cooperative
> > > way. More details can be found in the headache documents above :)
> > 
> > Just out of curiosity: When I start translating a test, would it keep
> > the version number 0 or would it become version 1 then?
> 
> It's version 0 by default as mentioned. See the top right version
> field if you wanna confirm when translating:

I thought, translating and saving my translated part, would count as a
new version or so ... ;)

> > > Just in case, in practice, the 'version' operation of a test case can
> > > be found on the right top corner when you edit a case like:
> > > 
> > >     http://manual-test.libreoffice.org/manage/caseversion/419/
> 
> > > Leave other uninteresting cases for other people who may be interested
> > > in them. That is to say, other people can see which cases have been
> > > executed by you, and vice versa :)
> > 
> > Would this be NL specific or would I see all testers?
> 
> What does it mean "NL speific"? All results are equally sharable and
> people do not special permission to see results.

"Native language" ... ;) Is there a possibility to see team member $X
from the Germanophone project, where he is testing and the like? I would
like to see some kind of filter to filter testers, so I am able to see,
where they are testing, which test failed on them and the like ... ;)

And I have two further questions:
1. When I edit (translate) a test, there is a pulldown menu at the
bottom of the page, where I can choose between "active" (which seems to
be the default), "disabled" and "draft". What happens, if I use "draft"?
Is this related to the whole test case, or is there a possibility to use
"draft" for my translation?
2. On the top of the page there is a button named "Install as Open Web
App". What is this? To install on a cell phone or the like?

Have a nice evening
Thomas.

-- 
> When there isn't sufficient virtual memory, the compiler bails out,
> giving an internal error message. When I kill some processes, the
> error goes away.
And what is the compiler supposed to do instead? Go shopping for you
and buy more memory?
		-- Falk Hueffner, on the GNU C++ compiler


More information about the Libreoffice-qa mailing list