Menu

Mijn onverwachte reis om een ​​softwaretester te worden (van instapniveau tot manager)

my unexpected journey becoming software tester

Probeer Ons Instrument Voor Het Oplossen Van Problemen

'Je bouwt een succesvol leven op ... Dag voor dag ...'

Mijn reis als Software Tester begon een beetje onverwacht.

Ik verscheen voor de eerste sollicitatierondes in de veronderstelling dat het een ontwikkelingsmogelijkheid was. Om eerlijk te zijn, zoals elke andere afgestudeerde informatica die er is, was ik een beetje sceptisch over het doorgaan met testen.

Maar uiteindelijk besloot ik het eens te proberen. Alleen met de hoop dat mijn nieuwsgierige karakter me op dit gebied zal helpen.

Ik kon het aanbod niet accepteren zonder deze vraag te stellen: krijg ik de kans om over te schakelen naar Ontwikkeling voor het geval testen mij niet interesseert?​

Geloof me, ik heb er nooit aan gedacht om Testing daarna te verlaten.

youtube naar mp3 langer dan 90 minuten

mijn-reis-als-software-tester

Toen ik verscheen voor de technische ronde, was ik niet voorbereid op meer dan de basisconcept van softwaretests ​Ik denk dat het enige waar ik doorheen kwam, de gedachte was dat ik logisch en niet theoretisch geëvalueerd word '.

Dit was mijn allereerste lering in Testen - ik begreep hoe we ( Freshers ) Werden geëvalueerd.

Zelfs vandaag gebruik ik vergelijkbare technieken bij het inhuren van eerstejaarsstudenten voor mijn team. Ik controleer hun logica, vasthoudendheid en benadering van een probleem boven al het andere.

Aanbevolen lezen => 4 belangrijke dingen die ik heb geleerd tijdens mijn reis als QA Test Manager

Ik kwam bij Zycus als QA Trainee en kreeg op een derde of vierde dag een product toegewezen. Het was een van de grootste (was toen in concept) en meest ambitieuze producten van het bedrijf. Nadat ik me de eerste paar weken had gevestigd, was er voor mij geen weg meer terug.

We begonnen als een QA-team van twee en al snel na een paar maanden was ik de enige die de testinspanningen dreef. In de eerste 2 - 2,5 jaar zelf had ik bijna 3000 defecten geregistreerd in verschillende categorieën, zoals Functioneel, Prestaties, Beveiliging, Gebruikersinterface, Bruikbaarheid, Meertalig , Multi-tenancy, etc.

Voordat ik nieuwe toevoegingen aan het Testing-team kreeg, had ik geruime tijd te maken met een sterk ontwikkelingsteam van 15-16 leden. Zelfs na de toevoegingen was de QC: Dev-ratio niet erg gezond en ik kan nog steeds met trots zeggen dat het een geslaagde reis was, gezien alles wat we hebben getest, geleverd en afgehandeld.

Het belangrijke punt dat ik hier wil benadrukken is- Dit alles kwam voort uit een goed begrip van testen in de praktijk en niet alleen uit theorie.

Ik zit nu bijna zes jaar in het vak Softwaretesten. Het is een geweldige reis geweest met zoveel verschillende ervaringen en veel vruchtbaar leren.

Momenteel werk ik als Senior QA Manager en verzorg ik zo'n 5-6 producten en modules. Maar wat mij echt vreugde en geluk geeft, is het leiden van een team van meer dan 30 gelukkige en gepassioneerde Testers.

Natuurlijk hebben veel mensen bijgedragen aan mijn leerproces, maar ik kan nog steeds zeggen dat de meeste van mijn ervaring en kennis op de moeilijke manier (en waarschijnlijk de beste manier) is gekomen, d.w.z. het zelf leren / oplossen.

'Ervaring is de beste leermeester.'

Terwijl ik dit zeg, bedoel ik helemaal niet dat je geen baat zult hebben bij het leren of volgen van gedocumenteerde theorieën over softwaretests. Wat ik geloof is, dit alles zal zeker helpen, maar Niets is beter dan het concept in de kern te begrijpen en de problemen moedig onder ogen te zien.

Ik geloof dat gedocumenteerde dingen je niets leren echt testen , hoewel het je wat richting kan geven en dan sta je er alleen voor. In mijn geval waren er in ieder geval problemen die mogelijk niet gedocumenteerd zijn om mijn exacte problemen op te lossen, of ik kon ze niet op tijd vinden. Mijn enige keuze was om het probleem / de situatie in de kern te begrijpen en erop te reageren met de aanpak die ik goed vond.

