Meniu

Călătoria mea neașteptată pentru a deveni un tester de software (de la nivel de intrare la manager)

my unexpected journey becoming software tester

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

„Construiești o viață de succes ... O zi la rând ...”

Călătoria mea ca Software Tester a început puțin neașteptat.

Am apărut pentru primele runde de interviu presupunând că este o oportunitate de dezvoltare. Sincer să fiu, la fel ca orice alt absolvent de informatică de acolo, am fost un pic sceptic cu privire la continuarea testării.

Dar, în cele din urmă, am decis să încerc. Numai cu speranța că natura mea curioasă mă va ajuta în acest domeniu.

Nu aș putea accepta oferta fără să pun această întrebare - Voi avea ocazia să trec la dezvoltare în cazul în care testarea nu mă interesează? :).

Crede-mă - nici măcar nu m-am gândit să părăsesc Testarea după aceea.

ms sql întrebări și răspunsuri la interviu

călătoria-mea-ca-tester-software

Când am apărut pentru runda tehnică, nu eram pregătit pentru altceva decât pentru conceptul de bază al testării software . Cred că singurul lucru care m-a condus a fost gândul că sunt evaluat logic și nu teoretic ”.

Aceasta a fost prima mea învățătură în testare - am înțeles cum noi ( proaspete ) au fost evaluate.

Chiar și astăzi, folosesc tehnici similare în timp ce angajez freshers pentru echipa mea. Le verific logica, tenacitatea și abordarea unei probleme peste orice altceva.

Citire recomandată => 4 lucruri importante pe care le-am învățat în călătoria mea ca manager de testare a calității

M-am alăturat Zycus ca stagiar de asistență profesională și mi s-a alocat un produs în a treia sau a patra zi. A fost unul dintre cele mai mari și mai ambițioase produse ale companiei. După ce m-am stabilit în primele câteva săptămâni, nu a mai existat nicio întoarcere pentru mine.

Am început ca o echipă de QA formată din doi și la scurt timp după câteva luni am fost singurul care a condus eforturile de testare. În primii 2 - 2,5 ani înșiși am înregistrat aproape 3000 de defecte în diferite categorii, cum ar fi funcțional, performanță, securitate, interfață, utilizare, Multilingv , Multi-Tenancy, etc.

Cu o perioadă considerabilă de timp înainte de noile adăugiri la echipa de testare, m-am confruntat cu o echipă puternică de dezvoltare de 15-16 membri. Chiar și după adăugări, raportul QC: Dev nu a fost foarte sănătos și pot spune cu mândrie că a fost o călătorie de succes, având în vedere tot ceea ce am testat, livrat și manipulat.

Punctul important pe care vreau să-l subliniez aici este- Toate acestea provin dintr-o înțelegere a testării în practică și nu doar a teoriei.

Sunt în domeniul testării software de aproape șase ani acum. A fost o călătorie uimitoare, cu atâtea experiențe diferite și o mulțime de învățare fructuoasă.

În prezent, lucrez ca Senior QA Manager care se ocupă de 5-6 produse și module. Dar ceea ce îmi dă adevărată bucurie și fericire este să conduc o echipă de peste 30 de testeri fericiți și pasionați.

Desigur, mulți oameni au contribuit la învățarea mea, dar tot pot spune că cea mai mare parte a experienței și cunoștințelor mele a venit pe calea grea (și probabil cea mai bună cale), adică învățarea / rezolvarea pe cont propriu.

'Experiența este cel mai bun profesor.'

În timp ce spun acest lucru, nu vreau să spun deloc că nu veți beneficia de învățarea sau urmărirea teoriilor documentate despre testarea software-ului. Ceea ce cred este că totul va ajuta cu siguranță, dar nimic nu poate bate înțelegerea conceptului de bază și confruntarea cu îndrăzneală a problemelor.

Cred că lucrurile documentate nu te vor învăța testare reală , deși vă poate oferi o anumită direcție și atunci sunteți pe cont propriu. Cel puțin în cazul meu, au existat probleme care nu pot fi documentate pentru a rezolva problemele mele exacte sau nu le-am putut găsi la timp. Singura mea alegere a fost să înțeleg problema / situația de bază și să reacționez la aceasta cu abordarea pe care am găsit-o corect.

Exemple - Cum am abordat în diferite situații

Permiteți-mi să explic acest lucru cu ajutorul problemelor / situațiilor cu care mă confruntam și cum le-am abordat.

# 1) Înțelegerea afacerii este mult mai mare decât testarea înțelegerii

