How to determine risk: This is another "it depends" question. Not having any details, there are a few generalized principles.
* If it is a new application developed from scratch, then everything is equal risk and bugs could be anywhere.
* If it is a new application developed from existing components/modules, then risks are at the integration level. Each module may work properly but they may not be re-used in the right context or assembled correctly.
* If it is an existing application that is having new features added, then the new features themselves are the greatest risk
* If it is a maintenance release (bug fixes only) of an existing application, then the validity of the bug fixes is first
* If it is a new application developed from scratch, then everything is equal risk and bugs could be anywhere.
* If it is a new application developed from existing components/modules, then risks are at the integration level. Each module may work properly but they may not be re-used in the right context or assembled correctly.
* If it is an existing application that is having new features added, then the new features themselves are the greatest risk
* If it is a maintenance release (bug fixes only) of an existing application, then the validity of the bug fixes is first
To estimate the time taken to test the application?
No: of uses cases designed for that application , these are straightforward application usages which the customer might be performing .... Believe me there can be many many more use cases which can be derived which the customer might not be very interested ..The idea is to test first those scenarios which are of top priority for the customer.
2) There might be cases where many test cases might be performing the same operations based on the interrelation with other cases, identify those and make sure you don't over test your application , test rework can be reduced by identifying redundant test cases ... Prepare a traceability matrix it will give you a clear idea of how requirements are reused in different test cases...
2) There might be cases where many test cases might be performing the same operations based on the interrelation with other cases, identify those and make sure you don't over test your application , test rework can be reduced by identifying redundant test cases ... Prepare a traceability matrix it will give you a clear idea of how requirements are reused in different test cases...
No comments:
Post a Comment