QA Journal: Risk-Based Testing

It is important to use risk-based testing to ensure the quality of the information product in medicine, insurance, banking and other industries along with other testing methods. The most risky areas of creating software are the objects for the test. This allows to anticipate negative scenarios and successfully implement the customer’s business goals.

In this article we will tell you how SimbirSoft works with risks, what risk assessment and risk management techniques we use and how they improve business of our clients.

First Risks

For the beginning, we will give an example from our practice in the development for the banking sector.

Customer proposal: focus on the web version of the bank for individuals.

The risk we identified: the possible loss of the audience due to the low demand of the web version among individuals in contrast to the mobile client-bank.

Our arguments: statistics of user preferences based on reviews and audience distribution by mobile and web versions.

Conclusions: the mobile version is more convenient for individuals, since the phone is always at hand. Operations are performed quickly; the authorization system allows access to all convenient services. In this case, quick access to a limited set of the most popular features is important.

Legal entities appreciate completeness of the functions provided, the ability to upload, print and work with a large amount of information. The web version is more convenient for these purposes.

Our solution: focus on the mobile client-bank for individuals. At the beginning of the project it is important to choose the right testing strategy. Let’s consider why it is important and how to choose it.

How to Choose a Testing Strategy

Sooner or later, all companies face the need to organize the testing process and come to understand that building its strategy is an important step in software development. Sometimes they understand it through their own bitter experience. It is especially dangerous to underestimate the role of testing and selecting a strategy when developing large-scale projects. The testing process should be chosen for the business goals and specifics of the project, otherwise it will not lead to positive results in a month or a year.

For example, consider the testing of mobile and web applications for the bank. At the start of the project, we selected a strategy based on requirements with a low level of detail. We used checklists to reduce the time for testing and support of the test basis. With the growth of functionality, the addition of acquiring, SMS-authentication and notification, more complex systems, checklists could no longer cope with their task. Over time, more and more QA specialists joined the team; it was necessary to transfer information and coordinate their actions. With the complication of the product, any change could affect the related functions, that is, the risk of regression increased. There was a need to automate regression tests, so we switched to test cases.

Conclusion: depending on the project, its specifics or the development stage, the testing strategy changes.

The strategy must be selected under the project objectives in order to ensure the quality of the product being produced in the best way. It answers the questions “what”, “where” and “when” will be tested. At any point in time you know where you are and where you will come in the future according to the strategy.

The business goal may be provision of the customer data security, as well as the software itself at the production stage. Security begins with the development process and continues through the testing phase.

For example, on one of the projects, we created a secure environment for development and testing, deployed an infrastructure that met all requirements and helped protect data. We requested certified tokens and personalized flash drives for each QA-specialist to access the test infrastructure. So we provided the business goal of the project in software security and kept the confidentiality of customer and user data.

Due to the testing strategy, you can focus on the really important aspects for a particular project. It is logical that the release of a mobile game or a complex banking CRM system requires different approaches to testing.

Best Testing Strategy for Fintech

We at SimbirSoft in our practice used the whole range of development methodologies but flexible technologies always remain priorities for us. And even in cases when, for a number of reasons, it is not possible to use them, the team adopts the best practices and applies them in their daily work. Testing becomes an integral part of the whole process and flows into the general workflow. In this case, it is responsible not only for the quality of the product, but even for the quality of the whole process of work.

Methods we use:

• flexible planning and preparation of internal releases;
• user story preparation;
• holding status rallies;
• holding retrospectives.

The testing strategy fully reveals itself in projects with complex business logic. For example, software for informational support of banks, building an Internet-acquiring system, an automated marketplace. In such projects, it is important to apply a suitable testing strategy, since the price of some errors can lead to real losses and greatly affect the company’s reputation for the worse.

Also, additional testing may be added to the main objectives of the testing: finding defects and checking software for compliance with requirements. For example, it is important for banks to quickly implement new requirements of banking regulatory authorities. This means that timely testing with the required quality for critical tasks will be added to the main goal.

Now let’s talk in more detail about how we build a strategy and why we often choose risk-based testing.

Advantages of Risk-Based Testing

There are several testing strategies that are chosen for specific goals:

• based on requirements;
• methodical;
• reactive strategies;
• advisory strategies.

In the case of working with projects with complex business logic, it is necessary to define stringent requirements when designing systems on which testing is subsequently built. A suitable tool is testing based on requirements.

One type of requirements-based strategy is risk-based testing. In this case, first of all, the parts of the system functionality that are most exposed to risks are tested. Risk is a possible negative consequence of system malfunction. The consequence is a risk in the presence of two components, such as opportunity and negativity.

There are two types of risks:

1. Product Risk

It can be manageable and unmanaged. In the example above, we are faced with manageable risk: rapid growth and complexity of functionality, and therefore the probability of regression increased. Here we solved the problem by having a clear test base and subsequent automation. The risk that we cannot influence is dependence on external systems and their failure in the integration process. Here we lay the events that will reduce their impact on our system. For example, the use of backup, exception handling, warning output for the user.

2. Project Risk

For example, on the project we were faced with the fact the customer had not worked with a distributed team before, and therefore the workflow used did not meet the requirements and created additional communication problems: lack of understanding, duplication of tasks, execution of mutually exclusive tasks, and so on. We agreed on the restructuring and improvement of the process: we reworked the workflow, introduced all the team members, held rallies, presentations and retrospectives. As a result, the work went in the right direction.

The risk-based approach allows you to gather a certain amount of risks, test risks with high priority in a short period of time and continue to provide the customer with metrics of how well they have been tested, showing the number of planned and completed cases and the number of defects.

The implementation of the risk-based approach on the project takes place in four stages:

Risk Identification — at this stage it is necessary to identify the risks and get their list.

Risk Assessment — here we analyze the list and classify it by priority.

Risk Mitigation — at this stage we determine how deeply we will test the risks.

Risk Management — here we decide how we will continue to work with them and pass them, to identify new risks.

Risks are identified and evaluated by a group of stakeholders during brainstorming sessions. The team should include business analysts or carriers of knowledge about the system from the customer, developers, manager or project manager, architects, and QA-specialists. In order to identify and assess risks, we involve, among other things, information security specialists, employees who work directly with the current system, a business analyst who is immersed in processes.

In Conclusion

Risk-based testing allows you to cover the most risky areas with test cases, thereby reducing their impact and likelihood of triggering. This is the most winning strategy for systems with complex business logic and a high cost of error. The solution is suitable for the banking sector, insurance companies, complex internal CRM-systems of medical profile. Using the risk-based approach, we also work with project risks, thereby improving the overall process of testing and project management.

Not sure about working with the remote team of developers? Learn about 7 most common IT outsourcing issues in our special article 7 Sins of IT Outsourcing

That’s how we work with apps that needed to become perfect and there is only a month for that: How to Bring an App Back to Life After Failed Development in Just a Month

Follow us on Medium! Never miss an article!