While it would be wonderful if we could have unlimited resources for testing – from our experience this is wishful thinking. Choices have to be made, and most of the time we go after issues that could prove critical for the business. When we define risk, we look at two dimensions as defined by HPE ALM (https://saas.hpe.com/en-us/software/alm): Business Criticality and Failure Probability. The first measures how crucial a requirement is for the business and the second indicates how likely a test based on the requirement is to fail.

Assessing risks 

While there are many ways to approach risk assessment, we usually use HPE ALM because it’s a reliable tool and saves us a lot of time. It has an integrated questionnaire that allows us to determine the risk and functional complexity of a requirement and give possible values for each criterion plus a weight assigned to each value. This allows us to evaluate the testing effort and determine the best testing strategy.

In assessing risk, comparing the changes between two releases or versions is fundamental for quality assurance to identify the risk areas, reducing the total testing efforts, managing project risks, bringing lots of value with less effort and more efficient testing.

The testing team can explore the risks and provide their feedback on the test execution and whether or not to continue testing.

Advantages vs Disadvantages

For some projects, the big challenge is to accommodate the need to reduce development time, while maintaining the scope. Under these conditions, a smart risk testing approach is key in allowing the testing team to develop their software in a timely manner, making the testing effort more efficient and effective.

Dealing with the most critical areas of the system first will counteract the additional time and costs of solving those issues at a later stage in the project. And maximize on the fact that the time is spent according to the risk rating and original mitigation plans.

A faster time to market and reduction of cost per quality are more easily achievable with this risk-oriented approach.

Proper risk identification in the analysis process, prevents the negative impact that assessing a risk as too low or based on too subjective criteria, could have.

Identifying potential issues that could affect the project’s cost or outcome, create an efficient risk-based testing work and ensure better product quality.

Overall Benefits

Using a testing approach that takes risk into account, promotes some of the best practices in risk management, while conducting fewer tests with a more focused view on critical areas, higher testing efficiency, and increased cost-effectiveness.

We invite you to test these benefits out for yourself and try on this software testing approach for size. If the size fits don’t hesitate to share some of your best practices in risk assessment software with us at Euro-Testing.

Or if you are not sure what testing approach would suit you best, let us know here! And we will tailor the best solution for your needs.

The context

One of our banking sector clients, asked us to help them with a solution which implied the upgrade of JIRA.  We had to upgrade from JIRA 313 to JIRA 7010 while going through all four intermediary versions.  All this, while the three environments (DEV, QA and PROD) had to stay synchronized.  

Needless to say, this task was labeled as mission critical by the client.

The problem

The main challenge was not losing data along the migration and maintaining the client’s current workflows. While you might say that this is something typical in the day-to-day activity of a software testing company, it’s also where the problems started showing up.

By default, Jira does not come with a built-in configuration porting mechanism from one environment to another. This means we have to rely on an JIRA add-on. Yet add-ons sometimes come with bugs and/or compatibility issues of their own. We got a first-hand taste of this when, with only three weeks left before the project deadline, we noticed that part of the data we tried to migrate became corrupt. Also, something was blocking the synchronization of environments. While we managed to fix part of the problems the main issue remained: customer IDs were not in synch.

The road to the solution

From what we could tell, the problem pointed to configuration management actions – the JIRA add-ons we used were not working as expected. Quite a predicament – it seemed that the add-ons were both the problem and the solution at the same time.  

We had to look for a new add-on which would offer us a good analysis of all the changes we were about to make during configuration deployments. Also, it had to shows how they would impact the existing configuration.

After some research, we came across Botron’s Configuration Manager Plugin (http://www.botronsoft.com/products/configuration-manager/ ). Simply put, it enables automated deployment of configurations across JIRA instances. It also allowed us to take system configuration snapshots: basically the whole configuration of the JIRA instance (projects, workflows, and custom fields). These could then be used to merge the configuration of one JIRA instance to another.

This may come as a surprise, but it was the only tool in the market capable of doing this the right way.

Long story short, it fixed our synchronization issues. We successfully migrated all relevant elements from user IDs to validations and other functions.

Last but not least, it also comes with a friendly user interface and a reliable (and fast) team behind it.

All in all, it’s a time saver.