[Software Testing] What is the difference between bank test projects VS regular projects? How to do it?

---

Preface

What is the difference between bank test projects and regular test projects?

1. Characteristics of banking applications

Multi-system integration, each testing task may involve multiple systems. Testers generally conduct testing based on business lines rather than applications.

Complex business processes
Powerful auditing
Massive data
Detailed transaction records
Real-time and batch processing
High concurrency
High-rate transactions per second
Secure transactions

Disaster recovery: When the main server or a certain server goes down, the system can still continue to run.

The ten points listed above are the most important features of the banking system. Based on these characteristics, we need to consider when testing:

1) Full coverage of all banking workflows and business needs
2) Application performance aspects
3) Application security aspects
4) Data integration
5) User experience
We will talk about the specific testing method later.

2. Typical stages of testing bank applications

1) Requirements collection

This stage mainly obtains requirements through requirements specifications, design documents, past cases, and communication with other project team members.

2) Requirements review

After the business manager completes the requirements document, he will hold a requirements review meeting. Participants generally include business managers, project managers, development leaders, test managers, testers and other roles.

From experience, most developers only focus on one thing in meetings, that is, what should this function be like? They rarely ask other questions, so this requires us testers to pay attention to or ask the following questions:
Project background, why should this requirement be added or modified? What problem does the customer hope to solve through this requirement? Is the solution reasonable? Is there a better way?

Demand details, what is this demand? If there are any unclear terms, you can bring them up for the business manager to understand.

Test plan, how to test this requirement? What are the criteria for passing the test?

Risks, what risks may there be in developing this requirement, what risks may be encountered in this testing task?

How does each risk need to be addressed? Under what circumstances is coordination required by the test manager?
Test cycle, when will the test start and how long will it last?
Interface person, which systems are involved in this requirement, and who is the interface person for each system?

Test environment. The bank's test environment is maintained by a dedicated person. You need to communicate and coordinate with him in advance.
The above points of concern can be remembered through the 5W1H principle when memorizing, namely why, what, when, who, where, and how.

Reminder: Read the requirements document before the requirements review meeting if possible.

3) Test requirements analysis and test case writing

At this stage, quality test engineers extract business scenarios from requirements documents (functional specifications or test cases) (in most cases, they require repeated communication with development). I am used to organizing business scenarios into excel to ensure requirement coverage.

Because bank projects usually involve multiple systems, and each system has a different division of labor. Therefore, I usually use a combination of mind maps and visio flow charts to study and confirm the data transmission between various systems and modules.

Includes:
Which systems are involved?
What piece of business does each system handle?
Where does the request start and end?
What data is transferred in each request?
How do we test or ensure that these requests are handled correctly when they succeed or fail?

This method can be said to rely on the idea of ​​​​white box testing, or it can be said to be a kind of gray box testing.

4) Test plan writing and review

Regarding the test plan, in some cases the test manager of the bank is responsible for writing it, and in other cases the test leader among the outsourced personnel is responsible for writing it.

In terms of review, after the test plan and test cases are completed, the test manager will take the lead and convene the project manager, test managers of other projects, test environment maintenance specialists, and test executors for review.

The meeting mainly focused on whether there were any omissions in the test plan, whether the test cycle was reasonable, whether the test environment could be arranged as scheduled, etc.

5) Functional testing

In an outsourced testing model like a bank, how to ensure test quality needs to be carefully considered, especially in terms of workflow.

Let me give you two examples:

First example:
During the test process, some banks will require developers to write three documents. These three documents need to be included as attachments during the test process. Send to test manager for review.

"Joint Debugging Test Cases": Each system developer needs to write and pass the self-test before submitting the test. After passing the self-test, you need to attach the screenshot of the passed test to excel.

"Joint Debugging Test Report": similar to a regular system test report.

"Impact Analysis": Tell us in the document where the requirements have been changed this time, how they were modified, and where this modification affects. This document can help us clarify the scope of testing and reduce missed tests.

Second example:
During the testing phase, some banks will require developers to note the cause of the bug, how to fix the bug, and impact analysis on certain bugs.

Both examples are about work processes and are mainly issues that managers need to think about. However, as ordinary testers, we can also learn from it and consider/ask why this bank does this instead of that? What problem do they hope to solve? Of course, if you have the opportunity, you can also study their solution effects.

6) Performance testing

The bank's performance testing is generally completed by the bank's internal performance testing specialists.

The following is the most comprehensive software testing engineer learning knowledge architecture system diagram in 2023 that I compiled.

1. Python programming from entry to proficiency

2. Practical implementation of interface automation projects

3. Web automation project actual combat

4. Practical implementation of App automation project

5. Resumes of first-tier manufacturers

6. Test and develop DevOps system

7. Commonly used automated testing tools

8. JMeter performance test

9. Summary (little surprise at the end)

Every fall is an opportunity to grow, and every failure is a stepping stone to success. Don't be afraid of making mistakes, and don't be afraid of being laughed at, because these will be the source of motivation for you to move forward!

On the stage of life, everyone has his or her own unique role and mission. Believe in yourself, develop your greatest potential, and add your own color to the world!

Only by continuous learning and progress can we maintain vitality and passion and stay young forever. We must believe that no matter our age, as long as we have dreams and pursuits, we can all create new brilliance!