Subscribe to receive all latest blog updates

In this article, we will tell you our own way of Impact Analysis introduction and work with it. Why did we decide to introduce Impact Analysis in software testing in our teams? What practical benefit from this innovation have we got and are getting today? You will get answers to these and many other questions concerning this topic while reading this material.

 

Written by:

Specialists of Network QA Team

Contents

Introduction

1. What is Impact Analysis?

1.1 Basic principles

1.2 Impact Analysis for developer

1.3 Impact Analysis for tester

2. Our experience with Impact Analysis

2.1 Life before Impact Analysis

2.2 Impact analysis in our projects

2.3 Features of the innovation introduction

Impact Analysis: our benefit

Conclusion

 

Introduction

We devise and implement different features, additional means that can be useful for a user. We work with the constantly changing acceptance criteria: we develop something, then change it, add something, remake something, etc.

In such continuous process of development, it is possible to face an unpleasant situation when it is difficult to track consequences of changes and modifications being introduced: to estimate what parts of the program may be affected and how significantly they may be affected.

As a result, testing is performed accordingly to the best practices, but some part of the product, some module or feature are looked over or checked not deeply enough, just because of the Impact Analysis in testing information absence.

Information presented in this article will be useful for those specialists who need to analyze, what product items made changes can influence on; i.e. for everyone who is related to IT product development.

We will touch upon such questions:

  • What is Impact Analysis in general?
  • What is software Impact Analysis and what is its importance in the developers’ and testers’ life?
  • How did it happen that we faced with the necessity of the Impact Analysis introduction in the process of our products development?
  • Exactly how and in what form do we use Impact Analysis in our projects?
  • Some interesting and important features of this innovation introduction;
  • Practical benefits of the Impact Analysis use.

It is safe to say that after reading this article you can figure out how to easily make your product better. If talking about Apriorit, we already rely on the Impact Analysis within all our software testing and quality assurance processes - you can learn more details on them here.

1. What is Impact Analysis?

1.1 Basic principles

First of all, let’s clarify what Impact Analysis is, who, when and why uses it.

Briefly, the Impact Analysis is used in software testing to define all the risks associated with any kind of changes in a product being tested. There exist several software Impact Analysis definitions that accent different aspects. It will be useful to consider each of these definitions because this will help you to make a decision and define to which of these definitions your personal Impact Analysis will be closer.

The first definition says that Impact Analysis means detection of potential consequences of changes or things that must be remade together with the introduced changes. Here, Impact Analysis is considered in terms of changes in the product.

According to the second definition, Impact Analysis is an estimation of the number of risks associated with the product changes, including the estimation of influence on resources, work and timetable. This Impact Analysis definition takes into consideration changes consequences in terms of the whole development process.

If we consult with ISTQB glossary, software Impact Analysis is an estimation of changes on different levels of development documentation, testing documentation and components for introduction of these changes and registration them in corresponding requests. Here, our attention is drawn to the fact that changes should be taken into consideration on all documentation levels: from the code to requests.

Knowing what Impact Analysis is, let’s clarify when Impact Analysis is used. It may be useful in such cases:

  • There are changes in requirements;
  • A request for product changes has been received;
  • The introduction of a new module or functionality into the existing product is expected;
  • Every time, when there are changes of the existing modules and product features.

Now, let’s answer the question: -Why?

Software Impact Analysis helps to answer such questions:

  • What modules and functionalities will be affected by changes and exactly what influence will changes have on them?
  • What new test cases should be created to cover a new module or feature and its relationship with existing elements?
  • How will changes influence on testing process in general and will we need any process correctives, for example, new tools, extra knowledge?
  • How will changes affect terms and budget?

Three main types of the software Impact Analysis are available:

  • Impact Analysis of Dependency – our first definition is the most suitable for this type;
  • Experiential Impact Analysis  - our second definition is the most suitable here;
  • Impact Analysis of the Traceability – this type is disclosed in full measures in the third definition (ISTQB glossary).

In this article we will consider Impact Analysis of Dependency that has been introduced into the process of our products development.

1.2 Software Impact Analysis for developer

Now, let’s discuss the question: what is software Impact Analysis for developer? What a specialist, who develops our project, must perform or be good at to work with Impact Analysis?

