Menu

Il mio viaggio inaspettato per diventare un tester del software (dal livello base a un manager)

my unexpected journey becoming software tester

Prova Il Nostro Strumento Per Eliminare I Problemi

'Costruisci una vita di successo ... un giorno alla volta ...'

Il mio viaggio come Software Tester è iniziato un po 'inaspettatamente.

Sono apparso per i turni iniziali dei colloqui presumendo che fosse un'opportunità di sviluppo. Ad essere onesti, come ogni altro laureato in informatica là fuori, ero un po 'scettico sull'idea di andare avanti con i test.

Ma alla fine ho deciso di fare un tentativo. Solo con la speranza che la mia curiosa natura mi aiuti in questo campo.

Non potrei accettare l'offerta senza porre questa domanda: avrò l'opportunità di passare allo sviluppo nel caso in cui il test non mi interessi? :).

Credimi, non ho nemmeno pensato di lasciare il Test dopo.

come aprire il file JSON in Android

il mio viaggio come tester di software

Quando sono apparso per il round tecnico, non ero preparato ad altro che al concetto di base del test del software . Credo che l'unica cosa che mi ha fatto capire è stato il pensiero di essere valutato logicamente e non teoricamente '.

Questo è stato il mio primo vero apprendimento in Testing - ho capito come noi ( matricole ) sono stati valutati.

Ancora oggi, utilizzo tecniche simili durante l'assunzione di matricole per la mia squadra. Controllo la loro logica, tenacia e approccio a un problema su qualsiasi altra cosa.

Lettura consigliata => 4 cose importanti che ho imparato nel mio viaggio come responsabile del test QA

Sono entrato a far parte di Zycus come apprendista QA e mi è stato assegnato un prodotto circa il terzo o quarto giorno. Era uno dei prodotti più grandi (era in fase di ideazione allora) e più ambiziosi dell'azienda. Dopo essermi sistemato per le prime settimane, non ho potuto tornare indietro.

Abbiamo iniziato come un team di controllo qualità di due persone e subito dopo pochi mesi sono stato l'unico a guidare gli sforzi dei test. Nei primi 2-2,5 anni avevo registrato quasi 3000 difetti in diverse categorie come Funzionale, Prestazioni, Sicurezza, UI, Usabilità, Multilingue , Multi-Tenancy, ecc.

Per molto tempo prima di nuove aggiunte al team di test, ho dovuto affrontare un forte team di sviluppo di 15-16 membri. Anche dopo le aggiunte, il rapporto QC: Dev non era molto salutare e posso ancora dire con orgoglio che è stato un viaggio di successo considerando tutto ciò che abbiamo testato, consegnato e gestito.

Il punto importante che voglio sottolineare qui è- Tutto questo proveniva da una comprensione del test in pratica e non solo dalla teoria.

Sono nel campo del Software Testing da quasi sei anni ormai. È stato un viaggio straordinario con così tante esperienze diverse e un apprendimento fruttuoso.

Al momento lavoro come Senior QA Manager, occupandomi di 5-6 prodotti e moduli. Ma ciò che mi dà vera gioia e felicità è guidare un team di oltre 30 tester felici e appassionati.

Certo, molte persone hanno contribuito al mio apprendimento, ma posso ancora dire che la maggior parte della mia esperienza e conoscenza è arrivata nel modo più duro (e probabilmente nel modo migliore), cioè imparando / risolvendolo da solo.

'L'esperienza è la migliore insegnante.'

Mentre dico questo, non intendo affatto dire che non trarrai beneficio dall'apprendimento o dal seguire teorie documentate sul test del software. Quello che credo è che tutto questo sicuramente aiuterà niente può battere la comprensione del concetto al centro e affrontare i problemi con coraggio.

Credo che le cose documentate non ti insegneranno veri test , anche se può darti una direzione e poi sei da solo. Almeno nel mio caso, c'erano problemi che potrebbero non essere documentati per risolvere i miei problemi esatti o non sono riuscito a trovarli in tempo. La mia unica scelta era capire il problema / la situazione al centro e reagire con l'approccio che ho trovato giusto.

Esempi: come mi sono avvicinato in diverse situazioni

Lascia che ti spieghi questo con l'aiuto dei problemi / situazioni in cui mi trovavo e come li ho affrontati.

