Product Owner e test automatizzati

What I would like to hear is how to keep bridging the gap after that: once there are automated tests in place, how do you help the Product Owner review them? Or is it enough for the Product Owner to know that the test passes, without looking at the test code itself?

Il Product Owner (o chiunque abbia il cappello Product Owner in quel momento) agisce in modo non tecnico. Rappresentano semplicemente il cliente e gli utenti del prodotto. Non si preoccupano di come funziona il processo, sono solo responsabili dello sviluppo, della priorità e dell'accettazione di storie.

Se il tuo Product Owner è anche uno sviluppatore (il che è possibile - che il paring non è tra quelli sconsigliati), forse il compito migliore per loro sarebbe quello di servire come sviluppatore dei casi di test. Se non sono uno sviluppatore, lavora con loro per vedere cosa vogliono. Qualcuno senza esperienza di sviluppo non otterrebbe valore dal vedere l'implementazione dei casi di test.

First, between the paper story and the implementation details, some assumptions may sneak in, and having the author of the story review the test can be invaluable. On the other hand, the implementation introduces quite a bit of noise, too, and requires the PO to become fairly technical (read code, run tests). Is the test implementation a "developer's detail", or is it fair to request the PO to become a bit of a developer in this area?

Questa è la differenza tra la verifica (i test automatici) e la convalida (test di accettazione e altri test / recensioni condotti dal proprietario del prodotto).

Il fatto che tu abbia casi di test per verificare la storia dell'utente è buono. Tuttavia, spetta al Product Owner convalidare effettivamente l'implementazione. Dire che il test è valido è sufficiente per dire "abbiamo implementato la storia così come la intendiamo", non abbastanza per dire "l'implementazione di questa storia soddisfa le esigenze del cliente e degli utenti". Il Product Owner deve eseguire test di accettazione aggiuntivi sull'applicazione per convalidare la storia e la sua implementazione.

However, some stories are "headless" and can only be verified via code, so unless the PO knows how to read and run tests, he/she will never be able to state that he verified the story complete.

Sto andando dritto su questo - quelli non sono buone storie di utenti. Il punto centrale di una user story è spiegare come l'utente interagirà con un sistema. Potresti sviluppare storie interne per analizzare una storia utente e quelle potrebbero essere "senza testa". Ma saprai che hai completato quelli basati sui test interni che hai superato e la storia utente più ampia che supera i test di accettazione.

Funzionalità e disconnessione

Nel mio lavoro, quando uno sviluppatore riprende un nuovo lavoro, la prima cosa che fanno è identificare chi è il "Proprietario". Poi vanno da loro per una rapida discussione sulla loro comprensione del problema e su quale sarà la soluzione prevista.

Una volta che lo sviluppatore ha terminato l'implementazione, torna al "Proprietario" per la disconnessione. La firma implica lo sviluppatore che mostra l'implementazione in un sistema funzionante (il loro sistema di sviluppo) con dati ragionevoli. Se il "Proprietario" è soddisfatto, si disconnettono e l'implementazione è completa. Se il "Proprietario" non è soddisfatto, lo sviluppatore identifica quali modifiche devono essere apportate. Poi li implementa e tenta di riprovare.