To perform successfully Impact Analysis, a programmer should have such skills:

  • Very attentive and detailed research of the relationships between the program modules;
  • Tracking of the shared resources;
  • Keeping Impact Analysis document up to date (adding new features, changing relationships).

Positive results from meeting these requirements won’t keep waiting for them! Now, a developer:

  • Considers the final product and not a separate module as result of his/her work;
  • Learns to track relationships between modules (program architecture understanding is necessary in this case);
  • Decreases risks of bug detection on last testing steps, while testing of modules skipped on the previous steps.

It is possible to mark out the only one negative moment:

  • It is necessary to allocate resources to support Impact Analysis documentation relevance.

1.3 Impact Analysis for tester

In the development process, any interaction method between developers and testers would be useful. At times, testers don’t receive full information about introduced changes. This fact, in turn, influences directly on the product testing reliability. It is Impact Analysis that is required to solve this problem.

Knowledge about the correlation and mutual influence of some changes can help testers:

  • Not to waste time on testing of those project parts that has not been affected;
  • To focus on the functionality where changes have been introduced;
  • To take into consideration other project parts possibly affected by the introduced changes.

Without Impact Analysis, testing specialist can use those test cases that in truth don’t cover last changes in the project. At the same time, he/she might not pay his/her attention to testing of those project parts that really require it.

It turns out that Impact Analysis in testing helps to decide on which areas to focus time and resources. Therefore, it is a very powerful tool that allows QA to considerably increase testing efficiency.

2. Our experience with Impact Analysis in software testing

2.1 Life before Impact Analysis

Before the Impact Analysis introduction, the communication scheme between developers and testers inside a project was slightly defective. Usually, after building of a new product version, project development team sent a testing request. This request contained the list of fixed bugs and link to the new version location.

Most often, the project is developed by several developers, each of which works on his/her task. Therefore, a new version is a merged result of several programmers work. But testing request is sent by that programmer who builds the version. So, as a rule, this programmer knows only his/her fixes and changes.

Thus, before the introduction and formalization of work with Impact Analysis, testing request contained no information about those parts of the project that were influenced by changes, and about their influence on other features. But even if such information was given, we could not consider it full and reliable. Moreover, such situations were rather an exception than a rule. And of course, there was not any guarantee that a programmer had taken into consideration all features, modules and functionalities, which had been or could have been affected in the process of his/her work with the project, especially in work process where other programmers work with the same version. At best, request for testing contained a brief description of changes made by the developer who initiated a new version build, and recommendation for more careful testing of the weak spots only according to his/her changes.

More detailed and useful requests were written after the introduction of new functionality or after the practically complete logic change of the existing functionality.

Under such conditions, the main problem of testers was to choose adequate testing volume and sequence for the new version.

Before the Impact Analysis introduction, we made decisions on testing basing on some kind of empiric criteria. For example, a tester knows that if feature A has been changed than there might be problems in feature D. At the same time, feature A never was related with feature B. Nevertheless, a tester might not know that the A and B features are for all that related with each other and after certain changes unexpected bugs may appear. In addition, if there is a lack of communication in the project, a tester may not know at all that feature A has been changed because behavior was similar to the bug of feature C.

Also, there were difficulties in defining testing priority. I.e. the question was: what part of the functional required full testing, what part – smoke testing, and for what part wild or acceptance testing was enough.

As a result, we faced difficulties with such main problems:

  • Features affected by introduced changes were not completely tested;
  • Time was wasted on testing features that had not been changed.

2.2 Impact Analysis in our projects

So, we have already told what situation we had before introduction and formalization of Impact Analysis usage. The problems described above were exactly the first reason to think about introduction of this innovation into the process of our products development. Also, it is rather popular technique in the modern SQA world.

Having discussed this question in details, we understood that it is a very useful practice that brings positive results almost in no time! Hence, here is the conclusion: it would be better for us to make this important step on the way to increasing our products quality and to adjusting product development process. All the more so, making this step is easy and convenient because some of us have already did the things that are included in the Impact Analysis process and worked with its results, but they did it intuitively and not completely, without formalization and centralization. It’s time to change it!

Initiative group of our specialists gathered a meeting where it was decided to begin development of the Impact Analysis strategy introduction into our work process. Some people were appointed to be responsible for this question in their projects. Also, the term, within which the development of the principles of usage and work with the Impact Analysis in each project must be finished, was determined.