# 1) La comprensione del business è superiore alla comprensione dei test

Bene, lo sapete tutti. Il test non è solo il test di poche convalide e l'esecuzione di alcune verifiche.

In qualità di tester, dovremmo visualizzare ogni possibile scenario, anche il più raro dei rari scenari senza fallo. Dovremmo considerare tutti i possibili dati di test che l'utente effettivo potrebbe utilizzare.

Per tutto questo dovremmo capire l'attività al meglio.

Non sarebbe sbagliato se dicessi che dovremmo comprendere il business e la base di utenti tanto quanto o anche più di quanto non faccia un analista aziendale.

Stavo affrontando probabilità simili.

Avrei dovuto comprendere scenari aziendali complessi nel dominio degli appalti, fai un brainstorming sui nuovi requisiti e valutali dal punto di vista dell'utente. Non avrei dovuto solo elaborare i miei casi, ma anche contribuire alle fasi di requisito e progettazione di ogni iterazione. Anche qui, nessun riferimento pronto è venuto in mio soccorso a parte la mia capacità di pensiero e di ragionamento.

Per comprendere meglio il business e progettare meglio i tuoi scenari / casi, niente funziona come carta e penna.

Leggi anche => 5 Devono avere strumenti non di prova per i tester per rendere la vita più facile

Prima di andare a Discussione sui requisiti incontro, annotavo in anticipo eventuali dubbi / correzioni / punti poco chiari. Ero solito scrivere gli scenari che volevo provare o costruire casi di test; a volte, anche disegnare i tuoi scenari funziona come un fascino.

Quando scrivi / disegni, entra nella tua mente con maggiore chiarezza e poi la tua mente lavora su queste informazioni e produce più scenari e dà una migliore chiarezza. Questo va avanti finché non ottieni quella sensazione di FATTO !!!

# 2) Esibirsi contro le probabilità e sotto pressione

Stavo lavorando su un prodotto che era / è enorme e abbastanza complesso da fare in modo che un team di 30 ingegneri lavorasse continuamente per tre lunghi anni per portarlo a un livello vendibile.

Per la maggior parte della fase iniziale, o ero in piedi (da solo) contro un team di 15-20 sviluppatori di livello junior, medio-senior e senior o ero accompagnato da uno o due altri tester. Tutti aggiungevano inesorabilmente nuove funzionalità al prodotto, il che richiedeva un'attenzione uguale e parallela da parte dei test.

Far parte di riunioni sui requisiti, scrivere casi, eseguirli, turni esplorativi, mantenere server, implementazioni, niente era facoltativo.

A quel punto non ero a conoscenza di alcuna metodologia, la migliore pratica , naturalmente o un libro che può mostrarmi soluzioni a tali problemi. Ancora oggi non sono sicuro che ci sia qualcosa che possa aiutarti precisamente a combattere le realtà di base mentre le affronti.

Quello che stavo facendo piuttosto è aggressivo e cicli rapidi di test esplorativi (A quel punto non ero a conoscenza del nome) su ogni funzione uno per uno e poi ripeti. Questa soluzione funziona esclusivamente sulla velocità con cui puoi spostare i tuoi pensieri e inquadrare situazioni / scenari.

Naturalmente, questo richiedeva un lavoro molto veloce e aggressivo, ma per me ha funzionato.

Quello che intendo per round aggressivo è, ti rivolgi una cosa alla volta (Pronuncia un elemento di un modulo alla volta) e testalo indipendentemente e in associazione con altri elementi / cose collegati.

Lettura consigliata => Come essere un drogato di produttività (soprattutto come tester)

Per esempio. Come testare una casella di testo.

Quello che puoi testare qui è:

  1. Se accetta e archivia i dati così come sono
  2. Convalida del tipo di dati
  3. Convalida lunghezza massima
  4. Gestione del personaggio speciale
  5. Gestione XSS
  6. Trattamento dati multilingue
  7. Gestione spazi vuoti / nessun dato
  8. Comportamento di tab e tasti di immissione
  9. Gestione degli errori (cross-browser)
  10. Allineamento dell'interfaccia utente (cross-browser)
  11. Copia incolla dati / trascina i dati dei collegamenti nella casella di testo
  12. La cosa più importante: il comportamento di questo campo w.r.t. altri elementi collegati (qualsiasi aspettativa aziendale collegata a questo campo come la compilazione di qualcosa in qualche altro campo in base ai dati in questo campo)

