Q: What can be done if requirements are changing continuously? (Cont'd...) [Continued on next page...]
- Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version.
- Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application.
- Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that's their job.
- Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.
- Design some flexibility into automated test scripts;
- Focus initial automated testing on application aspects that are most likely to remain unchanged;
- Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;
- Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;
- Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.
______________________________________________________
Copyright 1998 - 2008 by Rob Davis PE. All rights are reserved. No part of
this document may be reproduced in any form whatsoever
without written permission from Rob Davis, PE.
http://www.softwaretestengineer.com
http://www.robdavispe.com