Specialists responsible for this question held meetings in their project teams, as well as drew up the concrete goals, specifics and the ways of achieving the desired results via Impact Analysis introduction. The opinion of each team member was taken into consideration. Some important and interesting moments of the Impact Analysis introduction process will be discussed below in more details.

Now, we will just say that after the time expired, we’ve confirmed by joint efforts exactly how we will use Impact Analysis for each of our projects, how we will store and process the results.

So, firstly, we’ve defined that we will perform Impact Analysis and work with its results by means of the standard Excel tables.

The QA specialists together with all other project participants developed such tables for each project. As a rule, such tables contain the list of features/modules/functionalities of the product. Before sending the version for testing, developers mark the corresponding features/modules/functionalities that were influenced/could be influenced by the introduced changes in the same table.

For more detailed explanation, we will share our examples from some of our projects, both small and large ones.

Let’s discuss the first example: a small project with a few features.

The Impact Analysis table for such project looks in such way:

Changes/Impact

Feature1

Feature2

Feature3

Feature4

Feature5

Feature6

Feature1

×

 

 

 

 

 

Feature2

 

×

 

 

 

 

Feature3

 

 

×

 

 

 

Feature4

 

 

 

×

 

 

Feature5

 

 

 

 

×

 

Feature6

 

 

 

 

 

×

As you can see, the template is a matrix. All features/modules/functionalities, which can be singled out in this product (for example: installation, uninstallation, update, hot keys, Menu, Toolbar, Hints, Options, etc), are enumerated in this matrix horizontally and vertically. Vertically, we define those features that have been changed. Horizontally, we define the features, which performed changes can influence. Change of each feature influences itself and it is defined in the table diagonally beforehand.

Such table is at the same time some kind of a check-list for developer. This table ensures that he/she hasn’t forgotten any feature and analyzed all dependencies for each of them.

So, let’s suppose that a programmer knows what he/she has changed in the feature1. He/she looks at the given template and performs the analysis. The first we have already clarified is the fact that changes in the feature1 mostly influence the state of the feature1 itself. Later, the developer understands that changes in feature1 influence the state of feature3 and can influence the state of feature2. A specialist writes down all his/her thoughts in this matrix in the line for feature1. The same analysis is performed for each feature being changed. Analysis results are marked in a line corresponding for this feature.

We decided to use such colors to define the influence level:

  • Strong influence level: red color;
  • Moderate influence level: yellow color;
  • Weak influence level: green color.

Also, it is possible to use figures to define the influence level:

  • Strong influence level: 3;
  • Moderate influence level: 2;
  • Weak influence level: 1.

As a result, the table looks as follows:

Changes/Impact

Feature1

Feature2

Feature3

Feature4

Feature5

Feature6

Feature1

3

1

2

 

 

 

Feature2

 

 

 

 

 

 

Feature3

 

 

 

 

 

 

Feature4

 

 

 

3

2

3

Feature5

 

 

 

 

 

 

Feature6

 

 

 

 

 

 

Correspondingly, a QA specialist plans his/her work more thoroughly after he/she has received such a table. Using data from such Impact Analysis table gives an opportunity to prioritize testing tasks. This is especially important if there are strict time limits for the product testing.

Due to this example, a QA specialist can immediately notice that features 1, 4, and 6 need to be checked in details at first, features 3 and 5 – in the second turn, and feature 2 should be checked the last and maybe not in such details. Such analysis and planning provide the decrease of our risks considerably when the product is to be released within strict time limits. This ensures us that the most critical and important things will be tested. Having data from this table, we will never start testing from the low-priority features.

It is worth noticing that there are such projects, for which scale of 1, 2, 3 is not enough to define the influence level. A 5-point scale is used for such tables:

  • Very strong influence level: 5;
  • Strong influence level: 4;
  • Moderate influence level: 3;
  • Weak influence level: 2;
  • Very weak influence level: 1.

Now, let’s examine such example: we have a large-scale project, where there are a great number of features/modules/functionalities. And additionally, each module includes a certain number of sub-modules/features/functionalities.

For such projects, it is not reasonable to work and track the results of Impact Analysis with the matrix discussed above. For example, we have 40 main features; each main feature additionally has 15 features. As a result, we have such 600 x 600 table:

Changes/Impact

Main Feature1

