Proven tester/it: Difference between revisions

Latest revision as of 20:45, 12 July 2012

In other languages: English (en) italiano (it) português do Brasil (pt-br) [edit]

Ritrovi dei Proven-tester
Bodhi	Bugzilla

Un proven tester, anche noto come critical path wrangler, effettuando dei test di stabilità, verifica e riporta commenti sugli aggiornamenti riguardanti i
critical path packages (pacchetti che rientrano nel critical path). Dopo essersi procurato gli aggiornamenti dal repository updates-testing, invia i propri risultati sotto forma di karma, usando Bodhi.
Per un pacchetto che sia nel critical-path, perchè che esso possa essere inviato al repository stabile, occorre che un proven-tester dia karma positivo.

Un proven-tester è un membro del gruppo proventesters e per poterne far parte occore dapprima farsi approvare da un esperto del gruppo (mentor)
(vedi la sezione Per unirsi ai proven testers...)

Testing & Feedback

Prima di rilasciare un aggiornamento pubblicamente, i proven-tester verificano la stabilità di base del pacchetto. (La verifica della correttezza totale o un test volto a verificare la totale assenza di errori richiederebbe, com'è intuibile, ingenti risorse materiali/umane/temporali!) Esistono test che si applicano solo in alcuni aggiornamenti, ed altri che devono essere applicati ad ogni nuovo aggiornamento del pacchetto. In generale, un aggiornamento deve essere in grado di assicurare/presevare tutte le attività richieste dal critical path action e dalla Fedora release criteria.

I proven-tester verificano gli aggiornamenti, installando i pacchetti dal repository updates-testing. (Per configurare il proprio sistema, ad ottenere tali aggiornamenti, vedere la pagina QA:Updates_Testing). Per una rapida intercettazione di eventuali regressioni, si consiglia di effettuare un aggiornamento completo da questo repository almeno una volta al giorno. Si raccomanda anche di abilitare SELinux e impostare la modalità Enforcing.

Cosa testare

Test generale

Il sistema deve essere in grado di spegnersi e di riavviarsi
L'utente deve essere in grado di accedere al proprio desktop
L'utente deve essere in grado di accedere alla rete

Testare le applicazioni: Se il pacchetto è un'applicazione, verificare la correttezza delle sue funzionalità di base.

Testare librerie e componenti condivisi: Se il pacchetto contiene una libreria o un componente condiviso, eseguire un'applicazione da essa dipendente per verificarne il funzionamento.

Procedure di Feedback

Poichè il karma del proven-tester determina la promozione o meno a stable del pacchetto, all'occorrenza di una regressione e in base al relativo grado di severità, bisogna seguire una particolare procedura.

(FEK) Fedora Easy Karma è uno strumento usato dai proven-tester, che elenca i pacchetti installati dal repository updates-testing e che serve ad inviare feedback su un pacchetto testato. Se si ha poco tempo a disposizione per il testing, si può usare comodamente usare il parametro --critpath-only, che limita FEK ad elencare solo i pacchetti nel critical path, non ancora approvati.
Se non si usa il parametro, prestare particolare attenzione a quegli aggiornamenti nel critical path, come indicato nelle corrispondenti note descrittive.

No Bug - Feedback positivo

Solitamente, se non si incontra nessuno bug, e i test menzionati in precedenza sono superati senza difficoltà, il feedback sull'aggiornamento risulterà positivo ed i commenti (feedback), mettendo in evidenza che non è stato riscontrato nessun problema significativo, rifletteranno l'attuale usabilità del pacchetto.

Bug maggiori - Feedback negativo

Se nei test, si è identificato un problema grave su un pacchetto che si ritiene essere il diretto responsabile, il feedback risulterà negativo, ed in tal caso si prega di inviare un bug-report in Bugzilla, indicandone il link nel proprio commento di feedback. Inoltre, un buon messaggio prontamente inviato aiuta gli sviluppatori ad individuare in minor tempo la causa del problema.

Bug minori - Feedback neutro o positivo

Se si identifica un problema di entità minore che non impedisce le attuali funzionalità nel critical path, si prega di non inviare feedback negativo, ma di lasciare un feedback positivo o quantomeno neutro, con un commento spiegando il problema riscontrato (ed un link al bug-report, se esistente).

Testare pacchetti non familiari

Se non si conoscono uso/funzionalità di un componente, o come testarlo, non dare feedback nè positivo nè negativo. Per i paccheti nel critical path, se durante il test generale non si riscontrano problemi nelle funzionalità di avvio, rete, aggiornamento, è soddisfacente lasciare un feedback neutro, notando che il pacchetto aggiornato consente di avviare il sistema e di garantire le attività di base richieste dal critical path. Generalmente, queste informazioni non sono molto utili per quei pacchetti che non rientrano nel critical path, quindi si prega di inviare i commenti solo sui pacchetti direttamente testati e con i quali si è familiari.

Disaccordo di karma

Se il proprio test non ha dato problemi, ma altri tester indicano di aver identificato serie difficoltà con il pacchetto, si prega di provare a replicare il loro tipo di problema, e di dare feedback negativo nel caso si presentino le stesse difficoltà. Se non si è in grado di confermare il problema, perchè impossibilitati a creare le stesse condizioni iniziali, si prega di dare feedback neutro, notando l'impossibilità di replicare il problema. Dare feedback positivo soltanto nel caso in cui si è assolutamente sicuri della totale correttezza del proprio test, ritenendo quindi che il feedback negativo riportato da altro tester sia un errore altrettanto assoluto.

Per unirsi ai proven testers...

Dopo aver ottenuto un account in FAS (Fedora Account System), iscriversi al gruppo proventesters.
Inviare una richiesta in Fedora QA Trac, con il tipo proventester request ed il componente Proventester Mentor Request, chiedendo di voler diventare un proven-tester e di cercare un esperto.
Attendere la risposta (un paio di giorni) e poi seguire le istruzioni che verranno fornite dall'esperto.

Per accelerare il processo, puoi iniziare a prendere confidenza con le attività svolte da un proven-tester, seguendo le istruzioni che trovi in questa pagina ed iniziando anche ad inviare commenti sui test effettuati. Sarebbe ideale segnalare al proprio mentor che si sono apprese le istruzioni quì indicate, che si sa come installare e testare gli aggiornamenti da sottoporre a test, e come inviare i relativi feedback. Se si è già inviato qualche feedback, se ne indichi un link in modo che il mentor possa verificarne la correttezza!

Il mentore accetta le richieste di adesione da parte di candidati a proven-tester, verificando, prima dell'approvazione, che il candidato abbia letto e compreso le istruzioni indicate quì. Il processo di adesione e successiva approvazione è abbastanza veloce, e non presenta ostacoli, a meno di errori, intenzioni maliziose da parte del candidato o può interrompersi a causa della mancata visione delle istruzioni.

Processo di approvazione

@@ Line 1: / Line 1: @@
 {{autolang}}
-__NOTOC__
-Un '''proven tester''', anche noto come '''critical path wrangler''', effettuando dei test di stabilità, verifica e riporta commenti sugli aggiornamenti riguardanti i <BR> [[critical path packages]] (pacchetti che rientrano nel critical path). Dopo essersi procurato gli aggiornamenti dal repository [[updates-testing]], invia i propri risultati sotto forma di ''karma'', usando [[Bodhi]].<BR>
+{| style="align:center; margin: 1em auto;"
+! colspan="2" | Ritrovi dei Proven-tester
+|-
+|align=center|[http://bodhi.fedoraproject.org Bodhi]
+|align=center|[http://bugzilla.redhat.com Bugzilla]
+|}
+Un '''proven tester''', anche noto come '''critical path wrangler''', effettuando dei test di stabilità, verifica e riporta commenti sugli aggiornamenti riguardanti i <BR> [[critical path packages]] (pacchetti che rientrano nel critical path). Dopo essersi procurato gli aggiornamenti dal repository [[QA:Updates_Testing|updates-testing]], invia i propri risultati sotto forma di ''karma'', usando [[Bodhi]].<BR>
 Per un pacchetto che sia nel critical-path, perchè che esso possa essere inviato al repository ''stabile'', occorre che un proven-tester dia karma positivo.
-Un proven-tester è un membro del gruppo [https://admin.fedoraproject.org/accounts/group/view/proventesters proventesters] e per poterne far parte occore dapprima farsi approvare da un esperto del gruppo (mentor).
+Un proven-tester è un membro del gruppo [https://admin.fedoraproject.org/accounts/group/view/proventesters proventesters] e per poterne far parte occore dapprima farsi approvare da un esperto del gruppo (mentor)<BR> (vedi la sezione [[#Per unirsi ai proven testers...|Per unirsi ai proven testers...]])
-== Per unirsi ai proven testers... ==
+== Testing & Feedback ==
-# Dopo aver ottenuto un account in [https://admin.fedoraproject.org/accounts/login FAS (Fedora Account System)], iscriversi al gruppo ''proventesters''.
-# Inviare una richiesta in [https://fedorahosted.org/fedora-qa/ Fedora QA Trac], con il tipo ''proventester request'' ed il componente ''Proventester Mentor Request'', chiedendo di voler diventare un proven-tester e di cercare un esperto.
-# Attendere la risposta (un paio di giorni) e poi seguire le istruzioni che verranno fornite dall'esperto.
-Per accelerare il processo, puoi iniziare a prendere confidenza con le attività svolte da un proven-tester, seguendo le istruzioni che trovi in questa pagina ed iniziando anche ad inviare commenti sui test effettuati. Sarebbe ideale segnalare al proprio mentor che si sono apprese le istruzioni quì indicate, che si sa come installare e testare gli aggiornamenti sottoposti a test, e come inviare i relativi feedback. Se si è già inviato qualche feedback, se ne indichi un link in modo che il mentor possa verificare la correttezza del feedback!
+Prima di rilasciare un aggiornamento pubblicamente, i proven-tester verificano la stabilità di ''base'' del pacchetto. (La verifica della correttezza totale o un test volto a verificare la totale assenza di errori richiederebbe, com'è intuibile, ingenti risorse materiali/umane/temporali!) Esistono test che si applicano solo in alcuni aggiornamenti, ed altri che devono essere applicati ad ogni nuovo aggiornamento del pacchetto. In generale, un aggiornamento deve essere in grado di assicurare/presevare tutte le attività richieste dal [[critical path action#Actions|critical path action]] e dalla [[Fedora release criteria]].
-== Il processo di Test ==
+I proven-tester verificano gli aggiornamenti, installando i pacchetti dal repository '''updates-testing'''. (Per configurare il proprio sistema, ad ottenere tali aggiornamenti, vedere la pagina [[QA:Updates_Testing]]). Per una rapida intercettazione di eventuali regressioni, si consiglia di effettuare un aggiornamento completo da questo repository almeno una volta al giorno. Si raccomanda anche di abilitare SELinux e impostare la modalità ''Enforcing''.
+=== Cosa testare ===
-Proven testers verify a basic level of stability before releasing an update to the public. They do not need to test for total correctness or ensure complete test coverage. Some tests will vary depending on the type of the package, while others must pass for all updates. Generally speaking, an update should successfully execute all applicable [[critical path action]]s. The [[Fedora release criteria]] is another useful guide for minimum testing criteria.
+;* Test generale
+# Il sistema deve essere in grado di spegnersi e di riavviarsi
+# L'utente deve essere in grado di accedere al proprio desktop
+# L'utente deve essere in grado di accedere alla rete
-Proven testers verify updates by installing them from the updates-testing repository. For instructions on using this repository, see [[updates-testing|this page]]. To ensure rapid detection of regressions, you should perform a full system update from this repository at least once a day. You can update individual packages more quickly if the need for verification is urgent. We recommend that you have SELinux enabled and set to Enforcing mode (this is the default configuration, but many people disable SELinux after installing Fedora) for the purpose of testing.
+;* Testare le applicazioni
+: Se il pacchetto è un'applicazione, verificare la correttezza delle sue funzionalità di base.
-=== Test generali ===
+;* Testare librerie e componenti condivisi
-# The system must be able to shut down and reboot.
+: Se il pacchetto contiene una libreria o un componente condiviso, eseguire un'applicazione da essa dipendente per verificarne il funzionamento.
-# The user must be able to log in to the desktop.
-# The user must be able to access the network.
-=== Testare le applicazioni ===
+=== Procedure di Feedback ===
-If the package is an application, run the application and check that basic operations work.
-=== Testare librerie e componenti condivisi ===
+Poichè il ''karma'' del proven-tester determina la promozione o meno a ''stable'' del pacchetto, all'occorrenza di una regressione e in base al relativo grado di severità, bisogna seguire una particolare procedura.
-If it is a library or other shared component, run an application which uses the component and ensure that that works.
-== Procedure di Feedback ==
+[[Fedora Easy Karma/it|(FEK) Fedora Easy Karma]] è uno strumento usato dai proven-tester, che elenca i pacchetti installati dal repository ''updates-testing'' e che serve ad inviare feedback su un pacchetto testato. Se si ha poco tempo a disposizione per il testing, si può usare comodamente usare il parametro <code>--critpath-only</code>, che limita FEK ad elencare solo i pacchetti nel critical path, non ancora approvati.<BR> Se non si usa il parametro, prestare particolare attenzione a quegli aggiornamenti nel critical path, come indicato nelle corrispondenti note descrittive.
-Since a proven tester's karma determines whether an update is allowed to be promoted, they follow special procedures based on the severity of regressions they encounter. Use [[Fedora Easy Karma]] - see the page for instructions on installing and using this tool - to list all installed packages from the updates-testing repository and allow to file feedback on each one at a time. Note that you can use the parameter ''--critpath-only'', which will cause f-e-k to list only unapproved critical path updates, if you are short on time for testing. If you do not use this parameter, pay particular attention to updates whose description notes that they are critical path updates.
+; No Bug - Feedback positivo
+Solitamente, se non si incontra nessuno bug, e i test menzionati in precedenza sono superati senza difficoltà, il feedback sull'aggiornamento risulterà ''positivo'' ed i commenti (feedback), mettendo in evidenza che non è stato riscontrato nessun problema significativo, rifletteranno l'attuale usabilità del pacchetto.
-=== Feedback positivo ===
+; Bug maggiori - Feedback negativo
-Usually, you will be able to post positive feedback on an update. If you do not encounter any of the situations below, and find that the update passes the tests mentioned above and does not cause you any other problems, you should leave positive feedback and note that you were able to use the package successfully and did not notice any significant problems.
+Se nei test, si è identificato un problema ''grave'' su un pacchetto che si ritiene essere il diretto responsabile, il feedback risulterà ''negativo'', ed in tal caso si prega di inviare un bug-report in [[Bugzilla]], indicandone il link nel proprio commento di feedback. Inoltre, un buon messaggio prontamente inviato aiuta gli sviluppatori ad individuare in minor tempo la causa del problema.
-=== Bug maggiori ===
+; Bug minori - Feedback neutro o positivo
-If you identified any serious problems in earlier testing and were able to identify the package responsible, post negative feedback for that package. If possible, please file a bug report on the problem and link to the bug report in your feedback message. A good feedback message quickly and clearly identifies the behavior change and the cause, if you were able to determine it.
+Se si identifica un problema di ''entità minore'' che non impedisce le attuali funzionalità nel critical path, si prega di non inviare feedback ''negativo'', ma di lasciare un feedback ''positivo'' o quantomeno ''neutro'', con un commento spiegando il problema riscontrato (ed un link al bug-report, se esistente).
-=== Bug minori ===
+{{Admon/note|
-If you identify a problem which is minor in nature and does not impede the actual critical path functionality, please do not post negative feedback. Post neutral or positive feedback with a note of the issue encountered (and a link to a bug report if appropriate).
+; Testare pacchetti non familiari
+Se non si conoscono uso/funzionalità di un componente, o come testarlo, non dare feedback nè positivo nè negativo. Per i paccheti nel critical path, se durante il test generale non si riscontrano problemi nelle funzionalità di avvio, rete, aggiornamento, è soddisfacente lasciare un feedback ''neutro'', notando che il pacchetto aggiornato consente di avviare il sistema e di garantire le attività di base richieste dal critical path. Generalmente, queste informazioni non sono molto utili per quei pacchetti che non rientrano nel critical path, quindi si prega di inviare i commenti solo sui pacchetti direttamente testati e con i quali si è familiari.
-=== Bug già riportati ===
+; Disaccordo di karma
-If your testing uncovers no problems but you see that another tester has identified a serious problem with the package, please try to replicate their problem, and post negative feedback if you are now able to confirm it. If you are not able to confirm the problem but you suspect this may be because you cannot recreate the necessary conditions, please post neutral feedback noting that you were unable to duplicate the problem. Only post positive feedback if you are sure your testing indicates the other reporter's negative feedback is a mistake.
+Se il proprio test non ha dato problemi, ma altri tester indicano di aver identificato serie difficoltà con il pacchetto, si prega di provare a replicare il loro tipo di problema, e di dare feedback ''negativo'' nel caso si presentino le stesse difficoltà. Se non si è in grado di confermare il problema, perchè impossibilitati a creare le stesse condizioni iniziali, si prega di dare feedback ''neutro'', notando l'impossibilità di replicare il problema. Dare feedback ''positivo'' soltanto nel caso in cui si è assolutamente sicuri della totale correttezza del proprio test, ritenendo quindi che il feedback ''negativo'' riportato da altro tester sia un errore altrettanto assoluto.}}
-=== Pacchetti non familiari ===
+== Per unirsi ai proven testers... ==
-If you are not sure what the component does or how to test it, do not post positive or negative feedback. For critical path updates, if the above general tests of booting, network functionality and update functionality identified no problems, it is fine to leave a neutral feedback message noting that you were able to boot the system and perform critical path tasks with the update installed. This is generally not useful for non-critical path updates, however: please only comment on them if you are familiar with the package and able to test it directly.
+# Dopo aver ottenuto un account in [https://admin.fedoraproject.org/accounts/login FAS (Fedora Account System)], iscriversi al gruppo ''proventesters''.
+# Inviare una richiesta in [https://fedorahosted.org/fedora-qa/ Fedora QA Trac], con il tipo ''proventester request'' ed il componente ''Proventester Mentor Request'', chiedendo di voler diventare un proven-tester e di cercare un esperto.
+# Attendere la risposta (un paio di giorni) e poi seguire le istruzioni che verranno fornite dall'esperto.
-== Proven tester mentoring ==
+Per accelerare il processo, puoi iniziare a prendere confidenza con le attività svolte da un proven-tester, seguendo le istruzioni che trovi in questa pagina ed iniziando anche ad inviare commenti sui test effettuati. Sarebbe ideale segnalare al proprio mentor che si sono apprese le istruzioni quì indicate, che si sa come installare e testare gli aggiornamenti da sottoporre a test, e come inviare i relativi feedback. Se si è già inviato qualche feedback, se ne indichi un link in modo che il mentor possa verificarne la correttezza!
-Proven tester mentors accept requests from prospective proven tester members, and check that the applicants have read and understood the proven tester instructions before approving their membership. This process is not intended to be onerous, and we should expect to accept all applications unless they have obviously been made in error, seem malicious in intent or the applicant fails to affirm that they have read the instructions for the process.
-=== Diventare un mentor ===
+Il mentore accetta le richieste di adesione da parte di candidati a proven-tester, verificando, prima dell'approvazione, che il candidato abbia letto e compreso le istruzioni indicate quì. Il processo di adesione e successiva approvazione è abbastanza veloce, e non presenta ostacoli, a meno di errori, intenzioni maliziose da parte del candidato o può interrompersi a causa della mancata visione delle istruzioni.
-Any proven tester can become a mentor. Simply let any existing mentor or group administrator - those listed as ''administrator'' or ''sponsor'' in the [https://admin.fedoraproject.org/accounts/group/members/proventesters group member list] - know you would like to become a mentor, and they will upgrade you to ''sponsor'' level, which will allow you to accept applications to the group.
-=== Il processo di mentoring ===
+; [[Proven tester#Proven tester mentoring|Processo di approvazione]]
-You can [https://fedorahosted.org/fedora-qa/report/9 find membership applications] in Trac - they will appear under '''Proventester Mentor Request Release''' in that list. To accept an application, assign it to yourself. Now ensure that the applicant has applied to the FAS group, read the instructions on this page, and knows how to use the updates-testing repository and fedora-easy-karma. If the applicant provides links to some feedback they have already posted, read these to check that they are in line with the process. If all of this is in order, sponsor the applicant into the ''proventesters'' FAS group, and close the application ticket. You can see an example completed application ticket [https://fedorahosted.org/fedora-qa/ticket/67 here].
-== Link esterni ==
+[[Category:Italiano]]
-* [http://bodhi.fedoraproject.org Bodhi]
+[[Category:Da revisionare]]
-* [http://bugzilla.redhat.com Bugzilla]

Search