Voorbeelden - Hoe ik benaderde in verschillende situaties

Laat me dit uitleggen met behulp van problemen / situaties waar ik tegenaan liep en hoe ik ze benaderde.

# 1) Zakelijk inzicht is een tandje hoger dan het begrijpen van testen

Nou, dat weten jullie allemaal. Testen is niet alleen het testen van enkele validaties en het uitvoeren van enige verificatie.

Als tester moeten we elk mogelijk scenario visualiseren, zelfs het zeldzaamste scenario zonder fouten. We worden geacht alle mogelijke testgegevens te overwegen die de daadwerkelijke gebruiker zou kunnen gebruiken.

Voor dit alles, we worden verondersteld de zaken ten volle te begrijpen.

Het is niet verkeerd als ik zeg dat we het bedrijf en de gebruikersbasis net zo goed of zelfs meer moeten begrijpen dan een bedrijfsanalist.

Ik had dezelfde kansen.

Ik werd geacht om begrijp complexe bedrijfsscenario's in het inkoopdomein, brainstorm over de nieuwe vereisten en weeg ze af vanuit het perspectief van de gebruiker. Ik moest niet alleen mijn cases uitwerken, maar ook bijdragen aan de vereisten en ontwerpfasen van elke iteratie. Zelfs hier kwam geen enkele verwijzing mij te hulp, afgezien van mijn denk- en redeneervermogen.

Om het bedrijf beter te begrijpen en uw scenario's / cases beter te ontwerpen, niets werkt zoals pen en papier.

Lees ook => 5 Moet niet-testtools hebben voor testers om het leven gemakkelijker te maken

Voordat je naar Vereiste discussie vergadering, schreef ik vooraf eventuele twijfels / correcties / onduidelijkheden op. Ik schreef altijd de scenario's op die ik wilde proberen of om testcases op te bouwen; soms werkt zelfs het tekenen van uw scenario's als een charme.

Wanneer je schrijft / tekent, komt het helderder in je geest en dan werkt je geest aan deze informatie en produceert meer scenario's en geeft meer duidelijkheid. Dit gaat door totdat je dat gevoel van GEDAAN krijgt !!!

# 2) Presteren tegen de verwachtingen in en onder druk

Ik werkte aan een product dat enorm en complex genoeg was / is om een ​​team van 30 ingenieurs drie jaar lang onafgebroken aan het werk te krijgen om het op een verkoopbaar niveau te krijgen.

Tijdens het grootste deel van de beginfase zat ik ofwel (solo) tegen een team van 15-20 ontwikkelaars, variërend van junior, mid-senior en senior niveau, of werd ik vergezeld door een of een paar andere testers. Ze voegden allemaal meedogenloos nieuwe functies toe aan het product, wat gelijke en parallelle aandacht van de testkant vereiste.

Deel uitmaken van vereistenvergaderingen, cases schrijven, uitvoeren, verkennende rondes, servers onderhouden, implementaties, niets was optioneel.

Tegen die tijd was ik me nog niet bewust van enige methodologie, beste oefening natuurlijk of een boek dat me oplossingen voor dergelijke problemen kan laten zien. Zelfs vandaag weet ik niet zeker of er iets is dat u precies kan helpen de realiteit op de grond te bestrijden terwijl u ze onder ogen ziet.

Wat ik liever deed, is agressief en snelle rondes van verkennende toetsing (Ik was toen nog niet op de hoogte van de naam) op elke functie een voor een en herhaal. Deze oplossing werkt puur op hoe snel u uw gedachten kunt verschuiven en situaties / scenario's kunt kaderen.

Dit vereiste natuurlijk snel en agressief werk, maar het werkte voor mij.

Wat ik bedoel met agressieve ronde is, je richt je op één ding tegelijk (Zeg één element van een formulier per keer) en test het onafhankelijk en in combinatie met andere gekoppelde elementen / dingen.

Aanbevolen lezen => Hoe een productiviteitsjunkie te zijn (vooral als tester)

Bijv. Hoe een Textbox te testen.

Wat u hier kunt testen, is:

  1. Of het gegevens accepteert en opslaat zoals ze zijn
  2. Validatie van het gegevenstype
  3. Max lengte validatie
  4. Afhandeling van speciale karakters
  5. XSS-afhandeling
  6. Meertalige gegevensverwerking
  7. Omgaan met lege ruimtes / geen gegevens
  8. Gedrag van tab en enter-toetsen
  9. Foutafhandeling (cross-browser)
  10. UI-uitlijning (cross-browser)
  11. Kopieer en plak gegevens / sleep koppelingsgegevens naar het tekstvak
  12. Het belangrijkste - het gedrag van dit veld t.o.v. andere gekoppelde elementen (elke zakelijke verwachting die aan dit veld is gekoppeld, zoals het invullen van iets in een ander veld op basis van de gegevens in dit veld)