Sub-Feature1

Sub-Feature2

Main Feature2

Sub-Feature1

Sub-Feature2

Main Feature3

Main Feature1

х

 

 

 

 

 

 

 

 

 

Sub-Feature1

 

х

 

 

 

 

 

 

 

 

Sub-Feature2

 

 

х

 

 

 

 

 

 

 

 

 

 

х

 

 

 

 

 

 

Main Feature2

 

 

 

 

х

 

 

 

 

 

Sub-Feature1

 

 

 

 

 

х

 

 

 

 

Sub-Feature2

 

 

 

 

 

 

х

 

 

 

 

 

 

 

 

 

 

х

 

 

Main Feature3

 

 

 

 

 

 

 

 

х

 

 

 

 

 

 

 

 

 

 

х

We would have got an enormous, bulky document that is absolutely unreadable and impossible to use in the working process.

Therefore, we developed a special form of the Impact Analysis table for such projects. In rows, it contains all main features/modules/functionalities that can be singled out in the project. In columns, it contains all sub-modules or all features that concern each of the main features enumerated in rows.

Let’s look at an example of such table for more visual presentation:

Main Features/Sub-Features

Sub-Feature1

Sub-Feature2

Sub-Feature3

Sub-Feature4

Sub-Feature5

Sub-Feature6

Main Feature1

3

 

2

1

 

 

Main Feature2

 

 

 

 

 

 

Main Feature3

 

 

 

 

 

 

Main Feature4

 

 

 

 

 

 

Main Feature5

 

 

 

 

 

 

Main Feature6

 

 

 

 

 

 

 

 

 

 

 

 

For large projects with a number of features and functionalities, we use the table where a developer doesn’t mark exactly what feature was changed. He/she immediately marks which other features or functionality it influenced or could influence.

And typically, if the changes made by a developer influence the Sub-Feature1, it doesn’t mean that they also influenced all other sub-features. We can see this from our table for Example 2. Here, the changes made by a developer influenced only the Sub-Feature1, Sub-Feature3 and Sub-Feature4 and didn’t influence other Sub-Features.

Another specific of such approach is that even if a certain change influenced all Sub-Features concerning the Main Feature, the level of influence on these Sub-Features can be absolutely different.

Such approach to large projects gives us an opportunity to avoid duplication and bulkiness of information, which complicates the perception.

In addition, I would like to add that a developer specifies any information that is important for testing directly in the Impact Analysis table cell in each example. It can be such information:

  • Configuration, on which it is important to check the work of the version or certain feature;
  • Indication to other related product, in which given change should be checked;
  • Indication of a problem that existed in previous versions in a certain feature and which attention should be paid to when a new version is tested;
  • Any other useful data.

In the end, let’s discuss in details another example of a large project: enterprise product that has approximately 40 big features.

Developers that work with this project often perform one of such tasks:

  • bug-fixing;
  • adding a new sub-feature;
  • refactoring.

Any of these tasks touches upon one or several main functionalities. To mark them as affected in the table, a developer writes such information into the corresponding table rows:

  • Affected configuration: certain functionalities strongly depend on the operating system and other environment; so, the developer gives information whether the changes depend on the operating system and what operating systems it should be tested on at first.
  • Developer’s comments: at first, these are changes made by the developer. Often, it is a link to the bug-tracking, but it can be also a simple text description. In addition, these can be recommendations of the developer as for testing, assumptions as for possible bugs, etc., in fact, the most important information for the tester;
  • Importance: the estimation of the damage of made changes - either some numeric value, or color scheme as in other projects.
  • Plans of the developer for this feature. In the past, sometimes we had situations when we fully tested functionality after performed changes and then it appeared that at the same time developers made other changes, after which it was necessary to perform one more such testing during 10-16 hours. If developers write about their plans beforehand, we will be able to choose the most optimal testing scope at this stage.

This table looks as follows:

 

Features/Impact Analysis information

Affected configuration

Developer’s comments

Importance

Plans

Main Feature1

 

 

 

 

Main Feature2

 

 

 

 

Main Feature3

x64

Bug report #1111

4

-

Main Feature4

 

 

 

 

Main Feature5

all

Bug report #1112

2

Bug report #1001

Main Feature6

 

 

 

 

 

 

 

 

The table isn’t very volumetric and convenient enough to read.

