Impact Analysis is a study that allows you to specify the affected areas (affected areas) in the project when developing new or changing old functionality, as well as determine how significantly they were affected. <\/p>\n\n\n\n
Affected areas require more attention during regression testing.<\/p>\n\n\n\n
When Should I Conduct an Impact Analysis? <\/strong><\/p>\n\n\n\n Impact analysis can be useful in the following cases: <\/p>\n\n\n\n As we know, nowadays products are getting bigger and more complex, and components are increasingly dependent on each other. Changing a line of code in such a project can “break” absolutely everything.<\/p>\n\n\n\n Why do you need to conduct Impact Analysis? <\/strong><\/p>\n\n\n\n Information about the relationship and mutual influence of changes can help QA: <\/p>\n\n\n\n How to conduct Impact Analysis?<\/strong> <\/p>\n\n\n\n As you can see, only “step 6” requires the ability to read code, “steps 1-5” can be handled by QA even without knowledge of a programming language.<\/p>\n\n\n\n The most basic and basic thing to do is to carefully study the issue in the bug tracking system. Pay attention to all fields, especially: <\/p>\n\n\n\n Some important conditions or features described in the issue will help you identify the area of \u200b\u200btesting. For example, when you carefully read the issue, you find that the ‘Additional Background Information’ is marked that the problem can only be reproduced when using HTTPs. Therefore, we can note that when testing it would be nice to check the case with HTTP.<\/p>\n\n\n\n You will be surprised how much can be found in correspondence related to your task that was omitted and not indicated in the issue: <\/p>\n\n\n\n When testing changes, your goal is to find as many “broken” as possible and therefore you should boldly approach the developers, those “who may have broken” and ask directly: “You made changes, tell me what they can affect, what areas\/modules I need to check more carefully.” A good developer who understands that the sooner a bug is discovered, the cheaper it will be to fix it, will help you with advice, even if he is absolutely sure of his changes.<\/p>\n\n\n\n Changes that are made must be made somewhere. An example would be git, where it’s fairly easy to determine where the changes were made. By “place” I mean “specific file, specific function\/method, specific module”. And therefore, this “place” (this module, functionality) should be rechecked, tested for regressions.<\/p>\n\n\n\n Also, if they have been changed in some client files (JS, HTML, CSS, etc.), cross-browser testing should be carried out.<\/p>\n\n\n\n In order for QA to study descriptions, you first need to ensure that Developers start writing competent and understandable descriptions of changes. It would be nice if the developers followed the pattern for describing changes (git commits):<\/p>\n\n\n\n Ticket number and title <\/p>\n\n\n\n Everything is simple here – you need to read the code and imagine what it does. Of course, not many people can do it at this stage, but there is something to strive for. In addition, a deep understanding of the code is not always required. Basic knowledge of programming and a smattering of OOP knowledge may be enough to present a use case that covers the main functions.<\/p>\n","protected":false},"excerpt":{"rendered":" Impact Analysis is a study that allows you to specify the affected areas (affected areas) in the project when developing new or changing old functionality, as well as determine how significantly they were affected. Affected areas require more attention during … <\/p>\n","protected":false},"author":1,"featured_media":18873,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[703,724,723,19],"class_list":["post-4421","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general-qa","tag-bug","tag-code","tag-impact-analysis","tag-qa"],"yoast_head":"\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n