filfreire user image

Metadata of starting

thoughts, craftsmanship, testing, and quality
Toy Story, 1995

TL;DR: When starting at a new project as a tester, be on the lookout for meta-information that says a lot about the project and will help you guide your testing, but is typically not apparent, as so, it has to be unpacked with a detective stance testers should practice.

Sometimes as a tester you’ll be faced with switching between completely different projects with multiple different realities and associated contexts. Depending on who you work with or if you do consulting, this reality and project switch happens abruptly and you’re expected to quickly adapt and add as most value as you possibly can via testing efforts that somehow will need to emerge from unexpected and uncoordinated testing missions.

We feel confused, and in the midst of confusion we allow ourselves to create quick “shortcuts” of reality:

“Oh this projects seems bad! I hate it!”; “Oh this project seems awesome, I love it!”; “The people seem grumpy and unfriendly…”; “The people seem nice!”;

Adding to that, we feel completely lost. Like we’ve been piloting small airplanes our whole life, and in one instant we’re forced to pilot a boat with a complex console. But, contrary to the negative emotions we allow ourselves to develop even further into more negative emotions and thoughts, feeling lost is not bad.

For anyone feeling lost and confused, it seems like it’s the end of it, even before allowing a chance for anything to start. Times come when we’ve already given up. It might take years until we try to do something about it, but the decision to give up was long ago taken by a past-self, someone who we no longer recognize.

You might be wondering, what point am I trying to make here?

The illusion of confusion

Confusion in a software project and in life itself is not bad. Much less for a software tester inside that project. Your testing efforts shouldn’t start with “Despite all of this confusion, we still managed to do X”. They should embrace confusion and pick on it.

Look at it in another way. Confusion and being lost tells you more about the project you’re put into than you’re mistakenly led to believe initially by your feelings and observations. Starting at a project is the perfect moment for tremendous information gathering, analysis and experimentation, way beyond your initial onboarding process and the onboarding’s confines, and way outside the scope of what is initially apparent. Starting at a project should be like a royal hunting season for a thoughtful software tester.

Asking questions

I’ve come to develop through time some questions that I ask people directly, or I just try to build an answer from observations, talking to people, going through code, documentation, code reviews, and other, that I believe allow a tester to cope with confusion (even generating more of it, but that’s fine!) and make a difference when you’re trying to be crafty and help the project as best as you can, as early as possible.

There is no right or wrong answer for almost all of these questions. Every bit of information is a bit that will potentially guide and help me adapt my testing strategy and efforts.

I’ve compiled here a list of some of them, that I usually go through, most times in an unscripted way. All of them have the goal of peeling bits of information about the project, and I invite you to read each one, think about it a bit and try to think how you’d answer it in your current project, even if you don’t get the point of the question:

This list goes on, I can think of more questions, but these are the ones I keep coming back to eventually.

Now for the final trick…

Some of these questions are plain dumb. Some of them are harsh. Almost all of them are biased by my personal experience and path in the testing craft.

But, the final trick is: the questions don’t really matter. What matters is asking questions. What matters is fighting confusion with a detective attitude that every tester should nurture and grow. You fight confusion with questions, with problems, with bugs found, and with even more confusion.

The underlying goal is to develop the healthy habit of quickly gathering as much information as possible during the initial moments of a project, even information that at first hand might seem unimportant. I’ll get whatever I can grip regarding the project I’m placed into, because this “data about data” also guides my testing. And I’ll do it with these questions and many others resources.

On an ending note: If you never learn to love and embrace confusion in software testing, you’ll never feel the true joy of testing. To joke a bit: It’s the same as being a tomb raider while disliking and avoiding tombs.