“Hey, we just added a new video feature to the website. We can still release Friday, right?”
If this sounds familiar to you, you’re not alone. QA teams are frequently pushed to do last minute testing with limited understanding of the project overall or inadequate time to plan.
How can you be a supportive team player, but not let yourself and product’s quality be pushed around? How do you support innovation, yet not let the product slip below acceptable levels of quality? The good news is that there are several negotiating strategies that can help to address these common challenges.
First of all, start negotiations before crunch time. The most difficult time to negotiate or alter the course of events is when you are trapped in a corner right before release. Preparing yourself in advance requires that you cultivate relationships, establish communication channels and educate yourself.
Get to know your developers.
Know them personally and make sure they are comfortable coming to you to discuss project updates. Having a good relationship with the developers keeps you plugged in to changes coming your way. Moreover, you can plan better when you know how well they test their own code. They also might help test when a deadline looms.
Know their "customers.”
Who is requesting the software under test? How do they discuss their plans? Getting to know these stakeholders is critical to get the inside track for new projects, feature changes, and schedule changes. It also allows you to provide input early on when a proposed schedule change has the potential to negatively impact quality.
Be practical about your workload.
How “baked” is the code when it comes to you? How many features might be added in the middle of the project? More importantly, how much time do you have to spend testing? Being realistic early on can help you to more efficiently allocate resources and plan for the crunch early. Do you really need to test all 100 combinations of browsers and operating systems? What platforms are really essential and why? Can you eliminate some combinations with pair-wise testing?
Plan and communicate your test plan.
Plans are a means of communication, not an end in themselves. Write them at the appropriate level of detail for your audience and use them to get buy-in early on.
Rather than simply emailing a test plan to a bunch of people or getting a formal “sign-off,” follow up with a group review or target a few people for individual reviews. Use this as an opportunity to better understand what the “customer” wants and expects, what the developers are designing and implementing, and to let them know what you are planning on testing. These reviews should be done as a discussion not a presentation. Most importantly, use these reviews as an opportunity for everyone to understand what everyone is committing to!
But what happens when issues come up at the last minute?
In spite of our best efforts, not everything is foreseeable. Managing the testing process in the face of last minute feature changes and surprise deadlines requires finesse and leadership. Part of being a good leader and team player is leading others from a bad place to a good place and convincing them they want to go. Here are some common issues and how to handle them:
“We don’t have more time! Didn’t you know the release was in two days?”
Who says we don’t have more time? Is it development saying this? Is it marketing? Find out and go to the source. Make sure they know how testing will be impacted. Sometimes they just didn’t realize the impact and don’t really have a hard deadline.
“This deadline is mission critical and there’s no pushback!”
When there is a real deadline that is unmovable, prioritize. Is it more important than other projects you are testing? Ask your “customers” to make decisions so that resources can be reallocated from less critical projects to more critical ones.
“But everything is an equally high priority!”
Don’t just give in to this. If you are always accommodating, then “customers” may think your plans and estimates are padded. You need to be doing critical and high-priority stuff that will find the important bugs. These situations put your negotiating savvy to the test.
You have to convince your “customers” to choose one of three things:
(1) Extend the project deadline
(2) Provide help with the testing
(3) Reduce the testing, and thus increase risk
Let’s look at these one at a time.
Extend the deadline. Remind “customers” that your tests were well planned with their buy-in, and already include trimmed down testing focused on the most important areas. Is it more important and less risky to release the product as is and on time or to postpone release?
Get additional help. If it really, really has to be released by the due date, this is the next step in negotiating. Can marketing or development help do the testing? Some portions of last minute testing may involve scripted manual work that’s fairly easy for anyone that knows the site. Suggesting this as a solution also continues to keep the responsibility partially on other stakeholders.
Reduce testing and communicate risks. If all else fails, engage “customers” in the conversation and ask what they would cut from testing. Make sure other stakeholders share in the responsibility for their decisions to reduce testing and taking on more risk. Marketing or development team leads may use their authority to push a hard deadline, but not take the responsibility for the ramifications and instead push blame downstream to you.
Obviously the best case scenario is to avoid a crunch. Sometimes this is possible, and sometimes it isn’t. When it’s not, these negotiating strategies can offer basic practical ways to navigate in rough water when you are asked for last minute changes to testing or additional testing. In the end, build relationships, communicate with “customers” and if all else fails, know when and how to push back.
