• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to create less bugs in the development process?

 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

Here is the problem: We are maintaining a software application and our customers are unhappy with it because there are too many bugs in our weekly releases. There are change requests and bug fixes every week.

These change requests and bug fixes actually created more bugs in our application.

Here is our development process: Developers are given a few tasks(change or bug fix) per week. Developer codes, tests himself and commit to subversion. The deployment team packages the war and deploys it to the staging environment.

Customer tests it and is unhappy.

From my point of view, there are problems in this process:

1) Developer tests the part where he made changes himself and commits it.
2) Our team consists of 10 developers and there is no testing of combined code.
3) The test server is not utilized at all before the war is sent to the staging server for the customer to test.

My suggestion to the management:

1) Since Friday is the day the customer tests it, our company developers could commit all code by Wednesday evening.
2) Thursday morning will be spent on testing on our testing server. Developers test other developers' code. There could be bug fixes and commits again.
3) Thursday afternoon is spent on testing again and bug fixes and commits.
4) This process is repeated until severe bugs are resolved.

Hopefully this process will reduce the number of bugs.

Does anyone see problems with this process? Any suggestions? Better ideas for the process?

Thanks.
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First the number of environments is not enough. There can be up to 5 environments: development, system integration (SIT), user acceptance (UAT), staging (pre-production), production.

If end users are using the staging environment for "testing", which is wrong in my opinion.

Developers enhance/fix bugs locally, commit to source control. This version should deploy to the SIT environment for testing. Besides testing the changed/enhanced code, regression testing (testing other functions) should also be done. This way new stuff won't break old stuff.

Once SIT testing is ok then you deploy the app to UAT for end users to test. At this stage, there shouldn't be major bugs (of course unless you didn't do it properly not following user requirements).

Before production, the app can be deployed to a staging environment (which architecture/resources should be identical to production) for further (performance/stress) testing.
Users who doing the UAT should sign off the testing results before production. If there is no sign-off, no production deploy.

By the way, weekly deployment is somewhat too demanding/aggressive. If the development/testing is done properly, deployment should have been kept to a minimum.

As the saying goes, don't fix it unless it's broken.
 
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lost of good advice from KT.

Following that advice should help to cut down on the bug reports from users, which will eventually reduce the work on each iteration (once you've worked through your backlog).

I would suggest you try to deploy less frequently for a while e.g. every 2 weeks, to give you time to implement the extra testing and clear the most important bugs. Once the testing process etc is in place and working well, you might be able to shift back to weekly deployments, but you'd need to be sure your team can maintain this frequency without sacrificing quality, or you'll just end up getting into trouble again.

FWIW I've seen places where they deployed changes and fixes to production several times a day (scary stuff!) but only because the team had a really slick and highly automated testing and deployment process with excellent coverage. Most of us would probably not want to jump straight into that world without a lot of preparation!
 
Alan Blass
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all your replies.
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Trust there good test coverage as well right?

Maybe more automated testing could help. Maybe more Continous Integration server running the tests would help in on of the earlier environments mentioned.
 
Ranch Hand
Posts: 310
18
MS IE Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Developers testing their own code is not effective. In general, developers testing their own software is not effective. What I found to be the most effective is the hallway-testing technique. In this technique, you pick random people (ie. from the hallway) and ask them to look over your software. People that are not related to your project will find things that you will not see yourself. Those people look at the project differently and will use it differently, thus making such testing effective. If you can afford to bring a dedicated tester to your team it would be great as well. You can argument with the management that the cost of the tester can compensate the costs of constantly having to deal with bugs.

I agree with K. Tsang about the environments. Especially you should have a SIT environment.

Another thing is unit testing. Are you using them?

Your new suggestion sounds good. Consider to extend the iteration from one week to two. By taking one day off completely for testing and bug fixing, there is less time for implementing new features. That will create additional pressure that can lead to even more produced bugs.

There is one book you should read, it is about agile planning. My planning and project management skills got greatly improved after the lecture. Mike Cohn - Agile Estimating and Planning
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Adam Scheller wrote:Developers testing their own code is not effective.



There's an old saying in medicine that a doctor who treats himself has an ass for a physician and a fool for a patient. I have long maintained the same can be said for programmers who test their own code.

The problem is that the programmer "knows" where the problems are, therefore the code doesn't get tested in a manner consistent with real-world usage, it gets tested according to where the programmer "knows" it needs testing. Which like premature optimizations, is often wrong. Besides, some of us, at least, have personalties that do our design by inspired leaping around, and testing is best done by people who have the patience to plod through the same stuff over and over and not jump over the boring parts. There's a need for both types.

Automated testing (and regression testing) frameworks can help a lot. So can test-driven design. What helps even more is not having management with a "Just Git 'Er Dun!" attitude. You can get bogged down in getting everything right to the point where nothing gets done at all, but if you just rush mindlessly to the finish line, you're not going to get quality results.

Code reviews can help, as long as they're done in an analytical sense, and not - as is too often the case - as a weapon against the developer.

Get someone to analyze the bug reports and pin down where the problem areas are, then concentrate on getting them cleaned up.

Finally, consider the environment. If you're operating in Agile mode, one of Agile's basic tenets is that parts of the system will be incomplete/defective because you're developing incrementally and feeding back results to modify the future goals. So that might require educating users on expectations.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic