I have to say that I am speaking from a technical view point. This is something I have observed recently. We're in the maintenance phase of our project and our developers have quite a number of defects to fix. In the first place, I seriously dislike having defects under my name :) But thats just me I guess. I like to test out my code as much as I can so that there are very few defects in my name. I guess its a pride thing.
So coming back to the team, I've noticed that most developers tend to fix the defect stated in the defect tracking system (ok, nothings wrong with that) and they re-test the fix for the specified scenario only. So what happens if the fix breaks something else? They wait around for our QA friends to log another defect, and the cycle continues. Why cant they test out all scenarios and be personally satisfied that - yea! I've done a good job.
Potential reasons as to why this happens,
1. They are just too busy and are overloaded that they don't have time to test every scenario out. - Ok acceptable I guess... Its the management's fault in not managing their time better and creating an environment such that they can do the best they can.
2. Poor attitude - Ok I've fixed that defect. I'm done for now, I'm outta here!
How do we correct this?
- Ensure that defect fixes are not rushed! This is very important. If the team are pressurized into fixing n number of defects per day, then ofcourse we're going to wind up with this situation.
- Maybe ensure that we have automated test execution setup. So that we execute a sufficient amount of tests (junit and selenium tests) that ensure that the project is in a stable state. So once the developer checks in the code, the automated tests run and we're ensured that at least 60_75% test coverage has been executed. This will simplify the developers job too -> facilitates the environment being more stable-> simplifies the QA's job where they need to focus on complex scenario's and edge cases. Win-win situation.
No comments:
Post a Comment