|
Good discussion and viewpoint.
patbob wrote: I don't consider myself the owner of any of the code I write.
I have a conflict with this but I lean toward ownershipo because I have created numerous projects that I am the requirements gatherer, system analyst, developer, tester and deployer. I own it 100%.
You can see the app I created this way on multiple platforms:
Swift (iOS) app in app store : CYaPass on the App Store[^]
Android app in Google Play ==> CYaPass in Google Play[^]
As a windows winform app: ==> C'YaPass: Forget All Your Passwords | Get C'YaPass[^]
and even as a JavaScript, HTML5, Canvas app -- no install required, try it in your browser:
C'YaPass: Forget All Your Passwords | WebApp[^]
So my ownership ideas come from that. And I know dev's egos go crazy at times, but without ownership people just don't give a crap how things turn out generally. Just an opinion of course.
patbob wrote: s devs, its our job to not leave parts of the code untested. Period.
I know. You can't do everything. Except, when you have to. 
|
|
|
|
|
At my last position, we were responsible for making sure the code compiled, ran without exceptions, and updated the UI as expected. At that point, we handed it over to Q/A who had test cases to run the code against. We had to do this because most of the changes were UI changes, and you can't really automate them. All tests were run with a video capture so we could re-run the videos to see what the user did to make the code fault. It worked pretty well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Same with me on my last pos. And, the QA team was in India ( Don't ask me I didn't decide that) so after a check in we had to wait 24 hours for a testing cycle.
I once knew a guy who sat next to me, and his idea of testing was to open a DOS Command Prompt, CD to the folder the app was in, and run the EXE, which then opened the app in Windows (It was a Windows Forms app). "It runs, so it's OK"
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: "It runs, so it's OK"
Which is only slightly more useful than, "It compiles. Ship it!"
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Interesting. I have always eaten my own dogfood wherever practical and try to get everyone around me to do the same. Most larger shops have had decent QA but there is no point in passing untested code to QA in the hope that it'll scrape by - it won't.
I really don't understand the notion of cobbling code to together and passing it up the chain without, at the very least, checking to make sure it does something along the lines of what was required.
[EDIT} Perhaps it's because I come from an engineering background. You would not even consider letting a creation out of the shop without thorough testing. Perhaps that's what needs to be ingrained into the kiddies at uni.
modified 5-Jan-17 11:17am.
|
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
|
Actually, that's a really great personality description of most devs, I hope.
I agree 100%.
And you've raised an important point about some testers who have a chip on their shoulder and just bug report on the most ridiculous details. Great stuff.
|
|
|
|
|
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)?
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! 
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 time
|
|
|
|
|
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
modified 5-Jan-17 14:44pm.
|
|
|
|
|
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 completely agree with the comment about regression testing.
You have to at least run the code to make sure it works right? Why not frame that test in a way that can be run again? If you have a decent framework set up and are familiar with how to use it then it won't take much longer anyway.
Then sometime down the road you have to modify it (internal enhancement for performance or change in functionality) and it gives you so much more confidence to make the change knowing that you had good coverage tests from before.
|
|
|
|
|
And who tests the unit test
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
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 f***ing 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:
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. 
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.
|
|
|
|
|
These types are dangerous. Because of them crashing rockets and die people 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Yeah, it's quite terrible that people really do work like that.
Too bad they can't treat their dev like a craft.
|
|
|
|
|
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
|
|
|
|
|
Yeah, it's a sickness.
A person like that really shouldn't be a dev...well, really isn't a dev.
|
|
|
|
|
You should not have ask her out.
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
