Showing posts with label Software Testing. Show all posts
Showing posts with label Software Testing. Show all posts

Tuesday, November 10, 2015

TSR Model

TSR Model



                                                                 

TSR model depicts the key attributes that must be handled effectively for successful completion and closure of any project. 


Project scope defines the completeness of the product. Scope creep is one of the main risks of quality. It is where additional requirements are introduced after product execution has begun. It affects both time and cost and ultimately product quality. Hence, scope should be well managed in order to achieve a quality product.

Cost/ Resources are another factor we need to focus on. Reducing Cost will affect the product scope and ultimately affect product quality. Cost is mainly associated with resources. When more resources are assigned to a project to shorten the schedule or meet increased scope, the more the cost will increase.


Time is non-recoverable. Changing the project schedule will affect either scope or cost. If the project needs to be completed sooner, more resources need to be allocated. It will increase the cost. Another solution is to reduce the scope where some desired features are left out or de-prioritized. 

Monday, September 15, 2014

Seven Testing Principles

There are several testing principles identified by several parties during past years. Seven are identified as most common among those.

1. Testing shows the presence of defects.
Testing can show the available defects in the software but cannot prove that there are no defects. Although the tests are concluded with no errors, cannot guarantee that the software is error free. Testing reduces the risks that can occur due to undiscovered errors.

2. Testing everything is not feasible
Testing all combinations of pre-conditions and inputs is not feasible. Simply exhaustive testing cannot be approached. Have to prioritize the scenarios and risk analysis should be focused.

3. To find defects early, start testing early
If the defects should be found as early as possible, testing should be started early.

4. Defect Clustering
Testing should be focused on early found defect density and should be compared with expected results.

5.  If the same tests are repeated, there will be no new defects found
Test cases should be regularly revised and updated. Because, software changes. If the same sets of test cases are run over and over it will find no defects. Have to be updated with new scenarios. (pesticide paradox)

6. Testing is done differently in different contexts
Testing is context dependent.

7. Absence of errors fallacy
Finding and fixing defects will not be helpful if the system is not usable by the users and if it doesn’t fit to user expectations.