A Kathmandu il corso QA evita l’automazione per il primo mese

A Old Baneshwor, Kathmandu, Saarathi Academy insegna QA senza automazione per il primo mese. Quattro settimane su cosa testare, come scrivere un bug che si possa rifare, e come controllare API e database. Gli script arrivano dopo, quando le scelte sono solide¹.

Uno script ripete i controlli che decidi. Se i controlli sono deboli, l’automazione li renderà solo più veloci, non migliori. Il corso introduce Playwright dopo la quarta settimana e pubblica il syllabus settimanale prima del pagamento¹.

La prima settimana inquadra il lavoro del tester nel ciclo di sviluppo. Si parte dal viaggio di una funzione, dall’idea al rilascio. Si vede dove entra il testing in ogni passaggio. Si distinguono i livelli: un pezzo alla volta, pezzi insieme, e l’intera app come la usa un utente. In parallelo si aggiungono le basi di Git. Il codice dei test vivrà lì, e un datore guarda GitHub. La pratica si fa su Practice Software Testing, un negozio dimostrativo con una versione apposta piena di difetti. Si sceglie una pagina, per esempio login, e si elenca tutto quello che deve fare¹.

La seconda settimana entra nella progettazione dei test. Non si provano input a caso. Si scelgono i pochi che contano. Equivalence partitioning raggruppa gli input che dovrebbero dare lo stesso esito e ne prova un valore per gruppo. Boundary value analysis colpisce i bordi, dove spesso il codice cede. Caso semplice: un campo mese accetta da 1 a 12. Si prova 0, 1, 12 e 13, i valori ai lati di ogni bordo. Per un numero di cellulare nepalese si testano 9, 10 e 11 cifre, non cinquanta numeri a caso. In queste giornate si consiglia anche di iniziare un po’ di JavaScript ogni giorno, utile dalla quinta settimana¹.

La terza settimana allena la scrittura di un bug report che porta a una correzione. Un bug che non si può rifare non si chiude. La guida di Mozilla mette i passi per riprodurlo come parte più importante. Un buon report contiene quattro elementi: una sintesi breve che nomina il problema, passi numerati per rifarlo, cosa ti aspettavi e cosa è successo, il browser, il dispositivo e la versione. Due regole: separa ciò che hai visto da ciò che supponi, e un bug per segnalazione. Per chi scrive in inglese come seconda lingua, i passi numerati funzionano meglio dei paragrafi lunghi¹.

La quarta settimana scende sotto l’interfaccia. Postman manda richieste dirette all’API e mostra la risposta. Ogni risposta ha un codice di stato. Da 200 a 299 è successo, da 400 a 499 la richiesta è sbagliata, da 500 a 599 il server ha fallito, come spiega MDN. Un test semplice nasce da qui. Invia un valore vuoto o errato. Un’API solida risponde con 400 e un messaggio chiaro. Un 500 indica che il server non sa gestire il caso. È un bug da segnalare. SQL serve allo stesso scopo per i dati. Fai un ordine nell’app, poi esegui una SELECT per verificare che esista la riga con l’importo giusto. Così emergono difetti che i clic non mostrano¹.

Per tutto il primo mese basta un portatile vecchio. Servono solo un browser, l’app desktop di Postman, un editor di testo e Git. Il negozio di pratica gira online, quindi non si installa nulla di pesante. Gli strumenti più impegnativi arrivano dopo, quando inizia l’automazione. A quel punto saprai anche se il lavoro di QA fa per te¹.

Chi vuole provare stasera può aprire la versione difettosa del negozio di pratica, darsi 30 minuti, trovare un bug e scriverlo con le quattro parti. Poi installare Postman, inviare la prima richiesta seguendo la guida, leggere il codice di stato, romperla cambiando l’indirizzo e osservare di nuovo. Saarathi Academy struttura il corso in questa sequenza: testing manuale nelle settimane 1-3, Postman e SQL nella settimana 4, poi automazione con Playwright¹.

Il primo mese costruisce il pensiero. Il codice aiuta dopo, quando gli stessi controlli devono girare a ogni modifica¹.