my unexpected journey becoming software tester
'Du bygger et vellykket liv ... En dag ad gangen ...'
Min rejse som softwaretester startede lidt uventet.
Jeg dukkede op til de første interviewrunder, forudsat at det var en udviklingsmulighed. For at være ærlig var jeg som enhver anden kandidat i datalogi derude lidt skeptisk over for at gå videre med testning.
Men til sidst besluttede jeg at prøve det. Kun med et håb om, at min nysgerrige natur vil hjælpe mig på dette område.
Jeg kunne ikke acceptere tilbuddet uden at stille dette spørgsmål - Vil jeg få mulighed for at skifte til udvikling, hvis test ikke interesserer mig? :).
Tro mig - jeg fik aldrig engang tænkt på at forlade Testing efter det.
https www google comyoutube til mp3
Da jeg dukkede op til den tekniske runde, var jeg ikke forberedt på andet end grundlæggende koncept for softwaretest . Jeg antager, at det eneste, der tog mig igennem, var tanken om, at jeg bliver vurderet logisk og ikke teoretisk. '
Dette var min allerførste læring i testning - jeg forstod, hvordan vi ( friskere ) blev evalueret.
Selv i dag bruger jeg lignende teknikker, mens jeg ansætter freshers til mit team. Jeg kontrollerer deres logik, vedholdenhed og tilgang til et problem frem for alt andet.
Anbefalet læsning => 4 vigtige ting, jeg lærte på min rejse som en QA-testleder
Jeg kom til Zycus som en QA-trainee og fik tildelt et produkt på en tredje eller fjerde dag. Det var en af de største (var i konceptet dengang) og mest ambitiøse produkter i virksomheden. Efter at have slået mig ned i de første par uger var der ingen vej tilbage for mig.
Vi startede som et QA-team på to, og kort efter få måneder var jeg den eneste, der kørte testindsatsen. I de indledende 2 - 2,5 år selv havde jeg logget næsten 3000 defekter på tværs af forskellige kategorier som Functional, Performance, Security, UI, Usability, Flersproget , Multi-Tenancy osv.
I lang tid før nye tilføjelser til testteamet stod jeg imod et stærkt 15-16-medlemsudviklingsteam. Selv efter tilføjelserne var QC: Dev ratio ikke særlig sund, og jeg kan stadig stolt sige, at det var en vellykket rejse i betragtning af alt det, vi testede, leverede og håndterede.
Det vigtige punkt, jeg vil fremhæve her, er- Alt dette var fra en forståelse af testning i praksis og ikke kun teori.
Jeg har været inden for softwaretest i næsten seks år nu. Det har været en fantastisk rejse med så mange forskellige oplevelser og masser af frugtbar læring.
I øjeblikket arbejder jeg som Senior QA Manager og passer på nogle 5-6 produkter og moduler. Men hvad der giver mig ægte glæde og lykke er at lede et hold på mere end 30 glade og lidenskabelige testere.
Selvfølgelig har mange mennesker bidraget til min læring, men jeg kan stadig sige, at det meste af min erfaring og viden er kommet den hårde vej (og sandsynligvis den bedste måde), dvs. at lære / løse det alene.
'Erfaring er den bedste lærer.'
Mens jeg siger dette, mener jeg slet ikke at sige, at du ikke får gavn af at lære eller følge dokumenterede teorier om softwaretest. Hvad jeg tror er, at alt dette helt sikkert vil hjælpe, men intet kan slå forståelsen af konceptet i kernen og mod problemerne modigt.
Jeg tror, at dokumenterede ting ikke vil lære dig reel testning , selvom det kan give dig en vis retning, og så er du alene. I det mindste i mit tilfælde var der problemer, som måske ikke er dokumenteret for at løse mine nøjagtige problemer, eller jeg kunne ikke finde dem i tide. Mit eneste valg var at forstå problemet / situationen i kernen og reagere på det med den tilgang, jeg fandt rigtig.
Eksempler - Hvordan jeg nærmede mig i forskellige situationer
Lad mig forklare dette ved hjælp af problemer / situationer, jeg var imod, og hvordan jeg nærmede mig dem.
# 1) Forretningsforståelse er et hak højere end forståelse af test
Nå ved I alle dette. Testning er ikke kun at teste få valideringer og foretage en verifikation.
Som tester skal vi visualisere ethvert muligt scenario, selv det sjældneste af det sjældne scenario uden fejl. Vi formodes at overveje alle mulige testdata, som den faktiske bruger muligvis bruger.
For alt dette vi formodes at forstå forretningen fuldt ud.
Det vil ikke være forkert, hvis jeg siger, at vi skal forstå forretningen og brugerbasen så meget som eller endda mere, end en forretningsanalytiker gør.
Jeg stod over for lignende odds.
Det skulle jeg forstå komplekse forretningsscenarier i indkøbsdomænet skal du brainstorme de nye krav og veje dem ud fra en brugers perspektiv. Det var ikke kun meningen, at jeg skulle udarbejde mine sager, men også bidrage i fasen Krav og Design i hver iteration. Selv her kom der ingen klar henvisning til min undsætning bortset fra min tænkning og ræsonnement.
For at forstå forretningen bedre og designe dine scenarier / sager bedre, intet fungerer som pen og papir.
Læs også => 5 Skal have værktøjer, der ikke er testet, for at testere kan gøre livet lettere
Før du går til Kravsdiskussion møde plejede jeg på forhånd at nedskrive mulige tvivl / rettelser / uklare punkter. Jeg plejede at nedskrive de scenarier, som jeg vil prøve at bygge testcases på; nogle gange fungerer selv at tegne dine scenarier som en charme.
Når du skriver / tegner, kommer det ind i dit sind med bedre klarhed, og så arbejder dit sind på disse oplysninger og producerer flere scenarier og giver bedre klarhed. Dette fortsætter, indtil du får den følelse af KLAR !!!
# 2) Udfører mod odds og i pres
Jeg arbejdede på et produkt, der var / er stort og komplekst nok til at få et team på 30 ingeniører til at arbejde kontinuerligt i tre lange år for at få det til et salgbart niveau.
I det meste af den indledende fase var jeg enten op (solo) mod et hold på 15-20 udviklere lige fra junior-, mid-senior- og seniorniveau eller var ledsaget af en eller et par andre testere. De tilføjede alle ubarmhjertigt nye funktioner til produktet, hvilket krævede lige og parallel opmærksomhed fra testsiden.
At være en del af kravmøder, skrive sager, udføre dem, udforskende runder, vedligeholde servere, implementeringer, intet var valgfrit.
Dengang var jeg ikke opmærksom på nogen metode, bedste praksis , kursus eller en bog, der kan vise mig løsninger på sådanne problemer. Selv i dag er jeg ikke sikker på, om der er noget, der præcist kan hjælpe dig med at bekæmpe jordens realiteter, når du møder dem.
Hvad jeg snarere gjorde, var aggressiv og hurtige runder af sonderende test (Jeg var ikke klar over navnet på det tidspunkt) på hver funktion en efter en og gentag derefter. Denne løsning fungerer udelukkende på, hvor hurtigt du kan skifte dine tanker og ramme situationer / scenarier.
Selvfølgelig krævede dette virkelig hurtigt og aggressivt arbejde, men det fungerede for mig.
Hvad jeg mener med aggressiv runde er, du målretter mod en ting ad gangen (Sig et element i en form ad gangen) og test det uafhængigt og i forbindelse med andre sammenkædede elementer / ting.
Anbefalet læsning => Sådan skal du være en produktivitetsjunkie (især som en tester)
For eksempel. Sådan tester du en tekstboks.
Hvad du kan teste her er:
- Uanset om det accepterer og gemmer data, som de er
- Validering af datatype
- Validering af maks. Længde
- Specialhåndtering
- XSS-håndtering
- Flersproget datahåndtering
- Håndtering af tomme rum / ingen data
- Opførsel af fane og indtast nøgler
- Fejlhåndtering (cross-browser)
- UI-justering (cross-browser)
- Kopier indsæt data / træk linkdata til tekstboks
- Vigtigst - opførsel af dette felt w.r.t. andre sammenkædede elementer (enhver forretningsforventning knyttet til dette felt som at udfylde noget i et andet felt baseret på dataene i dette felt)
Giver det at tænke på ovenstående test dig tillid til, at intet meget virkelig kan gå galt med dette felt?
Nå, målretning mod en ting ad gangen fungerede altid for mig, og jeg plejede også at få noget arbejde færdig.
# 3) Når du er imod det 'uventede'
spørgsmål om manuel testinterview i 4 års erfaring
Hvilken bog tror du pludselig vil hjælpe dig med 'Sådan gør du', når du skal gøre noget, du aldrig har gjort før?
Hvis vi taler specifikt, så - Ingen.
Jeg husker det tidspunkt, hvor jeg i mangel af vores produktleder sammen med få andre junior- og mid-seniormedlemmer skulle implementere vores applikation på Demo (var produktion for os dengang) for første gang. Det var meget kritisk for første gang nogensinde demo af vores produkt.
Nå, det gjorde vi, men med masser af prøve-og-fejl. Årsagen er, at ingen af os havde ekspertise i Linux og shell scripting . Jeg husker, der var bekymringer fra vores IT-afdeling (alt i god tro) til min daværende leder om, at jeg kørte forkerte kommandoer på produktionsservere. Måske var dette bare en katalysator, og shell-scripting / Linux var min naturlige interesse, men i kort tid derefter endte jeg med at tage ansvaret for at vedligeholde og opgradere fem til seks miljøer samtidigt.
Shell og Linux fangede min interesse så godt, at jeg snart var den, der begyndte at gennemføre interne træningssessioner om det.
# 4) Når din præstation måles, er din oplevelse ikke
Meget tidligt i min karriere blev jeg sammenlignet og målt mod de meget udviklede og erfarne testere rundt omkring. Jeg tror, at mange af jer må have oplevet en lignende situation og vide, hvad de ekstra forventninger gør ved dig.
Midlet her var at Skub mig selv & Evolve .
Den eneste vej frem var at ikke tænke på, hvor mindre erfaren jeg er, ikke at begrænse mig selv af verdens standarder for at måle, hvor langsom / hurtig jeg skal vokse / lære. Ikke begrænser mig til verdens kriterier for, hvor hurtigt man skal begynde at føre og den titel, man har brug for, før man gør det.
Omkring dette punkt må jeg sige, uanset hvilket felt du tilhører, anbefaler jeg, at du læser Robin Sharmas leder, der ikke havde nogen titel. Det vil hjælpe dig med at frigøre det, der ligger i dig. Det vil fortælle dig, at ingen undtagen dig selv kan holde dig tilbage.
Hvis jeg skal binde min oplevelse i få sætninger, går det sådan:
”Din nysgerrighed, opmærksomhed på detaljer, disciplin, logisk tænkning, lidenskab for arbejde og evne til at dissekere ting er alt, hvad der betyder noget for at være en destruktiv og vellykket tester. Det fungerede for mig, og jeg tror stærkt på, at det vil fungere for dig. Hvis du har disse kvaliteter, skal det fungere for dig. ”
Nå, at læse så langt, hvis du tænker, at jeg fremmer grundlæggende menneskelige kvaliteter frem for dybere teoretisk viden, så er det ikke helt sandt. Jeg tror at starte med noget og smage succes på det, det afhænger lidt mere af dine indbyggede kvaliteter end af information, du har lært. Men for at gå langt inden for ethvert felt skal du lære lektioner, principper og oplevelser.
Også i mit tilfælde var jeg nødt til at lære terminologier, begreber og teorier til en vis grad, da jeg nåede længere i min karriere. Årsagen er, at du som tester er nødt til at interagere med flere mennesker, der vil tale i disse termer, og du skal forstå det.
Som lead eller co-tester får du en ny tester, der kommer fra en del af verden med sin egen viden om fakta, definitioner og terminologier. Også her kan du ikke forblive passiv over for disse ting; du er nødt til at have en forudgående viden om maksimalt mulige ting, der bruges / sagde derude.
Læring er uundgåelig.
Jeg var nødt til at lære mere om forskellige typer af test, hvordan man udfører disse og måder at forklare det til folk i mit team på det rigtige tidspunkt. Jeg var nødt til at evaluere nye ideer, værktøjer og implementere dem. At lære nye koncepter og metoder bliver lige så vigtigt, når du bevæger dig op ad stigen.
Læs mere => Vejledningen A til Z om valg af den bedste automatisering
Konklusion
Selv om det næsten er umuligt at skrive ned alle vigtige ting, jeg har lært i årevis, er dette mit forsøg på at opsummere det i en punktopstilling.
- Test er meget svært at definere. Nogen kan udføre fremragende test og kan muligvis ikke definere det med ord. Det er som du ser det.
- Alle kan have deres egen definition af test. Min var enkel- 'Du får en ting - Find fejl og gør det bedre.'
- Du behøver ikke nødvendigvis store teorier, komplekse matricer eller ISTQB for at være en destruktiv tester. Du skal være nysgerrig , fokuseret og lidenskabelig, tænker logisk og har dissektionsevne. At vide ekstra skader imidlertid ikke, men ikke på bekostning af at miste kernen.
- De traditionelle tilgange / begreber har også deres egen betydning, og jeg har lige respekt for dem i betragtning af, at der er en god del af verden, hvor disse er en retfærdig nødvendighed. Testning alene kan ikke udvikle sig; det omgivende skal også udvikle sig til det.
- Som tester bliver det lige så vigtigt at lære nyt værktøjer, teknikker og metoder, når du går videre . Testplanlægning, bedre tilgange til udførelse af forskellige typer test, Situationstest er et par at nævne.
- Da testning er flydende, adskiller definitionen af at være en rigtig pasform også meget fra organisation til organisation. At være en destruktiv eller fremragende tester kan bare være god nok til at få en løncheck, hvis du er heldig, eller det kan kræve ekstra viden om, hvordan test fungerer i traditionelle virksomheder. Begge har ret på deres eget sted.for eksempel.Jeg ansætter folk i henhold til min definition af test (som varierer lidt efter kandidatoplevelse og profil selvfølgelig).
- Da der er en stil med kodning, kørsel, madlavning; der er også en testform. Du nyder muligvis ikke det, medmindre du gør det på din måde. Hvad jeg mener er, at test kan have retningslinjer, men det bør ikke være hårdt bundet af mikroprocesserne.
- Den effektive bly skulle få sit team til at vælge arbejdet i stedet for at tildele. Han kan lejlighedsvis ændre det til forbedring af produktet.
- Prøv at træne dine folk i deres interesseområde og sammen med, hvor du vil have dem til at blive uddannet. Juster dit teams tanker og indsats efter det endelige mål, som er 'Den bedste kvalitet'.
- Forsøg ikke at styre dine medarbejdere, før dem. Vær venlig og tilgængelig, det gør arbejdet meget lettere.
- Hvert medlem af dit team skal elske det arbejde, de udfører, have en tilknytning til produktet og være kærlig over for menneskerne omkring. Så kommer kun de bedste af dem ud.
- Testverdenen skal udvikle sig. En betydelig del af verden bevæger sig til mere praktiske tilgange som Exploratory Testing, Context-driven test (som mange mennesker gør uden at vide, at det er det), som selv andre burde prøve at udvikle flere teknikker som
- Flere testfællesskaber skal dannes, og ligesindede bør mødes i større skala. Der er så meget at dele, lære, tilpasse og innovere.
Håber min erfaring og fund hjælper dig med at blive en bedre tester eller hjælper dig med at forstå testning bedre.
Yderligere læsning => Fra begynder til professionel: En komplet guide til en testprofessionals vellykkede rejse
Om forfatteren: Denne artikel er skrevet af STH-teammedlem Mahesh C. Han arbejder i øjeblikket som Senior Quality Assurance Manager, der har erfaring med at føre testfront for flere komplekse produkter og komponenter.
Vil elske at høre tilbage. Kommenter her eller nå ud til os. Mange tak for læsningen.
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Softwaretest QA Assistant Job
- Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
- Valg af softwaretest som din karriere
- Softwaretest Teknisk indhold Writer Freelancer Job
- Nogle interessante softwaretestinterviewspørgsmål
- Feedback og anmeldelser om softwaretestkursus
- Perfekt softwaretest CV-guide (med software-test CV-prøve)