Here is a question that has made many testers wonder on several occasions - “Why are there bugs/defects in the software? Why/How do errors creep into the software and make it buggy?” I realize the paradoxical nature of this question. i.e. If there won’t be any errors in software then there won’t be any need of testing. But again, as long as software development exists as a field of business, there would be errors in them. To me, if something is *bug free* it translates as: it is either too trivial or non-existent! The increasing complexity of software would make sure that there are defects in them. But the question remains: what are those factors that cause defects in software? Well, here are 10 reasons (not in any particular order) why I think bugs creep into the software that we develop/test:
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.
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.
Happy Testing…
I think all reasons other than the #1 is due to human factors. It is just that they manifest in different ways - unrealistic development time frame is due to some human thiunking too optimistically or Poor coding practices is a human problem. Communication is a human, more preciously social and cultural (Very few would want to part of poor communication on purpose - much of that is due to culture, education etc)
ReplyDeleteSo I can think of squeezing the whole post in one reason - "human". Also I see that there are lots of redundancy in the reasons quoted here ... while there might be (unique) 2-3 reasons only ... you appear you streched that bit to "make up" 9-10 resons ...
There is one reason that I do not quite agree "lack of skilled testing". Are saying that this would introduce or create bugs in software? Testers do not create bugs, best they can do is to identify them in most basic form and help developers to eradicate them. So I dont think bringing testing function (not human testers) as a reason for having bugs in the software.
I vaguely remember you identifying yourself as follower of context driven testing community ... (is that right?) ... your views about "testing (or lack of it)" as a reason for software bugs and your comments about TDD - make me surprised. A context driven tester would not say these things ...
You might want to clarify these ... and write a new post ...
Shrini
@ Shrini,
ReplyDeleteThanks for your comment. I understand that all of these reasons can be traced back to a *human being*. But again, the Software Development process itself is so human oriented that you take any aspect of it randomly and I am not sure if I would be too surprised if you can't link it to *human factor*! But does this mean we should stop thinking beyond *human factor*? Honestly, I don't see anything wrong in trying to identify more specific cause to any given aspect of testing (or whatever related to it).
Talking about squeezing the whole post into a single reason (human), I don't see any problem with it as long as you can cover all the possible reasons in a single point! While there is a human being behind most of those reasons, if we would look closely, those *human beings* share different roles and responsibilities (programmers, analysts, technical writers, testers, managers) and contribute to the defects under different contexts. That was the reason why I chose to try and separate them under different points instead of just labeling them under a generic *human* tag!
You said, testers don't create bugs. As far as I can remember I had deliberately chosen to use *introduce* instead of *create*! As you can see there is a subtle yet striking difference between them. Let's say as a tester I miss out to identify a defect in the application that I test and as a result this defect managed to slip into production. Wasn't it ME because of whom this defect was *introduced* into the production? Let me think of another scenario where your development team follows agile (say TDD or XP). An inefficient unit test may allow a defect to slip into the code. Even if the test was written by a programmer, he was also a tester IMHO and due to his poor test a defect was introduced into the system.
I vaguely remember you identifying yourself as follower of context driven testing community... (is that right?) Yes that is right. I do identify myself as a follower of context driven community (as of now). But I also remember that context driven community encourages it's follower to practice self-criticism and to give *context* more importance than the so-called best practices. Hence I wonder how my views about "lack of testing" can make you surprised! Moreover, I have no idea how following TDD (for that matter any agile methodology) could make me a non-follower of context driven community. Because to me, TDD is just another context. Correct me if I am wrong in my understanding.
-Debasis
The big news in the United States today is the alleged investment fraud by Bernard Madoff. Apparently, people have lost about $50 billion. There is evidence coming out that our Securities and Exchange Commission had reason to investigate Madoff and stop this fraud but did not.
ReplyDeleteI will not speculate on the reason that a fraud this huge was able to proceed for this long without being stopped.
What I will note is that in the United States, we have learned to rely on government regulators to protect us. We investigate many purchases and investments much less closely than people in some other countries because we know that some types of cheating are very unlikely (because of active government investigation) and others will cause trouble for the cheat.
Sadly, over the past 28 yeara, but especially over the past 8, many of our regulators have been doing less than we expect. The agencies have been funded less and in many cases, the government has hired managers for the agencies who are more sympathetic to the businesses being regulated than the people who are cheated or injured by those businesses.
What creates an outrage and a disaster -- whether we look at genuine disaster management (like Katrina) or environmental protection or finance industry regulation -- is that people depend on the competence and integrity of the regulators and so they do less to protect themselves.
What does this have to do with testing?
Development groups rely on test groups the way that countries rely on regulators. We trust them to do their work well and we do other things ourselves instead of redoing the work that we know will be done by the testers (regulators). If the testers do their work poorly, problems stay in the product -- partially because the testers don't find them and partially because the testers don't alert management to more general trends of weakness that cause corrective action in design and programming.
So, I agree, in some contexts, bad testing can certainly lead to lower quality.
@ Dr. Cem Kaner,
ReplyDeleteYou have made me the Happiest tester today by leaving behind your comment on my blog. It is a privilege and honor to have comment of a testing guru like you on my post, who also happens to be one of the pioneers of Context Driven Community. It is simply brilliant how you correlated regulators (Security and Exchange Commission) with testers. Thanks for the insight.
-Debasis
There are several other reasons why there might be bugs in software:
ReplyDelete1. Some of the requirements given by the client may be ambiguous, non-specific or conflicting with other requirements.
2. The developer may not fully complete a particular feature or bugs may be introduced due to distractions, high stress level, low knowledge level of technology or any other reason.
Any of these other reasons could be categorized under the headings given above, especially the big bucket of Human Factor.
I think it is important for the development team to perform a proper analysis (RCA for instance) of the bugs that are discovered. This would help create the awareness of the major reasons of the introductions of bugs and the team can take steps to mitigate these reasons. The analysis and action to close the major reasons of bugs should be repeated after every development cycle.
nice post i completely agree with you
ReplyDeleteGreat post.Thanks
ReplyDeleteThnkas for great post.It really helps me a lot
ReplyDeleteHello,
ReplyDeleteLooking forward to reading more.
Thanks Again. Will read on…
Very nice post. Where is 10th reason?
ReplyDeleteAgile Hybrid Software Development Processes that skirt all of the important parts that increase quality and help ensure good designs and just skip to the code it and ship it without any documentation, design, architecture, testing, peer reviews, etc. Agile works in the right places and circumstances. It works best when the basic tenets are adhered to in the right places. If it isn't done right, you end up with a mess and people calling for quality initiatives, wondering why they have quality issues.
ReplyDeleteBryan
Thanks for the nice topic
ReplyDeleteI think most of the reason were covered, I wanted to add the competency as another reason forcing developers to rush in order to publish the software before someone else does.
Also, one point to note is that many of the mentioned points could be related to poor project management.
Thanks