Geeft het nadenken over bovenstaande tests u het vertrouwen dat er niet veel echt mis kan gaan op dit gebied?

Eén ding tegelijk richten werkte altijd voor mij en ik kreeg ook wat werk af.

# 3) Als je te maken hebt met het ‘onverwachte’

Welk boek zal je volgens jou ineens helpen met ‘How to’ als je iets moet doen wat je nog nooit eerder hebt gedaan?

Als we specifiek praten dan ... Geen.

Ik herinner me de tijd dat ik, bij afwezigheid van onze productleider, samen met enkele andere junior- en mid-senior-leden voor het eerst onze applicatie op Demo (was toen productie voor ons) moest implementeren. Het was erg belangrijk voor de allereerste demo van ons product.

Nou, we hebben het gedaan, maar met veel vallen en opstaan. De reden hiervoor is dat niemand van ons expertise had Linux en shell-scripting ​Ik herinner me dat er door onze IT-afdeling (allemaal te goeder trouw) bedenkingen waren bij mijn toenmalige manager over het feit dat ik verkeerde opdrachten uitvoerde op productieservers. Misschien was dit slechts een katalysator en was shellscripting / Linux mijn natuurlijke interesse, maar in korte tijd daarna nam ik de verantwoordelijkheid voor het onderhouden en upgraden van vijf tot zes omgevingen tegelijk.

wat is de beste gratis pc-reiniger

Shell en Linux trokken mijn interesse zo goed, dat ik al snel degene was die er interne trainingen over ging geven.

# 4) Wanneer je prestaties worden gemeten, is je ervaring dat niet

Al heel vroeg in mijn carrière werd ik vergeleken en gemeten met de zeer ontwikkelde en ervaren testers die er waren. Ik denk dat velen van jullie een soortgelijke situatie moeten hebben meegemaakt en weten wat die extra verwachtingen met jullie doen.

De remedie hier was om Duw mezelf en evolueer ​

De enige manier om vooruit te komen was om niet na te denken over hoe minder ervaren ik ben, en mezelf niet te beperken door de wereldstandaarden om te meten hoe langzaam / snel ik zou moeten groeien / leren. Ik beperk me niet tot de criteria van de wereld: hoe snel je moet beginnen met leiden en de titel die je nodig hebt voordat je het doet.

Welnu, rond dit punt moet ik zeggen, ongeacht tot welk vakgebied u behoort, ik raad u aan Robin Sharma's The Leader Who Had No Title te lezen. Het zal je helpen te ontketenen wat er in je ligt. Het zal je vertellen dat niemand behalve jijzelf je kan tegenhouden.

Als ik mijn ervaring in enkele zinnen moet binden, gaat het als volgt:

“Jouw nieuwsgierigheid, aandacht voor details, discipline, logisch denken, passie voor werk en het vermogen om dingen te ontleden, is het belangrijkste om een ​​destructieve en succesvolle tester te zijn. Het werkte voor mij en ik ben er sterk van overtuigd dat het voor jou zal werken. Als je deze kwaliteiten hebt, moet het voor je werken. '

Als je tot nu toe leest als je denkt dat ik menselijke basiskwaliteiten promoot boven diepere theoretische kennis, dan is dat niet helemaal waar. Ik geloof dat om met iets te beginnen en er succes van te proeven, het iets meer afhangt van je ingebouwde kwaliteiten dan van informatie die je hebt geleerd. Om echter op welk gebied dan ook ver te komen, moet u lessen, principes en ervaringen leren.

Ook in mijn geval moest ik de terminologieën, concepten en theorieën tot op zekere hoogte leren naarmate ik verder in mijn carrière kwam. De reden hiervoor is dat je als tester moet communiceren met verschillende mensen die in die termen zullen praten en je moet het begrijpen.

Als hoofd- of co-tester krijgt u een nieuwe tester uit een deel van de wereld met zijn / haar eigen kennis van feiten, definities en terminologieën. Ook hier kun je niet passief blijven tegenover deze dingen; je moet een voorkennis hebben over de maximaal mogelijke dingen die er worden gebruikt / gezegd.

Leren is onvermijdelijk.