Ei bine, știți cu toții asta. Testarea nu înseamnă doar testarea a câteva validări și efectuarea unor verificări.

În calitate de tester, ar trebui să vizualizăm fără greș fiecare scenariu posibil, chiar și cel mai rar dintre scenariile rare. Ar trebui să luăm în considerare toate datele de testare posibile pe care utilizatorul real le-ar putea folosi.

Pentru toate acestea, ar trebui să înțelegem afacerea la maximum.

Nu va fi greșit dacă spun că ar trebui să înțelegem afacerea și baza de utilizatori la fel de mult sau chiar mai mult decât o face un analist de afaceri.

Mă confruntam cu cote similare.

Trebuia să să înțeleagă scenarii complexe de afaceri în domeniul achizițiilor, faceți brainstorming cu noile cerințe și cântăriți-le din perspectiva utilizatorului. Nu trebuia doar să-mi rezolv cazurile, ci și să contribui la etapele de cerință și proiectare ale fiecărei iterații. Chiar și aici, nicio referință pregătită nu a venit la salvarea mea, în afară de capacitatea mea de gândire și raționament.

Pentru a înțelege mai bine afacerea și a vă proiecta scenariile / cazurile mai bine, nimic nu funcționează ca pixul și hârtia.

Citește și => 5 Trebuie să aibă instrumente care nu sunt testate pentru ca testerii să facă viața mai ușoară

Înainte de a merge la Discutarea cerințelor întâlnire, obișnuiam să notez în prealabil posibile îndoieli / corecții / puncte neclare. Obișnuiam să notez scenariile pe care vreau să le încerc sau să construiesc cazuri de testare; uneori, chiar și desenarea scenariilor dvs. funcționează ca un farmec.

Când scrii / desenezi, îți intră în minte cu o mai mare claritate și apoi mintea ta lucrează la aceste informații și produce mai multe scenarii și oferă o claritate mai bună. Acest lucru continuă până când veți obține acel sentiment de GĂSIT !!!

# 2) Efectuează împotriva cotelor și în presiune

Lucram la un produs care era / este imens și suficient de complex pentru a face ca o echipă de 30 de ingineri să lucreze continuu timp de trei ani lungi pentru a ajunge la un nivel de vânzare.

În cea mai mare parte a fazei inițiale, fie m-am confruntat (solo) cu o echipă de 15-20 de dezvoltatori variind de la nivel junior, mijlociu și senior sau am fost însoțit de unul sau de alți testeri. Toți adăugau noi caracteristici la produs fără încetare, ceea ce necesita o atenție egală și paralelă din partea testării.

Fiind parte a întâlnirilor de cerințe, scrierea cazurilor, executarea acestora, runde exploratorii, întreținerea serverelor, implementări, nimic nu era opțional.

Până atunci nu eram conștient de vreo metodologie, cea mai buna practica , curs sau o carte care să-mi arate soluții la astfel de probleme. Nici astăzi nu sunt sigur dacă există ceva care vă poate ajuta cu exactitate să luptați împotriva realităților solului în timp ce le înfruntați.

Ceea ce făceam mai degrabă este, agresiv și runde rapide de testare exploratorie (Nu eram la curent cu numele până atunci) pe fiecare caracteristică una câte una și apoi repet. Această soluție funcționează pur și simplu cu cât de repede vă puteți schimba gândurile și vă puteți încadra situațiile / scenariile.

Desigur, acest lucru cerea o muncă reală rapidă și agresivă, dar a funcționat pentru mine.

Ceea ce vreau să spun prin rundă agresivă este, țintești câte un lucru pe rând (Spuneți câte un element dintr-o formă la un moment dat) și testați-l independent și în asociere cu alte elemente / lucruri legate.

Citire recomandată => Cum să fii un drogat de productivitate (în special ca tester)

De exemplu. Cum se testează o casetă text.

Ce puteți testa aici este:

  1. Dacă acceptă și stochează datele așa cum sunt
  2. Validarea tipului de date
  3. Validarea lungimii maxime
  4. Manevrarea personajului special
  5. Manipularea XSS
  6. Manipularea datelor multilingve
  7. Manipularea spațiilor goale / fără date
  8. Comportamentul tastelor tab și enter
  9. Manipularea erorilor (cross-browser)
  10. Aliniere UI (cross-browser)
  11. Copiați lipiți date / glisați datele linkurilor în caseta text
  12. Cel mai important - comportamentul acestui câmp w.r.t. alte elemente legate (orice așteptare de afaceri legată de acest câmp, cum ar fi popularea ceva în alt câmp pe baza datelor din acest câmp)

