My software testing tale
In this article, I will try to explain how I got here, and some of the challanges that someone that loves software development and testing will face.
It’s been already quite some time since I started and I have been in different projects that required me to switch technologies, positions, and even my attitude and actions towards people I work with.
How it all started
Im pretty sure I am not the only one that’s been hooked to a computer since they were young.
While I was very young kid, my dad used to launch some old computer games in MS-DOS terminal.
He does not remember at all the games (nor how he did to launch them) that he manually wrote into the terminal, but I remember many — one was Pitfall, which some of you may be familiar with.
Another one was a racing game with strong, vibrant colors.
At 8 years old, I was hooked to an old PC in a very small town down south in the Buenos Aires province. The internet was awful.
My first RPG was Argentum Online.
The game was electric, a full-blown community with pixel art battles, and music that to today brings tears of nostalgia.
At some point, which I am not exactly sure when, I got offered a WebMaster position for one of the Argentum servers. Now… being a kid, to me this seemed like a no-brainer, and this is manly because, a webmaster would instantly become a GameMaster. And in game, that means, I could be invencible!
And so it went.. I was given credentials to the hosting and FTP servers.
At the time, I had absolutely no idea what being a “WebMaster” meant.
And I started googling, and googling, and googling.
And eventually… I got the static, old php page working.
And the GameMaster title was given to me in-game. I was invencible.
From there, my curiosity went nuts. I created the page that my dad used to export onion to Europe, which was just plain HTML with images and very old style, but my dad will use this and show it to the rest of the family.
From that point I became the “fix-my-pc” kid for the family, as many of us did.
After that, and in my first years of highschool, I got into hacking.
Specifically, the kind of hacking a… script-kiddie will do.
Of course, I would think I still am a script-kiddie today, as I never really dug into hacking as a carrer.
I began doing CTFs, which I remember The Enigma Group being the first of them (now the project stopped — super sad to hear this — , but the IRC and the community was super helpful and fun, and you can still find solutions for the old page on Github).
The puzzles were fun as hell too. Later on during highschool I would turn off and prank my friends PC’s while on class, which was also pretty funny and they sent me to the director’s office for that.
And you might ask.. why you got into hacking?
To this day, to me it seems clear what the reason was — I watched The Matrix and my mind was absolutely blown.
Not only the VFX, but that “invincible” idea that I would get from games now was.. a reality.
What drives me, what drives us?
To me, what really interested me to learn new things had a common goal — to cure boredom.
That amazing feeling always came to me as that “aaah” we get after we finally experience the “click” when we find how something really works.
And in a field where everything grows old quickly, software is a never-ending mystery box where you always get new toys you can play around with, tweak, and create new beautfiul Frankenstain mostruoicitis with.
So that feeling is abundant.
Jobs, and being the manual workforce
At my first job, I was 17, almost finishing high school.
I got into a Oracle-based support role doing the night shift for Telefonica. Specifically, Oracle Enterprise Software Bus (ESB).
Oracle defines this service as:
An enterprise service bus moves data among multiple endpoints, both within and outside of an enterprise. It uses open standards to connect, transform, and route business documents as Extensible Markup Language (XML) messages, among disparate applications. It enables monitoring and management of business data, with minimal impact on existing applications. An enterprise service bus is the underlying infrastructure for delivering a service-oriented architecture (SOA) and event-driven architecture (EDA).
There were calls, almost all the time.
These involved mainly services/endpoints not working correctly, payment issues (the worst ones), services that required restarts, rollbacks, and looking at the logs for hours, until I figure out the error and either try to fix push the fix or wake up the appropiate dev.
Luckily, I was really comfortable with the Linux shell since I done that at my script-kiddie days.
So there I was, and after a few months of doing night-shifts, they eventually offered me a full-time position at the actual office.
I loved going there for the first time and seeing some many teams and people working on common goals — but at the same time.. the ESB server was a very interconnected one, so we had queues of people lining up at our desk, acting apologetic while at the same time asking us to solve stuff.
It was fun at first.. after some time, it became a problem.
We needed more people, the office was huge, and we were only 6!
Also, I was learning Python during that time, and I was taking freelance jobs on different platforms cause the pay for that job was not that great.
The local currency was not as good, so earning a few dollars doing specific projects (web-scraping, wordpress fixes, was mostly what I was into) was great.
During that time we were tasked to test a new implementation after a migration.
Me being a non-experienced kid, I was never tasked to stress and performance tests. Of course, I had absolutely no idea what was going on. Again.
So I wrote a few Python scripts for a bunch of endpoints to load and stress test, and eventually — before I got my hands dirty with Jmeter — all of us will use that.
And then I found out the faces of all the people when you break their stuff.
That same line that was forming in our desks was no longer the same.
And after that, I realized, I loved building and testing software, but I wanted to do both. Not just one.
I wanted to be in a dynamic position, not be in a place where I would get bored.
This was my reasoning for all the other jobs I would have in the future.
Somewhere I could shift to use different tools, and help building and testing.
I wanted to have a role across all the workflow from QAs, Devs, and Devops.
I wanted a little bit of everything, while still having a critical mindset on where to go next.
The problem of being stuck
Along the way, there are many things that I had to change in my mindset to understand this feeling, and that this “magic box” is just.. magical thinking.
So if you want something modern, or something different, and you have a working product, you still need that product to suit your customers, while considering the learning curve there is for programmers and testers to assimilate new technology.
Some of us ask, how a programmer can achieve a huge milestone on a 3-day hackathon, and then to do something that would be rather simple, it takes them a full week?
For me, that feels like being stuck.
Being un-motivated, bored. Stuff on fire all the time, no room for improvement. Whatever you want to call it.
That programmer does have the power, he/she just lacks the fun part of it. Not all programming or testing tasks are fun.
Not all jobs are fun. Should they be? Well, I wish they were.
Let’s go out that magic box for a second.
Do you like seeing your code thrown away when it does not perform as it should?
Do you still get that “aah” feeling when you see that what you worked on is getting replaced for “company policy”?
Do you feel good getting stuck on old-company code standards?
Do you feel slow and it does not seem like its up to you?
Getting out of the box
If you feel like these things affect you, and you dont want to get burn out, you have to look at the bigger picture.
And the bigger picture starts with how you feel, and do take time into account.
It’s been hard to me understanding how much time does it take to reflect change into a piece of work like software.
Some are instant, like the attitude you put towards it.
Some take longer, like migrating from monolithic to a microservice-oriented architecture.
These are based on specific things not only on the people you work with but a company as a whole.
If you think these tasks might be boring, but at the end of the day you will feel proud of achieving that goal — whatever it might be — and you know it will get better, carry on.
If you think there is no way to remediate the fun into your current work, quit.
Most of us are in a lucky position, there is plenty of offers.
Leverage that to not trade stress over money.
You might get less, but you surely get more for yourself if you are having fun.
And when the work-time, drop everything, and focus on yourself. Go out.
Have a different kind of fun.
The perfect equilibrum
In my case, I found that a position like Software Developer In Test (SDET) can really be across different parts in the software development lifecycle.
You can be tweaking pipelines, fixing bugs, and testing stuff. You get to experience the testing, and you can help out with the development. You work closely with all the teams.
You are also not fixed to a single point so I dont really get bored — keep in mind a company might offer a SDET position, but it’s just a fancy way to say a QA that can code — .
I can also lead teams into different ideas that I would love to execute, and teaching which I find super fun when you feel stuck.