How do you keep up with deadlines as a QA engineer?

QC Engineer Delia Stanescu explores the importance of deadlines and offers insight into how to manage them like a pro

By Delia Stanescu, QC Engineer, Cognizant Softvision

So, what is a deadline?

The deadline is the time when something is due, or the latest time by which something must be completed. Why do deadlines matter? Typically, we have deadlines for one of the following reasons:

• To ensure that we complete our work: it’s easy to delay or to forget a task that has no agreed upon end point and deadlines help to avoid this.

• To encourage a smooth flow of work: deadlines help us to collaborate toward achieving a shared goal, and to keep complex, multistage projects on track.

• To set expectations: deadlines make clear what we’re expected to deliver and when. This means that we can take control of our work, free of confusion.

We all deal with deadlines and sometimes we struggle to meet them. In the next few pages I’m going to walk you guys through some tips and tricks for how you can keep up with deadlines as a Software QA professional. Deadlines can become stressful if you are not used to adapting to changes, but over time, practice will help you get an objective perspective about things and you will train your mind to look for solutions rather than problems.

When reality is different than planned

A sprint has just ended and your team is planning the new sprint. The sprint starts and everything goes smoothly until everything goes off. But what happened? In software development there is lightning fast dynamic in everything. We are building and delivering high tech features faster than ever before. We are living in a fast-paced environment and we need to keep up with a lot of changes. Planning is needed, but plans can change and we need to embrace changes along the way. That’s just how the tech world we live in works.

You and your team have planned the QA activities and you are waiting for a build in order to start testing. But stuff happens: equipment may not get there on time, the software may be delivered on time but does not work, or due to some technical impediments, the development team might have to delay the deployment for a few days. This will impact your testing schedule and initial plan. Instead of panicking, try to adapt to the new situation. Think: what can you do?

Make a plan to accommodate the new reality

First, you need to determine if you are still able to cover the planned testing activities by the due date and what are the adjustments you can do to the initial plan. As you have less time, prioritize the most important tasks. Assess if you can test a couple of features together (to avoid regression testing) or maybe organize a few peer testing sessions with the QA team where you can all test together (more eyes are always better). Remember that our job as QA engineers is to mitigate risks, not find bugs. By running test cases, we mitigate the risks those test cases cover. Using a Risk Based Testing approach will help us test the functionality which, as we know, has the highest impact and probability of failure.

Another idea you can explore with the Product Owner or Project Manager is the prioritization of features in order to determine if some smaller features could be deployed in a Phase 2 release. If the features need to be deployed altogether, find out if a patch release can be deployed in case of emergency. This will give you and your team safety in case anything major appears.

If, after analyzing all options, you are still concerned about delivering the test results by the deadline, consult with the Product Owner or Project Manager about the situation. There might be more resources allocated for the project in order to help out with testing. If this is the case, be aware of how you delegate tasks to the new colleagues that are coming to help. Ideally, the extra resources should be in the QA field, but sometimes developers will be the ones to help.

Delegate the simpler tasks to the QA newcomers (ideally with requirements and test cases available) and have multiple sync-ups with them to make sure they have all the help they need. When an outsider QA contractor is allocated to help with testing, make sure to ramp them up on procedures such as test case results, bug reports, and processes to follow.

If a developer is helping out with testing, be aware that developers do not approach software testing in the same way that QA people do (developers have a different mindset), so make sure you give them documented test cases they have to sign off on. When developers are brought in as an additional work power to help QA, there is generally resentment on their part because they don’t really want to be doing QA work. This is where you can get creative and ask them to automate a suite of tests with verifiable results, or even a set of unit tests. Developers can provide a huge amount of help by writing solid and sharp unit tests meant to find code weaknesses. Discuss with the developer about how they think they can best help and try to agree on what is the best use of their time to help deliver the tests results. You will be surprised by how many ways a developer can help you with testing as long as they feel challenged and likes what they are doing.

Objectively assess the situation and learn to take risks

Nowadays, companies are taking more risks than ever before. As QA engineer, the person ultimately responsible for the product quality, you might be a bit skeptical to sign off a release you did not get the chance to fully test. The best you can do is present management a report with your prioritized risk analysis and communicate your concerns regarding releasing the software with the agreed-upon level of quality. Management will likely propose a solution based on their business expertise and previous experience. Sometimes your concerns will be considered justified and more time will be allocated for testing, while other times the management will decide to take some risks and go further with the release. Often, it’s better to anticipate than to react.

As QA professionals, our job is to communicate the situation as clearly as possible to your superiors, raising concerns and defining all risks as early as possible, but most of the time we don’t hold the final decision. Once we understand and apply these principles we will be able to better focus on planning our activities and communicating effectively with management whenever we have concerns. Take advantage of having bold management and learn from past experience. This will help you get a wider overview of future risks and make better decisions.

Keep in mind:

• Deadlines change and we need to adapt
• Practicing with tight deadlines helps you plan better, assess quickly, and communicate risks
• Get creative when running short on deadlines: test multiple features all-together, test in groups, apply risk-based testing, automate some of the work, think outside the box (exploratory testing can do the trick here)
• Delegate in a smart manner and review the results
• Clearly state your concerns to management (escalate), but be aware you are not the decision maker
• Embrace risks because this will expand your comfort zone

Get more insights from our engineering and design experts on our website!