One question, many responses.

I have been going through something of a transition phase in my life.   The project I was on, has effectively run its course, and so the uncertainty of where I would end up next began to pop up.   It has been a stressful time, and I know that there may be more stress in the future. Change seems to require quick study, a measure of patience, and the eagerness to take it by the horns and honk till the cows start moving. 

As I have begun preparing for this next assignment, anticipating that Testing will once again be a primary role that I will fill, I began thinking of how I could be better prepared to meet my new project team, and how I can be ready to give an answer to some of the things that may come up as a direct result of statements I might make, statements that are greatly influenced by a large measure of reading, and collaborating with other Test Pros online, through the blog o sphere, or twitter.  I find I am on edge, not in a bad way, but the Eagle Scout in me likes to be prepared.

Up till now, I've been something a lone gun tester, going where ever the current test ideas, or recent releases seem to point as areas of risk.   Sure, the previous project I worked with a pair of testers, but so much of the work I was doing, was different than theirs, that in essence, I brought something unique to the table something that provided value for those teams.   I want to continue to provide value on my next task.  There will be a lot of new faces, new ideas, and new challenges to overcome, but I'm ready, and eager to mount up and go chasing over and after what lies at that horizon.

As I have been preparing myself mentally for this scenario, a thought occurred to me late last night.  It was a thought that gave me pause.  The thought was this:

If you as a tester on an existing project, were allowed only one question on your first day about the project, what question would you ask?

 
 I regret that I had to hit the hay before I could see some of the fantastic responses from the twitterverse.  Some of the responses were similar to the ideas ruminating in my own head. Reid Sheppard asked: "What's the URL to the SUT?" Lanette Creamer asked: "1 question to who? Very important to know."

Truthfully, Lanette's question was really asking for clarity to the context of the above question I asked.  Since it was framed with out any context for where, or who was available to ask, it was very much an open ended question.  I intended it to be a little open ended, but as I slept on it I realized something.  Not only was it lacking in context, but it begged the question.  For any given project X, how much might you as a tester know before officially being on the Team?  

Every test effort begins a bit differently, but I imagine many of them where a new person is brought into an existing team (the specific context of which I was mulling), would begin by some kind of interview, or screening.  Unless the tester and hiring authority had some familiarity with the particular tester they are hiring, The tester could be just as much an unknown to the hiring manager, as the hiring manager, the test team, and product under test is at the start for the newly hired tester.

I find myself coming into a team that to my understanding has already been through several bug/fix and release cycles.  So to me, the context in this case actually includes a few things that are not clear in my statement. The Customer is an entity with which many people might have some experience, or at least preconceived notions regarding how this entity helps them leverage what their service provides. 

Stepping back from the specific instance in my mind, to a more general case, which is really where this question began.  How much does the average tester know about a project before going in?  It might depend upon how their interview and contact with the team began.  Maybe you know who the Customer is, but maybe that information is sensitive information that is only given once a person is a part of the team and agreed to sign on.  Maybe, you do not even have an idea of the scope or mission of the subject under test before agreeing to act as a tester.  Sure there may be cases were that information is available in that screening process, but if it isn't, that's context most testers would hope to grasp early in their testing role. 

Others responded with questions about why the limit of only one question? 

Ajay Balamurugadas asked: "How can I get information without getting restricted by number of questions? #there is a better question :)"

In fact, the limit of one was not meant in my formulation as a hard limit.  My thought was what is the first, question, the first one you'd ask so you can begin pondering all the who's and whats, whens, wheres, whys and hows of testing the application.  Perhaps I can give more idea why my thinking was 'limited' in this context.

When I first came on board here, I remember days of reading that I had to go through.  Much of it wasn't even related to the tasks I would be doing day to day.  time sheet training, ethics rules, benefit packages, taxes, I-9, so much paperwork.  So for someone who is coming in brand new, to be a full part of a team as a tester, the thought occurs to me that they might spend most of their first hours doing a lot of untester things.  So what if at the end of the day, you have an hour left, your tired from all of the tedious paperwork you've had to file, you've signed your life away with a non disclosure agreement, or perhaps signed a contract for term to serve.  Whatever the case is, the thought was this: 

What if in the span of that one remaining hour, in the process of being greeted by the team after you emerged from where HR had you sequestered,  what if one of those team members, not a customer, probably not even the manager, it could be another tester, a developer, a business analyst, whoever it may be, what if they turned to you and asked that question, "Hey, we are glad to have you with us.  Just ask us any question and we'll try to answer it."  However, the new colleague, then adds that they only have a few minutes to spare before they will be leaving for the end of the day.  It's possible you might only have enough time that first day for a single question to ask.  There are so many questions you could ask, and maybe there would be time for more than one question, but depending on the answer you receive it could take up the rest of the time to complete.  This was the frame of mind I was in when pondering this question.

In reality, that first question could be very important, or it could be just the first of a series of questions.  That first question might be forgotten, and left in the dust bin never to be remembered.  The thought would be not so much what is the one question you might ask, but rather what is the first question you would ask? Would it be the same question in a different context? Perhaps it would be different.

Truthfully this does not really matter, there are many questions that will need to be asked to successfully test any product.  Some of these will be obvious, and some will have to be unearthed after peeling back a few layers of the onion.  So I come back to Lanette's question, who is there to ask?  

If it is a tester, perhaps you might ask what areas they've had difficulty testing?  Or maybe you could ask them how the team documents the defects encountered.  If it was a programmer, you might ask them where they think the code is weak, or as Lanette suggested: 'I like to ask developers, "What was the hardest part of X to design? What was the hardest to code so far? What worries you?'  Sometimes the developer will know where their code is weak, or what areas were harder to code, or what areas they've had particular difficulty with.  These kinds of questions would help to identify areas of risk.

In actuality, it may not matter what our first question might be, in fact the thing that sticks out to me is that the issue really shouldn't be what the first question is.  The first question could have a myriad of answers, and in turn a number of counter, or clarifying questions could come up in the course of understanding that answer.   I found this an interesting puzzle to consider.  Just like I do not believe there is a such thing as 'best practices' in testing, there is testing that is good, and techniques, or approaches that are good in some contexts, but perhaps dangerous in others.  So perhaps the best response would be to ask the developer or tester that has opened this door, to simply explain their experience while testing the product.  As such an open ended question, the ideas that might be unearthed could be true gems that lead to effective testing down the road.