| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Kevin F. Quinn wrote: |
| 5 |
> Well, it strikes me that most if not all of the organisational questions |
| 6 |
> are not relevant to a tester; the only technical question that is |
| 7 |
> relevant is 9 (keyword marking), and even that would be reworded for the |
| 8 |
> tester perspective. The main point being that a tester can be a willing |
| 9 |
> user, with no dev capabilities at all; the ebuild quiz is written for a |
| 10 |
> different target group. In fact, it's useful if testers are not developers, |
| 11 |
> as devs often make assumptions without realising it. |
| 12 |
> |
| 13 |
> I guess it comes down to what you want a tester to do. In my mind, the |
| 14 |
> task of a tester is to emerge the package normally, record the use flag |
| 15 |
> configuration, and exercise the application as much as possible. Possibly |
| 16 |
> repeating with other use flag configurations. If you want testers to do |
| 17 |
> ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's |
| 18 |
> a good idea.. |
| 19 |
|
| 20 |
In my professional work, the pecking order is like this: |
| 21 |
|
| 22 |
developer --> integration/test --> system design --> management |
| 23 |
|
| 24 |
Of course, some of the developers I work with may disagree. ;) |
| 25 |
|
| 26 |
But the point is that the integration/test team knows about development; |
| 27 |
it just makes sense. The integration/test team needs to know a good deal |
| 28 |
about development *and* the overall system design to be affective. |
| 29 |
|
| 30 |
So I would say have all arch-testers take both the ebuild quiz and the |
| 31 |
newer QA/testing quiz. I suppose you could be more lax about scoring if |
| 32 |
you're really worried about not getting a large enough pool of testers. |
| 33 |
And I'm not arguing that an arch tester has to become a developer first; |
| 34 |
I'm just making the point that a good tester has the ability to switch |
| 35 |
back and forth between the 'big picture' and the 'bit level'. |
| 36 |
|
| 37 |
If you want fancy terminology, the testers need to know how to test the |
| 38 |
interfaces (in this case the portage API, probably by code walk |
| 39 |
throughs), and functional threads (you gave a great example, 'emerge the |
| 40 |
package normally, record the use flag configuration, and exercise the |
| 41 |
application'). |
| 42 |
|
| 43 |
Nathan |
| 44 |
|
| 45 |
-----BEGIN PGP SIGNATURE----- |
| 46 |
Version: GnuPG v1.4.1 (GNU/Linux) |
| 47 |
|
| 48 |
iD8DBQFDHF2E2QTTR4CNEQARArbJAKCEZ7K6HiTFKpVy9mEVkaTU9TFUvQCeLlLE |
| 49 |
l8v1xMYUtLLa4cvF5meZyJo= |
| 50 |
=W6Sq |
| 51 |
-----END PGP SIGNATURE----- |
| 52 |
-- |
| 53 |
gentoo-dev@g.o mailing list |
Archives