Mi sono imbattuto in una situazione in cui il team di sviluppo suggeriva che avrebbero inviato correzioni di bug al nostro ambiente di sviluppo piuttosto che all'ambiente di test e hanno chiesto al QA di testarlo prima. Non sono sicuro che sia una buona pratica, ho sempre pensato che fosse meglio testare nell'ambiente di test, ma forse ci sono circostanze in cui la verifica in ambiente di sviluppo ha più senso?
Consigli generali
Più l'ambiente è vicino a un clone di produzione, più accurato sarà il test. Più è lontano, più caveat.
Molti ambienti di sviluppo non sono simili alla produzione. Principalmente perché sono campi di gioco per gli sviluppatori per provare diverse configurazioni, pacchetti software, servizi, ecc ... Questo non significa che siano inutili (per i test), non saranno definitivi nel dimostrare che qualcosa è stato risolto .
Per quei pochi fortunati che dispongono di ambienti di sviluppo di alta qualità, non sono in realtà diversi dagli ambienti di test, vanno avanti e testano. Ricostruisci innanzitutto l'ambiente.
Per quegli ambienti con una certa deriva dall'essere produzione come, quindi eseguire un sottoinsieme dei test. Questi test mirano a mostrare una qualità sufficiente per ottenere quel codice in un ambiente più simile alla produzione. Nell'ambiente più simile alla produzione vorrei ripetere di nuovo quei test.
Stato di sviluppo nella tua organizzazione
Il fatto che i tuoi sviluppatori stiano suggerendo questo solleva una domanda nella mia testa. Perché questa funzione / correzione non entra nell'ambiente di prova?
Capire il problema di root ti aiuterà a modificare i processi, la tecnologia, la cultura e il sistema per cui sono state risolte i bug.
Per chiarezza: una penalità è una conseguenza negativa che si verifica a seguito di un'azione. Quindi quando dico "c'è una penalità?" Sto parlando di risposte specifiche che possono essere spiegate (il numero di difetti / correzioni controlla direttamente la remunerazione) o implicite (il membro del team è deriso).
Bene perché separare gli ambienti di sviluppo e test?
Normalmente è perché i tester vogliono il controllo su quando il loro ambiente cambia. È fastidioso quando un test che sta per scadere inizia a fallire senza che tu te ne accorga perché non ti sei accorto che l'ambiente è cambiato.
Ora una squadra di sviluppo che spinge verso un ambiente di sviluppo non è affatto strana. Non è strano per il team di sviluppo eseguire test in dev. È un po 'strano aver costruito un test env per il team addetto al controllo qualità e quindi fare in modo che il team addetto al QA utilizzi il test per testare.
Ma niente di questo è un problema fintanto che nessuno va e cambia l'ambiente quando le persone non si aspettano che cambi. Gestire il cambiamento è l'unica ragione per separarli comunque. Quindi, se per qualche motivo, vogliono sospendere questa separazione, forse per stringere il tempo tra la correzione dei bug e il feedback del QA, e forse solo una volta, quindi penso che potrebbe andare bene. Non sorprendere nessuno con questo.
Se funziona davvero bene per te, potrebbe cambiare il tuo modo di test.
Non esiste una risposta giusta per questa domanda. Questo dipende da come il tuo team sviluppa nuove funzionalità, come vengono fornite sulla produzione, il ciclo di sviluppo del team, se il progetto ha budget per avere molti ambienti, ecc.
Lavoro già su un software in cui solo alcune funzionalità sviluppate vengono fornite ai test. Per non unire molte filiali che non potevano essere consegnate alla produzione così presto, abbiamo deciso di separare un ambiente di test con solo il codice che verrà consegnato nella prossima versione del software. Quindi, usa l'ambiente dev non è la soluzione migliore in questo esempio.
Per i casi generali, la soluzione migliore è avere un ambiente di test separato, perché è normale che il team di sviluppo apporti alcune modifiche al software che rende l'ambiente instabile per un certo periodo. Quando ciò accade, il team addetto al controllo qualità non sarà interessato, poiché riceverà solo configurazioni più stabili dell'ambiente.
Ma il test nell'ambiente dev può funzionare anche, ma richiede più discipline e maturità dal team di sviluppo e controllo qualità. Se il team di sviluppo ha la preoccupazione di mantenere l'ambiente di sviluppo sempre stabile, quando qualcosa va storto devono dare la priorità alla stabilizzazione dell'ambiente affinché il team addetto al QA continui i propri test. Il team addetto al controllo qualità, ovviamente, deve essere a conoscenza di questo tipo di blocchi, segnalare e capire che ciò può accadere a volte.
Sarebbe stato un buon senso chiedere allo sviluppatore se ci fosse un motivo particolare per testare l'ambiente di sviluppo. Se c'è una buona ragione per testare l'ambiente di sviluppo. Se gli sviluppatori dicono che c'è una buona ragione ma non vedi la ragione, puoi scegliere tra testare l'ambiente di sviluppo e possibilmente iniziare una battaglia. Se gli sviluppatori ammettono che non c'è una buona ragione, la testerai ovunque tu pensi che sia giusto.