How to identify and manage Risks related to Testing...

There are several challenges and risks related to testing which may occur during your project execution. You should be careful and need to assess any possible risk coming into the project and should devise a mitigation strategy as early as possible.

This will help you manage your risks, help smoothing execution of project and help you release the product with best quality possible. I'm highlighting some of the risks that you might face as per SDLC phase for easier understanding. you should also evaluate risks in your project on a periodic basis as suitable, based on timeline of your specific project.

I also suggest you to publish frequent status report to your management team. This will allow you a platform and opportunity to convey the status and raise any concern/risk/challenge that you might face during the project. Many people think that sending status report is a waste of time but believe me if you utilize this tool effectively it will help a lot for smooth execution of your project.

1. Risks in Requirement phase - Requirement must be good in order for any project to be successful. Testers should review the requirements in detail from various perspective
1. Details are not available in requirements - All requirements should have sufficient details for an engineer to study them and able to build the required application. If requirements are not detailed then there might be lot of to-and-fro to understand the requirement which may consume crucial time during project execution
2. Requirements are ambiguous - Requirements should be precise and clear. Any 2 person reading the requirement should be able to understand similar meaning out of the specification. If requirements are ambiguous then these can be either built incorrectly or crucial issues might slip from the test cycles
3. Requirements are not testable - Each and every requirement should be testable. E.g. If a requirement is mentioned that 'UI should be good', then we may not be able to test the requirement as there can be different meaning for parameter 'good'. Similarly if there is requirement which says 'User should be able to login quickly'. It may have different meaning to different people.
4. Changing requirements - Some times you are trying to hit a moving target, with requirement specifications changing every now and then. You should evaluate the impact on your deliverables and  in case you find it a challenge then you should raise this
5. Non functional requirements are not mentioned - Ideally requirement specification should mention non-functional requirements e.g. Performance, Security etc. If these are not mentioned then it may become subjective whether a system is in usable condition or not.
6. Change Request - There might be change request coming into your project for which you do not get additional time. Any potential change request should be managed and come through a CR process and all impacts should be assessed before implementation of CR.
2. Risks in Planning - Most of the project fails due to the lack and improper planning, even if you are preparing the plan, you should at least provide your inputs to your leads/manager before a plan is approved. Anyway you are the ones who will be executing the project and should correct any discrepancy during planning phase itself.
1. Detail plan not present - Before we start the project we should plan our project efficiently. That means we should have broken all tasks to a manageable level and allocated resource and time for the execution of task. If this is not done properly, we might be setting up for the problem later
2. Inadequate Resources - Many a times we see either adequate resources are not assigned to the project or they are assigned very late in the project. If this is the case then we should raise a risk and possible impact due to the same.
3. Inadequate Test environment - Test environment is crucial aspect and we are expected to certify each and every possible environment combination. In case you do not get adequate test environment then you should raise this risk and in case you are not able to certify any particular combination, you should mention the same in the Validation report that you may prepare at the end of the project. Using this you should share the gap in execution as per the plan and share the impact with the management team
4. Inadequate Time - Most of the project teams face this problem across SDLC. First of all you should budget adequate time for each tasks using a standard estimation technique. You should break down each task to a granular level and should block adequate time. Also budget some time for new change requests coming you way at the later phase of the project, you can also refer total efforts on CR from some of your past projects as references. Also plan some time for casual/sick leave for your team and add some buffer in the project. You should provide adequate rationale while doing so and negotiate with your management
5. Inadequate Tools - In case there are tools planned in the project and are not available during execution, you should raise this risk and identify any other potential substitutes.
6. Movement of resources across test teams -  You will observe that many time resources are being shuffled across project teams. If this happens in your project then you should try to create shadow resource in your domain who have certain knowledge on techniques, tools and domain knowledge. Also try to create knowledge base documents across team and inculcate culture of knowledge sharing between team.
3. Risks in Design phase - This is a important phase of build any requirements. You should try to participate as much you can during the design phase and should review the design documents thoroughly.
1. Testers are not involved in designed - Many dev managers believe that testers do not play any role in design phase and try to keep them away. If this is the case then you should raise your concern and should try to get involved during design phase and provide your reviews. This will help you a lot while designing and execution of tests as you will have more perspectives to testing
2. Designs are not robust - While reviewing if you encounter that design are not comprehensive, detailed and robust you should raise you concern and should try to ensure that nay open gaps in design should be implemented ideally before coding or test execution. Also you should consider that designs are built with sustainability and scalability.
3. Performance is not considered during design - If performance consideration are not implemented in design then you should raise this appropriately
4. Risks in Development -
1. Unit test not comprehensive - Unit tests are important areas which can help identification of defects during early phase and effort of fixing an issue in code is also very less. In case you find many issues during testing then you should review unit test to see if they are adequately covering all possible gaps. In case you see any major deviation then you should raise this as a risk and help in correct this for future projects
2. Features are broken in consequent builds - In case you identify that features working in earlier builds are being broken in next build while fixing some other issues. You may also want to get the impact assessment for any fix in the release (ideally in issue base directly). This will help you identify any possible impact in the build and then aligning your regression testing accordingly.
3. Required documents are not provided by Dev - In case you do not get adequate documentation as planned e.g. release notes, mapping documents etc then you should raise this immediately so that correction can be done 
5. Risks in Test Design -  While preparing test scripts and test data you should assess any challenge and raise it. You should assess any further risks in addition to the planning risks listed above:
1. Test strategy is not devised - You should spend some time in determining test strategy so that you can proceed with design and execution of test. In case you determine any challenge during devising test strategy then you should raise this immediately for taking any corrective action. This may be any sort of dependency, tools availability, pre-reqs, coverage etc
2. All Test scenarios are not covered - In case you determine that the test scripts are not robust and do not cover all test requirements then you should raise the risk and negotiate for adequate time to correct them
3. Adequate test data is not present -If you observe that adequate test data is not prepared then you should update the data pool in your scripts
4. Reviewers are not available - Review is one of the most important aspect to evaluate the quality of test design
6. Risks in Test Execution - Test execution is one of the most important phases of any project, the results from this phase determines the quality and enables decision for the management for go-nogo. As testing team are owner of this phase, they should raise any risk that may hamper test execution and delay the release. 
1. Pre-requisites are not available - There might be some pre-requisites before you can start system test cycle. This can be in a form of tool, utility, stub, mapping document, test scripts, test environment, third party components etc. If these are not available then escalate immediately till you get all pre-reqs.
2. High number of test builds - Due to high number of build you might be require to spend lot of time in installing multiple builds and due to this you will not provide adequate coverage which might result in issues slipping through test phase. You should work with Dev team and identify a build plan with a designated date and in case the number is increasing then escalate the same to you superiors.
3. Many show stoppers are there in the build - You should conduct a smoke test round before you accept the build. This activity should be planned in you project. In case you find many show stopper issues then you should reject the build instead of spending time on the same.
4. Many key requirements are not present in the build - Many a times you will get the build on time but when you start the testing you will realize that there are key requirements missing from the build. If this happens you should raise this immediately. For longer run you should ask release team to provide some sort of release notes which will have all requirements and known issues published by dev team. This will help you evaluate if the build is ready for system test.
5. Regression time is not sufficient - You may end up doing routine testing and realize that there is not sufficient time to conduct full regression testing. In that case you should plan Risk Based Regression and highlight the same to the management in your status report. If there are genuine reasons you should negotiate either to get more testers to help you in testing or move the release dates while you can complete the required regression.