So, we discussed some examples of performing of Impact Analysis and its work with the results both in small and very large projects. You can surely find something suitable for you among them.

Finally, let’s answer the main question: What is our formalized system of work with Impact Analysis? It is an accurate succession of actions that each specialist in the team must perform. The main advantage of such method is that each of us has a clear understanding of his/her duties, and our expectations from each other are fully synchronized.

We have two efficient schemes of work with Impact Analysis we would like to share. What is the difference between them? The matter is that the system of version auto-build is absent in the project, where the first scheme is used, and in the second project, this system is present. Therefore, the filled Impact Analysis table attached directly to the testing request in the first case, and in the second case, it is stored on the server with the prepared versions.

First, let’s discuss in details the first variant of work, where the system of the version auto-build is absent.

The developer performs such things:

  1. Works at his/her task.
  2. As soon as he/she finishes the task, he/she opens the Impact Analysis table template that is stored in the public place and performs such things:
    • Marks the points, which performed changes could influence,
    • Sets the influence level (using colors or figures);
    • Writes down the required comments and additional information in the corresponding cells.
  3. Writes the testing request that corresponds to the testing request template approved in the team.
  4. Writes down all necessary information, which he/she considers to be useful for testing (bug reports, advice, check-points, etc.);

Please notice that the Impact Analysis table doesn’t replace the testing request, but complements it.

  1. Attaches the filled Impact Analyses table to a testing request email message or indicates that nothing will be affected as a result of performed changes.

The QA specialist performs such things:

  1. Opens the received testing request, examines information written in the request.
  2. Opens the Impact Analysis table, estimates and analyses information stored there.
  3. Plans the testing activity on the basis of table data, prioritizes tasks proceeding from the notes made by the developer in the table.
  4. Tests all product parts that are marked in the Impact Analysis table.
  5. Writes the testing report that corresponds to the template approved in the team.
  6. In the testing response, writes about the state of each product part, which were marked in the Impact Analysis table.

Now, let’s discuss the second variant of work, when the system of the version auto-build is used.

The developer performs such things:

  1. Works with the copy of code, performs the task and does not change basic repository.
  2. When he/she finishes the tasks, he/she makes changes according to it in the basic repository.
  3. As soon as the developer makes code changes in the basic repository, he/she opens the Impact Analysis table that is stored in the basic repository too and looks through the list of features, marks those features that were affected by introduced changes.

It is good for two reasons: firstly, a developer is still in the context of the problem and can give the most reliable information; secondly, he/she has an accurate check-list and information will not be lost or forgotten.

  1. Arranges the level of influence of the performed changes in this table (using colors or figures).
  2. Writes down the necessary comments, additional information in the corresponding cells.
  3. Saves the Impact Analysis table in the basic repository and proceed to the next task.
  4. The one, who builds the project, makes no additional efforts. With the Impact Analysis introduction, the system of the version auto-build is described in such way: the responsible person saves the table separately before the beginning of the build and clears the main table. The main table is ready for the changes, which will concern the next version.

After the build, the system copies the table in the corresponding project folder on the server with prepared versions. Thus, the system monitors that information in the table corresponds to project versions and allows the developers avoid unnecessary manual work.

  1. A developer writes a testing request and includes all required information that he/she thinks to be useful for testing (bug reports, advice, check-points, etc.).

The actions of the QA specialist are the same.

We use both these algorithms in different projects. They are the verified and smoothly running schemes. Its usage gives us the confidence in information that we receive and increases the quality and speed of our work.

2.3 Features of the innovation introduction

As we promised, let’s return to the process of the Impact Analysis introduction in our QA life and answer the questions: how we performed this and what interesting moments we faced during this process.

The fact is that Impact Analysis in software testing is an effort to receive information from the developers that is based on project architecture knowledge to define testing scope, level, and sequence.

First, we want to share our knowledge and experience in such question: How can we explain to developers that we need this introduction?

The main developers’ “against” arguments are as follows:

  1. Why do you need it?
  2. Why do we need it? It is unnecessary work for us.
  3. Do it yourself, you know the project well.
  4. A lot of objections as for the table form and the filling and sending procedure.

