Introducing Developer Testing Into an Existing Team - Project Manager Thoughts

Last time, I posted our developer's thoughts on the answer to this question: What was the tipping point for you that helped you decide automated developer testing was a worthwhile thing?

Here's what one of our project managers thought:

dalesmithtx: I've asked some of our developers that question, but I'm curious about your perspective as a project mangler, err..., I mean manager

 Project Manager: The past weeks on [our current project] have shown the value

 Project Manager: for sure

 Project Manager: The challenge is getting the business folks to agree on that value

 dalesmithtx: What value have you been able to see?

 Project Manager: We saw that we could refactor and not miss a beat

 Project Manager: assumes that your project is going to have time to refactor. When you only get one shot at integration testing that's a challenge

 Project Manager: too often we follow the path of (1) code in silos (2) come together for a few days of integration (3) jump into QA

 dalesmithtx: right

 Project Manager: in that case the value goes way down because any refactoring the team does is in their spare time as they fix bugs and prepare for launch

 dalesmithtx: Do you think you are going to be able to sell it to the business folks?  Or do you see a need to do so?

 dalesmithtx: (from my perspective, as long as they're getting sausage, why do they care what happens in the sausage factory?)

 Project Manager: my last point was it still has value on the NEXT project or even the next hotfix. It increases your chances for quality follow on releases

 dalesmithtx: sure

 Project Manager: understood but if they KNOW about it they are going to fight to give you less time as you're doing work that could be cut

 dalesmithtx: I dig what you're saying

 Project Manager: If you just build it in and don't draw attention to it ... then yes

 Project Manager: build it into the schedule I mean

 dalesmithtx: At some point when we have an hour or so, I would really like for the [our current project] and [our other current project] teams to sit down and talk through a "lessons learned" session on this stuff

 dalesmithtx: Not so much a post-mortem specific to our projects,...

 Project Manager: right

 Project Manager: a technical seminar sorta

 dalesmithtx: But a post-mortem about the development techniques we used in an agile setting and in a waterfall setting

 dalesmithtx: pros and cons

 dalesmithtx: right

 Project Manager: yep I mean it had a cost in [our current project] but since the work so far has been so lop-sided on the UI side compared to the rest of the engineering folks, we had time

 dalesmithtx: right - that's an important point...

 dalesmithtx: I want to claim victory, but I want to claim it on solid ground, not by hiding behind latency elsewhere in the project

 dalesmithtx: I guess I'm looking for a real measure of the value that developer testing has brought to us so far, and what we think we need to change if we expect to get more value out of it on future development

 Project Manager: ok

 Project Manager: yeah I agree I don't like hiding tasks

Share this post :

Introducing Developer Testing Into an Existing Team - Developer Thoughts

My friend Chad Myers posted recently about Introducting Quality-first Notions Into an Existing Team.  Since you are such a devoted fan of my blog, you undoubtedly know that we have recently introduced Test Driven Development, or at least automated developer testing, to our team in the context both a waterfall project and an Agile project.  Chad's post made me interested to see what folks on our team thought about developer testing now that they have been doing it for a bit.  So I’ve been asking folks what they think of developer testing, specifically whether or not they thought it was worth it and what it was that made them think that.  My point in doing this is that I want to gain actual value from our testing efforts, and not just remain in the “testing enthusiast” camp.  I, of course, am sold on the idea of developer testing, but I thought you would like to see some of the responses I got:

dalesmithtx: What was the tipping point for you that helped you decide automated developer testing was a worthwhile thing?_________________________________________________________

 DEV 1: Well, I'd say there was no tipping point.  It was more of a feeling of: I can't wait until we get this going.  Here are my feelings.

- The last shop I worked in used it and it proved its worth over and over.  I was the one who setup and ran the test scripts so I saw the effort through from beginning to end first hand.

- It's another means to increase our test coverage although it's not meant to be a substitute for other types of testing.

- It helps enforce more testing by developers.  For those developers who have not been exposed to test driven development, it's a big change.  It's easy to just write code but it's also risky.  Test driven development allows the developer a chance to think things through before writing code.

- I like to see you smile.

 dalesmithtx: Aww, that's so sweet!

 DEV 1: heh heh

_________________________________________________________

 DEV 2: when I ran nUnit and saw all the blinky green lights?

 dalesmithtx: good point

_________________________________________________________

 DEV 3: hmm...

 DEV 3: i guess i'd have to say finding mistakes in code while writing tests, which saves you some time up front when you start smoke testing.  it showed me that you are not just investing additional time - you're saving time in other areas, so the overall investment is only slightly more, but the benefits are far reaching.

 dalesmithtx: Very cool

 dalesmithtx: DEV 2's answer:

   DEV 2: when I ran nUnit and saw all the blinky green lights

 dalesmithtx: Yours is a bit more helpful

 DEV 3: haha... that's a big one too... until you see all green, you hate testing :-()

 DEV 3: :-)

 dalesmithtx: yup

_________________________________________________________

 DEV 4: I think the real selling point for me occurs when you later make some changes you don't anticipate will be problematic and then find out some the tests failed.  If not for the testing, there would have been issues.

 DEV 4: You can also refactor with much greater confidence.

 dalesmithtx: DEV 2's answer:

  DEV 2: when I ran nUnit and saw all the blinky green lights

 DEV 4: I think he meant red.

 dalesmithtx: :)

