DEV Community: Jason Sigler

Learning to Code? QA (Quality Assurance) Might Be A Good Place To Start.

Jason Sigler — Sun, 24 Jan 2021 20:12:01 +0000

this article was originally posted on my personal site here

Before becoming a software developer, I became a QA automation engineer. I had just switched majors and had a couple of CS classes and a basic understanding of javascript under my belt. I found a small software shop near me that was hiring an automation engineer, and I was lucky enough to have landed the job despite little experience with development. To say that it was like drinking from a fire hose would be an understatement- I had to learn what an automation framework was, how existing frameworks like Webdriver.io worked, how to modify the existing React codebase to accommodate my tests, what in the world agile was, and how to use industry-standard tools like Jira and Github.

Eventually, I moved on to a new company that would provide room to grow. My first job paid horribly, the developers were not helpful, and my overall long-term stability was questionable. However, the experience was invaluable to my career growth. I eventually landed a position with a new company that was supportive of my career goals and always willing to let me participate in company hackathons and other engineering tasks. A little over a year later, I was hired as a software engineer.

I always suggest that would-be developers keep the QA field in mind. The salary is typically good, they are almost always in demand, and it will give you industry experience that can really help launch your career (or even be a new career path you hadn't thought about).

What types of QA roles are there?

There is no real standard when it comes to QA job titles, so it can be confusing unless you pay close attention to the job description. However, there are 3 general categories that I group these jobs into:

QA Analyst

This is a generic term for a manual tester and is often interchangeable with the titles 'QA Engineer' and 'QA Tester' (or something similar). This job generally consists of performing manual tests of a product. You will often be testing a story or task for bugs before sending it off to the product owner for acceptance. These roles don't pay quite as well, but there's always an opportunity to learn and grow.
Automation Engineer

This often turns out to be a hybrid manual/automation position, although the amount of automation vs manual testing will be very company-specific. In this role, you'll be responsible for writing automated tests that will run against the front-end of a product. If you're working for a large, established company, you'll likely be adding to a large existing framework. Conversely, a startup might require much of the framework to be built out in parallel with development. This is a wonderful way to learn and build your coding skills, especially if you're working with an experienced team. If the company has truly embraced test automation, you'll learn a lot about Continuous Integration (CI) and Continuous Delivery (CD).
SDET

This is sort of a strange role that has no specific definition, but an SDET (Software Development Engineer in Test) is more of a developer-automation hybrid that has been called the 'unicorn of the QA world'. This is a QA professional that is both capable of development and writing automation, unit, and integration tests for a product. While role definition varies wildly, some companies consider their automation engineers SDETs.

What do I look for in a company?

If you're looking for a QA role, you want to find a company that knows exactly how QA fits into its engineering process. You may find a surprising number of smaller companies that know that they should be running automated tests and/or have quality assurance systems in place, but don't know how to implement them. You could be working on test automation with no clear vision of how they'll be executed. Always try to tease out this information during interviews.

You should also find a company in which there's room to grow. You may find that you love QA and want to make a career in it, but if you have any inclination of moving into a development (or product owner, etc.) role, you should communicate this early on. Developers should be willing to teach, and you should have access to pull requests, etc so that you can learn by reading code and getting involved in the process. Ask lots of questions about how they mentor, if there are any learning opportunities provided (Pluralsight, etc.), and how they feel about QA in general. Ask lots of questions, and don't be afraid to zero in on any red flags.

What Do I need to know?

You should have a solid grasp of javascript and at least one web framework (React, Angular, Vue). There are plenty of free resources available on the internet, as well as some solid courses on Udemy if that's more your style. While companies using Angular will be pretty much locked into Protractor for their testing framework, Webdriver.io is a good place to start. The documentation is good, there's a lower bar to entry, and there's plenty of help available if you get stuck.

Installing Webdriver.io and writing some automated tests for a project you've already built is a great idea. I find myself doing this for all of my Angular side-projects with the built-in Protractor framework.

Conclusion

I hope that this gave you something to think about as you navigate your journey into software development. QA is a wonderful and vital step in the development process, and I've worked with quite a few automation engineers that came from software development because they just loved the testing process. Whether this is a career or a step in your career journey, I wish you the best of luck!

Photo by heylagostechie on Unsplash

5 Lessons I learned in medicine that made me a better developer

Jason Sigler — Tue, 12 Jan 2021 20:11:30 +0000

Prior to my foray into software development, I was a paramedic and Army combat medic for 8 years. I fell in love with software in the middle of a biology degree and decided that it was my goal to use my newly found passion to improve medicine through software. While it might seem like these two disciplines are dissimilar, I quickly found that much of what I learned about the practice of medicine applied to my journey into software development.

You must embrace change

Much like medicine, software is a constantly-evolving field that moves quickly and will leave you behind if you don't put forth the effort to keep pace. Whether you've been in the industry 30 years or a week, you cannot simply 'do what you know' and expect to succeed.

While the foundations of computer science are less prone to significant change than those of medicine, frameworks and languages are updated often. Standards can vary from company to company, and new technology can be adopted at different rates.

If you aren't comfortable with adopting change, excelling as a developer is going to be a challenge.

You must be self-aware

This is something that everyone struggles with on some level, but is incredibly important. In medicine, we would consult with experts if we knew that our knowledge wasn't sufficient to provide the best possible care, or to see if there were any 'tricks of the trade' that might be applied in a certain situation. A cavalier 'I know everything' attitude is dangerous for patients and is not tolerated.

In software, you may not have the same safety mechanisms in place so it is your job to continually evaluate your own skills. When you're starting out, this can be especially difficult, but it is always helpful to find a mentor that is honest and willing to provide that much-needed gut check from time to time.

If you don't adopt a habit of self-evaluation early on in your career, its easy to get lost. You need to know when to ask for help, and understand that someone may have a better way to solve a problem. Take an honest inventory of your skillset early and often, then work to develop those skills. Don't put yourself into a position where you have to scramble to fill in knowledge gaps if your job situation suddenly changes.

You know when its time to move on

One of the great things about both medicine and software development is that there is a wonderful litmus test to determine if you're still a good fit for the industry:

Do I have anything left to learn?

A doctor once told me that if I ever felt that I knew everything that there was to know about a subject, then it would be best for the practice of medicine that I moved on. Software is the same way- if you don't have anything more to learn, then you have nothing more to contribute.

Software development is hard

Both medicine and software development are complex and difficult disciplines to master, so don't be surprised if new concepts don't come easily or seem unintuitive. People learn in different ways and at different rates, so don't waste energy on beating yourself up if you need extra time to grasp a concept. If you come up with a novel way to grasp a concept, share it with others- it may help someone else who is struggling.

Remember that anything can be learned given enough time and
effort. You can only control the effort.

Manage expectations

This seems fairly obvious, but it is especially true in software development. With many people facing financial struggles in 2020, there has been an influx of people both young and old looking to better themselves by learning to code. While I wholeheartedly encourage those who fell in love with coding (I did!), I have to warn everyone about managing expectations.

The hours are long, the job can be mentally draining, and a lack of care and passion for the craft could spell heartbreak years down the road. I've watched plenty of nurses and paramedics burn out within the first few years because their hearts just weren't in it, and the same is true for developers. Make sure that you are fully invested in this career path before you spend time and money to pursue it.

Photo by Hush Naidoo on Unsplash