Steps to move from Junior QA to Senior QA Engineer

10 min readOct 7, 2020

The life of a Junior QA Engineer is easily one of the most tedious roles in all of engineering. They are often hired to do the most mundane of tasks, such as running through a series of written steps on a new build over and over, to ensure no existing functionality has broken. Sometimes, they will get the chance to test something new, like a bug fix or, if they’re lucky, maybe even a new feature. However, for the most part, their purpose is to ensure there are no regressions in an upcoming release.

As fun as this may sound, there are a number of proactive steps a Junior QA can take to stand out and impress some of their teammates. If they can successfully incorporate all of these steps into their routine without compromising their regression testing tasks, they will almost definitely get the attention of a more senior QA, Developer, or Project Manager. With this increased recognition, along with the skills and knowledge you will gain when following these steps, the prospects of a Senior QA role will be very much within reach.

It is worth mentioning that the sure-fire way of instantly improving your worth as a QA engineer is by learning automation. The number of resources for learning automation is immense, so adding even the most basic automation knowledge to your skillset would increase your value tremendously. If you can combine some automation skills with the steps below, you will surely stand out within your company as a highly valuable member of the team.

Become very familiar with the application you are responsible for testing

This sounds like a no-brainer and something any QA person should be focused on, but there is a significant difference between a Junior QA’s familiarity with the application and a Senior QA‘s familiarity with the application. For the most part, a Junior QA is running a series of test steps that have been given to them, either by another QA or a Project/Product Manager of the application. Their goal is to ensure each step is run in a timely manner to ensure that there are no regressions in that build compared to the previous build and that they are not the bottleneck for a release.

One way for a Junior QA to go above and beyond here is by running test steps that are not part of their written test script, otherwise known as Exploratory Testing. Exploratory Testing is vital in testing, and the majority of bugs will be found during Exploratory Testing, as compared to Prescriptive Testing. Exploratory Testing is not just poking around at the app or site in hopes to discover a bug. In order to successfully run a comprehensive exploratory test, one must fully understand the feature they are testing and anticipate where undiscovered bugs may be hidden before testing even begins. This could be based on where previous bugs have commonly been found, or on a recent change in a specific part of the app, or where the app is dependent on inconsistent third party functionality.

Another way to become more intimate with the application you are testing is by reading through all of the specs and documentation that you can get your hands on. If the spec is written well, it will include a section that explains why the team has decided to introduce a specific feature, and what problem is being solved or mitigated. The more a QA Engineer understands the reasoning behind every change, the more equipped they will be once they begin testing. Testing a feature with little to no knowledge of it beforehand will almost certainly lead to missed bugs.

Become very familiar with all the applications that directly touch your application

An excellent way to gain confidence in testing and increase your knowledge is by learning as much as possible about the related applications that touch your product. An example could be if you are responsible for testing an iOS app, but your company also has a similar Android app, plus a website for users, it would be beneficial for you to understand how the Android app and the website function. Gaining some familiarity with these peripheral products would give you a broader understanding of how your product is intertwined with the others.

For example, if there is a section for users to enter comments, and you notice that the Android app and the website show the exact same comments, you can assume there is likely a third-party plugin that is being used to collect all of those comments. In turn, this would also inform you that if something ever did break with comments, it could be an issue with that third-party plugin and not the actual code of the app. After a quick A/B test with a previous version that you know did not have the bug, you can conclude which party introduced the bug. This information could save a developer a bit of time and could even be helpful in spotting bugs in those peripheral products.

Become very familiar with all the infrastructure around the application you are responsible for testing

One of the most significant differences between a Junior and Senior QA is that a Junior QA is almost never expected to understand what exactly goes on behind the scenes of the product. There are almost always a number of moving parts that must complete a complex dance before the product is even in a state that can be tested. If you can become even remotely familiar with each of these moving parts, you will quickly give yourself more credibility within the team and maybe put yourself in a position to catch bugs earlier in the process.

For example, let’s say you are responsible for testing a website, and for the majority of testing, you wait for a developer to tell you when staging is ready to be tested. Most likely, you are waiting for a few days, maybe weeks, for a developer to tell you to start your regression testing. If this is the case, you should ask yourself — what exactly is happening during these few days or weeks of waiting? Is it possible to gain some insight into what they are doing and what exactly is being put on staging? If you do some more digging you might find out that during that time, the developers are pushing each new feature and bug fix to GitHub, and you are just waiting for a developer to place all of those changes onto staging in one fell swoop. At this point, you should ask yourself — what is stopping me from testing these changes before they even make it to staging? If you can put yourself in a position to test each GitHub branch individually, you will be able to:

