Problems
oPoor requirements – if the requirements are not clear, unfinished, too common, and not testable, then there will be problems.
oUnrealistic schedule – if too much work is given in too little time, problems are inevitable.
oInadequate testing – no one will know whether or not the program is any good until the customer complain or systems collide.
oFuturities – requests to pile on new features after development is underway; extremely common.
oMiscommunication – if developers do not know what’s needed or customer’s have wrong expectations, problems are assured.
Solutions
oSolid requirements – clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. Use prototypes to help nail down requirements. In ‘agile’-type environments, continuous close coordination with customers/end-users is necessary.
oRealistic schedules – allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.
oAdequate testing – start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. ‘Early’ testing ideally includes unit testing by developers and built-in testing and diagnostic capabilities.
oStick to initial requirements as much as possible – be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, work closely with customers/end-users to manage expectations. This will provide them a higher comfort level with their requirements decisions and minimize excessive changes later on.
oCommunication – require walkthroughs and inspections when appropriate; make extensive use of group communication tools – groupware, bug-tracking tools and change management tools, intranet capabilities, etc.; insure that information/documentation is available and up-to-date – preferably electronic, not paper; promote teamwork and cooperation; use prototypes and/or continuous communication with end-users if possible to clarify expectations.
For more information visit =>http://softwaretestingguide.blogspot.com
