Blind Squirrel Approach: What do you do when requirements are sparse

"Because even a blind squirrel finds a nut once in a while ..."

You may be familiar with this saying, or you may not have ever heard of it before. The message is simple: given the likelihood of failure, success can happen, even in the slightest of ways. How does this apply to QA you ask?

New to the project

You, intrepid QA / Software Engineer in Test, have been assigned a new project, or are filling for someone. If the Test Plan is adequate, you should have all the information you need to successfully complete your task. But what if you don't? Do you panic?

• Solution-1: If a fellow teammate has handed off the project to you, they should already on-board you to the project and provide as much background, context, and other details of relevance. If this wasn't the case, the next-most person in the list is your team lead or manager. The team leads should have some substantial information and are usually the best "go-to" people on the team.
  
• Solution-2: I've always felt the need to read through as much as I can and get a Producer / Project Manager to sit with me and get a proper on-boarding (if the QA Lead / QA Manager hasn't already done so).

Sparse Requirements

So you are now on the project and have been somewhat on-boarded to the project, but the details are still fuzzy. What do you do?

• Solution-1: If you're like me, you investigate. You talk to the people assigned to this project and you get the details you need. I usually start with the developers, before I go to the producer. This is frowned upon, but who better to get the explicit information than from the people who need these details to complete the project. If a developer can successfully code against requirements, you can test against it. Developers will also provide additional insight you may need to consider in testing.
  
  Once the test cases are written (or updated), show this to the Producer for final approval. All will be right in the world.

Lack of Information

You've asked your team lead and there was a lack of clarity (tsk tsk). You asked the Developer for some insight and got none. Now you reach your wit's end and go to the Project Manager. They hand you documents that are sparse of details and have gaps in requirements. What's a good tester to do?

• Solution-1: This may not be a totally true scenario, but let's suspend belief for one second and entertain the likelihood that information is sparse. In the absence of information, a good tester has to take matters into his / her hands and ask for an S.O.W (scope of work), Requirements Document, or something in writing that outlines the expectations of the project.
  
  I've had this happen to a slight degree. The takeaway was that a huge amount of time was wasted doing some unnecessary investigative work to get the information I needed and successfully do my job.

Conclusion

For any QA Tester or Software Engineer in Test (SEIT), information is the key to success. The more we have, the better off we'll be. In my past history and all the way up to now, "I DON'T KNOW" has never been an acceptable answer. If you don't know, its because you didn't MAKE the time to know. If you didn't ask the right questions or do your due diligence, then its on you, dear tester.

If you asked the right questions but got the wrong information then the source of the information is suspect. All the more reason to keep asking questions.

Its our job to understand what it is that we are doing and why. I always ask, "why am I doing this?" not because of some defiant need to assert my position, but more because I want to understand the business logic. Also, I want to understand the scope of what I'm doing and to whom I'm doing it for. All these questions help me be a better tester, not just a cog in the machine.

This may or may not have helped you .. but if I can, let me offer one piece of advice:

ALWAYS BE ASKING?