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.
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.
