Quali qualità fanno un buon ingegnere QA?

Cosa fa un buon ingegnere QA

• Comprensione ampia del prodotto

Per testare efficacemente un prodotto, l'ingegnere QA deve conoscerlo abbastanza bene. Questo sembra ovvio, ma purtroppo è spesso sottovalutato. Conoscere bene il prodotto include anche sapere come gli utenti finali si aspettano che funzioni. Anche questo può sembrare ovvio, ma ricordate che la parte più grande nei test è il test black-box. L'ingegnere del QA deve avere una visione "focalizzata sul cliente".

Ma un buon ingegnere del QA deve anche sapere come è progettato il prodotto perché più si conosce il prodotto, meglio si è in grado di testarlo. Tuttavia, l'ingegnere del QA dovrà analizzare il design solo dopo che il suo black-box testplan è stato completato. Infatti, conoscere il design può influenzare ampiamente la strategia di test. È meglio scrivere prima il piano di test con una visione di alto livello, ottenendo poi sempre più informazioni per raffinare il test.

• Comunicazione efficace

La comunicazione è un'abilità estremamente importante per un ingegnere QA. Naturalmente, le riunioni (stand-up ecc.) e i rapporti di stato fanno parte della comunicazione ma, cosa più importante, un ingegnere QA deve essere particolarmente efficiente nei seguenti compiti:

• Comunicazione diretta con i team di sviluppo e di definizione del prodotto
• Capacità di comunicare con persone tecniche e non tecniche
• Avere la diplomazia di dire "no" quando un bug è considerato come non risolto
• Avere la diplomazia di comunicare su un bug senza "offendere" lo sviluppatore. Gli sviluppatori possono spesso sentirsi offesi quando un bug viene presentato. Questo è naturale al 100%. Questo è il motivo per cui l'ingegnere QA deve avere la capacità di "criticare senza offendere"
• Non fare affidamento sul database di "bug tracking" per la comunicazione! Non c'è niente di meglio di un sistema di bug tracking per creare "incomprensioni" tra i team di sviluppo e QA
• Creatività

Il test richiede molta creatività. I bug sono spesso nascosti e la semplice esecuzione dei test positivi ovvi avrà solo poche possibilità di trovare effettivamente dei bug. Quindi, l'ingegnere del QA deve usare la sua creatività per capire tutti gli scenari che possono rilevare un bug. In altre parole, l'ingegnere del QA deve essere in grado di "vedere oltre l'ovvio".

• Conoscenza dello sviluppo

La Quality Assurance richiede la conoscenza dello sviluppo del software per due motivi fondamentali:

• Sono necessarie capacità di sviluppo per poter eventualmente codificare i test automatici
• Se si sa come sviluppare, si hanno idee migliori su cosa è "pericoloso" codificare, quindi cosa testare più a fondo
• Driver per i risultati

Un buon ingegnere QA non dimentica mai che l'obiettivo finale non è solo trovare bug ma anche farli risolvere. Una volta che un bug è stato trovato ed è stato "riconosciuto" dal team di sviluppo, all'ingegnere di QA può essere richiesto di "convincere" le persone a correggerlo.

Inoltre, ottenere un bel framework di automazione con strumenti intelligenti non porta nulla se alla fine non trova alcun bug.

• Chiedetevi se l'automazione vi aiuterà a trovare più bug e quando
• Privilegiate i vostri compiti di test sull'unico criterio importanteQuanti bug probabilmente troverà? Quanto saranno importanti i bug trovati (rilevare migliaia di bug cosmetici è irrilevante/inutile - e spesso facile - fino a quando tutti i bug maggiori/mostruosi sono stati trovati)?