Risk-Based Software Testing

In order to ensure the proper quality of software in the field of insurance, medicine, banking, and other spheres, it’s needed to perform not only classical testing by specified parameters, but also execute a lot of tests based on real risks.

For such tests, it is necessary to choose the riskiest moments of the developed software logic. This method allows you to foresee all negative scenarios of web product behavior and to quickly implement all business goals that were set by the client.

In order to use certain examples and methods for problems solving, we will analyze a classic Internet acquiring system testing.

Risk Group at the Start of the Development

The client’s wish – the web product functionality is focused on the interaction between bank and individuals.

The obtained risk is the potential loss of some individuals due to the small demand of the product web version, unlike the mobile version of the software (client-bank application).

QA’s arguments – it’s current statistics of user preferences based on feedback and the process of distributing the audience according to the number of downloads of the web and mobile software version.

As a result, most individuals prefer the mobile version, as their smartphones are always nearby. It’s really easy to make financial transactions, many services and parameters became available with the help of a fast authorization system. It is a very important fact that the mobile version has a set of the most popular and available components.

Legal entities need completeness of the provided data, the ability to work with the parameters of downloading, uploading the tables and other items of big data. Therefore, they choose the web version.

The company’s solution – the capabilities of the mobile application are designed according to the individuals’ needs.

Now we will consider choosing the right testing strategy.

Someday, all companies come to the same conclusion: it is necessary to finally organize well-designed testing. The process of creating such a strategy is an extremely important stage in the development of any software. And such a conclusion sometimes comes through personal and painful experience.

It is very deceptive to ignore the role of testing and choosing a strategy for big projects. The nature of the testing process should be constantly chosen for the established business goals and features of the project, otherwise, it will be impossible to achieve positive results while interacting with the software.

Let’s take, for example, the classic mobile banking application and its web version. At the beginning of the project, you need to choose the right testing strategy, based on the requirements with an extremely low level of detail.

The well-known checklists were used there in order to minimize the time intervals for testing and support of the checked basis. But after a while simple checklists couldn’t cope with the tasks assigned to them because of new functionality, the implementation of acquiring, and authorization via SMS, etc.

Gradually, new specialists joined the team of testers and there was a need to give them new information and coordinate subsequent actions. Moreover, there was a risk of the work logic regression with each complication of the functionality. The automation of regression tests became more necessary since new test suites appeared.

To conclude, the testing strategy can change a lot according to the project specification and the number of development stages.

The testing strategy needs to be chosen, taking into account the goals of the current project in order to cover the developed web product with the test, and answering such questions as “when”, “what” and “where” will be checked. Testers always know the current stage of testing and where they need to go – that’s all on the basis of the strategy that was created before.

Also, it helps to emphasize the main aspects of any project. It is logical to assume that the release of any mobile product or big banking CRM-platform will need various tests.

Peculiarities and Components of Risk-Based Tests

Risk-based testing components

There are several kinds of testing strategies which are chosen to reach some goals:

1. Requirements-based testing;
2. Methodical checks;
3. Reactive strategies;
4. Consultative strategies.

If one works with the difficult products from the banking services it is necessary to identify strict requirements while creating a strategy; it will be the basis for the project team in the future. And remember that effective tool is a test, based on requirements.

One of the strategies of requirements based testing is risk-based tests. And don’t forget that only those parts that are at greater risk should be tested at first.

Risk is a potential negative consequence of some incorrect functioning of a system. Any consequence can be a risk in the case of two things: negativity and possibility.

All risks can be divided into 2 types:

• Web product risk. It can be controlled or uncontrolled depending on the situation. The controlled one can be described as functionality complicating which causes regression and so the project team must solve some new problems (for example, creating backup files, some information processing, special message output). Uncontrolled risk is the situation when current web product logic depends on external systems and there is a recorded failure of their performing.
• Project risk. Some group of difficulties and unexpected situations which can happen on a project. In order to solve such a kind of problems specialists often use a risk-based methodology which allows identifying earlier the number of such risks, group them according to the importance and execute necessary tests. After some checks are performed the client will get analytical metrics which contain a detailed analysis of the tested things, executed test cases, and information about further bug identifying in related functionality.

The risk-based methodology can be divided into 4 stages:

1. Risk Identification – at this stage you need to spot all potential risks and make the list;
2. Risk Assessment – here you need to analyze risks according to their priority;
3. Risk Mitigation – at this stage, you have to define the level of risks testing;
4. Risk Management– also you should decide what to do in such a case if the risks that weren’t found before will be identified during the new block of functionality deployment.

The whole project team works on the risks during the so-called brainstorm sessions. It means that such a team needs to include not only specialized developers but also business analysts, project manager, technical architect, QA specialist and even a client representative who need to get extensive knowledge about the software development.

Moreover, for a complete understanding of the risk-based methodology, we will analyze the way of Internet acquiring platform testing.

Compatibility With Risks

(Based on Internet Acquiring Methodology)

For example, we have the following requirements:

• The number of simultaneous connections can’t be more than 1000;
• Complete safety of financial transactions processing;
• Only the person who makes a financial transaction has personalized access to it;
• Support of SET (Secure Electronic Transaction) safety standard.

The following situations can be in a group of risks:

• system failure in the case of the maximum number of simultaneous connections;
• if hackers use SQL injection while manipulating with transactions;
• unauthorized access to third-party transactions while editing the URL parameters;
• loss of confidential data in case of lost connection during financial transactions;
• applying of the expired certificates while providing the SET platform.

Also, there’s a group of organized risks:

• unplanned system failure because of external architecture reject;
• work with cases which are difficult to reproduce and can’t be found in the tested environment a priori.

From the all listed above, we can conclude that every risk comes from the requirements which are in the system but aren’t confined to it. During the testing process, some risks can be deleted or offset according to the project’s aim and requirements to the developed system.

There’s a special test suite for any product risk provided that any requirement or risk will be covered with at least one active test case. It’s possible to extend the test suite to the necessary level of detailing taking into account the aims of testing.

Also, there’s a list of actions for any organizational risk. And these actions allow reducing the negative impact of such risk to the developed product.

The Nature of Risk Assessment and Management Methodology

Nowadays QA specialists use several risk assessments and management: lightweight methods (PRAM and PRISMA) and more classic (formal) ones – FTA and FMEA.

If the FMEA method is used than the team of developers should check all created processes and test system modules interaction where an unidentified bug can be and which is able to cause a worse performance of the software.

In the case of FTA usage, all the reasons that can be a bug accelerator inside the system business processes are analyzed. The analytics is built from the main risk to the easiest.

The only difference between these two methods is that the first one is meant for software functionality and the second one – for the nature of business processes.

Moreover, there are some other flexible approaches except these traditional and time-consuming processes. For example, PRAM method (Project Risk Analysis and Management) and PRISMA (management of software risks).

With their help, we can easily combine strategies based on risks and requirements. Requirement specifications are used as basic information while working with these methods but the other requirements or suggestions can be added during testing.

The lightweight methods are very similar to the classic ones. They help to focus on commercial and technical risks, analyze all risks and factors that can influence the undesirable situation.

Conclusion

Risk-based testing facilitates the coverage of the most dangerous and risky parts of software with qualitative and volume test cases so the level of undesired processes and situations is reduced. Such testing is a winning combination while working with difficult products that have huge business logic.

Such tests that quality control companies perform are very popular in different spheres like the banking industry, insurance companies, as well as while creating a difficult corporate CRM system.