Why SQE is hard and why it’s still worthwhile to pursue it as a career Pt. 2

In my previous post, we looked at why SQE is hard. So then why should anyone consider a career in it? The short answer is, you should consider it if it works for you, but that’s no answer is it?

Here are 5 good reasons I can think of off the top of my head, 

1) It will give you flexibility in your career

SQE has a wide breadth. Contrary to popular opinion, SQE doesn’t start after the developer compiles the code/project and sends out an email about it and gloats about it to Jane from pre-sales for 2 hours. No, SQE spans the entire SDLC (whichever model it may be).

As you progress in your career in SQE you will get more opportunities to shift left and get involved earlier on in the process. Product Owners, Project Managers, and members from other business functions will value the technical exposure you have had at the ground level. In my experience, I have seen engineers move left but I don’t think I have heard of anyone moving from left to right.

The other side of the story is SQE's develop more carry-forward skills(A.K.A. Transferable Skills) than developers. For example, the testing body of knowledge is not bound by any technology or tool. Yes, if you join a new company you will still need to learn to use their automation framework or other technologies but you won’t need to learn how to design test cases or how to manage defect reports again.  

2) It's a stable software engineering discipline  

This is because, one, the carry forward skills SQEs develop. It’s a lot easier for an SQE to jump companies after putting in 5 years in a niche domain than a developer.

Two, the relatively slow speed of change in SQE tools, methods, and technologies. Because there isn’t as much money to be made making tools for SQEs as there is for developers, the rate of change and new entries to the market is low.   

3) It's a relatively safe way to keep scratching the software engineering itch

The world has a way of giving you what you ask of it and the truth of the matter is if you’re in software engineering because of an itch to understand the nuts and bolts, then because of the nature of the beast sooner or later there’s going to be way too many types of nuts and bolts for you to even have an idea of where they all fit. Yes, you can always put in the time and figure out where a particular type of nut or bolt should go but then you quickly come to the realization that you don’t have that kind of time and that sometimes people just keep handing you more just because you’re not just in it for the money.

   

Now if you are a developer, to climb the ranks (in your organization or community) you need to show your expertise(maybe the level of expertise you need to show is negatively correlated to how good you are with your people skills and social standing but let’s not get into it <wing tongue out emoji>). This is hard because sometimes the technologies and tools the management pushes down on you are unproven or have no easy way of learning let alone mastering. So you can find yourself between a rock and a hard place.

The situation is better if you’re in SQE. Depending on how technical of SQE role you’re playing you may be expected to know absolutely nothing about the innards of a System (think black box or COTS UAT) or just enough to verify and validate the developers' work. This translates to safety. You can learn new things or the same things as the developer but at your own speed without risking a mess.  

      

4) You get to shape the quality of a product

As an SQE you will have a say in the quality of the products that run through you. Unless your company is banking on a cost advantage it makes sense for them to push out the highest quality products. Even if the price is your company's competitive advantage, if the quality is lacking new arrivals can take market share. If you are someone who really appreciates quality over quantity, chances are you will find SQE work inherently rewarding and you will grow.

5) Pay is good

Depending on how technical the SQE role is and a few other factors like how good you are at your work and how well your company is doing, SQEs can expect to be paid as much as developers.

Why SQE is hard and why it’s still worthwhile to pursue it as a career Pt. 1

Learning SQE is like learning to play the drums, anyone can learn to keep a beat, but very few can master the instrument. SQE is hard because of its breadth and depth. Let me stretch the drumming analogy further and explore this idea.

For the world to start calling you a great drummer, you need to be able to keep the beat and add bells and whistles regardless of the type of music the rest of your bandmates might start to play. Similarly, to be a good SQE you need to be good at a bunch of things. You need to,

1. Be good with the SQE body of knowledge: The process, the levels, the types, test design techniques etc.
2. Be good with functional testing (both manual and automated).
3. Be good with non-functional testing (including load, reliability, stress, and security)
4. Be able to do static testing.
5. Be able to manage stakeholders.

I could have made the above list even more granular, but I think you get the idea. The breadth of SQE is wide.

