We have discussed last week about total number of bug count and how can we reduce bugs. It was an open discussion, and I really enjoyed people's comments.
Few major reasons described by people are:
- UI Issues
- Legacy code issue/Existing functionality issues
- KLOC rule/BUGS per 1000 LOC
- Bug logging categorization ( one bug but reported many times )
- Strict timeline
- Lack of proper unit testing/integration testing cycle
- Lack of impact area analysis
Before discussing on these points in detail let's have a look on what is actual meaning of "so many bugs".
One hair in soup is too many and in head too few. It all depends. There is no context to judge it. Firefox's each release contains about 1000 open bugs, but it is considered to be quite usable.
Perception of the quality of a product can vary greatly between the programmer and other user. Developers and users/business people have very different views of what bugs mean. For a developer, every bug found and fixed increases the developer's confidence in the code, since it is getting more robust. For a user, every bug found (even if fixed) decreases their confidence.
If you are judging only by the bug count found in testing, then that is unfortunate.
I have seen may products which are judged on the basis of user's experience and it plays a big role however there were no bugs are reported from QA end.
Few products were reported as buggy (from product due to complexity of product) but they are generating good percentage amount of revenue and running smoothly however no bugs are reported from QA end.
Sometimes End user reported few issues which are basically marked as missing features most of times and in few cases it was closed due to wrong manipulation of data analysis.
In few cases such bugs were closed by providing data in Excel to client or closed by discussion with sales person and clients.
UI Issues: I believe that HTML developer provide W3C validated HTML code and HTML also verified via QA Team. Developer when integrate HTML, code will become buggy.
There are many reasons for UI issues.
Developer avoid cross browser testing with all versions of browses.(see browser plus OS matrix)
Sometimes developers write own front-end logic which is already written and cross checked but newly written code fails as per standard that follow through out website.
KLOC rule/BUGS per 1000 LOC reason is not fit in our case(website development) because if we look into codebase and nature of bugs 60-80 % of code lines were captured by HTML of code associated with front-end page rendering logic.
Another point is in house testing is not also so much focusing on security testing, environmental issues or load and performance testing.
Some times we have contributed more by removing code than adding ;-)
In our last release we spent good amount of time to discover that code required pdo_mysql extension and few code APIs are behaving unexpected results in 64 bit machine.
Here bootstrap plays a powerful role. https://github.com/twitter/bootstrap (Bootstrap is a sleek, intuitive, and powerful front-end framework for faster and easier web development.)
Lets start look seriously at front-end part, try to avoiding unmoduler JS and HTML codebase.
Legacy code issue/Existing functionality issues :
Always Fix bugs before write new code and mark such bugs with a new tag in bugzilla.
see here http://www.joelonsoftware.com/articles/fog0000000043.html
Lack of impact area analysis:
It might be that the requirements weren't clear or correct, and that was reflected in the code and picked up by the testers.
Failure mode and effects analysis should be a part of designing.
Some how we can say we should follow more tighter software development processes. During writing code, always think in mind that we are building software of medical or military environment.
Other important areas are Static code checking, peer code reviews, unit testing, component testing, system tests. It's easy to get a couple of hundred lines of code per day but try to get a couple of hundred quality lines of code per day and it's not so easy.
No comments:
Post a Comment