Can-Do List: One way to get unstuck. Really.

I met a person working as a test contractor on a project recently who said to me: “There are no requirement documents so therefore I cannot write test scripts. And this means, I cannot test.”

I’ve heard this before from other test contractors. I don’t understand the logic being applied.

I tilted my head and was speechless. I thought I should keep listening to see if I could better understand. But I didn’t. In this case, it seemed the tester believed the only way to approach testing was to read and review requirements, write test scripts, and then execute test scripts. Since this one approach was not an option in the environment at that time, the tester felt dead-ended with his work.

Meanwhile I had my own immediate roadblocks to attend to. So here’s what my problem was, how I solved it and then I’ll loop back to the test contractor’s problem.

I was contracted to execute performance testing of an application. I didn’t have access to the application I was testing – by which I mean I didn’t have the needed permissions to access the application. I did not have VPN permissions so up to that point; I had not seen the application or knew much about the app. I had no previous experience with the application. In fact, I didn’t know what the application looked like or how to navigate around the application, the type of data the application worked with. So I was feeling a bit stuck to be certain. But I did have access to the physical environment, other people on the project and to a SharePoint site although the SharePoint site had so many documents on it that I was overwhelmed with no sense of where to begin.

But I’ve been in those shoes before – meaning I’m at the start of a body of work but all I can see is a dead end not a beginning.

I was so frustrated at one particular point that I sat myself down and kept asking myself one question over and over in an internal (admittedly loaded with mix of frustration and somewhat sarcastic internal voice) brainstorming style. My question: What can I do? Note the word can is in italics as I felt painfully aware of what I could not do.

I’d prompt myself, well … what can I do? I pulled out a pen and notebook and decided to write a list. A list of possible next steps that I could pursue on my own would certainly make me feel better. And maybe unlock my problem somehow. Here are some of the items I wrote:

• I can talk to person X, the lead project expert on the application and see if she can give me an overview of the application.
• I can listen to the other contractors – not the testers but the developers and designers and learn what project concerns they have (including concerns that don’t make it project status reports).
• I can call the Help Desk again and appeal to them to escalate my request for access.
• I can begin writing a test plan because even without access to the application, I know what I want to test and what I plan to do once I can get started. I can update the plan later as I learn. And writing always helps me clarify my thinking. And with this client, written material will end up being needed so sketching out a draft now might be useful.
• I can pretend for a moment that I have access to the application. What is it (one item or a list of activities) that I so badly wish I could do?
• I can talk to the project manager to hear what expectations she might have of me. (And see how it matches or does not match to the person who brought me onto the project.)
• I can talk to the other testers and see if I can hear their thoughts on testing, the application, performance concerns, anything – who knows where that might lead me.

I shut my laptop off. I walked around. I talked to people. I started learning whatever I could. I felt better. The physical movement helped. Not feeling trapped at a desk focusing on what I could not do helped.

I did as much as I could that day and then I left. I had another project for another client to work and I told myself maybe tomorrow would look better.

It was days before my access was granted and I was finally able to login and see the application I was scheduled to test. When I finally logged into the application after so much aggravation getting to the starting point, I froze for a few minutes – now what? But instead of feeling stuck, I thought about what the project expert had taught me about the app. I pulled out my notes from our session together. I found my way around the application. I started to become unstuck.

So now let’s wander back over to the test contractor’s problem. He believes that having no requirement docs means he cannot create test scripts and therefore cannot test.

In the language of my teenage daughter: Really? (Really is a favorite word of hers and as a result (sadly) is deeply injected into my language as well. Note that the tone of the word “really” is the essential ingredient.) You really cannot do anything to proceed because you don’t have a document. Really?

To-do lists are common. We all slave away at battling to-do’s versus the amount of hours in a day – nothing new there. But a can-do list is empowering. It reminds me to seek another path, find another way. It doesn’t fix roadblocks that need to be resolved but building a can-do list (versus a to-do list) helps strengthen me when I feel down or defeated or stalled out – really.

I don’t need a document to learn an application. I can investigate in ways I identified, and there are other options for learning as well – blogs and forums can help with the reality of an application over a requirements doc any day. As a tester, I should have enough curiosity to get learning and start my work with more than one approach – I may have a favorite approach or a familiar approach to my work but I should be able to see beyond one approach. Next time you think you are stuck ask yourself: really?