Last night I participated at .NET user group meeting in San Diego. I should not feel that out of place, after all, I work with .NET development even if I choose to focus on testing, and I love talking to my developers about all the cool stuff they get excited about. And that tends to be about some very neat way of implementing something. I thoroughly enjoy the excitement they have for their craft even if I occasionally wonder how something like that could be so interesting, but I know they feel the same about me ranting about something really cool on the testing scene or what I learned about our product or people or whatever makes me tick this time.
The speaker of the evening was David McCarter, speaking with a title Rock your apps: 10 things you probably aren't doing. I enjoyed the talk, in particular I found it funny that we share so many things to rant about in for example realizing how the world around the implementation details work. But something he said, not the main message of his talk, left me really puzzled.
With the shock of that statement, I had a discussion on the topic on the way home to learn to my shock that there were recent experiences close to me (that's what happens when you change your circles, new shocking information - be careful who you date...) that somewhere managers had actually asked to remove already created unit tests as good developers are not supposed to need tests. The mere idea is awful.
My experience is that a lot of times we in the teams hide behind "estimates" and "not being given enough time" to not create unit tests. The reality is that we need much time, as we don't have the skills to do the unit tests. We add them after creating the software, when adding them is harder, and we tend to be very careful refactoring in fear of breaking things. I can't expect my managers to give me a blank check on time to not provide end-user visible value, but I've experienced my managers being very helpful in finding timeboxes in which to drive things forward.
This took me back to situation in my current place of work two years ago. Actually, the developers were telling me when I joined the company that they are not allowed to do unit testing, just feature after another. I soon learned it was not true - or it was true as their perception. I helped the team negotiate a week of each month on learning the basic skills on this. They could have started any time before me. It was just about asking, suggesting, finding a balance.
For any of my testing colleagues out there: ask your developers if they feel they are not allowed to do unit testing, and when you can help them. There's so many things on how you can help. Support their message. Talk on their behalf. Reframe unit tests as "executable documentation" like Liz Keogh suggests if it helps. Ask for effort for developers to participate in testing, and organize that as their refactoring time to allow for adding the tests they'd want to add. Acknowledge the work someone does on adding tests. Be interested in their experiences, and help share those in the team, just by voicing out a question that others are not asking. Create an atmosphere where the managers see that this practice creates a lot of positive around it, pinpoint the good and help improve the bad.
And if it happens that your developers really don't yet want to do unit tests, send them somewhere to meet their happy colleagues who are already doing that. What you say will have less impact that their peers saying and showing things.
Unit testing, as agile emphasizes it, is the best thing that has happened to quality. Even though it is a type of testing I tend to not deliver.
Who really stops developers from doing unit tests? Their own perceptions. Help them change that. Developers might say managers, but have the developers then really done all there is in advocating for their perspective? Investing into unit tests is a valuable practice in the bigger scheme of things.
The speaker of the evening was David McCarter, speaking with a title Rock your apps: 10 things you probably aren't doing. I enjoyed the talk, in particular I found it funny that we share so many things to rant about in for example realizing how the world around the implementation details work. But something he said, not the main message of his talk, left me really puzzled.
Most places don't let you do unit testing.I felt like I had entered a time warp and jumped 15 years back in time, it has really been so long for me to have heard things like that. I feel that nowadays you are required to do unit testing. They actually teach it in universities - at least where I come from. And test-driven development is pretty popular too in my agile-like circles.
With the shock of that statement, I had a discussion on the topic on the way home to learn to my shock that there were recent experiences close to me (that's what happens when you change your circles, new shocking information - be careful who you date...) that somewhere managers had actually asked to remove already created unit tests as good developers are not supposed to need tests. The mere idea is awful.
My experience is that a lot of times we in the teams hide behind "estimates" and "not being given enough time" to not create unit tests. The reality is that we need much time, as we don't have the skills to do the unit tests. We add them after creating the software, when adding them is harder, and we tend to be very careful refactoring in fear of breaking things. I can't expect my managers to give me a blank check on time to not provide end-user visible value, but I've experienced my managers being very helpful in finding timeboxes in which to drive things forward.
This took me back to situation in my current place of work two years ago. Actually, the developers were telling me when I joined the company that they are not allowed to do unit testing, just feature after another. I soon learned it was not true - or it was true as their perception. I helped the team negotiate a week of each month on learning the basic skills on this. They could have started any time before me. It was just about asking, suggesting, finding a balance.
For any of my testing colleagues out there: ask your developers if they feel they are not allowed to do unit testing, and when you can help them. There's so many things on how you can help. Support their message. Talk on their behalf. Reframe unit tests as "executable documentation" like Liz Keogh suggests if it helps. Ask for effort for developers to participate in testing, and organize that as their refactoring time to allow for adding the tests they'd want to add. Acknowledge the work someone does on adding tests. Be interested in their experiences, and help share those in the team, just by voicing out a question that others are not asking. Create an atmosphere where the managers see that this practice creates a lot of positive around it, pinpoint the good and help improve the bad.
And if it happens that your developers really don't yet want to do unit tests, send them somewhere to meet their happy colleagues who are already doing that. What you say will have less impact that their peers saying and showing things.
Unit testing, as agile emphasizes it, is the best thing that has happened to quality. Even though it is a type of testing I tend to not deliver.
Who really stops developers from doing unit tests? Their own perceptions. Help them change that. Developers might say managers, but have the developers then really done all there is in advocating for their perspective? Investing into unit tests is a valuable practice in the bigger scheme of things.
