Gestione dei protocolli di test manuali [chiuso]

4

Dobbiamo organizzare un elenco molto lungo di test eseguiti manualmente. Attualmente usiamo i documenti di Word, li stampiamo controllandoli ecc. Soprattutto, ma funziona, con problemi.

Problemi con la soluzione corrente

  • Richiedere ed eseguire sottoinsiemi, a seconda delle modifiche effettive. (ovvero, i test 153, 155-157 e 24325 devono essere eseguiti solo se il modulo X è cambiato)
  • Branching. Versioni diverse (che sono ancora mantenute, fino a un certo punto) hanno protocolli di test diversi, ma condividono molti contenuti. Copia e ampli manuale pasta.
  • Tracciamento dei documenti "Modello di prova" e "Prova eseguita". È un ufficio un po 'vecchio stile con molte forme e amp; leganti.
  • Tracciamento nel controllo del codice sorgente insieme alle modifiche di origine. Idealmente, nello stesso modo le caratteristiche vengono copiate / spostate tra i rami, vale a dire come documento diffuso incluso in un commit.

Requisiti del contenuto

I documenti hanno bisogno di immagini (di solito, specifiche di configurazione hardware e schermate di curve "buone"), caselle "Passa / Scarta" e formattazione minore (suc ha enfasi, passaggi, distinzione di "cose da fare" e "cosa aspettarsi" )

Idea attuale

Uno dei miei sviluppatori ha suggerito di utilizzare invece documenti HTML (Sharepoint Designer è ritenuto appropriato per la modifica), "normalizzarli in qualche modo in modo da renderli diffusi" e metterli sotto controllo di versione insieme alle fonti.

Personalmente non sono interamente venduto su questa idea per vari motivi, ma sono d'accordo con gli altri ragazzi che se funziona è meglio dei documenti di Word.

La domanda:

Come gestiresti / gestiresti la documentazione per i test manuali? Conosci qualche strumento? Idee?

Siamo aperti ad altre soluzioni, ma solo con il minimo sforzo di sviluppo personalizzato. Esempio: installazione di software dedicato, la configurazione di alcuni modelli sarebbe ottima, ma non abbiamo risorse per "hackerare qualcosa insieme a XML e fogli di stile e un database, che dovrebbe essere facile".

Alcuni fatti e figure

Il controllo del codice sorgente è git, 6 sviluppatori di software, ~ 1.5KLoc, uno eseguito attraverso tutti i test manuali richiede circa 4 settimane uomo (ordine di grandezza) e approssimativamente lo stesso in tempo di parete con tutte le modifiche e ripetizioni. (Un'esecuzione completa avviene solo per le versioni principali.)

Nota: Non dirmi di testare automaticamente, grazie, ma lo facciamo già. I test manuali prevedono l'integrazione, la visualizzazione e l'equipaggiamento di misurazione esterno. Inoltre, l'informazione prodotta è così multiforme che le scoperte di un ingegnere che conosce l'intero sistema scopre molto di più con una sola occhiata a un grafico.

Esempio: una configurazione tipica del test dovrebbe essere simile a questa, ogni punto interrogativo deve essere "controllato", di solito è 5..15 test per impostazione

Connect 10Ohm resistor to S1. Connect amplifier input to OUT 1. Run test Template 42.

  • Measure voltage over resistor. ~1Vrms ?
  • In Table 3 Uac = 1.0 V, Iac= 0.1 A, ISNR+D > 45 dB ?
  • U(f) Spectrum flat for f > 10 Hz?
  • ...
    
posta peterchen 10.08.2011 - 11:43
fonte

2 risposte

1

Che ne dici di spostare la documentazione di test in un formato come reStructuredText ? Saresti in grado di conservare la documentazione in git insieme al codice sorgente ed è più facile da differe rispetto ai documenti di Word. Ti permette di generare la documentazione in altri formati come HTML e PDF. Per quanto riguarda il primo punto sui test di sottoinsiemi, in REST è possibile rendere i documenti comprensivi di altri documenti in modo da poter disporre di documenti "modello" che selezionano documenti "test case" da posizioni diverse e generano documenti di istruzioni di prova completi per moduli diversi.

    
risposta data 10.08.2011 - 12:42
fonte
1

Utilizziamo link per gestire i nostri test manuali. Ci consente di creare una serie di test / modelli diversi che possono essere combinati in diverse suite di test e i controlli di qualità eseguono le suite di test a seconda del tipo di test che devono eseguire (smoke test, pre-release, post release) ecc.

Ogni analisi viene tracciata separatamente ed è possibile creare report su diversi aspetti. C'è molta flessibilità su come strutturare il singolo test, in modo da poter fallire l'intero test (es. Test 42) o un singolo passo nel test (es. "In Tabella 3 Uac = 1.0 V, Iac = 0.1 A, ISNR + D > 45 dB? ").

Non consiglierei a nessun processo di affidarsi a documenti condivisi, anche se sono controllati dalla fonte, poiché alla fine si impiegano molto tempo per la manutenzione. Meglio andare con uno strumento che è stato creato per lo scopo:)

    
risposta data 09.12.2015 - 02:02
fonte

Leggi altre domande sui tag