Siamo in procinto di spostare la nostra origine dati da Mongo a MS SQL Server. La nostra sfida è che abbiamo due tester verdi. Come squadra, stiamo cercando di lavorare con l'approccio di test più sensato.
Abbiamo due origini dati (un MS SQL, un Oracle) che vengono integrate tramite un file flat feed in un MongoDB, che viene utilizzato per presentare i dati di prodotto su un sito web. Il nostro endpoint è convertire il MongoDB in MS SQL.
Abbiamo due pezzi da testare.
-
Confronto dell'origine dati. Il feed di dati viene caricato in entrambe le origini. Il nostro DBA ha installato Simba MongoDB ODBC con il driver del connettore SQL per permetterci di effettuare confronti side-by-side usando SQL. A mio avviso, il rischio maggiore qui è che il driver esegue il proprio insieme di interpretazioni sulla struttura sottostante dei documenti nell'origine Mongo per presentare i dati come tabelle e, inoltre, le nostre query devono anche ridefinire il dati per essere sicuri di poter confrontare fonti SQL e Mongo.
-
Confronto della logica di visualizzazione . Gli oggetti dati che guidano le pagine del prodotto sono teoricamente indipendenti dall'origine, ma nel front-end è presente una logica di visualizzazione che potrebbe essere influenzata se il modello di dati SQL e il modello di dati Mongo non sono allineati esattamente - e non lo sono. Abbiamo installato HtmlAgilityPack per confrontare elementi sulle pagine del prodotto usando C #. Non sono sicuro di quali rischi ci siano.
Considerate le considerazioni aggiuntive che:
- Stiamo spostando il DB Oracle su MS SQL quest'anno e utilizzeremo questo approccio di prova per quel progetto.
- Abbiamo un disperato bisogno di test automatici per le nostre pagine di prodotto.
- Abbiamo un piano per normalizzare l'origine del DB SQL in fasi successive al cutover, e quindi per eliminare i feed di dati, che richiedono tutti confronti rigidi di origine dati / visualizzazione.
- I nostri tester non hanno esattamente esperienza con i dati di test e le interfacce web, e non hanno background di sviluppo che consentano loro di scrivere codice per i test automatizzati.
Le mie preoccupazioni sono che potremmo considerare l'approccio sbagliato perché i tester non hanno esperienza sufficiente per dirci cosa possono fare. Il gruppo dev sa come testare in questo modo , quindi è così che lo stiamo progettando. Non so se questo approccio funzionerà e sarà mantenibile attraverso le versioni del prossimo anno senza un investimento significativo di tempo e risorse non-tester, e se richiede tempo e risorse non-tester, se questo continuo investimento vale la pena se ciò significa i tester finiscono per fare un lavoro che non richiede pensiero.
C'è un altro modo per farlo che potrebbe essere utilizzato dai nostri tester, per consentire loro di avere più controllo sul processo di test, supportare il loro sviluppo delle competenze e fornire anche l'automazione per le versioni future?