Why should software have bug?
Printed From: One Stop Testing
Category: Software Testing @ OneStopTesting
Forum Name: Bug Report @ OneStopTesting
Forum Discription: After Creating the Test Plan, Writing the Test Cases and using them, Finally We need to generate those Bug Reports which Proves that Testers are Good enough & most importantly Indispensable.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=339
Printed Date: 02Jan2025 at 9:46am
Topic: Why should software have bug?
Posted By: vidhya
Subject: Why should software have bug?
Date Posted: 26Mar2007 at 11:23pm
Why does software have bugs:
1. Miscommunication or no communication - as to specifics of
what an application should or shouldn't do (the application's
requirements).
2. Software complexity - the complexity of current software
applications can be difficult to comprehend for anyone without
experience in modern-day software development. Multi-tiered
applications, client-server and distributed applications, data
communications, enormous relational databases, and sheer size of
applications have all contributed to the exponential growth in
software/system complexity.
3. Programming errors - programmers, like anyone else, can make mistakes.
4. Changing requirements (whether documented or undocumented) -
the end-user may not understand the effects of changes, or may
understand and request them anyway - redesign, rescheduling of
engineers, effects on other projects, work already completed that may
have to be redone or thrown out, hardware requirements that may be
affected, etc. If there are many minor changes or any major changes,
known and unknown dependencies among parts of the project are likely to
interact and cause problems, and the complexity of coordinating changes
may result in errors. Enthusiasm of engineering staff may be affected.
In some fast-changing business environments, continuously modified
requirements may be a fact of life. In this case, management must
understand the resulting risks, and QA and test engineers must adapt
and plan for continuous extensive testing to keep the inevitable bugs
from running out of control - see 'What can be done if requirements are
changing continuously?' in Part 2 of the FAQ. Also see information
about 'agile' approaches such as XP, also in Part 2 of the FAQ.
5. Time pressures - scheduling of software projects is
difficult at best, often requiring a lot of guesswork. When deadlines
loom and the crunch comes, mistakes will be made.
6. egos - people prefer to say things like:
* * 'no problem'
* * 'piece of cake'
* * 'I can whip that out in a few hours'
* * 'it should be easy to update that old code'
* instead of:
* * 'that adds a lot of complexity and we could end up making a lot of mistakes'
* * 'we have no idea if we can do that; we'll wing it'
* * 'I can't estimate how long it will take, until I take a close look at it'
* * 'we can't figure out what that old spaghetti code did in the first place'
If there are too many unrealistic 'no problem's', the result is bugs.
7. Poorly documented code - it's tough to maintain and modify
code that is badly written or poorly documented; the result is bugs. In
many organizations management provides no incentive for programmers to
document their code or write clear, understandable, maintainable code.
In fact, it's usually the opposite: they get points mostly for quickly
turning out code, and there's job security if nobody else can
understand it ('if it was hard to write, it should be hard to read').
8. Software development tools - visual tools, class libraries,
compilers, scripting tools, etc. often introduce their own bugs or are
poorly documented, resulting in added bugs.
|
|