Ik moest meer leren over verschillende soorten testen, hoe ik deze moest uitvoeren en manieren om het uit te leggen aan mensen in mijn team in de juiste fase. Ik moest nieuwe ideeën, tools evalueren en deze implementeren. Het leren van nieuwe concepten en methodologieën wordt net zo belangrijk als je de ladder op gaat.

Lees meer => De A tot Z-gids over het selecteren van de beste automatisering

Gevolgtrekking

Hoewel het bijna onmogelijk is om alle belangrijke en kleine dingen die ik in de loop van de jaren heb geleerd op te schrijven, is dit mijn poging om het samen te vatten in een lijst met opsommingstekens.

  • Testen is erg moeilijk te definiëren. Iemand kan uitstekend testen en kan het misschien niet in woorden omschrijven. Het is zoals u het ziet.
  • Iedereen kan zijn eigen definitie van testen hebben. De mijne was simpel- 'Je krijgt een ding - Zoek fouten en maak het beter.'
  • Je hebt niet per se grote theorieën, complexe matrices of ISTQB nodig om een ​​destructieve tester te zijn. Je moet het zijn nieuwsgierig , gefocust en gepassioneerd, logisch denken en kunnen ontleden. Extra weten kan echter geen kwaad, maar niet ten koste van de crux.
  • De traditionele benaderingen / concepten hebben ook hun eigen belang en ik heb evenveel respect voor hen gezien het feit dat er een groot deel van de wereld is waar dat een rechtvaardige noodzaak is. Alleen testen kan niet evolueren; daarvoor moet ook de omgeving evolueren.
  • Als tester wordt het net zo belangrijk leer nieuw tools, technieken en methodologieën terwijl u verder gaat ​Testplanning, betere benaderingen om verschillende soorten tests uit te voeren, situationele tests zijn er een paar om te noemen.
  • Omdat testen vloeiend is, verschilt de definitie van een goede pasvorm ook enorm van organisatie tot organisatie. Een destructieve of uitstekende tester zijn, is misschien net goed genoeg om een ​​loonstrookje te krijgen als je geluk hebt, of het kan extra kennis vereisen van hoe testen werkt in traditionele bedrijven. Beiden hebben gelijk op hun eigen plek.bijv.Ik neem mensen aan volgens mijn definitie van testen (die natuurlijk een beetje varieert per kandidaat-ervaring en profiel).
  • Omdat er een stijl is van coderen, rijden, koken; er is ook een stijl van testen. Je geniet er misschien niet van, tenzij je het op jouw manier doet. Wat ik bedoel is dat testen richtlijnen kan hebben, maar het zou niet gebonden moeten zijn aan de microprocessen.
  • De effectieve voorsprong moet zijn team het werk laten kiezen in plaats van toewijzen. Hij kan het af en toe wijzigen om het product te verbeteren.
  • Probeer uw mensen op te leiden in hun interessegebied en samen met waar u wilt dat ze worden opgeleid. Breng de gedachten en inspanningen van uw team op één lijn met het einddoel, namelijk ‘De beste kwaliteit’.
  • Probeer uw mensen niet te leiden, maar leid ze. Wees vriendelijk en benaderbaar, het maakt het werk een stuk gemakkelijker.
  • Elk lid van uw team moet houden van het werk dat ze doen, gehecht zijn aan het product en aanhankelijk zijn naar de mensen in de buurt. Dan komen alleen de besten naar buiten.
  • De testwereld moet evolueren. Een aanzienlijk deel van World verschuift naar meer praktische benaderingen zoals Exploratory Testing, Context-driven testing (wat veel mensen doen zonder te weten dat het het is), die zelfs anderen zouden moeten proberen en meer technieken zoals de
  • Er zouden meer testgemeenschappen moeten worden gevormd en gelijkgestemde mensen zouden op grotere schaal samen moeten komen. Er is zoveel te delen, te leren, aan te passen en te innoveren.

Ik hoop dat mijn ervaring en bevindingen je helpen een betere tester te worden of je helpen om testen beter te begrijpen.

Verder lezen => Van beginner tot professional: een complete gids voor een succesvolle reis van een testprofessional

Over de auteur: Dit artikel is geschreven door STH-teamlid Mahesh C. Hij werkt momenteel als Senior Quality Assurance Manager en heeft ervaring met het leiden van testfronten voor meerdere complexe producten en componenten.

Ik hoor graag terug. Reageer hier of neem contact met ons op. Heel erg bedankt voor het lezen.

Aanbevolen literatuur

^