Review of a review

Recently I was asked to review an article written by a colleague and afterwards it made me think about how I actually read and review text and how I approach test and testing.

The article itself was written as a discussion on the different approaches for a company to solve the webpage / mobile site issues. It was written for the general public and therefore did not contain massive amounts of technical details, rather focusing on the pros and cons of each solution.

My analysis of my own review (self-review?) is as follows, and can be split into three parts:

First i read through the article and just made some minor notes on where i got stuck some way or another. One read through, pretty much skimming the article

Next came the focused read, where I comment each part on a technical and understanding level. Do this make sense? is this actually correct? etc. Each time i got stuck or started questioning things i went back and reread the sentence or the whole chapter, and also checked statements on their validity. I also discussed some parts with the writer to make sure I understood what the aim or goal was.

Finally I once again started over and read the article as the person that the article was aimed at. So this time the focus was more on: Would I understand the text? Will this help me decide which solution to go for?

Once all this was done i cleaned up my notes and handed the article back to be updated. But the important thing here is that I made sure I was available to take questions regarding my comments.

So the conclusion ?

• For me to feel done with my review i read the article three times
• Different focus each time
• Checked and/or discussed questions with writer during review
• Active collaboration
• Written comments was also explained once the review was done
• Is my comments understood correctly?

Some notable observations are that not once did I actively check spelling, this due to the fact that I know another more suitable reviewer (teacher) would focus on the language. It took me three reads to feel done with the review. It was imperative to have the opportunity to discuss my comments directly with the writer to clarify questions and avoid misunderstandings.

How can this be translated to test then ?

In general terms my review are in three phases. First a quick smoke test, is this stable for the actual test? Secondly system test or even system integration test, do each part function as expected? Finally the acceptance test, is this what was actually ordered? The spell checking can be seen as the regression test, standard functionality that should work.

Another way of looking at it is the approach. First I read the requirements or User Story, do I have enough to start test? Secondly I execute the testing, focusing on different parts, digging into possible bugs etc. Lastly I rerun some of the test to get the big picture before finalizing my test report.

And as pointed out time and time again, communication is imperative. And this must be both with the business as well as the developers to avoid misunderstandings, and in the long run to avoid false negatives being reported as defects.

Trying something new and unknown is always good and will provide new insights, even if it just shows that you work in a similar manner regardless of situation.

Have you reviewed your work approach recently?

Give it 10 minutes and it might give you a big “oh-moment”