__________________________________________________________

 DEV 5: yea for me it was the first time I broke a test

 DEV 5: went oh rainbow

 DEV 5: that saved me 2 hours

 DEV 5: I transposed two strings

 DEV 5: was supposed to be string str3 = str1 + str2;

 DEV 5: instead I did

 DEV 5: string str3 = str2 + str1

 DEV 5: in one function

 DEV 5: unit test caught it instantly

 DEV 5: would have taken me at least 2 hours to get UI setup to test

 dalesmithtx: yeah

 dalesmithtx: Yeah, for me it was really hooking up automated testing with CI, which we haven't really emphasized here yet

 dalesmithtx: At least not on our current project

 dalesmithtx: As soon as it clicked with me that a failed test means a failed build, I got it

 DEV 5: yea

 DEV 5: I think DEV 7 has best def yet though

 DEV 5: its used like double blind accounting

 DEV 5: & for the same reason

 DEV 5: chances are you won't make the same mistake in the same way both places

 dalesmithtx: right, I like that

 DEV 5: yea so do I

____________________________________________________________

 DEV 6: hmmmm

 DEV 6: for one confidence in your code of what it does and does not ...

 dalesmithtx: Do you remember if there was a particular incident?  Or was it more of a general sense, arrived at through multiple tests?

 DEV 6: ... and knowing what you delivered in regard to the business rules in the spec ...

 DEV 6: yea a general sense via tests

 DEV 6: no ah hah moment :)

 dalesmithtx: right

____________________________________________________________

 DEV 7: Your and DEV 8's respect

 dalesmithtx: :)

 dalesmithtx: that ain't worth much

 DEV 7: I have to be honest I did not do it as much as I should have

 DEV 7: And let it slide by the wayside when the project got well under way

 DEV 7: :(

 DEV 7: I just lost it

 DEV 7: your respect that is

 dalesmithtx: :)

 dalesmithtx: nah

 DEV 7: So, I hope to win your argument I get more issues with my code :)

 DEV 7: I am still interested in approaching code that way

 dalesmithtx: What are the implications of introducing developer testing to a legacy environment?

 DEV 7: Just felt very rushed through much of the project

 dalesmithtx: sure

 dalesmithtx: that's the reason I'm asking though - just wondering what it has really gained us so far, and what we would change in future development efforts to get more out of developer testing

 DEV 7: I know I dropped it around the time I had issues testing DB calls

 DEV 7: But I see that as soon as those calls are at least a call away thet get mocked out anyway

 dalesmithtx: so that's in interesting point - getting tangled up in physical dependencies is definitely a stumbling block to widespread adoption

 dalesmithtx: understanding techniques on how to deal with those situations would help, but  we have to have a vision on why we should do this in the first place

 DEV 7: More practice would have let me see that it's not such a huge issue

 DEV 7: Cool

 dalesmithtx: sure, absolutely

 dalesmithtx: I'm also interested in how to communicate the vision of what testing brings to others in our organization

 DEV 7: Well hopefully you can get some good examples out of [our current project] code

 dalesmithtx: and [our other current project]

 DEV 7: Leave it anonymous though, so people don't think that I cause so many bugs

 dalesmithtx: LOL

 DEV 7: hehheeh

___________________________________________________________

 DEV 8: i just generally think automated developer machines (ADM) are very cool

 DEV 8: but it was when Chad [Myers] came to [my former employer] and showed us the error of our ways.  I was converted by an itinerant preacher

 dalesmithtx: :)

Share this post :

Tracking Technical Debt in ReSharper

I love ReSharper. It's purely platonic. After all, I am a married man. But it's always there for me: my trusty little sidekick, my own personal Sancho Panza. Its array of helpful features is truly impressive: it enhances editing capabilities; it helps me organize the classes in my projects; it cleans up my code for me; it tells me when I'm missing references; it offers suggestions for more readable conditional statements; it's a floor wax, a dessert topping, and a gentle laxative.

One of my favorite ReSharper features is the To-do Explorer. It scans your code base filtering on comment tags you define ("//TODO", et al) and gives you a clickable sorted list of those items. It's nicer than the VS TaskList in that you can sort the results in different ways (my favorite being by namespace and type), and you can copy the results to the clipboard or save them out to a text file.

Since swinging into TDD at our office in the last few weeks, we've started taking the idea of Technical Debt very seriously. As we're working through our implementation, we recognize that there are some deadlines which will force us to make some compromises on design decisions. That's ok as long as we don't forget to go back and re-work those things later. We've found that an easy way to track those things is to mark them with the comment tag "//DEBT" and set up a ReSharper To-do Explorer filter for that tag. Then when we're planning our next phase, we've got a sortable, printable list of items we know we have to prioritize into the project plan.

Taking that idea a bit further, we decided to standardize on the following three code comment tags and create ReSharper To-do Explorer filters for each:

1. //HACK == a HACK is something we put in place knowing it was wrong to begin with, and knowing it has to be taken care of as quickly as possible.
2. //TODO == a TODO could be anything that we need to complete by the end of the current iteration.
3. //DEBT == a technical debt is a calculated decision to complete a feature in this iteration using a design we know we will need to refactor in a future iteration. 

When we take a look at To-do Explorer, we get something like this:

So before the end of the current iteration, we know we need to clean up our HACKs and TODOs.  And at the beginning of the next iteration, we can throw the DEBTs in with the requirements to be prioritized and worked into the iteration plan.

I'm sure there are other ways to track technical debt that offer more info, but this is a quick, easy, and cheap way.

Share this post :