Developers Who Test (and Don't)
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
A quote from a former colleague: "Stop finding bugs, that's the clients (= user) job" And yes she was serious, and no that wasn't even my worst experience dealing with her.
Tom
-
Johnny J. wrote:
but mostly waste of time in my opinion!
If your unit tests are a waste of time then you are doing it wrong. There's no point in writing unit tests unless they add to the quality of the code and give confidence that the software works as expected. The book you need to read is this one. [^]. It's the only book on the subject I recommend. You should quickly see improvements in your unit testing strategy.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
Osherove's book is a great one. This new one I mentioned is quite good too because it takes a broader view and doesn't just focus on Unit Tests but is attempting to change the mindset of developers to understand they need to : build quality in. Also, Unit Tests / TDD can feel redundant... ...as soon as you write them, you alter the code to pass those tests but then you don't need the tests to run any longer because you know you altered the code to pass the tests. But, they are helpful because, 1. they help you think about quality 2. they help with regression testing
-
Do you proofread your own prosa? Or do you review your own bookkeeping? Testing your own stuff is not such a great idea. You tend to build your misconceptions into the tests and sometimes you try to prove how good you are a little too hard. And these are just some unintentional reason why this can go all wrong.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.I've worked in numerous roles in IT so this method works for me. I'm destructive to software. I started out in support at a medium sized place with a smaller software group (25 people). The dev sat a row over. I asked him once, "Hey, this customer makes a great point. Why does this do that?" GreyBeard: Shut up! I then moved into QA. Once the devs were having a design session that leaked into the hallways. Another support guy -- who really used the software to help users -- said, "Hey, I think you're forgetting about X." GrayBeard Devs: Shut up! We will cross the bridge when we get to it. You are wrong about that design element. Support Guy: Wait guys. Seriously. Think about-- GrayBeards: Shut it! Support guy: :confused: 6 months later after new software release with this new design... Support guy: <hangs up phone> Remember that design element I mentioned? Well, the customer just fell into that hole. Graybeards: Shut! Up! Support Guy: I'll enter it as a bug in the system. :rolleyes: Later in my QA career, devs would say, "hey, monkey, go test and we'll give you a banana..." I entered a 10,000 character URL and hit post. It crashed Oracle instance!! Hahaha... (no, you cannot do that now, but you could in IE 2.x,3.x) Enter steps into bug tracker and submit. Heh, heh, heh. There's your treat, dev. Dev: What do you want me to do with that bug you entered. me: I don't care. It kills the Oracle instance and your app dies so it doesn't mean anything to me. Ignore it if you like. If you feel confident to go to prod with that. Dev: <sulks off into another direction. > For the win!!
-
A quote from a former colleague: "Stop finding bugs, that's the clients (= user) job" And yes she was serious, and no that wasn't even my worst experience dealing with her.
Tom
-
These types are dangerous. Because of them crashing rockets and die people :mad:
Press F1 for help or google it. Greetings from Germany
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
I've worked with people like that, but I've also worked with people who were specifically hired as testers. What I've seen is that the arrogant kind of dev you're talking about (and they exist just about everywhere) tends to be a lot more careful -- and involved! -- when they know that there is someone who will be confirming that everything works OK. I know that the next comment my annoy some people here, but this is somewhere where Agile works exceedingly well. The morning stand-up ritual builds really good connections between devs and testers.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I've worked with people like that, but I've also worked with people who were specifically hired as testers. What I've seen is that the arrogant kind of dev you're talking about (and they exist just about everywhere) tends to be a lot more careful -- and involved! -- when they know that there is someone who will be confirming that everything works OK. I know that the next comment my annoy some people here, but this is somewhere where Agile works exceedingly well. The morning stand-up ritual builds really good connections between devs and testers.
I wanna be a eunuchs developer! Pass me a bread knife!
I can actually see what you mean in the case of (true) Agile, because in that case the hand-off from dev to QA should be so tight that it is as if the hand-off were simply the one person who played the role as dev would now put on her QA hat and do the tests. In that case you would be right and that is really how it should work and that is again directly tied to ownership. But, i assure you, long ago when that dev said that to me, it was entirely because testing was beneath him. Great conversation here though.
-
R. Giskard Reventlov wrote:
I really don't understand the notion of cobbling code to together and passing it up the chain
I can't get inside that mentality either. It's quite terrible. I think it's either: 1. complete Ego-driven dev with a seasoning of laziness or 2. complete Lazy-driven dev with a seasoning of ego. :laugh:
I fit into option one: The ego will not allow me to deliver crappy code - the QA (users) are anally retentive, pedants who delight in sending back a bug report. Laziness - I loathe writing the same code twice.
Never underestimate the power of human stupidity RAH
-
Osherove's book is a great one. This new one I mentioned is quite good too because it takes a broader view and doesn't just focus on Unit Tests but is attempting to change the mindset of developers to understand they need to : build quality in. Also, Unit Tests / TDD can feel redundant... ...as soon as you write them, you alter the code to pass those tests but then you don't need the tests to run any longer because you know you altered the code to pass the tests. But, they are helpful because, 1. they help you think about quality 2. they help with regression testing
I find unit tests helpful when initially developing some new functionality, as they allow me to focus on the new functionality and getting that working in isolation. Then I can look at integrating the new functionality when I know it works. And definitely agree with your point about regression testing. I think this is possibly the single most powerful reason to use them. If I make a change to the code, I want to be sure I have changed all the affected areas, and breaking unit tests gives me exactly that.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
We're set up here now with SonarQube hooked into the CI system so if test coverage on new code is below 80% the change is automatically rejected (and it does reject changes). We still get people saying "I don't understand why I need to test", which I hear as "I don't understand why I need to write higher quality code and catch issues earlier when they can be fixed more rapidly and where it's cheaper to do so". I find that if you can set up a system to show unit tests being run, coverage information and actions being taken when issues are found then there tends to be more corporate buy-in. We had a senior manager here who wanted screens up so he could see the information each time he walked by the different teams.
Eagles may soar, but weasels don't get sucked into jet engines
-
Sereiously, I've seen VERY few unit tests where I didn't think: There's no way this is EVER going to fail! And then I wonder: Why did you (not me, but the programmer who wrote it) waste your time writing the test (and running it over and over again)? :confused: And why do managers insist that you write tests for every tiny detail that can't possibly go wrong? I'm not against unit testing as such, but I think it's WAY overrated. To be fair, I HAVE seen tests that were actually were nice to have (and written one or two myself) - but mostly waste of time in my opinion! :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the timeAnd who tests the unit test
We're philosophical about power outages here. A.C. come, A.C. go.
-
I've worked in numerous roles in IT so this method works for me. I'm destructive to software. I started out in support at a medium sized place with a smaller software group (25 people). The dev sat a row over. I asked him once, "Hey, this customer makes a great point. Why does this do that?" GreyBeard: Shut up! I then moved into QA. Once the devs were having a design session that leaked into the hallways. Another support guy -- who really used the software to help users -- said, "Hey, I think you're forgetting about X." GrayBeard Devs: Shut up! We will cross the bridge when we get to it. You are wrong about that design element. Support Guy: Wait guys. Seriously. Think about-- GrayBeards: Shut it! Support guy: :confused: 6 months later after new software release with this new design... Support guy: <hangs up phone> Remember that design element I mentioned? Well, the customer just fell into that hole. Graybeards: Shut! Up! Support Guy: I'll enter it as a bug in the system. :rolleyes: Later in my QA career, devs would say, "hey, monkey, go test and we'll give you a banana..." I entered a 10,000 character URL and hit post. It crashed Oracle instance!! Hahaha... (no, you cannot do that now, but you could in IE 2.x,3.x) Enter steps into bug tracker and submit. Heh, heh, heh. There's your treat, dev. Dev: What do you want me to do with that bug you entered. me: I don't care. It kills the Oracle instance and your app dies so it doesn't mean anything to me. Ignore it if you like. If you feel confident to go to prod with that. Dev: <sulks off into another direction. > For the win!!
raddevus wrote:
Dev: What do you want me to do with that bug you entered.
I would have start a fire after that question.
I do not fear of failure. I fear of giving up out of frustration.
-
A quote from a former colleague: "Stop finding bugs, that's the clients (= user) job" And yes she was serious, and no that wasn't even my worst experience dealing with her.
Tom
You should not have ask her out.
I do not fear of failure. I fear of giving up out of frustration.
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
I must be so freakin' old. It would never occur to me to give someone something attributable to me without making sure it works. I've wasted so much time. If there's a problem then someone would probably tell me if it were really important. So much time wasted.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
OriginalGriff wrote:
used by your bank, your car, your life support machine
User Acceptance Testing?
WiganLatics wrote:
User Acceptance Testing?
That's how things are done. Just consider the current failure rates for HDD's. They're cheap and they'll replace it. Much cheaper for them then paying someone to make sure they (at least) work when they leave the factory.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
If for nothing else, I find unit tests the quickest way to debug new features and check they actually work. Far quicker than manually clicking through UI controls until you get to your new feature / bug fix. Although I have worked with devs who pass on to QA without even running through the code themselves . .
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
Sometimes it's better that the original developer doesn't write the (automated) tests. Sometimes all that means is that the developers misconception of the requirements gets written twice. OTOH, a test script that runs through all the expected interactions is useful, and yes, the basic test data for those interactions. That said, most place I've worked don't have dedicated testers - just user acceptance testers.
-
I just started reading a very interesting book (Developer Testing: Building Quality Into Software (amazon)[^]) and the intro reminded me of a time I had a similar exchange with a dev.
Jeff Langr said:
One developer, however, quit two days later without saying a word to me. I was told that he said something to the effect that “I’m never going to write a test, that’s not my job as a programmer.” I was initially concerned that I’d been too eager (though I’d never insisted on anything, just attempted to educate). I no longer felt guilty after seeing the absolute nightmare that was his code, though.
Back in the day when I was in QA, I approached a developer about a recent change he'd made to the code. Me: "Hey, can I get the data you used to test your changes?" Dev: "What data?" Me: "Well, you know. The data you used to test after you made the changes and did the build? I figure I can use it as a starting place for data I can send through to insure the changes work." Dev: "Oh. I didn't run any tests. That's for you to do. I built the thing and put it out there. Now, go test it." Me: :wtf: :~
Sure, programmers should do some unit and module testing. But too often, programmers test their software when used the way it is supposed to be used. It is not like the "five year old test": Place a five year old by the keyboard and tell him "You just do what you want to do, and you'll have another ice cream cone every time you make the program crash". Real testing must be done by "misbehaved" testers. People who are paid by the number of bugs they find, not by the number of code lines they write. 30 years ago, before software testing was an established discipline, we used student summer interns: If they stayed with us for more than half a year, they learned the programmer's way of thinking, using the software the intended way, and the number of bugs detected gradually. Every summer we got a new group of students, unfamiliar with the software, and the detected bugs count rose sharply. Nowadays, we have a separate testing team - full time, but then: They are educated in the discipline of testing. Their profession is to identify corner cases, defining stress testing, managing bugs databases (programmer solution: add a comment in the code: "To do: Fix this bug when time allows" :-)), and rating the severeness of the bugs, making sure that the all the serious bugs are really fixed before the product is released. Besides: Their job is to bark at the programmers when bugs are found that should never have been made at all. Programmers don't like to be barked at. So they do proper unit and module tests just as much to quiet down the testers as to satisfy the customers :-) I think the t-shirt I am wearing today is somehow related to my own program/bug-writing experience - it says "Experience - the ability to recognize a mistake when you repeat it". That certainly describes my experience when my code goes to the testers.
-
I fit into option one: The ego will not allow me to deliver crappy code - the QA (users) are anally retentive, pedants who delight in sending back a bug report. Laziness - I loathe writing the same code twice.
Never underestimate the power of human stupidity RAH
-
I must be so freakin' old. It would never occur to me to give someone something attributable to me without making sure it works. I've wasted so much time. If there's a problem then someone would probably tell me if it were really important. So much time wasted.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
W∴ Balboos wrote:
It would never occur to me to give someone something attributable to me without making sure it works.
That's exactly how I feel about it. It was literally like listening to a crazy person when he said he hadn't even shot one element of data through the thing. Crazy! And, you're not old, you have a fine attention to The Craft of Software Development. (Also, I'm old too.) :laugh: