Richiedere casi di test di analisi di qualità prima dell'implementazione / modifica

C'è da dire su tutto questo. A causa di questo essere programmatori.SE ignorerò l'aspetto di perdere il favore con alcune persone e la tua "sconcertante". Se vuoi un input su questi, ti suggerisco di pagare posto di lavoro.SE una visita, invece.

A parte questo, diamo un'occhiata ai problemi tecnici qui:

• Sei uno sviluppatore (presumo qui), che dice al QA come fare il suo lavoro. Ovviamente, dovresti essere ben preparato a rispondere in modo soddisfacente alle seguenti domande:

  • Perché conosci meglio? Hanno lavorato in qualche modo prima, ora vuoi cambiarlo, quindi è meglio dargli una ragione.
  • Sei in grado di richiedere un cambiamento del processo di sviluppo? Il QA probabilmente ha un processo per aderire e tu hai chiesto loro di rovinarlo. Di nuovo, meglio avere una buona ragione.

• I casi di test del QA non dovrebbero essere disponibili per gli sviluppatori in anticipo per un motivo. Il TDD è una cosa, ma l'intero punto del QA è di avere una verifica indipendente . Se sei influenzato dai loro casi di test, indebolisci l'intero sistema. Personalmente, se lavorassi in QA, questa sarebbe la mia ragione numero 1 per non darti dei casi di test.

• Potresti aver confuso use-case / "usability" e "test-case" nella tua domanda. La differenza è enorme. Come accennato in precedenza, non si dispone dei diritti per accedere ai casi di test di QA in anticipo, ma si dovrebbe ottenere l'accesso ai casi d'uso per la funzione che si suppone debba implementare. Tuttavia, i casi d'uso normalmente non sono mantenuti nel QA. Potresti persino doverli inventare tu stesso in collaborazione con un cliente o un product manager.

• Hai detto che stavi "provando un approccio guidato dai test", il che fa pensare a una domanda immediata: perché provarci? Esiste una cultura di TDD sul posto di lavoro o no? Se non c'è, allora devi procedere con molta attenzione e lentamente (vedi le domande precedenti, eccetto che saranno chieste dai tuoi co-sviluppatori invece del QA questa volta).

In sostanza, questo potrebbe essere semplicemente un grosso malinteso e se lo fai notare come tale potresti essere fortunato a sistemare le cose con quelle altre persone. Non possiamo dire qui cosa esattamente hai detto loro, ma se hai davvero chiesto a loro di violare i loro processi, anni di esperienza e sacrificare l'intero punto del loro lavoro di verifica - solo a causa tua - allora potresti volerli avvicinare di nuovo in un modo molto più semplice.

Non è mai una buona idea cercare di rendere TDD out-of-blue su requisiti complessi. TDD è inteso come approccio e impegno a lungo termine. TDD non renderà più semplice implementare le richieste di modifica e le nuove funzionalità durante la notte.

Inoltre, come ha detto Carl, avere risposte come "se possibile" e "forse" mostra solo mancanza di comprensione e impegno da parte del management. Se hai correttamente spiegato tutti gli alti e bassi della tua implementazione e cosa potrebbe accadere se le cose rimangano nel modo in cui sono ora, dovrebbero avere risposto sì o no. Questo è il ruolo chiave del management. Decidere cosa fare in base a ciò che dicono le persone sotto di loro.