Automazione a livello di GUI o API in Scrum

Non provi a "completare l'automazione" . Invece, hai storie come tutti gli altri. Potresti avere storie rigorosamente per l'automazione, o meglio, l'automazione fa parte dei criteri di accettazione di una storia di un utente.

Sei (o dovrebbe essere) parte di un team per cui l'automazione fa parte di ciò che viene consegnato. Il tuo lavoro non si distingue dalla tua squadra. Insieme dovresti decidere cosa puoi offrire come una squadra .

Uno sprint di due settimane non dovrebbe significare "possiamo scrivere il codice in due settimane", ma piuttosto "possiamo scrivere il codice e testarlo tra due settimane". Se non puoi farlo in due settimane, o hai bisogno di storie più semplici, membri del team migliori o sprint più lunghi.

Per quanto riguarda i test dell'API, scegli una lingua appropriata e inizia a scrivere il codice che chiama la tua API.

1. Spezzando le attività di automazione in modo che possano essere completate in un singolo sprint.
2. Vedi 1.
3. Si prega di definire i test API. Se ti riferisci a testare l'interazione di più unità di codice (interne e / o esterne), allora probabilmente stai guardando test di integrazione .

Una rapida ricerca su google ha rivelato QTP come un robot della GUI. Tali strumenti sono strumenti di test black box , test del binario compilato dell'applicazione che simula un utente premendo i pulsanti, immettendo valori in alcuni campi, controllando i risultati mostrati in altri campi ecc. In genere, non sapere in quale linguaggio di programmazione è stato scritto il programma originale. La creazione di tali test in genere ha senso solo dopo che le parti della GUI hanno raggiunto un certo livello di stabilità.

Quando si parla di test di livello API (al contrario dei test del robot della GUI), stiamo parlando di test della casella bianca della logica della GUI, non attraverso gli elementi della GUI stessa, ma attraverso uno strato API di l'applicazione che è molto "stretta sotto la GUI". Tale livello API viene creato più facilmente applicando il "Model-View-Presenter" modello . Questo modello consente di eseguire test in un approccio di presentatore , che consente di creare test automatici (unità) molto presto - quando facendo TDD, prima del codice per la logica della GUI stessa. Questi test sono tipicamente scritti dagli sviluppatori che stanno scrivendo il relatore, nella stessa lingua dell'applicazione stessa, e in genere si ha bisogno solo di qualcosa come uno strumento di test gratuito xUnit, non di più.

Secondo la mia esperienza, entrambi i tipi di approcci di test possono testare cose diverse. Ma entrambi gli approcci possono essere utilizzati anche per testare molti requisiti sovrapposti, nel caso in cui preferirei chiaramente i test di livello API (le mie precedenti esperienze con i robot della GUI erano, diciamo, un po 'deludenti, troppi sforzi per trarne minori benefici). Ma il tuo chilometraggio può variare.

Riguardo a Scrum: non l'ho mai fatto, ma sospetto che i test che utilizzano uno strumento per la GUI siano scritti meglio dopo ogni sprint, mentre i test a livello di API dovrebbero essere parte dello sviluppo durante lo sprint.