my unexpected journey becoming software tester
'Du bygger et vellykket liv ... En dag av gangen ...'
Min reise som programvaretester startet litt uventet.
Jeg dukket opp for de første intervjurundene forutsatt at det var en utviklingsmulighet. For å være ærlig, som alle andre utdannede innen informatikk der ute, var jeg litt skeptisk til å gå videre med testing.
Men til slutt bestemte jeg meg for å prøve. Bare med et håp om at min nysgjerrige natur vil hjelpe meg på dette feltet.
Jeg kunne ikke akseptere tilbudet uten å stille dette spørsmålet - Får jeg muligheten til å bytte til utvikling i tilfelle testing ikke interesserer meg? :).
Tro meg - jeg har aldri engang tenkt på å forlate Testing etter det.
hvordan du håndterer popup-vindu i selen webdriver
Da jeg dukket opp for den tekniske runden, var jeg ikke forberedt på noe mer enn grunnleggende konsept for programvaretesting . Jeg antar at det eneste som tok meg gjennom var tanken på at jeg blir vurdert logisk og ikke teoretisk ’.
Dette var min aller første læring i Testing - jeg forsto hvordan vi ( freshers ) ble evaluert.
Selv i dag bruker jeg lignende teknikker mens jeg ansetter nybegynnere til teamet mitt. Jeg sjekker deres logikk, utholdenhet og tilnærming til et problem fremfor noe annet.
Anbefalt lesing => 4 Viktige ting jeg lærte i min reise som QA Test Manager
Jeg begynte i Zycus som QA Trainee og ble tildelt et produkt på en tredje eller fjerde dag. Det var en av de største (var i konseptet den gang) og mest ambisiøse produktene til selskapet. Etter å ha slått meg ned de første ukene, var det ingen vei tilbake for meg.
Vi startet som et QA-team på to, og snart etter noen måneder var jeg den eneste som kjørte testinnsatsen. I løpet av de første 2 - 2,5 årene hadde jeg logget nesten 3000 defekter i forskjellige kategorier som funksjonell, ytelse, sikkerhet, brukergrensesnitt, brukervennlighet, Flerspråklig , Multi-Tenancy, etc.
I lang tid før nye tilskudd til Testing-teamet var jeg oppe mot et sterkt 15-16-medlemsutviklingsteam. Selv etter tilleggene var QC: Dev ratio ikke veldig sunt, og jeg kan fortsatt stolt si at det var en vellykket reise med tanke på alt vi testet, leverte og håndterte.
Det viktige punktet jeg vil trekke frem her er- Alt dette var fra en forståelse av testing i praksis og ikke bare teori.
Jeg har vært i Software Testing-feltet i nesten seks år nå. Det har vært en fantastisk reise med så mange forskjellige opplevelser og masse fruktbar læring.
For tiden jobber jeg som Senior QA Manager og ser etter 5-6 produkter og moduler. Men det som gir meg ekte glede og lykke er å lede et team på 30+ glade og lidenskapelige testere.
Selvfølgelig har mange bidratt til læringen min, men jeg kan fortsatt si at det meste av min erfaring og kunnskap har kommet den harde veien (og sannsynligvis den beste måten), dvs. å lære / løse det på egenhånd.
'Erfaring er den beste læreren.'
Mens jeg sier dette, mener jeg slett ikke at du ikke vil ha nytte av å lære eller følge dokumenterte teorier om programvaretesting. Det jeg tror er at alt dette helt sikkert vil hjelpe, men ingenting kan slå forståelsen av konseptet i kjernen og møte problemene dristig.
Jeg tror at dokumenterte ting ikke vil lære deg ekte testing , selv om det kan gi deg en viss retning, og så er du alene. I det minste i mitt tilfelle var det problemer som kanskje ikke ble dokumentert for å løse mine nøyaktige problemer, eller jeg kunne ikke finne dem i tide. Mitt eneste valg var å forstå problemet / situasjonen i kjernen og reagere på den med den tilnærmingen jeg fant riktig.
Eksempler - Hvordan jeg nærmet meg i forskjellige situasjoner
La meg forklare dette ved hjelp av problemer / situasjoner jeg var opp mot og hvordan jeg nærmet meg dem.
# 1) Forretningsforståelse er et hakk høyere enn forståelse av testing
Vel, dere vet alle dette. Testing er ikke bare å teste få valideringer og gjøre noen bekreftelser.
Som tester skal vi visualisere ethvert mulig scenario, til og med det sjeldneste av det sjeldne scenariet uten feil. Vi skal vurdere alle mulige testdata som den faktiske brukeren kan bruke.
For alt dette, vi skal forstå virksomheten til det fulle.
Det vil ikke være galt hvis jeg sier at vi skal forstå virksomheten og brukerbasen så mye som eller til og med mer enn en forretningsanalytiker gjør.
Jeg hadde lignende odds.
Jeg skulle egentlig forstå komplekse forretningsscenarier i anskaffelsesdomenet, brainstorm de nye kravene og veie dem ut fra brukerens perspektiv. Jeg skulle ikke bare utarbeide sakene mine, men også bidra i Krav- og designfasene for hver iterasjon. Selv her kom ingen klar referanse til unnsetning bortsett fra min tenkeevne og resonneringsevne.
For å forstå virksomheten bedre og designe dine scenarier / saker bedre, ingenting fungerer som penn og papir.
Les også => 5 Må ha verktøy som ikke er testet for at testere skal gjøre livet enklere
Før du drar til Kravdiskusjon møte, pleide jeg å skrive ned mulige tvil / rettelser / uklare punkter på forhånd. Jeg pleide å skrive ned scenariene jeg vil prøve å bygge prøvesaker på; noen ganger, til og med å tegne scenariene fungerer som en sjarm.
Når du skriver / tegner, kommer det inn i tankene dine med bedre klarhet, og deretter jobber tankene dine på denne informasjonen og produserer flere scenarier og gir bedre klarhet. Dette fortsetter til du får den følelsen av FERDIG !!!
# 2) Utfører mot oddsen og i press
Jeg jobbet med et produkt som var / er stort og komplekst nok til å få et team på 30 ingeniører til å jobbe kontinuerlig i tre lange år for å få det til et salgbart nivå.
I det meste av den innledende fasen var jeg enten oppe (solo) mot et team på 15-20 utviklere som spenner fra junior-, mellom-senior- og seniornivå eller ble ledsaget av en eller et par andre testere. De la alle nye funksjoner til produktet ubarmhjertig, noe som krevde like og parallell oppmerksomhet fra testsiden.
Å være en del av kravmøter, skrive saker, utføre dem, utforskende runder, vedlikeholde servere, distribusjoner, ingenting var valgfritt.
Da var jeg ikke klar over noen metodikk, beste praksis , kurs eller en bok som kan vise meg løsninger på slike problemer. Selv i dag er jeg ikke sikker på om det er noe som kan hjelpe deg med å bekjempe realitetene i bakken når du møter dem.
Det jeg heller gjorde er aggressivt og raske runder med utforskende testing (Jeg var ikke klar over navnet da) på hver funksjon en etter en og gjenta deretter. Denne løsningen fungerer utelukkende på hvor raskt du kan skifte tanker og ramme situasjoner / scenarier.
Selvfølgelig krevde dette virkelig raskt og aggressivt arbeid, men det fungerte for meg.
Det jeg mener med aggressiv runde er, du målretter mot en ting om gangen (Si et element av en form om gangen) og test det uavhengig og i tilknytning til andre koblede elementer / ting.
Anbefalt lesing => Hvordan være en produktivitetsnarkoman (spesielt som en tester)
F.eks. Hvordan teste en tekstboks.
Det du kan teste her er:
- Om den godtar og lagrer data som den er
- Validering av datatype
- Maksimal validering av lengde
- Spesiell karakter håndtering
- XSS-håndtering
- Flerspråklig datahåndtering
- Håndtering av tomme rom / ingen data
- Oppførsel av fanen og tastene
- Feilhåndtering (nettleser)
- Brukergrensesnittjustering (nettleser)
- Kopier lim inn data / dra koblingsdata til tekstboks
- Viktigst - oppførselen til dette feltet w.r.t. andre koblede elementer (enhver forretningsforventning knyttet til dette feltet som å fylle ut noe i et annet felt basert på dataene i dette feltet)
Gir det å tenke på ovennevnte testing deg tillit til at ingenting mye kan gå galt med dette feltet?
Vel, målretting mot en ting av gangen virket alltid for meg, og jeg pleide også å få fullført arbeidet.
# 3) Når du er oppe mot det 'uventede'
Hvilken bok tror du plutselig vil hjelpe deg med ‘Hvordan’ når du skal gjøre noe du aldri har gjort før?
Hvis vi snakker spesifikt, så - Ingen.
Jeg husker den tiden da jeg, sammen med få andre Junior- og mid-seniormedlemmer, i fravær av vår produktleder skulle distribuere applikasjonen vår på Demo (var produksjon for oss da) for første gang. Det var veldig viktig for første gang demo av produktet vårt.
Vel, vi gjorde det, men med mye prøve-og-feil. Årsaken er at ingen av oss hadde ekspertise på Linux og shell scripting . Jeg husker at det var bekymringer fra IT-avdelingen vår (alt i god tro) til min daværende leder om at jeg kjørte feil kommandoer på produksjonsservere. Kanskje dette bare var en katalysator og skallskripting / Linux var min naturlige interesse, men kort tid etterpå endte jeg opp med å ta ansvar for å opprettholde og oppgradere fem til seks miljøer samtidig.
Shell og Linux fanget interessen min så godt at jeg snart var den som begynte å gjennomføre interne treningsøkter på den.
# 4) Når ytelsen din blir målt, er ikke din erfaring
char nummer til int c ++
Veldig tidlig i karrieren min ble jeg sammenlignet og målt mot de veldig utviklede og erfarne testerne rundt. Jeg tror mange av dere må ha opplevd en lignende situasjon og vite hva de ekstra forventningene gjør med deg.
Midlet her var å Push myself & Evolve .
Den eneste veien videre var å ikke tenke på hvor mindre erfaren jeg er, ikke å begrense meg selv av verdens standarder for å måle hvor sakte / raskt jeg skal vokse / lære. Ikke begrenser meg til verdens kriterier for hvor snart man skal begynne å lede og tittelen man trenger før man gjør det.
Vel, rundt dette punktet, må jeg si, uavhengig av hvilket felt du tilhører, anbefaler jeg deg å lese Robin Sharma's The Leader Who Had No Title. Det vil hjelpe deg med å slippe løs hva som ligger i deg. Det vil fortelle deg at ingen bortsett fra deg selv kan holde deg tilbake.
Hvis jeg må binde min erfaring i få setninger, går det slik:
“Din nysgjerrighet, oppmerksomhet på detaljer, disiplin, logisk tenkning, lidenskap for arbeid og evne til å dissekere ting er alt som betyr noe for å være en destruktiv og vellykket tester. Det fungerte for meg, og jeg tror sterkt at det vil fungere for deg. Hvis du har disse egenskapene, må det fungere for deg. ”
Hvis du tenker at jeg fremmer grunnleggende menneskelige egenskaper fremfor dypere teoretisk kunnskap, så er det ikke helt sant. Jeg tror å starte med noe og smake suksess på det, det avhenger litt mer av dine innebygde kvaliteter enn av informasjonen du har lært. For å komme langt i alle felt må du imidlertid lære leksjoner, prinsipper og erfaringer.
Også i mitt tilfelle måtte jeg lære terminologier, konsepter, teorier til en viss grad da jeg nådde lenger i karrieren. Årsaken er at du som tester må samhandle med flere mennesker som vil snakke i disse vilkårene, og du må forstå det.
Som leder eller medtester vil du få en ny tester som kommer fra en del av verden med sin egen kunnskap om fakta, definisjoner og terminologier. Også her kan du ikke holde deg passiv overfor disse tingene; du må ha forkunnskap om maksimalt mulige ting som brukes / sa der ute.
Læring er uunngåelig.
Jeg måtte lære mer om forskjellige typer testing, hvordan jeg skal utføre disse og måter å forklare det for folk i teamet mitt på riktig stadium. Jeg måtte evaluere nye ideer, verktøy og implementere dem. Å lære nye konsepter og metoder blir like viktig når du beveger deg opp stigen.
Les mer => Veiledningen A til Å om valg av beste automatisering
Konklusjon
Selv om det er nesten umulig å skrive ned alle viktige ting som jeg har lært gjennom årene, er dette mitt forsøk på å oppsummere det i en punktliste.
- Testing er veldig vanskelig å definere. Noen kan gjøre suverene tester og kan kanskje ikke definere det med ord. Det er slik du ser det.
- Alle kan ha sin egen definisjon av testing. Min var enkel- 'Du får noe - Finn feil og gjør det bedre.'
- Du trenger ikke nødvendigvis store teorier, komplekse matriser eller ISTQB for å være en destruktiv tester. Du må være nysgjerrig , fokusert og lidenskapelig, tenk logisk og har disseksjonsevne. Å vite ekstra skader imidlertid ikke, men ikke på bekostning av å miste kjernen.
- De tradisjonelle tilnærmingene / begrepene har også sin egen betydning, og jeg har like stor respekt for dem med tanke på at det er en god del av verden hvor de er en rettferdig nødvendighet. Testing alene kan ikke utvikle seg; omgivelsene må også utvikle seg for det.
- Som tester blir det like viktig å lære nytt verktøy, teknikker og metoder når du går videre . Testplanlegging, bedre tilnærminger for å utføre forskjellige typer testing, Situasjonstesting er noen få å nevne.
- Ettersom testing er flytende, er definisjonen av å være en riktig passform også veldig forskjellig fra organisasjon til organisasjon. Å være en destruktiv eller utmerket tester kan bare være god nok til å få en lønnssjekk hvis du er heldig, eller det kan kreve ekstra kunnskap om hvordan testing fungerer i tradisjonelle selskaper. Begge har rett på sitt eget sted.f.eks.Jeg ansetter folk i henhold til min definisjon av testing (som varierer litt etter kandidatopplevelse og profil selvfølgelig).
- Siden det er en stil med koding, kjøring, matlaging; det er også en stil med testing. Du liker kanskje ikke det med mindre du gjør det på din måte. Det jeg mener er å teste kan ha retningslinjer, men det skal ikke være vanskelig bundet av mikroprosessene.
- Den effektive ledelsen skulle få teamet sitt til å velge arbeidet i stedet for å tildele. Han kan av og til endre det for å forbedre produktet.
- Prøv å trene folkene dine i deres interesseområde og sammen med hvor du vil at de skal bli opplært. Juster teamets tanker og innsats mot det endelige målet, som er 'Den beste kvaliteten'.
- Ikke prøv å administrere folket ditt, led dem. Vær vennlig og imøtekommende, det gjør arbeidet mye lettere.
- Hvert medlem av teamet ditt skal elske arbeidet de gjør, ha et vedlegg til produktet og være kjærlig mot menneskene rundt. Da kommer bare de beste av dem ut.
- Testverdenen må utvikle seg. En betydelig del av verden beveger seg til mer praktiske tilnærminger som Exploratory Testing, Context-driven testing (som mange mennesker gjør uten å vite at det er det) som selv andre bør prøve å utvikle flere teknikker som
- Flere testmiljøer bør dannes, og likesinnede bør komme sammen i større skala. Det er så mye å dele, lære, tilpasse og innovere.
Håper min erfaring og funn hjelper deg med å bli en bedre tester eller hjelper deg med å forstå testing bedre.
Videre lesing => Fra nybegynner til proff: en komplett guide til vellykket reise til en testperson
Om forfatteren: Denne artikkelen er skrevet av STH-teammedlem Mahesh C. Han jobber for tiden som Senior Quality Assurance Manager med erfaring fra å lede testfront for flere komplekse produkter og komponenter.
Vil gjerne høre tilbake. Kommenter her eller ta kontakt med oss. Tusen takk for at du leser.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Noen interessante spørsmål om intervjuer med programvaretesting
- Programvaretestkurs Tilbakemelding og anmeldelser
- Perfekt programvaretest CV-guide (med programvaretester CV-prøve)