GroTechMinds

The ‘W’s and ‘H’s of Impact Analysis Meeting:
Introduction:

It is a software tester’s responsibility to be aware of the answers to questions such as, what is impact analysis meeting? Why do we do it? Who does it? How do we do it? and to have the assertiveness to implement it. Let’s understand the context that requires and demands the impact analysis meeting and get to know the answers to the questions above.

What is a build?

In software testing, the term ‘build’ refers to a version of an application under test (AUT) or a specific instance of that application, at a particular point in time. After the build undergoes optimized testing with test suits having maximum test coverage, and that have met the criteria of test suite passing percentages, the testing team is in a safe and confident position for sign-off to the release team.
The industry standard in passing percentage of unit testing or component testing is usually 90% to 92%, Integration or system integration testing is 94% to 96% and system testing or end-to-end testing is 98% to 99%.
When it comes to smoke testing, it is done before all the other testing and as soon as the build is received by the tester. Its passing percentage is 100%, which ensures the basic and critical functions of that build are working as per the requirement. Unstable builds are usually put through the smoke test suite and those builds that are stable and that come under legacy builds are put through the sanity suite.

What is regression testing?

Whenever a new feature is added to an existing build, a bug or a series of bugs has been fixed, when some form of code modification has been done, an existing feature is being modified or when it is deleted, it is essential to perform regression testing. Although the changes may seem to be minor and isolated and are unlikely to have an impact on the system as a whole, the probability of bugs in the unmodified modules in a new build is always present.

Regression testing ensures that the changes done to a build haven’t affected the functionality of unchanged or unmodified modules.

The various types of regression testing are,
  •  Unit regression testing (Testing only the modified part of the application)
  • Regional regression testing or partial regression testing (Testing the modified part of the application along with the impacted areas)
  •  Full regression testing (Testing the modified part of the application along with the impacted areas as well as the unimpacted areas)
Why do we do impact analysis meeting?

Performing full regression testing (running the entire regression suite), upon receiving a new build is exhaustive and can consume a lot of resources that can be better spent on other STLC (Software Testing Life Cycle) activities. To prevent our regression testing from being turned into exhaustive testing, we have to perform the impact analysis meeting. Using this, we can decide which part of the build is affected by the changes and which isn’t affected. This allows us to see the viability of performing a type of regression testing only on the impacted areas called partial regression testing and can efficiently utilize our resources.

Who conducts the impact analysis meeting?

An impact Analysis meeting is usually conducted by the senior QA tester or the developer to determine the areas that have a higher probability of being affected by the changes in the current build. To have clarity and solidarity on the decision we are required to include the domain experts who may also include, the architect, the business analyst, the product manager, the developers, the testers, the database administrator, etc.

Depending on the results of the impact analysis meeting, we decide which type of regression testing is best suited for the new build. Regional regression testing is the widely performed type of regression testing as its benefits are too much to be taken advantage of.

How do we do impact analysis meeting?

One of the efficient ways, the Impact analysis meeting can be done is by performing it in stages,

Stage 1: The preparation stage:

1. Defining the Change: We have to clearly outline the list of changes or modifications that are being introduced, whether it’s a new feature, bug fix, or system modification.

2.  Assembling the Team: We have to invite the representatives from development, testing, and product management to ensure a well-rounded perspective.

3. Gathering Information: The developers should provide details about the change’s technical implementation. The testers should have a thorough understanding of existing test cases and the system’s functionality.

Stage 2: During the Meeting:

1.Presenting the Change: The development lead or product manager should clearly explain the nature and purpose of the change.

2.Impact Brainstorming: Facilitating a discussion about potential areas the change might be affected or impacted. This could involve data flow, integrations with other systems, user interface elements, or business logic.

3. Risk Assessment: Evaluating the severity of potential impacts by considering how critical the affected functionalities are, and the likelihood of encountering issues.

4. Testing Strategy: Determining the scope of regression testing which might involve re-running existing test cases, creating new ones to cover the modified areas, or a combination of both.

5. Action Items: Assigning clear ownership for tasks like updating the test cases or regression testing is crucial for the maximum efficiency of resources.

Stage 3: Documentation stage:

Documentation: Document the key takeaways from the meeting, including the identified impacts, risks, and testing plan.

Some of the highly recommended practices to be followed when conducting the impact analysis meeting are,
  • Using Visual Aids: Diagrams, flowcharts, or system architecture maps can aid in visualizing the change’s impact.
  • Prioritizing Risks: Focusing on the most critical functionalities or on the areas with the highest potential for regression.
  • Collaborative Environment: Encouraging open communication and participation from all team members.
  • Follow-up: Scheduling a follow-up meeting to discuss the testing progress and address any new concerns that may arise.
What can we conclude from this?

To effectively manage the resources available in the SDLC(Software Development Lifecycle), during the testing phase, performing the impact analysis meeting is crucial. It provides better utilization of resources which has a direct impact on the quality of the software that is being released.

Conclusion:

In conclusion, Impact Analysis Meetings are essential for the success of software testing efforts. By properly assessing the ‘Who’, ‘What’, ‘When’, ‘Where’, ‘Why’, and ‘How’ of prospective changes, teams may reduce risks, improve decision-making, and ultimately deliver high-quality software. Implementing an organized approach to Impact Analysis Meetings helps improve communication, collaboration, and efficiency throughout the software development process. So, the next time you’re planning a project, remember the value of doing Impact Analysis Meetings to set yourself up for success.

A career in software testing offers a dynamic and rewarding path for individuals passionate about quality assurance and ensuring the reliability of software products. With technology continuously evolving, the demand for skilled software testers is on the rise, making it a lucrative field to consider for those interested in quality assurance, problem-solving, and attention to detail. By embracing continuous learning, staying updated on industry trends, and honing your technical skills, you can pave the way for a successful and fulfilling career in software testing. So, if you have a knack for uncovering bugs, optimizing performance, and ensuring seamless user experiences, a career in software testing might just be the perfect fit for you. 

Upskill Yourself
Consult Us