Impact analysis evaluates the changes that were made to a system/application to identify the intended consequences as well as possible side effects of a change and to identify the areas in the system that will be affected by the change.
This means that impact analysis should be done before a change is made to help decide if the change should be made.
Impact analysis help improve the quality of the software by reducing the likelihood of finding unexpected defects i.e. this would be considered as a defect prevention technique.

Release notes is a document that is released as part of the final build that contains new enhancements/changes and the defect fixes as part of that build.

Typical tasks that tester performs may include:

• Reviewing test plans
• Analysing, reviewing and assessing requirements, specifications and other test artifacts
• Design and execute test cases
• Prepare test data
• Evaluate results from test case executions

Organisations may need their own separate testing teams. Here are couple of possible reasons as to why this is so:

• They are more likely to recognize different kinds of failures because of their perspectives and biases.
• They are able to verify, challenge or disprove assumptions made by stakeholders during specification and implementation of the system.

There are many benefits that comes with adopting Agile methodology. These include but not limited to:

1. Higher product quality – In Agile development, testing is integrated during the cycle, which means that there are regular checkups to see that the product is working during the development. This enables the product owner to make changes if needed and the team is aware if there are any issues.
2. Higher customer satisfaction – Able to receive customer’s input/feedback before, during and after each sprint leading to a higher customer satisfaction as the product will be of a higher quality.
3. Reduced risk – agile iteratoin allows risk idetnficiation and mitigation early on in the development thus reducing time and cost.
4. Rapid delivery – Agile is an iterative development model and the work is divided into small cycles (typically 1-4 weeks). This means that the features can be developed, tested and released quicker.
5. Allows for changes (more flexible) to requirements

Testing occurs from the get-go i.e. unlike waterfall where we test after the development, it occurs side-by-side with development. Also note that the responsibility is shared between all the members of the scrum team, this means that the developers in the team may also carry out testing.

A change request is a proposal to a modification to a product or system.
Below are the process for handling a change request once it has been documented and received:

1. Information gathering step where more change request details are requested if they are lacking and any ambiguities and mistakes are clarified and fixed.
2. Once enough information is available, assess and determine whether it is indeed a valid change request. Determine whether this change is in scope or not based on various criteria e.g. risk, scheudle, available resources and priorities and etc.
3. Identify any possible risks, determine the complexity of the work and also peform risk analysis to determine the impact of this change.
4. Approval – Change request then goes under review for an approval.
5. Impmentation – the change request is communicated to the team, the actual work is carried out and it is monitored until it is closed/completed.

Root cause analysis is a systematic process for finding and identifying the root cause of a problem or event.

The 5-whys method/technique involves one asking “why?” five times in a row to identify the root cause of the problem.

Regression is a type of testing that gets performed to ensure that a change made to the system has not broken the existing functionality of the system. It is done after an enhancement or defect fixes are made to the system. Impact analysis is required to identify possible impacted areas due to those changes.
Selecting test cases for regression testing require:

• Knowledge on the bug fixes and how it affects the system
• Includes core/critical features of the product
• Include the test cases in error-prone areas
• Include areas that the changes have impacted

Defects do reoccur if the symptoms are treated instead of the underlying causes. The root cause is often a failed control, process, or a gap in staff skill sets that caused an earlier condition or event. Root Cause Analysis is carried out in order to tackle this problem.
There are two approaches/methods to RCA:

1. Fishbone diagram
2. 8D Five Why’s