What I learned doing code reviews

Recently I started doing something I’ve always wanted to do but never actually got into: code reviews. I have some prior experience with code but not enough to write on an enterprise level. I always feared that my lack of ‘coding standards’ would be a big barrier to break. However, since reviewing code for a month or two it is going better than expected.

This is a story of how I found a new way of providing value.

During this time I mostly learned by looking at the code reviews other team-members were making. Seeing what kind of remarks they gave and applying that in other pull requests (PR) that I would review. In the end the PRs must be approved, which I don’t often do based on just a code review. Luckily the PRs are deployable themselves, and thus testable.

Reflecting on the last project

My last project was in the financial sector. The product we made was used by private banks. Our users were the Investment Managers of those banks. They are called the rock stars of the banking world. Those people didn’t have time for us. We could get little information from them via their secretaries or some meeting that was planned meticulously. And in that meeting only 1 or 2 of our people could be present, to make sure they didn’t spent too much time. Getting specs or finding out what to build and build the right thing was not an easy task. Our business analysts had their work cut out for them but did a very good job with the resources they had. Getting feedback from them was even more difficult. Especially getting it fast so we could change the product quickly. Despite all that, we were able to deliver a working product to all clients. This blogpost is a reflection on what I think I did well, what didn’t do well and what I would have changed if could have done it over.

Sprinkling chaos

The day isn’t even half and twice I’ve caused chaos!

This morning I asked the analyst in my team why I got to state A instead of state B as I expected. She was also very confused and embarked on a quest!
First we discussed it among ourselves and decided we didn’t know enough and so we went to one of the developers.
We explained him what was going on and after a short while he just said “I don’t know, ask the other developer.”. And so we did! We started talking to him and saw him panic. He made that change! We we’re on the right track. So after quizzing him on WHY he made the change it turned out that it was never documented. He was told to do it in some call and he just executed it.
Now the analyst got a bit annoyed. She’s supposed to know these kind of changes. She’s the one in charge of keeping the documents up to date. These documents we provide the client so they know how to use the product. So she started grilling the developer on who told him, when and why?

In the rear-view mirror

I’m a consultant, and my project ran at its end. It’s been very nice and I’ve learned so many things. I started out as a very junior tester but my colleague got me up to speed pretty fast. I gave shape to my own testing ideas, became the sole tester and even test lead.

This is not a bug!

I’ve been in discussions before whether something is a bug or not numerous times. To me this can be frustrating, because I believe this change will improve the product and should be done anyway.

Feel the testing!

Testing is often regarded as a black/white field. Something is correct or something is wrong. But any practiced tester will know that there’s much more to it than that. There are always things that are not in the analysis and even things that are in the analysis might feel strange to you.

What do you do?

– “I’m a tester.”
*Nods*
I take from their reaction they know what I said, but have no idea what I do.
– “Most of the times I find defects in software, written by others.”
I see that they now have some idea of what I do, but are still left with questions. So I continue:
– “I try to make sure that when we deliver a product, that it actually helps the users. No-one needs more software, they want a solution for their problem.”
“Ow yeah! At my job I have this software that doesn’t help me at all!”
Lots of times they’ve experienced bad software before. Telling them that I’m working to help the user, helps them understand why my job is valuable.

Automation, not always self-evident!

Lots of companies now request automation. And although automation is a good thing, there is a place and time to implement it. When you’re trying to automate an application that’s still prone to have big changes, you’ll find yourself doing a lot of rework. It will make it a lot harder to write tests that only fail when the application is wrong and not the test.

My spyglass into the code

As a tester you don’t always have access to the code of your application. Sometimes this doesn’t matter, but it can also be very useful. I can’t keep up with the developers writing code, but I do have a tool that allows me to use the code to my advantage.

That tool is the ‘AppMon’ by Dynatrace. This application monitoring tool injects code in the code-base and records all the executed code. This data can then be displayed and searched. As a tester, this provides you with a massive amount of information and a spyglass into the code.

disclaimer: This is not a sales pitch. This is just my appreciation for this tool in form of a blogpost. There might be similar tools out there that do the same.

Crisis averted

In times of crisis, our first reaction is to start looking for a guilty person. This is a normal reaction, but not a constructive one. But what should we do when a crisis does come up?