Our “pro” arguments are as follows:

  1. We need it! We need it to estimate the testing scope correctly.
  2. To firstly test those parts, in which there are more important bugs. Here, such phrase works magically on the developers: as nobody likes when critical bugs are found at the last moment.
  3. No, we don’t know the internal project relations. Yes, you know them, at least partly.
  4. All procedure objections were solved at meetings and discussions.

So, after first opinions were received, we gathered another meeting as for the Impact Analysis and discussed all pros and cons. Surely, everyone understood that Impact Analysis is very useful and necessary both for testers and for developers. However, the list of features in projects was discussed for about a week. Such questions were discussed: how small should the features be? What features to merge and vice versa, what features to separate into smaller ones? Why not to make the list in the form of tree? What features are connected and what features are not?

Finally, we figured out and tested such rules:

  1. Remember: To introduce some innovation, such two conditions must be considered:
    • Some problem must be present. Explain the problem to developers and make sure that they have understood it and understood correctly.
    • The innovation must resolve some problem. Describe exactly how the introduction of a technique/tool/etc, which you offer, solves the problem.

Never try to introduce the innovation just because you like it. If there is no problem, don’t touch it.

  1. Do not get hard on developers. If you cannot explain the benefit and get them on your side, even the direct instruction from the manager won’t work for good.
  2. Provide information about the innovation from the third party source to the programmers. It can be an article, lection, presentation, etc. Also, it is possible to turn to an authoritative representative from other team, where this innovation is already used.
  3. It is a very good approach (for you and for others) to write out all pros and cons.
  4. Emphasize the benefit that developers and the whole project will receive from the innovation.
  5. Give a possibility for those developers, who support the innovation, to persuade their colleagues themselves. They will find a common language easier.
  6. It is useful to look at the situation from developer’s point of view. Try to imagine how his/her work changes due to these new duties.
  7. Demonstrate exactly how the work process will be constructed after the innovation introduction to developers. To perform this, you should understand clearly: what, how and why. Be ready that they will ask questions, a lot of questions, and that they will argue.
  8. Emphasize that they will not burn the candle at both ends using this innovation. Let them stop being afraid.
  9. Remember that they won’t give up immediately. Don’t expect that.
  10. Undertake all preparations that should be done before the innovation.
  11. Make sure that the developers’ wishes are taken into account. Don’t forget that you are in the same boat with them.
  12. Don’t let the work with innovation go without strict control and management, at least at the beginning.
  13. After a certain period of time, analyze the results of the innovation usage. Provide information based on facts for the general review. Show the efficiency of the innovation – it motivates.
  14. Thank. If the innovation increases efficiency, developers will thank you too.

3. Impact Analysis: our benefit

Not to sound proofless, we want to describe the real-life example and tell what practical benefit the introduction of the Impact Analysis procedure makes for us. This example is very simple. But it is noteworthy because it was noticed by one of our developers.

Later, we will use a certain quality metric that is called Quality Level (QL). It is the metric that we constantly use for our projects practically every day. For those, who does not face it very often or maybe has never heard about it at all, we will make a small digression and explain what it is.

QL is an indicator of the quality level of the tested version.

It is calculated by such formula:

Quality Level = (Passed\(Total-No Run))*100

Where:

  • Total means the total amount of the performed test cases;
  • Passed means the number of  test cases passed successfully;
  • Failed means the number of test cases passed unsuccessfully;
  • No Run means the number of not passed test cases;
  • N/A means the number of test that are impossible to run at the moment.

Example of the QL calculation:

Total =

361

%

Passed =

310

85,9

Failed =

26

7,2

No Run =

25

6,9

N/A =

0

0

Quality Level =

92,3 %

So, knowing what QL is, we can return to the example we want to make.

It consists in the comparison of two testing requests: before and after Impact Analysis. Both requests contained the request for testing of the state of a certain feature in one of our projects.

At first, let’s describe the result of testing for this request and the situation in the project before the Impact Analysis introduction.

A tester received the mentioned request and performed testing of the feature specified in the request. The feature worked perfectly. A tester didn’t find any bugs. He sent the testing response where he wrote that bugs were not detected and QL = 100%.

At first sight, everything was just perfect. But some time later (it is good that not after release), it was discovered that changes in this feature led to break in other feature, because they were closely related with each other.

Whose fault is it in such situation? Is it the fault of the developer who did not check the influence of introduced changes on the dependent feature? Or is it the fault of the tester who did not come to an idea to check the feature, which the changes could influence? It is a rhetorical question; there is no use to look somebody to blame. The important thing is that the quality of the product, on which both testers and developers were working, suffered.