confirm a bug fix much earlier
discover any regressions caused by a specific change
send the developer feedback much earlier in the development cycle
increase your technical skills by learning how to pull and checkout branches from GitHub onto your local machine

The more under-the-hood applications you familiarize yourself with, the more you will grow as a QA Engineer and gain more trust from Developers and Project Managers. Also, in the long term, this will help you continually learn and increase your technical skills in applications that are widely used in engineering teams everywhere.

When writing bug tickets, be as detailed and organized as possible

QA is often the linking chain between the development team and the release process. In this nexus, we are required to create bug tickets that are detailed enough for a developer to read through and quickly understand the problem. all while ensuring the ticket is readable by non-technical people so they can decide the priority of the ticket. Because we need to satisfy both of these requirements, we must create tickets that include as much detail as possible while maintaining readability. A ticket with a vague title and one giant paragraph as the description is often difficult to parse through for everyone.

When creating tickets, having a consistent template would create organization in the ticket plus increase the readability and understanding of the problem. I usually try to use the following template when creating a ticket:

Descriptive bug title — the bug title is the first thing everyone will read, so if we can have them understand the problem from just the title, everything else is a bonus.
Thorough description in the body of the ticket — In the description section of the ticket, include a detailed summary of the problem. Think of this as a more exhaustive explanation of the bug title. This should include details like how consistent the bug reproduces, and on what platform you saw the bug (iOS version, Android version, Chrome vs Safari, etc.).
Steps to repro — Each ticket should include a section for what steps someone can take to reproduce the issue. This should be as detailed as possible — a good rule of thumb is to assume the person reading it has never used the product before.
Expected Results vs Actual Results — Include a thorough description of what you expected to happen and what you actually saw. This is the section where you would add as much detail of the bug as possible.
Include screenshots or screen recordings — Always add a screenshot or a recording of the issue to each bug ticket. In many cases, people will look at these attachments before reading anything in the description.
Include any logging if possible — If you have access to logs, include these in the bug ticket. Depending on what platform you are testing, accessing crash logs could vary. So if you do not currently have access to collecting logs, any developer would be more than happy to show you how to do that.

Create as much visibility into your QA process as possible

In most companies, only the QA team knows exactly what the entire QA process looks like. This lack of transparency often creates a lot of confusion with what exactly the QA team is doing. If you can create transparency into the QA process, where the entire engineering and release team can see what exactly goes on behind the scenes, this would introduce a large number of benefits:

Engineers know exactly when their code will get tested within the release process.
Release managers will see exactly how long it takes for regression testing to be completed, and what the regression testing consists of.
Engineers can make suggestions of what to add/change in the regression testing before it begins, based on any specific code change.
Added documentation will make onboarding much easier for any new QA member.
If you are the one to create the transparency of the QA process, people will start to view you as the go-to person for any QA related questions, which will increase your name recognition and perceived knowledge on the process and product.

There are a number of ways to create transparency in the QA process. A good question to ask yourself when thinking of how to create this transparency is — what platforms are my target audience already using for similar documentation? A lot of the time, the answer is either GitHub wikis, Google Docs, Notion, or any other tool that the organization uses for knowledge-management. Whatever platform you decide to use, make sure you integrate this QA documentation to an already-existing platform in order to make it easy as possible for everyone to locate and reference them.

Be overly vocal and opinionated, with proper data to back up your ideas

Very few people within the organization are as knowledgeable of the entire product and all its features as the QA team. With a few exceptions, developers and product/project managers are usually asked to focus on one or two aspects of the product, which will give them expertise in those few features. However because the QA team is constantly testing the entire product, we are a good resource to use when it comes to deciding the look and feel of a new feature.

As a QA member, taking advantage of this intimate knowledge of the product is beneficial for both the QA engineer and the product itself. If you are testing a feature that you feel like can be improved in any way, you should not hesitate to voice your opinion. For the most part, all engineers and managers are very welcoming to any opinions you may have. However, before voicing your opinion, it is best to do so with as much data and facts to defend your ideas.

A few examples of how to collect data to defend your opinion are:

Does the look and feel of the new feature seem largely different from other features within the app? If so, find that differing feature and ask why we aren’t we implementing the new feature in a similar fashion.
If you are testing a new feature, and there is a very similar feature in a more popular app, ask yourself if our feature feels drastically different from the already-proven feature. If so, will this significant difference cause confusion for the end-user, and should we consider changing it to mirror the more popular app?
If there is a major change being made to an existing feature, ask yourself if it makes sense to spend so much effort to even make this change. This decision can be made by collecting analytics and seeing how often the end-user uses the feature, and if the change being implemented would increase that usage or not. If you can prove the existing feature is almost never used, and the change to the feature will likely not increase that, you can suggest to delay that change and to focus on something more important.