So, you managed to keep the beat going and added the bells and whistles to everything the rest of the band threw at you. Now the band is grooving, and the next thing you know, ‘the man’ opens the thick soundproofed door to the studio, hold a wide grin and say,

‘Kid... Pack your bags because you’re getting the golden ticket.’

You’re a little suspicious of the grin but you abide. Now you’re in the big leagues. Playing clubs with the big boys. The bells and whistles you added in on the run-down drum-kit back at home is not going to cut it here. The other drummers have 12-piece sets, they know how to mic the drum kit just right, they know how to sweet talk the owners of the clubs and man do they know how to drum.

Getting back to SQE, its not just enough to wet your feet in the 5 verticals I listed at the start. You need to climb down deeper into each of them. Here are a few tips if you're just getting started,

1. To be good at the SQE body of knowledge:  Study senior testers. After a few years, I recommend you read the ISTQB syllabus (or better yet get certified). This way you will easily be able to map real-world experiences to what you will find in the syllabus. It will stick in your mind better.
2. To be good at functional testing: Start off with a manual functional testing job and learn on the job. Understand how the testing activities are carried out across the different test levels. Get exposure and then move to automation. Spend a few years in test automation learning on the job. The key is to be familiar with the general process so that if you need to switch the technology stack you can still adjust in time.
3. To be good at non-functional: Get a good grasp of reliability, stress and load testing. Like with automation, Focus on the general process and concepts rather than on specific tools but do get real-world experience using a popular tool.
4. To be good at static testing: Keep you’re programming skills sharp. Take on side projects even if they’re basic, just to keep your coding and DevOps skills sharp. Learn on the side, this way you won't feel lost if you need to do shift-left. Look for opportunities to get exposure.
5. To manage stakeholders better: Learn on the job, study test managers and leads. Put yourself out there and venture out into management studies consider an MBA.

Nothing can substitute for on-the-job exposure. So, if you’re starting out try to join a company that can give that to you or work with your company so that you can chart a way forward. Like with other software engineering disciplines, learning stops when you stop engineering, so keep learning!

Sounds like a lot of work? Yes, it is. So in the next post, I’ll touch on why SQE is still worth all the trouble. 

Even lovers need a holiday

It’s been a while! I last wrote just before I left 99x (a great place to work, give them a try), but to explain my absence I need to rewind 4-5 years further.

I shifted from Technical Writing to SQE in 2013 right after I got my bachelor's (The reasons for this shift are better covered in a future post). I walked through the doors of the company as a novice software quality engineer not knowing a defect from an error. It also didn’t help that the company was probably the techiest employer in the country.

WSO2 does open source B2B, so naturally, development was fast phased and at the cutting edge. The products were built and shipped fast using various reputable open-source components. The product line aimed to cater to all the needs an enterprise might possibly have as they moved along their digital transformation journeys. So, for a fresh off-the-mill engineer like I was at the time, it was a fat kid at the buffet kind of situation (Honestly, I’m not body shaming here. The phrase just felt right in the sentence).

The testing work my team did was mostly manual and on the fly. In hindsight, I can understand why. For such fast phased open-source development and for the business model employed by the company it just didn’t make sense to automate each and everything thing above the component layer before shipping or be uber methodical (bare in mind this was some time ago, things may have changed since I left). So, I walked out with great technical exposure (for a tester) but little exposure to general testing processes and test automation.

The next couple of years I spent polishing up my automation skills and landed a great job at Sysco LABS. The company is a favored employer in Sri Lanka and in my opinion, a great place to learn carry forward in demand SQE skills. This is what I did for the past 3 years. I humbly sharpened my core testing skills by learning and using them all on the job. I am very fortunate to have got the opportunity to cover the full QE stack at the company.

I am definitely a better SQE to have had the fast paced startup testing experience at WSO2 and the methodical process-oriented testing experience at Sysco LABS. 

Well, all of what I’ve written so far doesn’t really answer why I haven’t blogged for 5-6 years. Well, I was busy. I had a lot on my plate. Things to learn on the job, a kid to care for, to get in shape, and I somehow found the time to get my masters. Now that the master's is out of the way, and I’ve put some miles behind the job I should be able to push out a post every now and then. 

Next time with some real SQE stuff...