| 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
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.