Meny

Min oväntade resa till att bli programvarutestare (från nybörjarnivå till chef)

my unexpected journey becoming software tester

Prova Vårt Instrument För Att Eliminera Problem

'Du bygger ett framgångsrikt liv ... En dag i taget ...'

Min resa som programvarutestare började lite oväntat.

Jag deltog i de första intervjuomgångarna under antagande att det var en utvecklingsmöjlighet. För att vara ärlig, som varje annan datavetenskapskandidat där ute, var jag lite skeptisk till att gå vidare med Testing.

Men slutligen bestämde jag mig för att prova. Bara med ett hopp om att min nyfikna natur kommer att hjälpa mig inom detta område.

Jag kunde inte acceptera erbjudandet utan att ställa den här frågan - Får jag en möjlighet att byta till utveckling om testning inte intresserar mig? :).

Tro mig - jag har aldrig ens tänkt på att lämna Testing efter det.

ba frågor att ställa på intervjun

min resa-som-en-programvarutestare

När jag dök upp för den tekniska omgången var jag inte beredd på något mer än grundläggande koncept för programvarutestning . Jag antar att det enda som tog mig igenom var tanken att jag utvärderas logiskt och inte teoretiskt ”.

Detta var mitt allra första lärande i testning - jag förstod hur vi ( nybörjare ) utvärderades.

Även idag använder jag liknande tekniker när jag anställer nybörjare till mitt team. Jag kollar deras logik, uthållighet och inställning till ett problem framför allt annat.

Rekommenderad läsning => 4 Viktiga saker jag lärde mig i min resa som QA Test Manager

Jag gick med i Zycus som QA Trainee och tilldelades en produkt någon tredje eller fjärde dag. Det var en av företagets största (var i koncept då) och mest ambitiösa produkter. Efter att ha lagt mig ner under de första veckorna var det ingen väg tillbaka för mig.

Vi började som ett QA-team på två och strax efter några månader var jag den enda som körde testinsatserna. Under de första 2 - 2,5 åren hade jag loggat nästan 3000 defekter i olika kategorier som Functional, Performance, Security, UI, Usability, Flerspråkig , Multi-Tenancy, etc.

Under en lång tid innan nya tillägg till testteamet var jag emot ett starkt 15-16-medlemmars utvecklingsteam. Även efter tilläggen var QC: Dev-förhållandet inte särskilt hälsosamt och jag kan fortfarande stolt säga att det var en lyckad resa med tanke på allt vi testade, levererade och hanterade.

Den viktiga punkten jag vill belysa här är- Allt detta var från en förståelse för testning i praktiken och inte bara teori.

Jag har varit i Software Testing-fältet i nästan sex år nu. Det har varit en fantastisk resa med så många olika upplevelser och massor av fruktbart lärande.

För närvarande arbetar jag som Senior QA Manager och ser efter 5-6 produkter och moduler. Men det som ger mig riktig glädje och lycka är att leda ett team med 30+ glada och passionerade testare.

Självklart har många bidragit till mitt lärande, men jag kan fortfarande säga att de flesta av mina erfarenheter och kunskaper har kommit på den hårda vägen (och förmodligen det bästa sättet), dvs.

'Erfarenhet är den bästa läraren.'

Medan jag säger detta menar jag inte alls att du inte kommer att dra nytta av att lära dig eller följa dokumenterade teorier om programvarutestning. Vad jag tror är att allt detta säkert kommer att hjälpa till ingenting kan slå förståelsen av konceptet i grunden och djärvt möta problemen.

Jag tror att dokumenterade saker inte lär dig verklig testning , även om det kan ge dig lite riktning och då är du ensam. Åtminstone i mitt fall fanns det problem som kanske inte dokumenterades för att lösa mina exakta problem eller så kunde jag inte hitta dem i tid. Mitt enda val var att förstå problemet / situationen i grunden och reagera på det med den inställning som jag fann rätt.

Exempel - Hur jag närmade mig i olika situationer

