Other Posts

Observe as A Photographer, as A Tester

coverimage

“Photography is an art of observation. It’s about finding something interesting in an ordinary place… I’ve found it has little to do with the things you see and everything to do with the way you see them.” – Elliott Erwitt

Since the beginning of this year, I took photography as a “serious” hobby. The interesting thing I found is that the more I have learned about photography, the more I can feel the similarities between photography and software testing.

The importance of observation is one example. Observation is a crucial skill for gaining and collecting information. For a photographer, observation is an essential part of taking every great photo; For a software tester, observation is the search key to find the problems and risks. Therefore, things I learned to sharpen observation skill as a photographer can also be applied to a tester.

Observe from different perspectives and angles

Sometimes a beginner photographer gets a glimpse of a scene, then a final conclusion is quickly made without thinking: “There is nothing to photograph.”

Really nothing to photograph? Mostly not. The lack of perception often leads to the result of “nothing to photograph”. Even shooting the same ordinary subject for several times already, a photographer needs to train not only to observe a subject from different perspectives: color, shape, texture, background, light, shadow, etc… but also to observe a subject from the different angles: lie down on the grand, stand up on a chair, frame using a window, shoot through other objects… There is always something new which can be found from different perspectives and different angles.

The same thing applies to the tester.

If you are a tester who follows the requirements and testing processes, sooner or later, everything of the product becomes too familiar and too obvious to you. You start to build up an attitude of “everything is known” and “everything is fine”: “It works as expected!”, “All automated checks pass, what could possibly go wrong?”…

It’s a good timing to observe the product from different perspectives:

  • From user perspective: How this feature can solve user’s real problem?…
  • From business perspective: How can we measure and analyze if this feature makes sense to help achieve our goal?…
  • From programmer perspective: How does this business logic impact the programming complexity?…

It’s also a good timing to observe the product from different angles:

  • From user’s feedback: Does the user understand how to use this function as we think?
  • From product log: Does the product log contain enough information for debugging?…
  • From codebase: Are errors handled correctly for some special data?…

After those observations, you are able to look for that which others would never see. Some hidden requirements and new risks will be clearly revealed.

Observe with a focus

Sometimes a beginner photographer enjoys a lot the moment of pressing camera shutter button, so it’s easy to fall into the trap of taking photos of everything without paying attention to anything.

Really need to shoot everything? Mostly not. Photographing everything leads to the lack of focus. Especially in a fast-changing scene with tons of subjects, a photographer needs to train to observe with a focus on the most important subject in the current moment, in order to reach the purpose: What is the story you are going to tell with this photo you want to photograph now?

The same thing applies to the tester.

If you are a tester who has to “check everything”, probably you get quite exhausted in repeating endless test steps… If you are a tester who believes in “automate everything”, probably you get quite busy with writing and maintaining automated checks all day long…

It’s a good timing to observe with a focus:

  • Are all these automated checks equally valuable to keep maintaining?
  • What would be the worst situation that happens to the product in the next release?

Take a breath from busy daily work and think about the focus on the most important thing: What is the information you are going to get with this test you want to perform now?

Observe emotions

Sometimes a beginner photographer likes digging deep inside technical theories and following the rules: wide-angle lenses for landscapes, telephoto lenses for portraits… After using the “right” gear setup with the “right” technique, taking a great photo sounds promising, right? Not really. Gears and skills are admittedly important in theory. However, a great photo should be able to convey emotions. In order to capture and understand emotions, the photography needs to train to observe emotions through the cold viewfinder: gesture, body language, feeling, expressions, mood… Observation is more than seeing.

The same thing applies to the tester.

If you are a tester who takes KPIs and measurements seriously, probably you have built some technical KPIs like code coverage, the number of defects, passed tests, covered requirements… These KPIs are not good enough to simply tell you what could go wrong before that things actually happen.

It’s a good timing to free yourself from those numbers on the paper and observe emotions from people around you:

  • Does the product owner feel confused and lose in the differences between real implementations and expected features?
  • Does the programmer feel unsure about merging the code refactoring?
  • Does the team have a bad mood about current works?

The feeling of confusion, the fear of uncertainty, or other negative emotions can be the strong signals that some potential crises are going to happen, which are now hidden in communication, in the process, in codebase… Capture and understand emotions, pull out the problems and handle them with the team before it’s too late.