According to the words of the same developer, who described this example, even if the additional information about what change affect had been present in this request, it would not have rescued the situation. Firstly, it is not obvious that the developer analyzed all possible influences of the change without a check-list. Secondly, the information about the influence of performed changes on other product parts was considered to be rather additional than the main one; that’s why, it was considered to be less important both by the tester and by the developer. When the tester, basing on his personal experience, nevertheless analyzed the influence and tested parts affected by the changes, the developer could just overlook this information in the testing response. Even more, it was written somewhere at the end of test response and did not catch the eye.

And how is this process performed now – after our innovation?

Firstly, a developer, when sending a request, analyses the influence of the changes. Secondly, performing this analysis, a developer never forgets about the features, which introduced changes influenced, because he/she will see all these features in the Impact Analysis table. Thirdly, what is the most important in this example, a programmer would never overlook information about testing of those parts of the product, which the changes influenced. Why? Because now, the QL value includes not only results of testing of the main feature, in which changes were made. Our new rule is to take into account everything that was tested in QL, i.e. the feature state and the state of everything that was marked by developer in the Impact Analysis table. And if the QL value is decreased because of some bugs found in the part, influenced by changes, developer will surely see it.

Thus, the estimation of the project situation became more accurate and corresponds to the reality. Now, our pseudo-100% won’t cheat the developer. Even more, developers won’t need to spend a lot of time and search for important information in our testing responses.

By the way, I want to say a few words about reports. The Impact Analysis introduction was a reason to perform one more quality change in our work. After we created Impact Analysis table templates in each project, formalized the procedure of its usage in testing requests and testing responses, we thought about such question: why not to standardize the requests and responses? We thought about it and did it.

After discussion with developers, we worked out the standards and rules for testing requests and responses (these are common for all team members). Now, our requests and responses have an accurate structure and identical design. This helps all members of the development team to spend less time on reading the received information, improve its perception and raise the quality of our communications.

Conclusion

So, we told you our story of introduction and work with Impact Analysis within our software testing tasks.

We have examined such things in this article:

  • Impact Analysis meaning and definition;
  • Why the necessity of the Impact Analysis introduction appeared;
  • Exactly how we performed such innovation – we discussed some examples from the projects;
  • Which difficulties we faced during the innovation introduction;
  • How we should resolve these difficulties;
  • What practical benefits from this innovation we received and continue receiving.

Let’s sum up what we achieved when we introduced Impact Analysis into everyday work:

  • The testing efficiency and the quality of the whole project increased: now, features that should be tested are not lost. The features influence on each other is accurately traced now. There are less unexpected and unpleasant surprises.
  • Time for testing decreased: now, the tester doesn’t beat his/her brains trying to guess what performed changes could influence in the tested feature. Also, the tester doesn’t test the unnecessary features, which the changes couldn’t influence.
  • We achieved the standardization of testing requests and responses because we created the table templates for Impact Analysis; we also created templates for requests and responses. This made our work much easier.
  • Developer’s responsibility increased: now, every developer before sending the testing request thinks what his/her changes could influence; thus, the developer takes the responsibility for the sent request.
  • Tester’s responsibility increased: now, every tester should analyze the Impact Analysis table and give a testing response of each feature specified in the table.
  • Testing tasks priority became clear known: the influence level is arranged in the Impact Analysis table, that is why tester knows what to test at first and what to test last of all.
  • There is more knowledge about the project: interaction of features and their influence on each other is now tracked, that is why testers and developers can know the project better.
  • Testers store experience on detection of dependencies in the project. Now, a tester can more correctly define, which part of the project the found bug refers to, using the statistic from the Impact Analysis tables.

With introduction of Impact Analysis and the formalization of work with it, we resolved those problems that we faced earlier, made our work more efficient and increased our products quality. Now, we feel ourselves much more satisfied by the general work process and its results. You can learn more about software Quality Assurance tasks we resolve in Apriorit in this section.

If you face the situations and problems that are discussed in this article, use our experience for your good. Take the knowledge we shared as a basis and work out a system, which would fit each member of your team. And then, the positive results will not keep waiting for them!

 

Continue reading with the next post What does a business analyst do.