Come professionista dei progetti Appian, saprai che una costante è trovarsi di fronte a continui cambiamenti di requisiti e miglioramenti nei processi.
Sai che Appian è una piattaforma ampia, unificata, ricca di soluzioni e altamente agile. Man mano che il progetto entra nella fase di manutenzione correttiva, il numero di piccoli cambiamenti aumenta, influenzando qualsiasi parte dell'applicazione, quindi:
TUTTO È SUSCETTIBILE A CAMBIARE, persino quelle parti che erano stabili.
Ora, i test di regressione coprono l'intera applicazione, sono più estesi rispetto alla fase di creazione del progetto, che si concentra solo sulle nuove parti. Di conseguenza, se i test non sono automatizzati, avrai notato che i test sono diventati il nuovo collo di bottiglia per il delivery. Tutti gli occhi sono puntati sul team di QA, e dobbiamo aspettare che completino il lavoro per rilasciare la nuova versione.
In altre tecnologie, il team tecnico non è così veloce nello sviluppo evolutivo e si combina meglio con il team di QA. Ma in Appian, i cambiamenti sono molto rapidi e i test?... dipende! La chiave sta nel modo in cui affrontiamo e risolviamo la regressione.
La gestione della regressione influisce senza dubbio sull'efficienza, sulla redditività e anche sul successo del progetto e, di conseguenza, sulla fidelizzazione del cliente.
Quali sono le misure più comuni che adottiamo?
- Nel caso in cui tu stia automatizzando i test, avrai bisogno di coinvolgere figure di alto livello come un QA engineer per apportare le modifiche alle automazioni correlate. In genere, queste figure hanno un approccio molto tecnico e meno orientato alla funzionalità. Il loro coinvolgimento costante di solito comporta costi elevati e non sempre sono altamente reattivi o risolutivi. Spesso è comune che il QA engineering stia lavorando contemporaneamente su altri progetti non Appian.
- Nel caso in cui tu non stia automatizzando, coinvolgerai tester manuali. Ma poiché ora devi eseguire una regressione sull'intera applicazione, avrai bisogno di più tester per completare i test in tempo, o la regressione richiederà significativamente più tempo.
Per una gestione soddisfacente del QA, è necessario implementare un buon grado di automazione dei test.
Ci sorgono sempre queste domande;
Se per la maggior parte dei cambi bisogna fare il correttivo dei test automatici ci richiede quasi più sforzo che apportare le stesse modifiche allora.......
- Perché dovrei continuare ad automatizzare i test?
- Come posso gestire l'impatto dei cambiamenti sui miei test automatici?
Dovremmo quindi cercare un modello in cui un piccolo cambiamento corrisponda a un piccolo impatto sull'automazione dei test...
Sono sicuro che queste sono domande, che tutti i professionisti Appian si sono posti.
Ci piacerebbe condividere la nostra esperienza acquisita avendo avuto l'opportunità di partecipare a progetti di rilievo insieme a professionisti eccellenti a tutti i livelli.
Sulla base della nostra esperienza sul campo, possiamo dire che abbiamo visto come ogni progetto Appian che supera i 6 mesi ha bisogno di implementare test automatici per minimizzare le deviazioni. (di tempo e di costi). Quindi, quali sarebbero i punti più importanti da considerare per implementare l'automazione dei test?
- Scegli attentamente lo strumento di automatizazione test.
- Comprendi bene in quale fase si trova il tuo progetto.
- Valuta il livello di cambiamenti che stai affrontando e l'eccellenza dei risultati.
1 Strumenti
Strumenti Generalisti
Saprai che esistono numerose applicazioni e strumenti generalisti, sempre più potenti, che consentono di automatizzare efficacemente la regressione. Per ulteriori informazioni sulle alternative disponibili sul mercato, ti consigliamo di leggere altri articoli nel nostro blog che trattano questo tema. Tuttavia, la potenza (soprattutto dei più costosi) dal punto di vista di un progetto BPM o di un'esperienza con progetti Appian, evidenzia i seguenti vantaggi e svantaggi:
- Sono strumenti volti a semplificare la vita degli specialisti QA, soprattutto in progetti con tecnologia tradizionale. Di conseguenza, il loro grado di collaborazione non è elevato.
- Hanno una notevole potenza tecnica per problemi generali (riconoscimento di immagini, elaborazione di testi, ...)
- Sono pensati per progetti stabili, con poco bisogno di manutenzione.
- Non seguono la filosofia Appian in termini di utilizzo di componenti riutilizzabili.
- Di solito non sono orientati alla costruzione.
Vogliamo fornire alcuni esempi significativi basati sulla nostra esperienza reale, poiché ci siamo trovati in diverse situazioni in cui tali automazioni sono state più un problema che una soluzione.
Orientamento alla manutenibilità di Appian
In più di un'occasione, abbiamo visto come i responsabili dei test di qualità provenienti da progetti al di fuori del mondo di Appian abbiano implementato la propria soluzione di automazione concentrandosi sulla regressione. Dopo aver compiuto un grande sforzo tecnico nell'automazione, i continui cambiamenti nello sviluppo hanno reso inutile tale sforzo, e si è gettata la spugna, poiché non era sostenibile mantenere i costi della licenza più i costi dell'ingegneria QA.
Cambiamento delle versioni di Appian
Come sai, Appian evolve la piattaforma con 4 versioni ogni anno. Il cambio di versione della piattaforma può avere un impatto sul rendering degli oggetti. Va considerato che la maggior parte delle soluzioni generaliste si basa proprio sul rendering, sulle posizioni degli schermi o nel tentativo di trovarli (piuttosto che comprendere gli oggetti di Appian).Recentemente ci siamo trovati in un grande progetto, automatizzato con uno strumento generalista, potente e costoso, dopo un cambio di versione di Appian che ha avuto un impatto sul rendering, tutti i test di regressione smisero di funzionare! È stato necessario uno sforzo di testing enorme per adattare i test già realizzati, poiché erano diventati inutilizzabili, e si è messa in discussione l'utilità reale di tale strumento nel progetto!
Specialista in Ingegneria QA
No é un segreto che gli specialisti in ingegneria QA sono profili molto ricercati e costosi sul mercato.
Quindi é molto complicato ottenere un beneficio in uno scenario di piccoli cambi continui. Più complesso sarà lo strumento, più costoso sarà il profilo e più ci costerà mantenere il progetto.
Strumento per specialisti o App specializzata nella piattaforma
Entriamo in gioco noi!
L'esperienza accumulata in significativi progetti Appian, sia nell'area dello sviluppo che nell'automazione del testing, ci ha portato a creare una soluzione che coinvolge designer di Appian, QA e tester, manager, product owner e specialisti funzionali. Infatti, la nostra soluzione AAT (Appian Automated Testing) può risultare utile per ogni partecipante al progetto, poiché non richiede competenze tecniche né comporta la scrittura di linee di codice o la gestione di script.È orientata agli utenti finali e presenta una visione funzionale.
Rispetto agli strumenti generici spesso implementati nei progetti Appian, che vengono abbandonati dopo alcuni mesi a causa della loro mancanza di adattabilità ai cambiamenti e al turnover degli specialisti, la nostra soluzione è stata molto apprezzata dai nostri clienti poiché ogni membro del team può capire e mantenere i test.
L'evoluzione della nostra soluzione ha queste caratteristiche principali:
• AAT è uno strumento specifico, focalizzato su Appian.
• Non è necessario avere competenze di programmazione, qualsiasi utente, ad esempio un tester manuale, può utilizzarlo e creare test automatici in poco tempo.
• È basato sul comportamento e non su altri sistemi di riconoscimento (Come abbiamo giá parlato in blog anteriori), ed è in grado di reagire in modo altamente reattivo ai cambiamenti.
• Grazie ai suoi componenti riutilizzabili, è possibile modificare componenti che influenzano decine di casi di test in pochi minuti.
• È collaborativo, cioè tutti i profili possono contribuire al ciclo di testing. Inoltre, consente a qualsiasi utente, dal tester allo sviluppatore, passando per il Product Owner, di eseguire o persino modificare qualsiasi test in modo estremamente rapido e semplice.
2 Momento o fase del proyecto
Sei sicuro che la tua strategia di testing automatico sia allineata con la fase in cui si trova il tuo progetto?
Avere una visione delle fasi del progetto ti consente di adattare dinamicamente la strategia di testing.
Progetto nuovo
In questi casi, la regressione è minima, anche se aumenterà con il passare degli sprint. Ti consigliamo di gettare le basi del progetto scegliendo una metodologia BDD e uno strumento che la supporti completamente, come AAT.
Progetto in fase di cambiamento
Il cambiamento di fase è un momento eccellente per capire che hai bisogno di implementare una soluzione importante per evitare problemi di regressione nella nuova fase in cui stai entrando. Tieni presente che, a meno che tu non abbia utilizzato fin dall'inizio il BDD e non abbia quasi tutto automatizzato, è necessario che tu pensi seriamente a come affrontare la regressione. Non prevenire lo sforzo della regressione comporterà sicuramente importanti deviazioni.
Progetto in corso
Se hai sintomi che qualcosa non va, soprattutto se le anomalie vengono rilevate in ritardo o le UAT si prolungano sempre di più, ti suggeriamo di non sottovalutarlo. È qui che i test di regressione sono più importanti e hanno più peso. Ci sono diverse modalità per riorientare la gestione del QA. Chiedici di spiegarti come.
Progetto in uno stato critico
Se il team è nuovo nel progetto e non lo ha ancora fatto proprio, o se il progetto è iniziato male e ha sempre subito deviazioni, diventa molto difficile da gestire man mano che cresce. È il momento di chiedere consigli e aiuto. Siamo a tua disposizione per una seconda opinione, per aiutarti con le strategie per riorientare il progetto e per affiancarti nel rimettere la situazione in carreggiata, in modo che entri in una regressione controllata.
3 Valuta il livello di cambiamenti che stai affrontando e l'eccellenza dei risultati
Se il progetto è molto stabile, non c'è molto da dire... Ma se ci sono cambiamenti, considera le chiavi dell'eccellenza:
- BDD: crea il test automatico durante lo sviluppo, non aspettare che lo sviluppo sia completato, in modo che i designer possano utilizzarlo.
- Shift-left: il test deve essere eseguito costantemente. Almeno ogni notte, in modo che il team possa vedere i risultati quotidianamente.
- Mantieni l'allineamento con Appian: 1 componente di Appian = 1 componente di test. Migliorerà la manutenibilità del test.
- Esegui i test in tutti gli ambienti non produttivi.
- Effettua audit periodici sulla qualità del tuo codice.
Conclusione
Potremmo continuare a parlare approfonditamente della nostra esperienza con la regressione, affrontando gli aspetti chiave dell'adattamento al cambiamento, ma per riassumere:
- Nella maggior parte dei progetti Appian è conveniente automatizzare la regressione, ma sempre avendo una buona strategia e un'adeguata strumentazione in linea con essa.
- Il QA deve essere sempre allineato all'approccio Agile fornito da Appian come piattaforma. Perderlo è una delle principali cause per cui si smette di automatizzare.
- I benefici dell'automazione della regressione sono molteplici: aiuta ad aumentare la fiducia nel progetto sia internamente nel team che nei confronti del cliente finale, riduce i problemi di impatto dovuti al turnover di personale, dinamizza e accelera gli sprint e rafforza il valore dei delivery.
Per noi è importante confrontarci con nuove situazioni e ti incoraggiamo a presentarci il contesto del tuo progetto.
Tieni presente che di solito una prova di concetto senza impegno di una settimana è sufficiente per individuare elementi importanti e valutare la fattibilità delle soluzioni.
