QA Improvements on 4.2.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

QA Improvements on 4.2.0

Raphael Bircher-3
Hi all,

I believe the 4.1.4 shows us, that we have to do a better job in QA. A  
minor release should never go to a rc5. I believe we all (and I pointing  
my finger to myself) underestimated the regression risk at the 4.1.4.

So, to do a better job in the 4.2.0 I propose the following changes.

- Define test areas, where tester should keep an extra eye on it. (based  
on the changes)
- Doing Developer Snapshots again in a 2 Week frequency (or so)
- Switch the AOO Profile for the snapshots to AOO-Dev
- mobilize the willing testers to keep a critical eye on this builds
- maybe also run the automated tests for Apache OpenOffice.

The idea is to make the bug cycle shorter. Improvements should be tested  
right after the implementation and not short before the release. A fresh  
bug is easyer to fix as a old one.

What do you think about this.

Regards Raphael


--
My introduction https://youtu.be/Ln4vly5sxYU

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: QA Improvements on 4.2.0

Patricia Shanahan
I like all this.

In addition, I would like to get set up to do code review. I don't like
the idea of changes going out to millions of users having only been
seriously examined by one programmer - even if I'm that programmer.

For both code review and testing, we need more active developers in the
security team, so that they can have access to unreleased security fixes.

On 10/23/2017 8:45 PM, Raphael Bircher wrote:

> Hi all,
>
> I believe the 4.1.4 shows us, that we have to do a better job in QA. A
> minor release should never go to a rc5. I believe we all (and I pointing
> my finger to myself) underestimated the regression risk at the 4.1.4.
>
> So, to do a better job in the 4.2.0 I propose the following changes.
>
> - Define test areas, where tester should keep an extra eye on it. (based
> on the changes)
> - Doing Developer Snapshots again in a 2 Week frequency (or so)
> - Switch the AOO Profile for the snapshots to AOO-Dev
> - mobilize the willing testers to keep a critical eye on this builds
> - maybe also run the automated tests for Apache OpenOffice.
>
> The idea is to make the bug cycle shorter. Improvements should be tested
> right after the implementation and not short before the release. A fresh
> bug is easyer to fix as a old one.
>
> What do you think about this.
>
> Regards Raphael
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: QA Improvements on 4.2.0

Pedro Lino-3
In reply to this post by Raphael Bircher-3
Hi Raphael, all

> I believe the 4.1.4 shows us, that we have to do a better job in QA. A  
> minor release should never go to a rc5. I believe we all (and I pointing  
> my finger to myself) underestimated the regression risk at the 4.1.4.

+1

> So, to do a better job in the 4.2.0 I propose the following changes.
>
> - Define test areas, where tester should keep an extra eye on it. (based  
> on the changes)
> - Doing Developer Snapshots again in a 2 Week frequency (or so)
> - Switch the AOO Profile for the snapshots to AOO-Dev
> - mobilize the willing testers to keep a critical eye on this builds
> - maybe also run the automated tests for Apache OpenOffice.

As a user/tester/part-timeQA I agree to all points.

But, please include Language packs in Developer Snapshots. Running a build with an un-matching language pack causes very serious usability problems (this is IMO the only advantage of including all languages in a single installer).

Creating a blank AOO-Dev profile is a two edged sword: you get a clean start (and avoid trashing the user's work profile) but it isn't a realistic usage (and therefore testing will not find those day to day problems that resulted in the need to go to RC5)
Maybe a middle term would be to create a separate Dev profile that is a copy of the user's profile (including all extensions)?

> The idea is to make the bug cycle shorter. Improvements should be tested  
> right after the implementation and not short before the release. A fresh  
> bug is easier to fix as a old one.

That is the ideal situation. But requires more communication (the QA mailing list is unused for months) and especially more man power (on all platforms!). The only way to get more users is to add needed/missing features and get visibility...

Regards,
Pedro

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: QA Improvements on 4.2.0

Dave Fisher
Hi -

I agree and wrote the same on a different thread the other day.

Regards,
Dave

> On Oct 24, 2017, at 3:28 AM, Pedro Lino <[hidden email]> wrote:
>
> Hi Raphael, all
>
>> I believe the 4.1.4 shows us, that we have to do a better job in QA. A
>> minor release should never go to a rc5. I believe we all (and I pointing
>> my finger to myself) underestimated the regression risk at the 4.1.4.
>
> +1
>
>> So, to do a better job in the 4.2.0 I propose the following changes.
>>
>> - Define test areas, where tester should keep an extra eye on it. (based
>> on the changes)
>> - Doing Developer Snapshots again in a 2 Week frequency (or so)
>> - Switch the AOO Profile for the snapshots to AOO-Dev
>> - mobilize the willing testers to keep a critical eye on this builds
>> - maybe also run the automated tests for Apache OpenOffice.
>
> As a user/tester/part-timeQA I agree to all points.
>
> But, please include Language packs in Developer Snapshots. Running a build with an un-matching language pack causes very serious usability problems (this is IMO the only advantage of including all languages in a single installer).
>
> Creating a blank AOO-Dev profile is a two edged sword: you get a clean start (and avoid trashing the user's work profile) but it isn't a realistic usage (and therefore testing will not find those day to day problems that resulted in the need to go to RC5)
> Maybe a middle term would be to create a separate Dev profile that is a copy of the user's profile (including all extensions)?
>
>> The idea is to make the bug cycle shorter. Improvements should be tested
>> right after the implementation and not short before the release. A fresh
>> bug is easier to fix as a old one.
>
> That is the ideal situation. But requires more communication (the QA mailing list is unused for months) and especially more man power (on all platforms!). The only way to get more users is to add needed/missing features and get visibility...
>
> Regards,
> Pedro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (817 bytes) Download Attachment