Discussions

News: When Finding And Fixing Bugs Is More Intensive Than Developing The Application

Bookmark and Share Get thread feed

  1. When Finding And Fixing Bugs Is More Intensive Than Developing The Application (4 messages)


    How many times have you had the following conversation, or something like it:

    Tester A: "Look at that bug; it's pretty straightforward that the functionality doesn't match our test case. Why can't somebody do a quick smoke test before checking in the code?"

    Developer A: "Well, yes I agree that's a bug. We just ran out of time; the schedule is tough for us, we did those most important verifications before we checked the code in; we made sure all Unit Tests passed, we made sure that the build is solid, and we wrote as many automated test scripts as possible but we didn't have enough time to cover that functionality. It's great that the testing team found that bug, we can fix it later."

    Tester B (Test Lead): "But that costs a lot, we spent a whole day to manually execute all the functional test cases and found at least 5 obvious bugs. They could be identified even without looking at the test cases. Now we need another day for regression test after your team gets them fixed."

    Developer B (Develop Lead): "But that's the reality, isn't it? It's normal to have bugs. We cannot avoid delivering bugs together with the code. That's why we have a testing team."

    Ethan Huang tackles the topic of spending too much time finding and fixing bugs, and not enough time writing good code from the beginning. Does going beyond Test Driven Design to Test Driven Requirement help solve the problem? Find in this blog about Creating Bugs vs. Fixing Bugs.




    Reply to this

    Threaded Messages (4)

  2. LOL[ Go to top ]

    Yes I have heard that many times and even wondered the term "smoke test".  What we did is that we let other team of developers test ours and we in theirs.  Of course at the same time, we were all wondering.."why are we doing QA job?".
    Reply to this Reply to original

  3. But you ARE QA [ Go to top ]

    That's the thing. The people that hired you are probably thinking 'why do all of those QA people keep referring to themselves as developers???'
    Reply to this Reply to original

  4. Needed Articles[ Go to top ]

    I would like to take a moment and appreciate Cameron McKenzie
    for posting this article. The Serverside.com or Infoq.com should put a category related to practical things and post those over there. Things should be learned from the realtime world rather than thinking theoretically.

    Thanks Cameron once again.
    Reply to this Reply to original

  5. True that QA does a lot of unit testing[ Go to top ]

    I've found that where I work the QA team does the unit testing as well as the real QA (functional) testing. Developers say they never have time to write unit tests. So, QA ends up doing the unit testing.
    Reply to this Reply to original