Låt mig förklara detta med hjälp av problem / situationer jag var emot och hur jag närmade mig dem.

# 1) Affärsförståelse är ett steg högre än att förstå testning

Ni vet alla detta. Testning är inte bara att testa några valideringar och göra en verifiering.

Som testare ska vi visualisera alla möjliga scenarier, även de sällsynta i det sällsynta scenariot utan att misslyckas. Vi ska överväga alla möjliga testdata som den faktiska användaren kan använda.

För allt detta, vi ska förstå verksamheten till fullo.

Det kommer inte att vara fel om jag säger att vi borde förstå verksamheten och användarbasen så mycket som eller till och med mer än vad en affärsanalytiker gör.

Jag hade liknande odds.

jag skulle förstå komplexa affärsscenarier i upphandlingsdomänen, brainstorma de nya kraven och väga dem ur användarens perspektiv. Jag var inte bara tänkt att ta reda på mina ärenden utan också bidra i krav- och designfaserna för varje iteration. Även här kom ingen redo referens till min räddning förutom min tänkande och resonemangsförmåga.

För att bättre förstå verksamheten och utforma dina scenarier / fall bättre, ingenting fungerar som penna och papper.

Läs också => 5 måste ha verktyg som inte testar testare för att göra livet enklare

Innan du går till Kravsdiskussion möte, brukade jag skriva ner eventuella tvivel / korrigeringar / oklara punkter i förväg. Jag brukade skriva ner de scenarier jag vill försöka bygga testfall på; ibland fungerar till och med att rita dina scenarier som en charm.

När du skriver / ritar kommer det in i ditt sinne med bättre tydlighet och sedan arbetar ditt sinne på den här informationen och ger fler scenarier och ger bättre tydlighet. Detta fortsätter tills du får den känslan av KLAR !!!

# 2) Utföra mot oddsen och i tryck

Jag arbetade med en produkt som var / är enorm och tillräckligt komplex för att få ett team med 30 ingenjörer att arbeta kontinuerligt under tre långa år för att få den till en säljbar nivå.

Under större delen av den inledande fasen var jag antingen uppe (solo) mot ett team med 15-20 utvecklare som sträckte sig från junior-, mellan-senior- och seniornivå eller åtföljdes av en eller några andra testare. De lade alla nya funktioner till produkten obevekligt, vilket krävde lika och parallell uppmärksamhet från testsidan.

Att vara en del av kravmöten, skriva ärenden, genomföra dem, utforskande omgångar, underhålla servrar, distributioner, ingenting var valfritt.

Då var jag inte medveten om någon metod, bästa praxis , kurs eller en bok som kan visa mig lösningar på sådana problem. Även idag är jag inte säker på om det finns något som kan hjälpa dig att bekämpa markens verklighet när du möter dem.

Det jag snarare gjorde är aggressivt och snabba undersökningsrunder (Jag var inte medveten om namnet då) på varje funktion en efter en och upprepa sedan. Denna lösning fungerar uteslutande på hur snabbt du kan flytta dina tankar och bilda situationer / scenarier.

Naturligtvis krävde detta riktigt snabbt och aggressivt arbete men det fungerade för mig.

Vad jag menar med aggressiv runda är, du riktar in en sak åt gången (Säg ett element i en form åt gången) och testa det självständigt och i samband med andra länkade element / saker.

Rekommenderad läsning => Hur man är en produktivitetsjunkie (speciellt som testare)

T.ex. Hur man testar en textruta.

Vad du kan testa här är:

  1. Oavsett om den accepterar och lagrar data som de är
  2. Validering av datatyp
  3. Validering av maxlängd
  4. Specialkaraktärs hantering
  5. XSS-hantering
  6. Flerspråkig datahantering
  7. Hantering av tomma utrymmen / inga data
  8. Uppförande av fliken och Enter-tangenterna
  9. Felhantering (webbläsare)
  10. UI-justering (webbläsare)
  11. Kopiera klistra in data / dra länkdata till textrutan
  12. Viktigast - beteendet för detta fält w.r.t. andra länkade element (alla affärsförväntningar kopplade till detta fält som att fylla i något annat fält baserat på data i detta fält)

Ger det att tänka på ovanstående testning dig självförtroende att ingenting mycket kan gå fel med detta område?

Tja, inriktning på en sak åt gången fungerade alltid för mig och jag brukade också få lite jobb.

# 3) När du står emot det 'oväntade'

Vilken bok tror du plötsligt hjälper dig med ”Hur man” när du ska göra något du aldrig har gjort förut?

Om vi ​​pratar specifikt då- Ingen.

Jag kommer ihåg den tid då jag i avsaknad av vår produktledning, tillsammans med få andra Junior- och mid-seniormedlemmar, skulle distribuera vår applikation på Demo (var produktion för oss då) exempel för första gången. Det var mycket viktigt för första gången demo av vår produkt.

Tja, vi gjorde det, men med massor av försök och fel. Anledningen var att ingen av oss hade expertis på Linux- och shell-skript . Jag kommer ihåg att det kom oro från vår IT-avdelning (allt i god tro) till min dåvarande chef om att jag kör fel kommandon på produktionsservrar. Kanske var detta bara en katalysator och shell-skript / Linux var mitt naturliga intresse, men på kort tid efter det slutade jag med att ta ansvar för att underhålla och uppgradera fem till sex miljöer samtidigt.

Shell och Linux fångade mitt intresse så bra att det snart var jag som började genomföra interna träningspass på det.

# 4) När din prestation mäts är din upplevelse inte

Mycket tidigt i min karriär blev jag jämförd och mätt mot de mycket utvecklade och erfarna testarna runt. Jag tror att många av er måste ha upplevt en liknande situation och vet vad dessa extra förväntningar gör med dig.

Åtgärden här var att Push myself & Evolve .

Den enda vägen framåt var att inte tänka på hur mindre erfaren jag är, inte begränsa mig av världens standarder för att mäta hur långsamt / snabbt jag ska växa / lära mig. Inte begränsa mig till världens kriterier för hur snart man bör börja leda och titeln man behöver innan man gör det.

Tja, runt denna punkt måste jag säga, oavsett vilket fält du tillhör, rekommenderar jag att du läser Robin Sharmas The Leader Who Had No Title. Det hjälper dig att släppa loss vad som finns i dig. Det kommer att berätta att ingen utom dig själv kan hålla dig tillbaka.

Om jag måste binda min upplevelse i några meningar går det så här:

“Din nyfikenhet, uppmärksamhet på detaljer, disciplin, logiskt tänkande, passion för arbete och förmåga att dissekera saker är allt som är viktigt för att vara en destruktiv och framgångsrik testare. Det fungerade för mig och jag tror starkt att det kommer att fungera för dig. Om du har dessa egenskaper måste det fungera för dig. ”

hur man gör ett ddos-program

Tja, att läsa så långt om du tänker att jag främjar grundläggande mänskliga egenskaper över djupare teoretisk kunskap, så är det inte helt sant. Jag tror att börja med något och smaka på framgång, det beror något mer på dina inbyggda egenskaper än på information du har lärt dig. Men för att gå långt inom vilket område som helst måste du lära dig lektioner, principer och erfarenheter.

Även i mitt fall var jag tvungen att lära mig terminologier, begrepp, teorier i viss utsträckning när jag nådde längre i min karriär. Anledningen är att som testare måste du interagera med flera personer som kommer att prata i dessa termer och du måste förstå det.

Som lead eller co-testare kommer du att få en ny testare som kommer från någon del av världen med sin egen kunskap om fakta, definitioner och terminologier. Även här kan du inte vara passiv gentemot dessa saker; du måste ha en förkunskap om maximalt möjliga saker som används / sagt där ute.

Lärande är oundvikligt.