Pensare ai test di cui sopra ti dà la certezza che nulla può davvero andare storto in questo campo?

Beh, mirare a una cosa alla volta ha sempre funzionato per me e anche io ero solito completare alcuni lavori.

# 3) Quando ti trovi di fronte all ''inaspettato'

Quale libro pensi che ti aiuterà improvvisamente con 'Come fare' quando dovresti fare qualcosa che non hai mai fatto prima?

Se parliamo in modo specifico, allora ... Nessuno.

Ricordo la volta in cui, in assenza del nostro Product lead, io, insieme a pochi altri membri Junior e mid-senior, dovevamo distribuire la nostra applicazione su un'istanza Demo (era di produzione per noi allora) per la prima volta. È stato molto critico per la prima demo in assoluto del nostro prodotto.

Ebbene, lo abbiamo fatto, ma con molte prove ed errori. La ragione è che nessuno di noi aveva esperienza Linux e script di shell . Ricordo, c'erano preoccupazioni sollevate dal nostro reparto IT (tutto in buona fede) al mio manager di allora riguardo al fatto che eseguissi comandi sbagliati sui server di produzione. Forse questo era solo un catalizzatore e lo scripting di shell / Linux era il mio interesse naturale, ma poco dopo ho finito per assumermi la responsabilità di mantenere e aggiornare da cinque a sei ambienti contemporaneamente.

Shell e Linux hanno catturato il mio interesse così bene che presto sono stato io a iniziare a condurre sessioni di formazione interna su di esso.

# 4) Quando le tue prestazioni vengono misurate, la tua esperienza non lo è

All'inizio della mia carriera, venivo confrontato e misurato con i tester molto evoluti ed esperti in circolazione. Credo che molti di voi debbano aver vissuto una situazione simile e sappiano cosa fanno queste aspettative in più su di voi.

Il rimedio qui era quello di Spingiti ed evolvi .

L'unico modo per andare avanti era non pensare a quanto fossi meno esperto, non limitarmi agli standard mondiali di misurazione di quanto lento / veloce dovrei crescere / imparare. Non limitandomi ai criteri di World su quanto presto si dovrebbe iniziare a guidare e il titolo di cui si ha bisogno prima di farlo.

Ebbene, intorno a questo punto, devo dire che, a prescindere dal campo a cui appartieni, ti consiglio di leggere The Leader Who Had No Title di Robin Sharma. Ti aiuterà a liberare ciò che è dentro di te. Ti dirà che nessuno tranne te stesso può trattenerti.

Se devo legare la mia esperienza in poche frasi, va così:

“La tua curiosità, attenzione ai dettagli, disciplina, pensiero logico, passione per il lavoro e capacità di analizzare le cose è tutto ciò che conta per essere un tester distruttivo e di successo. Ha funzionato per me e credo fermamente che funzionerà per te. Se hai queste qualità, deve funzionare per te '.

Bene, leggendo fino a qui se stai pensando che sto promuovendo qualità umane di base su una conoscenza teorica più profonda, allora non è completamente vero. Credo che iniziare con qualcosa e assaporare il successo, dipende leggermente più dalle tue qualità intrinseche che dalle informazioni che hai appreso. Tuttavia, per andare lontano in qualsiasi campo, devi imparare lezioni, principi ed esperienze.

Anche nel mio caso, ho dovuto imparare le terminologie, i concetti, le teorie in una certa misura man mano che avanzavo nella mia carriera. La ragione è che, come tester, devi interagire con diverse persone che parleranno in questi termini e devi capirlo.

Come lead o co-tester, avrai un nuovo tester proveniente da qualche parte del mondo con la sua conoscenza di fatti, definizioni e terminologie. Anche qui non puoi restare passivo verso queste cose; devi avere una conoscenza preliminare delle cose massime possibili usate / dette là fuori.

L'apprendimento è inevitabile.

