Come scrivere storie utente per un'API framework

Suggerirei di affettare verticalmente per le storie, non orizzontalmente:

As a QA group member, I can write a test using a page API that goes to a specific page, click on a button and verifies that I navigates to the right target page.

Quindi implementa il livello API della pagina e il livello base necessari per supportarlo, e non di più. Ciò è dimostrabile e ha un valore aziendale: puoi effettivamente scrivere un test ed eseguirlo.

Quindi segui le altre sezioni verticali:

As a QA group member, I can write a test that goes to a specific page, fill in a text box, click on a button and verifies that I navigates to the right target page.

E miglioramenti incrementali (Cuke per esempio)

As a QA group member, I can write a test using a cucumber like DSL that goes to a specific page, click on a button and verifies that I navigates to the right target page.

Questo è rischioso. Scrum detta team interfunzionali, il che significa che le "storie degli utenti" per il controllo qualità non hanno più senso delle storie per gli sviluppatori. I QA non sono utenti, sono parte del processo di sviluppo e i test di accettazione automatizzati - presupponendo che tu sia veramente impegnato a farli - si riflettono meglio in quanto tali.

Quando abbiamo iniziato a fare questo tipo di test sul mio team, è stato un picco. Quindi, è stato inserito nella fase di "test" per ogni funzionalità e qualsiasi sviluppo a livello di framework è stato addebitato alle singole attività. Questo era intenzionale; volevamo riflettere sulla gestione che i test non erano più facoltativi e che rimandarli avrebbe solo causato il tempo di sviluppo delle altre funzionalità.

Quando i test iniziano a diventare un po 'troppo approssimativi, li ripartiamo in debito tecnologico e assegniamo un giorno o anche una settimana per lavorarci.

Non ho avuto nulla se non brutte esperienze con le user story interne. Non sei mai abbastanza sicuro quando hanno finito perché, come stai vedendo da te, i criteri di accettazione sono ampiamente interpretabili.

Se sei costretto a creare storie di utenti, ti suggerisco di creare una trama per servizio / azione, ad esempio:

As a tester, I would like to be able to automate a successful login via the web browser, so that I can write automated tests for logged-in features.

Queste storie diventeranno ripetitive, come spesso accade quando vengono utilizzate in modo inappropriato, ma è meglio dei test che riguardano la ricerca di elementi nella pagina, che, come dici tu, sono già offerti dal framework. In questo caso, ogni trama corrisponde (approssimativamente) a un passo o una condizione di Gherkin.

È inoltre possibile suddividere tutti i passaggi come attività e creare una trama per ogni pagina / servizio. Dipende dalla velocità con cui lavora la tua squadra. Se riesci a modellare l'intera pagina e tutti i suoi servizi in un ciclo, fallo. Se non sei sicuro, continua con story-per-service o avvia un picco per migliorare la stima.