Nella mia azienda utilizziamo JIRA per nuove richieste di funzionalità e quindi il reparto QA registra eventuali errori / difetti nel Quality Center. Trovo che Quality Center sia molto poco user-friendly in quanto richiede IE perché utilizza ActiveX.
È prassi comune utilizzare tracker separati per richieste e difetti di funzionalità? C'è qualche vantaggio nell'avere tracker separati?
Ciao.
In realtà ho lo stesso setup nel mio lavoro. Devo dire che non ha senso, se usi QC solo per memorizzare i difetti. Se hai bisogno di tracciamento dei bug, puoi restare con Jira. Ma devi capire che QC è uno strumento dedicato al controllo qualità e fa molto di più. Quindi ha senso avere Jira e QC se tu (intendo QA al tuo lavoro) usi tutte / la maggior parte delle funzionalità QC e hai un plugin Jira che sincronizza i difetti tra QC e Jira (ne so circa due plugin per Jira in quel modo).
[fine della risposta]
Se stai pensando ' ma perché il QA di Fck ha bisogno di questo stupido strumento? ' fammi scoprire un po 'di QC per te.
Si prega di comprendere che sebbene entrambi forniscano funzionalità di tracciamento dei bug, hanno obiettivi e finalità molto diversi. Presumo che la maggior parte delle persone (programmatori) qui sappiano Jira, quindi scoprirò un po 'di QC per te:
P.S. È un grande strumento, usato correttamente funziona alla grande, altrimenti fa schifo
La funzione di qualcuno è l'errore di qualcun altro . Ad esempio, si tratta di un bug se il testo di un pulsante è troppo piccolo per essere letto, un pulsante si trova in un posto strano come nella barra di stato o il testo di aiuto è meno utile? Gli utenti probabilmente direbbero di sì, mentre gli sviluppatori (e forse gli utenti esperti) direbbero spesso di no, perché hanno familiarità con le stranezze.
Avere sistemi separati aggiunge inerzia al passaggio da uno all'altro piuttosto che riclassificarlo. Ciò significa che l'escalation di un'importante richiesta di funzionalità è artificialmente meno probabile di quanto avverrebbe con un singolo sistema.
Naturalmente, potrebbe non essere necessario che gli utenti siano in grado di vedere segnalazioni di bug, ma solo richieste di funzionalità. Questo dovrebbe essere possibile per garantire un moderno sistema di gestione degli errori.
I sistemi separati non sono affatto una buona idea. Significa che devi cercare in 2 posti. Significa che non puoi collegare i difetti a una richiesta di funzionalità genitore. Significa che hai 2 insiemi di ID di tracciamento ... l'orribilità continua.
Un singolo sistema semplifica la vita. La maggior parte dei sistemi di tracciamento decenti ti consentiranno di contrassegnare / contrassegnare una voce come una "caratteristica" piuttosto che una cosa reale che è rotta.
Per il mio modo di pensare, una richiesta di funzionalità è semplicemente un difetto - la mancanza della funzione comprende un difetto negli occhi della persona che ha fatto la richiesta: "Se non puoi fare X allora è rotto e io lo voglio ".
Nella mia attività corrente registro tutto ciò che viene segnalato dai clienti, alcuni dei quali sono difetti e alcuni dei quali sono richieste di nuove funzionalità. Per quanto mi riguarda, ho bisogno di un posto unico per tutto per semplicità e visibilità.
Dipende dalla tua politica in merito a bug e amp; stampa.
Risolvi sempre tutti i bug aperti prima di rilasciarli? In tal caso, tracker separati sono probabilmente una buona idea (o almeno un filtro nel tuo software di tracciamento principale che lo rende essenzialmente come tracker separati).
Se, d'altro canto, la tua organizzazione utilizza una politica più "Agile", allora puoi considerare bug == features == stories e devi solo dare la priorità e consegnare il maggior numero possibile di storie ad alta priorità in ogni ciclo. Qui, scarichi tutto in un unico tracker.
Le richieste e i difetti di funzionalità sono fondamentalmente la stessa cosa: a qualcuno piacerebbe che il sistema cambiasse in qualche modo, fornendo nuove funzionalità o correggendo comportamenti errati. È utile disporre di un singolo elenco consolidato in modo che la priorità relativa possa essere applicata a tutte le richieste e i difetti delle funzionalità nel backlog; i singoli sviluppatori possono lavorare su una cosa alla volta e l'elemento successivo più importante può essere lo sviluppo di una funzione o una correzione per un difetto. Una richiesta di funzione potrebbe essere più importante di un difetto in sospeso e viceversa.
Per quanto riguarda gli strumenti che menzionate, come evidenziato in alcune delle altre risposte, Quality Center è principalmente uno strumento di controllo qualità che consente di inserire requisiti, definire casi di test ed eseguire test passo-passo. Quando un test fallisce, è naturale sollevare immediatamente un difetto senza modificare il contesto e Quality Center fornisce funzionalità di gestione dei difetti per consentirvi di farlo. La difficoltà è quindi nel gestire il processo di correzione e test dei difetti rispetto agli altri lavori che si trovano nel backlog e questo è dove le cose possono complicarsi. Ho visto team che si sono stabiliti in modo tale che le richieste di funzionalità vengano sollevate come "difetti" nel Quality Center per dare loro una visione completa del lavoro arretrato; questo ha una strana sensazione, tuttavia sollevare difetti in un altro strumento, ad es. JIRA rompe il collegamento tra il difetto e il test da cui ha avuto origine.
Potrebbero esserci altri validi motivi per utilizzare uno strumento specifico, ad es. se è stato integrato con il repository del codice sorgente e il processo di distribuzione, il che potrebbe ignorare il livello di scelta su come integrare il processo front-to-back. Il miglior demo che ho visto di una soluzione completa di requisiti per l'implementazione è Rational Team Concert, tuttavia non ho avuto esperienza pratica con esso.
Quality Center ha i ganci per i test automatizzati che possono essere utilizzati da un dipartimento QA. Non so se JIRA ha funzionalità simili o no. Dove lavoro, abbiamo Target Process e Quality Center che tengono traccia dei bug, quindi in questo momento le cose sono duplicate fino ad un certo punto.
Non lo farei. Nel momento in cui inizi a implementare una nuova funzione, creerai nuovi bug. Quindi potresti anche avere la nuova funzione direttamente lì, in modo da poterla seguire insieme a tutti i bug correlati.
Monitorare i difetti e le richieste di funzionalità separatamente non è una cattiva idea, e l'ho visto spesso. Sembra che il problema sia l'utilizzo di due sistemi diversi che potrebbero non essere nemmeno in grado di comunicare tra loro. Puoi usare JIRA per rintracciarli entrambi? In questo modo puoi legare i difetti futuri alle richieste di funzioni precedenti e vedere come tutto si interconnette. Questo può essere utile.
Non ho mai sentito nessuno che usi due sistemi incompatibili. È noto che maggiore è il costo della transizione, meno è probabile che qualcuno possa effettuare una transizione. Le funzioni per / da transizioni di bug sono comuni, quindi non ha senso separare i problemi.
La maggior parte dei sistemi di gestione dei problemi maturi consente di definire flussi di lavoro abbastanza diversi per ciascun tipo, che dovrebbero risolvere la maggior parte dei problemi. Ci sono anche abbastanza plugin per ricevere richieste dagli utenti senza renderli utenti sul sistema di tracciamento dei problemi.
Leggi altre domande sui tag issue-tracking qa