January 13, 2015 at 2:14 am
The problem I always faced when testing my own code, particularly when I was a software developer, was that I tended to not test things the way users would test them. I could pretty much guarantee that a user, when asked to test some new functionality, would be able to break it pretty quickly, particularly when the testing was at the beginning of a test iteration. Once I got over the annoyance of my code being found wanting and my fallibility laid bare, I actually found this a very useful process.
My fear is that placing more testing in the hands of developers will lead to the same results - a problem only arises when the software goes live rather than having it caught earlier when a user has managed to break it within minutes if not seconds.
Gordon.
January 13, 2015 at 3:31 am
Having worked in software development for 29 years, I understand what Gordon is saying about testing with "blinders" and not always recognizing how a user may blunder through a piece of software.
There does seem to be a disturbing trend, however. The editorial alluded to it, and I've seen it in the software company where I work - that developers these days seems to concentrate on pushing the code out, but maintain little responsibility for making sure that the code is right (other than within it's immediate realm) within the context of the application. And when it's not right, well, it's up to Q.A. to catch it, or Support to triage it, or some other team to fix the data errors caused by the problem.
I get that it's sometimes hard to see the forest for the trees, and a developer instructed to work on a specific module with specific requirements may not understand the impacts further down the road of making a certain change. (This is where the unit testing can help.)
But developers should be involved in testing and fixing issues caused by their code. A) It provides an opportunity for learning new things about the software upon which they are working, and b) it may give them some understanding of what they are putting others through in trying to resolve the problems. If the developer has any sense of ownership and responsibility, this will make them a better developer.
January 13, 2015 at 4:30 am
It's not simply a developer creating a bug. It's the whole process starting from the people who gather requirements to the final testers that needs to be overhauled.
Most of the bugs I see introduced are a result of either bad requirements, unrealistic deadlines, unrealistic estimates, or not understanding how the process or functionality really works. Usually it's a combo of a few of those things.
TDD is great, but the code base has to be designed to handle it. Most of these legacy systems we "upgraded" can't fully support unit testing. So we take a 'some is better than none' approach. But it means not everything gets fully tested by until tests.
There's more to it than simply making a developer fix his/her own bugs. That only helps for the simple, stupid errors newbies make.
January 13, 2015 at 5:49 am
"Most of the bugs I see introduced are a result of either bad requirements, unrealistic deadlines, unrealistic estimates, or not understanding how the process or functionality really works. Usually it's a combo of a few of those things."
I have been in software development for 20+ years now and that statement is exactly right!
January 13, 2015 at 6:45 am
I spent 42 years as a developer in various languages and as a DBA heavily involved in producing SQL code. Due to my own testing as I worked, I rarely had any bugs discovered by QC testing. If developers take pride in their product, they WILL get the testing done, if they have the true understanding of the language and the assignment. I also did lots of breaking down and testing pieces of code for others in order to get needed performance and reliability. Good developers will not depend on someone else finding their bugs.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 13, 2015 at 7:44 am
Steve,
I have been creating unit tests for database code for many years now, using DBFit and some early techniques gleaned from the folks at SQLity. Having developed using TDD and without, I can say without a doubt using TDD will make your code better now and easier to maintain later.
Aaron Mertes
January 13, 2015 at 7:51 am
So none of the blame falls at the feet of the developer it seems....
January 13, 2015 at 8:06 am
skeleton567 (1/13/2015)
[font="Arial Black"]Good [/font]developers will not depend on someone else finding their bugs.
+1000. Amen to that!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 13, 2015 at 8:40 am
gordon.feeney (1/13/2015)
The problem I always faced when testing my own code, particularly when I was a software developer, was that I tended to not test things the way users would test them. I could pretty much guarantee that a user, when asked to test some new functionality, would be able to break it pretty quickly, particularly when the testing was at the beginning of a test iteration. Once I got over the annoyance of my code being found wanting and my fallibility laid bare, I actually found this a very useful process.My fear is that placing more testing in the hands of developers will lead to the same results - a problem only arises when the software goes live rather than having it caught earlier when a user has managed to break it within minutes if not seconds.
Gordon.
The issue here is that you're not testing correctly then. If you find users breaking things in different ways, write tests (later) to catch those issues.
January 13, 2015 at 8:44 am
I agree with Steve. You will make judgement errors on how the system will be used not only at the time of development, but after many interactions users will come up with ways to use the system that nobody could have predicted. The good news is, you already have a suite of tests and seed data that can you use to quickly add the necessary tests, drop the unnecessary ones and have those tests as an aid when communicating with analyst/customer to confirm you're understanding of what is the logic supposed to do exactly.
January 13, 2015 at 8:59 am
I think it goes back to who is responsible. I was on a team of about 10 progs and there was continual efforts to lay blame. Finally it was decided that the programmers were always are 100% responsible. It was amazing how fast the bug counts were reduced and the output didn't go down. The other thing that helped our bug count go down was the semi-adversarial relationship we had with the QA dept. Everyone wanted to avoid them (professionally). It worked well for us.
January 13, 2015 at 9:01 am
That's really interesting, though an us-verses-them mentality between developers and QA (though natural) will most likely lead to tension and possibly worse designs.
January 13, 2015 at 9:20 am
... move some of the testing burden into the development process. While this sounds like a bad idea, overburdening developers that already struggle to meet deadlines, I'd note that part of the burden of development is fixing the mistakes they make.
Developers should pursue quality as much as anyone else. But while we're busy pointing fingers at the developers, let's also point them right back at the people managing them, who often set ridiculous deadlines and galloping (let alone creeping) scopes.
January 13, 2015 at 9:36 am
It seems there is never enough time to properly test software after it is complete.
There in lies a significant part of the problem. To define something as "complete" before it is properly debugged and tested is designing and developing for an expected level of failure. If we define complete as properly tested and fixed before it is complete, it might get better.
In this day and age we have two scales or expectation. As the article states users expect the software to work without failure. Companies expect to make a profit from the services they are supplying. To some, just good enough is great. To others just good enough for the developer is not good enough for the user community.
If we defined "complete" as partly tested in the airlines business, you would be buying a chance to get to your destination not a ticket.
M.
Not all gray hairs are Dinosaurs!
Viewing 15 posts - 1 through 15 (of 33 total)
You must be logged in to reply to this topic. Login to reply