Gândirea la testarea de mai sus vă oferă încredere că nimic nu poate merge cu adevărat în neregulă cu acest domeniu?

Ei bine, direcționarea la un singur lucru la un moment dat a funcționat întotdeauna pentru mine și obțineam și eu finalizarea lucrărilor.

# 3) Când vă confruntați cu „neașteptatul”

cel mai bun instrument de revizuire a codului pentru git

Ce carte crezi că te va ajuta brusc cu „Cum să” atunci când ar trebui să faci ceva ce nu ai făcut până acum?

Dacă vorbim specific atunci - Nici unul.

Îmi amintesc de vremea când, în absența liderului nostru de produs, împreună cu puțini alți membri junior și mijlocii trebuia să implementăm aplicația noastră pe Demo (pentru noi era producția de atunci) pentru prima dată. A fost foarte critic pentru prima demonstrație a produsului nostru.

Ei bine, am făcut-o, dar cu multe încercări și erori. Motivul fiind, niciunul dintre noi nu avea experiență Linux și shell scripting . Îmi amintesc, au existat îngrijorări adresate de departamentul nostru de IT (toate cu bună-credință) managerului meu de atunci cu privire la executarea comenzilor greșite pe serverele de producție. Poate că acesta a fost doar un catalizator și shell scripting / Linux a fost interesul meu natural, dar în scurt timp după aceea, am ajuns să îmi asum responsabilitatea de a întreține și actualiza simultan cinci până la șase medii.

Shell și Linux mi-au atras interesul atât de bine, încât în ​​curând am fost cel care a început să organizez sesiuni de formare internă asupra acestuia.

# 4) Când performanța dvs. este măsurată, experiența dvs. nu este

Foarte devreme în carieră, eram comparat și măsurat cu testerii foarte evoluați și cu experiență din jur. Cred că mulți dintre voi trebuie să fi experimentat o situație similară și să știți ce vă fac acele așteptări suplimentare.

Remediul aici a fost să Împingeți-mă și evoluați .

Singura cale de urmat a fost să nu mă gândesc la cât de puțin experimentat sunt, fără a mă limita la standardele mondiale de măsurare cât de lent / repede ar trebui să cresc / să învăț. Nu mă limitez la criteriile lumii în ceea ce privește cât de curând ar trebui să înceapă să conducă și titlul de care ai nevoie înainte de ao face.

Ei bine, în jurul acestui punct, trebuie să spun, indiferent de domeniul în care aparțineți, vă recomand să citiți The Leader Who Had No Title. Te va ajuta să dezlănțuie ce se află în tine. Vă va spune că nimeni în afară de voi nu vă poate reține.

Dacă trebuie să-mi leg experiența în câteva propoziții, merge așa:

„Curiozitatea, atenția la detalii, disciplina, gândirea logică, pasiunea pentru muncă și abilitatea de a diseca lucrurile sunt tot ceea ce contează pentru a fi un tester distructiv și de succes. A funcționat pentru mine și cred cu tărie că va funcționa pentru tine. Dacă ai aceste calități, trebuie să funcționeze pentru tine. ”

Ei bine, citind până aici, dacă vă gândiți că promovez calitățile umane de bază pe baza unor cunoștințe teoretice mai profunde, atunci acest lucru nu este complet adevărat. Cred că pentru a începe cu ceva și pentru a gusta succesul, depinde puțin mai mult de calitățile tale încorporate decât de informațiile pe care le-ai învățat. Cu toate acestea, pentru a merge departe în orice domeniu, trebuie să învățați lecții, principii și experiențe.

Și în cazul meu, a trebuit să învăț terminologiile, conceptele, teoriile într-o oarecare măsură pe măsură ce am ajuns mai departe în carieră. Motivul fiind că, ca tester, trebuie să interacționezi cu mai mulți oameni care vor vorbi în acești termeni și trebuie să-l înțelegi.

În calitate de lider sau de co-tester, veți avea un nou tester care vine dintr-o parte a lumii, cu propriile sale cunoștințe despre fapte, definiții și terminologii. Și aici nu puteți rămâne pasiv față de aceste lucruri; trebuie să aveți o cunoștință prealabilă despre lucrurile maxime posibile folosite / spuse acolo.

Învățarea este inevitabilă.

A trebuit să aflu mai multe despre diferitele tipuri de teste, cum să le execut și modalități de a le explica oamenilor din echipa mea în stadiul potrivit. A trebuit să evaluez ideile, instrumentele noi și să le pun în aplicare. Învățarea conceptelor și metodologiilor noi devine la fel de importantă pe măsură ce urcați pe scară.

Citiți mai multe => Ghidul de la A la Z privind selectarea celei mai bune automatizări

Concluzie

Deși este aproape imposibil să notez toate lucrurile majore și minuscule pe care le-am învățat de-a lungul anilor, aceasta este încercarea mea de a o rezuma într-o listă cu marcatori.

  • Testarea este foarte dificil de definit. Cineva poate face teste superbe și s-ar putea să nu fie capabil să o definească în cuvinte. Este așa cum vedeți.
  • Toată lumea poate avea propria definiție a testării. Al meu a fost simplu- „Vi se dă un lucru - găsiți defecte și îmbunătățiți-l.”
  • Nu aveți neapărat nevoie de teorii mari, matrice complexe sau ISTQB pentru a fi un tester distructiv. Trebuie să fii curios , concentrat și pasionat, gândesc logic și au capacitate de disecare. Cu toate acestea, cunoașterea suplimentară nu dăunează, dar nu cu prețul pierderii esenței.
  • Abordările / conceptele tradiționale au, de asemenea, propria lor importanță și am același respect față de ele, având în vedere faptul că există o bună parte a lumii în care acestea sunt o necesitate justă. Testarea singură nu poate evolua; împrejurimile trebuie să evolueze și pentru asta.
  • Ca tester, devine la fel de important pentru invata noi instrumente, tehnici și metodologii pe măsură ce avansați . Planificarea testelor, abordări mai bune pentru a efectua diferite tipuri de testare, testarea situațională sunt câteva dintre acestea.
  • Deoarece testarea este fluidă, definiția de a fi o potrivire corectă diferă foarte mult de la o organizație la alta. A fi un tester distructiv sau excelent ar putea fi suficient de bun pentru a obține o verificare a plății dacă aveți noroc sau ar putea cere cunoștințe suplimentare despre modul în care funcționează testarea în companiile tradiționale. Ambii sunt chiar la locul lor.de exemplu.Angajez oameni conform definiției mele de testare (care variază puțin în funcție de experiența candidatului și, desigur, de profilul).
  • Deoarece există un stil de codare, conducere, gătit; există, de asemenea, un stil de testare. S-ar putea să nu vă bucurați decât dacă o faceți în felul dvs. Ceea ce vreau să spun este că testarea poate avea îndrumări, dar nu ar trebui să fie legată de micro-procese.
  • Conducerea eficientă ar trebui să-i facă echipei sale să aleagă munca mai degrabă decât să atribuie. El îl poate modifica ocazional pentru îmbunătățirea produsului.
  • Încercați să vă instruiți oamenii în zona lor de interes și împreună cu locul în care doriți să fie instruiți. Aliniați gândurile și eforturile echipei dvs. cu obiectivul final, care este „Cea mai bună calitate”.
  • Nu încercați să vă gestionați oamenii, conduceți-i. Fii prietenos și abordabil, ușurează mult munca.
  • Fiecare membru al echipei dvs. ar trebui să iubească munca pe care o desfășoară, să aibă un atașament față de produs și să fie afectuos față de oamenii din jur. Atunci vor ieși doar cei mai buni dintre ei.
  • Lumea testării trebuie să evolueze. O parte considerabilă a lumii se îndreaptă spre abordări mai practice, cum ar fi testarea exploratorie, testarea bazată pe context (pe care o fac mulți oameni fără să știe că este aceasta), pe care chiar și alții ar trebui să încerce să dezvolte mai multe tehnici precum
  • Ar trebui să se formeze mai multe comunități de testare și oamenii care au aceleași idei ar trebui să se reunească la o scară mai largă. Există atât de multe de împărtășit, învățat, adaptat și inovat.

Sper că experiența și constatările mele vă vor ajuta să deveniți un tester mai bun sau să vă ajute să înțelegeți mai bine testarea.

Lecturi suplimentare => De la începători la profesioniști: un ghid complet pentru călătoria de succes a unui profesionist în testare

Despre autor: Acest articol este scris de Mahesh C., membru al echipei STH. În prezent lucrează ca Senior Assurance Quality Manager, având experiență în conducerea frontului de testare pentru mai multe produse și componente complexe.

Îmi va plăcea să aud înapoi. Comentează aici sau contactează-ne. Mulțumesc mult pentru lectură.

Lectură recomandată

^