Simple Wikipedia definition of Bug is: “A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.”
Other definitions can be:
An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction.
An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction.
or
A fault in a program, which causes the program to perform in an unintended or unanticipated manner.
A fault in a program, which causes the program to perform in an unintended or unanticipated manner.
Lastly the general definition of bug is: “failure to conform to specifications”.
If you want to detect and resolve the defect in early development stage, defect tracking and software development phases should start simultaneously.
We will discuss more on Writing effective bug report in another article. Let’s concentrate here on bug/defect life cycle.
What are the reasons of defects
1. Human factor: It is because human beings develop software. It is often said that “to err is human, to forgive divine”. Human beings are not perfect. They are prone to make mistakes. As human beings develop software, it would be foolish to expect the software to be perfect and without any defects in it! Hence there are errors in software. Ironically, we are yet to discover any other non-human agent who could develop software any better than human beings. So we continue to rely on the human intelligence to develop software thus allowing chances of errors in it.
2. Communication failure: Another common reason for software defects can be miscommunication, lack of communication or erroneous communication during software development! The communication failure can happen at different levels (requirement gathering stage, requirement interpretation/documentation stage, requirement-to-implementation translation stage etc.). Imagine a case where the requirements are vague or incomplete. This could lead to a situation where the programmers would have to deal with problems that are not clearly understood, thus leading to errors. Another scenario of problem with communication may arise when a programmer tries to modify code developed by another programmer.
3. Unrealistic development timeframe: Let’s face it. More often than not software are developed under crazy release schedules, with limited/insufficient resources and with unrealistic project deadlines. So it is probable that compromises are made in requirement/design to meet delivery schedules. Sometimes the programmers are not given enough time to design, develop or test their code before handing it over to the testing team. Late design changes can require last minute code changes, which are likely to introduce errors.
4. Poor design logic: In this era of complex software systems development, sometimes the software is so complicated that it requires some level of R&D and brainstorming to reach a reliable solution. Lack of patience and an urge to complete it as quickly as possible may lead to errors. Misapplication of technology (components, products, techniques), desire/temptation to use the easiest way to implement solution, lack of proper understanding of the technical feasibility before designing the architecture all can invite errors. Unfortunately, it is not that the people are not smart; it is just that they often don't-have-time/are-not-allowed to think!
5. Poor coding practices: Sometimes errors are slipped into the code due to simply bad coding. Bad coding practices such as inefficient or missing error/exception handling, lack of proper validations (datatypes, field ranges, boundary conditions, memory overflows etc.) may lead to introduction of errors in the code. In addition to this some programmers might be working with poor tools, faulty compilers, debuggers, profilers, validators etc. making it almost inevitable to invite errors and making it too difficult to debug them!
6. Lack of version control: If as a tester you keep encountering lots of occasion of regression bugs that keep showing up at regular intervals, then it is about time to check the version control system (if at all any). Concurrent version systems help in keeping track of all work and all changes in a set of code base. Complete lack of a version control system to safeguard the frequently changing code base is a sure fire way to get lots of regression errors. Even if a version control system (e.g. Visual SourceSafe) is in place, errors might still slip into the final builds if the programmers fail to make sure that the most recent version of each module are linked when a new version is being built to be tested.
7. Buggy third-party tools: Quite often during software development we require many third-party tools, which in turn are software and may contain some bugs in them. These tools could be tools that aid in the programming (e.g. class libraries, shared DLLs, compilers, HTML editors, debuggers etc.) or some third-party shrink-wrapped plug-ins/add-ons used to save time (like a shopping cart plug-in, a map navigation API, a third party client for 24X7 tech support etc.). A bug in such tools may in turn cause bugs in the software that is being developed.
8. Lack of skilled testing: No tester would want to accept it but let’s face it; poor testing do take place across organizations. There can be shortcomings in the testing process that are followed. Lack of seriousness for testing, scarcity of skilled testing, testing activity conducted without much importance given to it etc. continues to remain major threats to the craft of software testing. Give your team some time to introspect and I won’t be too surprised if you find it in your own testing team! While you might argue that poor testing do not *introduce errors* in software, actually they do! Poor testing do leave the software in a buggy state. Moreover, in this era of agile software development poor unit tests (e.g. in TDD) may result in poor coding and hence escalate the risk of errors.
9. Last minute changes: Changes that are made to requirement, infrastructure, tools, platform can be dangerous, especially if are being made at the 11th hours of a project release. Actions like database migration, making your software compatible across a variety of OS/browsers can be complex things and if done in a hurry due to a last minute change in the requirement may cause errors in the application. These kind of late changes may result in last minute code changes, which are likely to introduce errors.
Considering that this post has been talking about possible cause of errors, defects and bugs in software, did you notice any error in this post! Did you notice that I have listed out only 9 reasons as against the promised 10 in the blog post title? Well, it is a deliberate error. Why don't you come up with the 10th (may be 11th, 12th... as well) reason why there are defects in software? Feel free to let me (and other readers) hear your reason(s) by commenting below.
2. Communication failure: Another common reason for software defects can be miscommunication, lack of communication or erroneous communication during software development! The communication failure can happen at different levels (requirement gathering stage, requirement interpretation/documentation stage, requirement-to-implementation translation stage etc.). Imagine a case where the requirements are vague or incomplete. This could lead to a situation where the programmers would have to deal with problems that are not clearly understood, thus leading to errors. Another scenario of problem with communication may arise when a programmer tries to modify code developed by another programmer.
3. Unrealistic development timeframe: Let’s face it. More often than not software are developed under crazy release schedules, with limited/insufficient resources and with unrealistic project deadlines. So it is probable that compromises are made in requirement/design to meet delivery schedules. Sometimes the programmers are not given enough time to design, develop or test their code before handing it over to the testing team. Late design changes can require last minute code changes, which are likely to introduce errors.
4. Poor design logic: In this era of complex software systems development, sometimes the software is so complicated that it requires some level of R&D and brainstorming to reach a reliable solution. Lack of patience and an urge to complete it as quickly as possible may lead to errors. Misapplication of technology (components, products, techniques), desire/temptation to use the easiest way to implement solution, lack of proper understanding of the technical feasibility before designing the architecture all can invite errors. Unfortunately, it is not that the people are not smart; it is just that they often don't-have-time/are-not-allowed to think!
5. Poor coding practices: Sometimes errors are slipped into the code due to simply bad coding. Bad coding practices such as inefficient or missing error/exception handling, lack of proper validations (datatypes, field ranges, boundary conditions, memory overflows etc.) may lead to introduction of errors in the code. In addition to this some programmers might be working with poor tools, faulty compilers, debuggers, profilers, validators etc. making it almost inevitable to invite errors and making it too difficult to debug them!
6. Lack of version control: If as a tester you keep encountering lots of occasion of regression bugs that keep showing up at regular intervals, then it is about time to check the version control system (if at all any). Concurrent version systems help in keeping track of all work and all changes in a set of code base. Complete lack of a version control system to safeguard the frequently changing code base is a sure fire way to get lots of regression errors. Even if a version control system (e.g. Visual SourceSafe) is in place, errors might still slip into the final builds if the programmers fail to make sure that the most recent version of each module are linked when a new version is being built to be tested.
7. Buggy third-party tools: Quite often during software development we require many third-party tools, which in turn are software and may contain some bugs in them. These tools could be tools that aid in the programming (e.g. class libraries, shared DLLs, compilers, HTML editors, debuggers etc.) or some third-party shrink-wrapped plug-ins/add-ons used to save time (like a shopping cart plug-in, a map navigation API, a third party client for 24X7 tech support etc.). A bug in such tools may in turn cause bugs in the software that is being developed.
8. Lack of skilled testing: No tester would want to accept it but let’s face it; poor testing do take place across organizations. There can be shortcomings in the testing process that are followed. Lack of seriousness for testing, scarcity of skilled testing, testing activity conducted without much importance given to it etc. continues to remain major threats to the craft of software testing. Give your team some time to introspect and I won’t be too surprised if you find it in your own testing team! While you might argue that poor testing do not *introduce errors* in software, actually they do! Poor testing do leave the software in a buggy state. Moreover, in this era of agile software development poor unit tests (e.g. in TDD) may result in poor coding and hence escalate the risk of errors.
9. Last minute changes: Changes that are made to requirement, infrastructure, tools, platform can be dangerous, especially if are being made at the 11th hours of a project release. Actions like database migration, making your software compatible across a variety of OS/browsers can be complex things and if done in a hurry due to a last minute change in the requirement may cause errors in the application. These kind of late changes may result in last minute code changes, which are likely to introduce errors.
Considering that this post has been talking about possible cause of errors, defects and bugs in software, did you notice any error in this post! Did you notice that I have listed out only 9 reasons as against the promised 10 in the blog post title? Well, it is a deliberate error. Why don't you come up with the 10th (may be 11th, 12th... as well) reason why there are defects in software? Feel free to let me (and other readers) hear your reason(s) by commenting below.
Leave a comment