Can You Test This Real Quick?

We’ve all been there. Cornered by your boss, usually near the end of the day, and you’re asked to test something “real quick”. You want to be a team player, as most of us do. But you also know that “real quick” probably means cutting corners to get a high-level, sub-par test done. If you’re lucky, you have automation in place so its just a matter of validating any failures. If you’re not so lucky, you have to get your manual test strategy ready. So how would you handle this scenario? I’ll share some advice and lessons learned from my experiences.

Keep Calm, Carry On

Early in my career, when something like this would arise, there was a good chance it would send me into a spiral of anger. ‘How do they expect me to test this real quick when I don’t even know what I’m testing’. ‘This is a day worth of testing that I’m just supposed to magically get through in an hour’. Sound familiar? There was usually a 50/50 chance I was over-reacting. I can admit that now. Once I got into the requirements and understood what was being asked, I was comfortable I could adequately test ‘real quick’ and moved forward. So my first piece of advice is to take the information in, ask for a few minutes to review the request, and then move forward. If it turns out that the request will take longer than “real quick”, keep reading.

Hope Is Not A Strategy

There could be this slight feeling deep inside you that tells you to just cut corners, get it tested quickly, and hope for the best….don’t do it! Why? Simple. By obliging, you’d be training those around you that you’re the go-to person if they want to quickly get something through the pipeline. I’ve made this mistake before. What I’ve learned was those same people that urged me to test it quickly were nowhere to be found when something went awry in production. If you’re being asked to test something quickly, you’re probably working within an organization that views QA as a final stage and doesn’t respect that quality is owned by everyone. If that is the case, all eyes will be on you when a defect slips to production.

Is This Critical – Risk vs Reward

Another important thing to consider is how critical what you’re being asked to test is. I’ve been in situations before where our site was down and nothing we could do could make that worse. They really just wanted to smoke test a fix and to get it live asap. Sometimes that risk is worth the reward. As mentioned earlier, hopefully, you’ve got automation to cover the critical areas. If not, settling for less testing might be a reasonable request.

Strategize and Communicate

Once you’ve realized it isn’t a ‘quick test’, and the fix isn’t critical, the next step is to strategize and communicate. The goals for this stage are to tell the requestor why you can’t test it in the timeline given by detailing your test strategy, and what a realistic timeline is. The key to accomplishing these goals, from my experiences, is clearly communicating the following things:

• A realistic timeline – You can’t finish testing in the timeline given, so what is a realistic timeline? Try to be as detailed as possible, using minutes or hours to describe your needs.
• A quick overview of the areas you’re planning to focus on – This will help others understand the timeline you’ve given. Perhaps they weren’t considering the areas you’re proposing. I also like to break down my estimate in this area too. If you’ve listed out areas of the application to test, apply low-level estimates to each section.
• Manual vs. Automation – I like to help others understand what type of testing I’m planning to do. Automation can cover a larger application terrain in a shorter period of time. Manual testing takes longer and requires more thought. These fluctuations can help account for any new estimates you’re giving as well. In addition to that, are you planning to exploratory test or is there a set of test cases you’ll be executing?

Confirm and Deliver

Ok, so you’ve taken the time to assess and document what you need to do, how you’re going to accomplish it, and how long it’s going to take. You hit enter on the keyboard to send it out and wait for confirmation back…not so fast! You’re effectively in the negotiation phase. I’ve found that both context and emphasis can get lost in an email or over a slack message. Once you send your message, go find the requestor (perhaps your boss) and walk them through your plan. Let them see the passion for quality in your eyes so they can’t say no!

Note: It would be a great idea to share your test strategy with the developer that worked on the change to ensure you’ve covered everything!

You’ve Done All You Can

I’ll tell you, there is nothing more exhilarating than making your case and getting the time you need to get things tested the right way! It can make your day or even week! See I’m even using more exclamation points in this paragraph, that’s how exciting it is!

On the flip side, your balloon really gets popped if your boss comes back and tells you to get it done quickly anyway. Not to worry, because by communicating what you’ve outlined above, you’ve shared the risk with others. Instead of you cutting the corners on your own, your team (or boss) is now making that decision. A quick piece of advice: if you’re put in this situation often, where you’re asked to cut corners anyway, I’d be considering a new job. Being respected for your skills and what you bring to the table should not be undervalued.

Even if you’re asked to test quickly, you can still lean on your testing skills to make the right decisions with the time you have. If I find myself in this position, I will consider a couple of things: risk-based testing and exploratory testing.

Risk-Based Testing: With the previous analysis above, you’ve already outlined where automation can help and where manual testing is needed. Sometimes automation doesn’t help at all. Either way, stay focused on getting the riskiest testing (the testing most likely to produce a bug) knocked out first. These are areas that immediately touch the code changes and/or areas that are prone to breaking. Finally, focus on the critical end to end paths to ensure the customer can do the things that make the company money. While this wouldn’t be the full lot of testing you desired, it would still ensure the important things are tested.

Exploratory Testing: If you’re pressed for time, the last thing you’ll want to do is spend time documenting steps in a test case. Instead, focus your efforts around exploratory testing, You can create a feature map with the areas you need to test and start testing.

Wrap Up

We are all going to find ourselves in this situation at some point. I made some mistakes early in my career by not pushing back and communicating my needs upfront. This resulted in production defects that made the situation worse. I learned that by taking a step back, understanding what exactly the testing needs are, and communicating the realistic timelines, I was sharing my strategy, and risk, with others. You’re not always going to win the battle of ‘can you test this quickly’, however, you can always control how you manage your way through it.

Comment below and share your experiences with the community. How have you handled this situation in the past? Any lessons learned?