Hi Joost,
Joost Andrae a écrit :
Hi,
What I'd like to see in the future is:
- joint and better coordinated efforts from QA and development to
*fix* bugs
What I'd like to see is:
- joint and better coordinated efforts from QA and development to test
and QA features and to qualify bugs/issues and to work together on
creating/designing an improved product.
yes, I'm all with you here, less complains and a better opinion of the
work we achieved would be how I formulate it ;)
Trying to contribute in some QA places, I would like a clear how-to
achieve this. On the last time I've had the impression that whatever
the tools or the manual tests you run, they are not useful or not the
good way to help. I had the impression that developers were not happy
because the QA of cws took to much time, do we lack people here,
skills or is it on bug triage ? May be having a more concrete picture
on where we are needed would help to better employ our energy ;)
The QA project has application related sub teams. These teams are happy
to get other people involved into application related testing and QA and
to work on child workspaces. Doing automation is useful even if you do
not find an error within the test scripts you've run. The more
http://quaste.services.openoffice.org gets status information of
testruns the better we can check if there are regressions within the
version that has been tested (eg. a CWS) vs. the last master workspace.
To improve this we need people who write Testtool testscripts.
Well, you describe a kind of wonderful world I didn't found yet. I've
run automation testools several time on several versions, only to find
that my tests was not reliable and didn't help any where unless I make
the same tests manually.
Confirming issues is important. If a developer get's some sort of cook
book to reproduce an issue the better he/she will be able to find a
solution to fix this issue. But it is not the job of the QA team to
define the issues to be fixed. This must be a common understanding
between QA, development and other stakeholders and more important it's
influenced by the sponsor of the developer.
You have a definition I miss: who is a sponsor. I this this word in
several mails and in the PDF doc Marint indicated, but how do you define
a sponsor?
- the common goal of the project to work on bugfixing (instead of the
separate statement of the QA project that fixing bugs is not within
our responsibility)
Bugs/issues are usually not fixed by someone within the QA team but by a
developer.
yes, but it's a work together approach.
Yes and on a side note, I've already heard from some developers that
QA is not within their responsibility, so yes, it links to what you
said above, a better work together.
QA and development must work together to get a common understanding
about what needs to be fixed within the next version. On the other hand
we have restricted man power on both sides (Development and QA) so we
need to talk about what can be fixed and what needs too much time and
what's more important. It's always a negotiation to define what get's in
and what get's out of the upcoming release.
Yes, but we know that the negotiation is currently arbitrary and doesn't
rely on the community involvement.
- the commitment to fix bugs even in old features (and not only
regressions). Each feature once was new. Following our current policy
you just need to wait long enough to counter the regression argument.
A regression is a regression... If a regression is found then it should
be marked as regression. Regressions get more attention to be fixed
within the upcoming version.
Yes, you're right, my fear is that the release list may become
overwhelmed by the request of each of us, but this is may be a good
thing, I'm not able to say.
How could we help?. Is there a vision on how the workflow of the
volunteers is organized in the QA project or every body is like me,
working on confirming issues, then closing verified, then manual
testing depending of my mood of the day. May be some management is
needed here also to better organize our forces?
It's up to your motivation what you like to contribute. I cannot force
you to do this and that. There are a lot of opportunities:
what I mean is that I've some skills, some time, some energy, some
willing, I know all the areas describe bellow and have already
participated in almost all of them but...
- automation (testtool, api)
- manual tests
- localization tests
- verifying issues of just integrated child workspaces within the
current master build (to verify there are no integration related issues
regarding this CWS)
- confirming unconfirmed issues (and to check if the description is easy
to reproduce)
... but in the time frame, where is the best way to follow the release
process. For example, I've download m51 today and planed to do Writer
TCS on it the 2 next days, is it really what is needed for QA or is it
more useful that I go on with finding duplicates on unconfirmed issues ?
Personally I'd like to motivate you to work together with eg. Jaqueline
Rahemipour to get all QA teams of all native language teams to have at
least one representative within http://qa.openoffice.org. We could link
those teams together on our QA website.
Yes, I agree with you, may be I could start by list the responsible
personn on QATrack and see who is missing comparing with the NLC.
Joost has bloged on the QA week-end you (the DE project) organized,
I'm sure it was very interesting and productive. May be it could
become an event for the QA project too?
In the mean time this event got visitors from various countries:
Germany
Austria
Switzerland
The Netherlands
Mongolia
Czech Republic
oh great!
I'm sure it would be interesting to have a QA meeting on the upcoming
OpenOffice.org conference instead of (me) doing another presentation
about QA or about the release process. We could prepare an agenda
beforehand if you like.
What do you think ?
It would be a real pleasure for me :)
Kind regards
Sophie
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