Jag var tvungen att lära mig mer om olika typer av tester, hur man utför det och sätt att förklara det för människor i mitt team i rätt skede. Jag var tvungen att utvärdera nya idéer, verktyg och implementera dem. Att lära sig nya koncept och metoder blir lika viktigt när du går uppför stegen.

Läs mer => A till Z-guiden för att välja den bästa automatiseringen

Slutsats

Även om det är nästan omöjligt att skriva ner alla viktiga saker som jag har lärt mig under åratal, är detta mitt försök att sammanfatta det i en punktlista.

  • Testning är mycket svårt att definiera. Någon kan göra utmärkta tester och kanske inte kan definiera det med ord. Det är som du ser det.
  • Alla kan ha sin egen definition av testning. Gruvan var enkel- 'Du får en sak - hitta fel och göra det bättre.'
  • Du behöver inte nödvändigtvis stora teorier, komplexa matriser eller ISTQB för att vara en destruktiv testare. Du måste vara nyfiken , fokuserad och passionerad, tänker logiskt och har dissektionsförmåga. Att veta extra skadar dock inte men inte på bekostnad av att förlora kärnan.
  • De traditionella tillvägagångssätten / koncepten har också sin egen betydelse och jag har lika respekt för dem med tanke på att det finns en bra del av världen där de är en rättvis nödvändighet. Att testa ensam kan inte utvecklas; det omgivande måste också utvecklas för det.
  • Som testare blir det lika viktigt att lära sig nytt verktyg, tekniker och metoder när du går vidare . Testplanering, bättre metoder för att utföra olika typer av test, Situationstester är några att nämna.
  • Eftersom testning är flytande skiljer sig definitionen av att vara rätt passform också väldigt mycket från organisation till organisation. Att vara en destruktiv eller utmärkt testare kan bara vara tillräckligt bra för att få en lönecheck om du har tur eller det kan kräva extra kunskap om hur testning fungerar i traditionella företag. Båda är rätt på sin egen plats.t.ex.Jag anställer människor enligt min definition av testning (som varierar lite per kandidatupplevelse och naturligtvis profil).
  • Eftersom det finns en typ av kodning, körning, matlagning; det finns också en typ av testning. Du kanske inte tycker om det om du inte gör det på ditt sätt. Vad jag menar är att testa kan ha riktlinjer men det borde inte vara svårt bundet av mikroprocesserna.
  • Den effektiva ledningen bör få sitt team att välja arbetet snarare än att tilldela. Han kan ibland ändra det för att förbättra produkten.
  • Försök att träna dina människor i deras intresseområde och tillsammans med var du vill att de ska utbildas. Rikta in teamets tankar och ansträngningar med slutmålet, som är 'Den bästa kvaliteten'.
  • Försök inte att hantera dina människor, led dem. Var vänlig och lättillgänglig, det gör jobbet mycket enklare.
  • Varje medlem i ditt team ska älska det arbete de gör, ha en koppling till produkten och vara tillgiven mot människorna runt omkring. Då kommer bara de bästa av dem.
  • Testvärlden måste utvecklas. En betydande del av världen går till mer praktiska tillvägagångssätt som Exploratory Testing, Context-driven testing (som många gör utan att veta att det är det) som även andra bör försöka utveckla fler tekniker som
  • Fler testgemenskaper bör bildas och likasinnade människor bör träffas i större skala. Det finns så mycket att dela, lära sig, anpassa och förnya.

Hoppas min erfarenhet och fynd hjälper dig att bli en bättre testare eller hjälper dig att bättre förstå testning.

Ytterligare läsning => Från nybörjare till proffs: En komplett guide till en testproffs framgångsrika resa

Om författaren: Denna artikel är skriven av STH-teammedlem Mahesh C. Han arbetar för närvarande som Senior Quality Assurance Manager med erfarenhet av att leda testfronten för flera komplexa produkter och komponenter.

Kommer att älska att höra tillbaka. Kommentera här eller kontakta oss. Tack så mycket för läsningen.

Rekommenderad läsning

^