Wednesday, March 19, 2014

Reading and writing code could be two different skills

Yesterday's workshop 'Brutal Refactoring Game' left me thinking about the regular discussion about testers coding skills. The workshop was about writing beautiful, well-structured code. While I consider myself a non-coding tester, I've done some programming in my years in software development - I still keep realizing that with all the things I could learn that are related to testing, programming isn't that high on my list.

The workshop left me thinking about my relationship with code.

We were supposed to pair up to create tic tac toe -game. With the first smell note of 'no code', we (a team of two testers) googled up a solution to copypaste, knowing that the next smell note would be lack of tests. And that the idea of the exercise is not to show copypasting and googling skills, but actually learn stuff on programming.

We looked at the solution we had, with the idea of adding tests and changing the code so that tests would be possible. We could easily read the implementation, we could see it was not beautiful in how it was structured. And that adding tests on that structure would not be a straightforward task.

We started working with our own solution, to run into problems with inexperience with the actual coding part. So again I faded out to googling, looking at examples with tests. I found some really nice implementations that were a pleasure to read.

I realized I do this as part of my work regularly. I read code, usually with the purpose of understanding what is included to guide particular ideas I would test with. Reading code is not that difficult and it gives me a lot for the testing. I don't read the code to cover it, but more from the point of view of understanding complexities or exceptions, and the scope of the actual implementation.

Just like with the workshop-time googling, I feel I recognize good and bad, and different styles. With the bad ones, I can tell why it's bad (againts a set of expectations I've learned) but it's clear I can't do it better myself. I feel awful when this happens, to a scale that makes me not speak out loud  about it depriving the developers the chance of feedback. Instead of talking about the code, I turn to using the software and showing problems the code has in execution.

So just an idea: could reading and writing code be two different skills, and when we talk of testers needing to code, reading - even shallow reading - might be sufficient? Feeling apologetic for what I can and can't do isn't helpful, and just leads to not optimize what we can do in the team together.

I think I'll try actively doing more of code reviews and talk about my perception with the developers. My lovely team mates would appreciate my effort regardless of my inability to tell how that should be.





2 comments:

  1. I think reading and writing code are two different, although related, skills. One does not have to be able to write code, in order to be able to comment how code written by someone else looks or reads. If code is a tangled mess of hard to read hacks or slightly obscure variable names, it doesn't matter who points it out and asks if it could be written more cleanly.

    As a programmer, I tend to read a lot of code that has been written by someone else. I truly appreciate when I don't have to second guess what is happening or spend hours hunting down details in order to understand how things work. If we can write code in a way that testers can understand it, surely other programmers would understand it too?

    ReplyDelete
  2. I too read code, when I have some time to, mainly for the purpose of inventing more/better test ideas. We code review all of our commits, and reading those is also a rather nice way to be up to speed on the progress of what should and what shouldn't work (talking is better of course but this is fun too).

    All this time I have been shy in giving comments on the code (as the coders DO know better), but got just a great suggestion a while back on the #hsdl which was to ask coders for a brief walkthrough on the code commit. Idea was, that the coders then actually review their own code at the same time, often noticing places of problems themselves. So I get help on understanding the code better, and don't need to feel that I'm "wasting" the time of the coders. Done this a few times now, and feel pretty good about it.

    ReplyDelete