Ho dovuto imparare di più sui diversi tipi di test, su come eseguirli e sui modi per spiegarli alle persone del mio team al momento giusto. Ho dovuto valutare nuove idee, strumenti e implementarli. L'apprendimento di nuovi concetti e metodologie diventa altrettanto importante man mano che si sale la scala.

Leggi di più => La guida dalla A alla Z sulla selezione della migliore automazione

migliori servizi di teleconferenza gratuita

Conclusione

Sebbene sia quasi impossibile annotare ogni cosa importante e minuta che ho imparato nel corso degli anni, questo è il mio tentativo di riassumerla in un elenco puntato.

  • Il test è molto difficile da definire. Qualcuno può eseguire test superbi e potrebbe non essere in grado di definirlo a parole. È come lo vedi.
  • Ognuno può avere la propria definizione di test. Il mio era semplice 'Ti viene data una cosa: trova i difetti e migliorala.'
  • Non hai necessariamente bisogno di grandi teorie, matrici complesse o ISTQB per essere un tester distruttivo. Devi esserlo curioso , concentrato e appassionato, pensa in modo logico e ha capacità di dissezione. Tuttavia, conoscere gli extra non fa male, ma non a costo di perdere il punto chiave.
  • Anche gli approcci / concetti tradizionali hanno una loro importanza e ho lo stesso rispetto nei loro confronti considerando il fatto che c'è una buona parte del mondo in cui quelli sono una giusta necessità. I test da soli non possono evolversi; anche l'ambiente circostante deve evolversi per questo.
  • Come tester, diventa altrettanto importante imparare di nuovo strumenti, tecniche e metodologie mentre vai avanti . Pianificazione dei test, approcci migliori per eseguire diversi tipi di test, Test situazionali sono alcuni per citarne alcuni.
  • Poiché i test sono fluidi, anche la definizione di essere adatto è molto diversa da organizzazione a organizzazione. Essere un tester distruttivo o eccellente potrebbe essere sufficiente per ottenere uno stipendio se sei fortunato o potrebbe richiedere una conoscenza extra di come funzionano i test nelle aziende tradizionali. Entrambi sono al loro posto.per esempio.Assumo persone in base alla mia definizione di test (che varia leggermente in base all'esperienza del candidato e al profilo, ovviamente).
  • Poiché esiste uno stile di codifica, guida, cucina; c'è anche uno stile di test. Potrebbe non piacerti se non lo fai a modo tuo. Quello che voglio dire è che i test possono avere linee guida ma non dovrebbero essere vincolati dai micro-processi.
  • Il vantaggio efficace dovrebbe fare in modo che il suo team scelga il lavoro piuttosto che l'assegnazione. Può occasionalmente modificarlo per il miglioramento del prodotto.
  • Cerca di formare le tue persone nella loro area di interesse e insieme a dove vuoi che vengano formate. Allinea i pensieri e gli sforzi del tuo team con l'obiettivo finale, che è 'La migliore qualità'.
  • Non cercare di gestire le tue persone, guidale. Sii amichevole e disponibile, rende il lavoro molto più facile.
  • Ogni membro del tuo team dovrebbe amare il lavoro che sta facendo, avere un attaccamento al prodotto ed essere affettuoso verso le persone intorno. Allora solo il meglio di loro verrà fuori.
  • Il mondo dei test deve evolversi. Una parte considerevole del mondo si sta spostando verso approcci più pratici come il test esplorativo, il test guidato dal contesto (che molte persone fanno senza sapere che è) che anche altri dovrebbero provare e sviluppare più tecniche come il
  • Più comunità di test dovrebbero essere formate e persone che la pensano allo stesso modo dovrebbero riunirsi su scala più ampia. C'è così tanto da condividere, imparare, adattare e innovare.

Spero che la mia esperienza e le mie scoperte ti aiutino a diventare un tester migliore o ti aiutino a comprendere meglio i test.

Ulteriore lettura => Dal principiante al professionista: una guida completa al viaggio di successo di un professionista del test

Circa l'autore: Questo articolo è stato scritto dal membro del team STH Mahesh C. Attualmente sta lavorando come Senior Quality Assurance Manager con esperienza di test frontali leader per molteplici prodotti e componenti complessi.

Mi piacerebbe sentire di nuovo. Commenta qui o contattaci. Grazie mille per la lettura.

Lettura consigliata

^