Ngày nay, các hệ thông tin như Lập kế hoạch tài nguyên công ti Enterprise Resource Planning (ERP), Quản lí quan hệ khách hàng Customer Relation Management (CRM) và Quản lí dây chuyền cung cấp Supply Chain Management (SCM) đều rất lớn, móc nối lẫn nhau qua một số ứng dụng và nền, và lan toả qua các tổ chức khác nhau. Những hệ thống phức tạp và lớn này phải được thiết kế và kiểm thử cẩn thận.

Nếu loại hệ thống này chỉ kiểm thử theo phương pháp truyền thống như kiểm thử đơn vị và kiểm thử chức năng, thì không thể nào xác định được liệu toàn thể hệ thống có làm việc tốt hay không. Việc tìm ra lỗi sau khi toàn thể hệ thống được thực hiện đầy đủ sẽ rất tốn kém, đặc biệt bởi vì nhiều tổ chức sẽ phải được tham gia vào việc tìm và sửa vấn đề. Kiểm thử tích hợp được cần tới vì mục tiêu của nó là thu được cái nhìn sâu vào chất lượng của việc thực hiện toàn hệ thống. Bằng việc thêm kiểm thử tích hợp vào tập các kiểm thử truyền thống, nhiều rủi ro có thể được nhận diện và sửa.

Kiểm thử tích hợp bao gồm vài bước. Bước đầu tiên là xác định chiến lược kiểm thử. Mục đích là xây dựng là “cách tiếp cận kiểm thử hợp tác”, bởi vì thường có vài tổ chức tham gia vào phát triển hệ thống toàn bộ. Không có chiến lược kiểm thử, không ai sẽ chịu trách nhiệm cho toàn thể hệ thống, và có nguy cơ là các hệ thống sẽ làm việc tốt theo cách riêng của nó nhưng không làm việc tốt khi tổ hợp với các hệ thống khác. Do đó, kiểm thử tích hợp là cần thiết để kiểm thử việc tích hợp thực tế của toàn hệ thống như một mục tiêu, và để tạo ra một nhóm trung tâm chịu trách nhiệm cho kiểm thử. Điều khác cần xem xét trong chiến lược này là ở chỗ làm việc chức năng của các hệ thống nên được chứng minh trước khi bắt đầu kiểm thử tích hợp. Trong trường hợp này kiểm thử tích hợp có thể hội tụ vào kiểm thử việc thực hiện các đặc tả và kiểm thử kết cấu nền. Nếu tiền điều kiện không được thoả, kiểm thử tích hợp thường trở thành kiểm thử chức năng đơn thuần của hệ thống. Điều cũng quan trọng là phạm vi của kiểm thử tích hợp phải được xác định rõ ràng nếu không những thứ không liên quan khác có thể được đưa vào trong kiểm thử tích hợp và làm cho nó phức tạp hơn là nó phải vậy.

Trao đổi về kiểm thử tích hợp là quan trọng. Những người tham gia thường không biết lẫn nhau vì họ làm việc trong các tổ chức khác nhau với các hệ thống khác nhau. Điều quan trọng là mọi người hiểu và tham gia vào kiểm thử tích hợp để tránh bất kì trao đổi lầm nào hay vấn đề nào về sau. Trong tình huống lí tưởng, môi trường kiểm thử phải được thiết lập, nơi đồng nhất với môi trường sản xuất và được chuyên dành cho tích hợp. Thường các môi trường khác nhau được gắn lại với nhau, điều tạo ra kết quả không tin cậy của kiểm thử.

Bước thứ hai là Lập kế hoạch. Vào lúc này người quản lí, người chịu trách nhiệm cho kiểm thử tích hợp phải được bổ nhiệm. Người quản lí này nên chắc chắn rằng mọi tổ chức có tham gia đều phải có một điều phối viên để làm việc cùng để đảm bảo việc tích hợp sẽ làm việc thông suốt. Người quản lí tích hợp phải biết tất cả về lập kế hoạch của các hệ con để thiết lập kế hoạch tổng thể cho kiểm thử tích hợp. Việc lập kế hoạch tích hợp này là bắt buộc. Nếu một trong các hệ thống bị chậm, trình tự kiểm thử và ưu tiên bị ảnh hưởng, điều gây ra hiệu quả tác động dây chuyền (domino) cho lập kế hoạch. Điều này đặc biệt gay cấn cho tích hợp, vì dây chuyền mạnh ở chỗ nối yếu nhất của nó. Vậy, việc lập kế hoạch cho kiểm thử tích hợp phải được chuẩn bị bao gồm tất cả các phần phụ thuộc và sẽ đủ thời gian trong trường hợp bị trễ.

Bước thứ ba là về thiết lập trường hợp kiểm thử. Tri thức chuyên gia và kinh nghiệm của những người hỗ trợ cho kiểm thử nên được dùng để phát triển tập chung các trường hợp kiểm thử. Mọi kiểm thử viên đều phải đồng ý với tập các trường hợp kiểm thử để đảm bảo toàn thể hệ thống sẽ được kiểm thử. Trong khi chuẩn bị sẽ có các vấn đề cho nên người kiểm thử phải nhanh chóng tìm ra giải pháp, điều có thể tác động tới các qui trình của một trong các hệ thống. Người ta khuyến cáo rằng người quản lí tích hợp cần thiết lập một diễn đàn nơi tất cả các đại diện, mỗi người từ từng tổ chức tới gặp gỡ. Diễn đàn như vậy đảm bảo rằng mọi người đều biết tình trạng của kiểm thử tích hợp và những vấn đề có thể trước khi việc kiểm bắt đầu.

Bước thứ tư là thực hiện kiểm thử tích hợp. Đây là khoảnh khắc mấu chốt vì nó cần chú ý  đặc biệt. Bởi vì độ phức tạp của môi trường kiểm thử, điều quan trọng cần thực hiện điểm vào môi trường để chắc chắn mọi thứ làm việc hoàn hảo. Sau đó, việc kiểm thử có thể bắt đầu, và trong những kiểm thử này các giai đoạn truyền thống có thể được áp dụng theo trình tự các kiểm thử. Liên quan tới bất kì vấn đề nào nảy sinh, vấn đề tích hợp phải được làm tài liệu và truy nhập được với các bên tham gia. Khoảnh khắc thực hiện kiểm thử phải được lập kế hoạch cẩn thận bởi vì tất cả mọi tổ chức đều tham gia, điều tuyệt  đối cần thiết là có tổ hỗ trợ thường trực, như tổ kết cấu nền và những người phát triển để cung cấp hỗ trợ. Điểm cuối cùng cần chú ý là ở chỗ phiên bản của đối tượng kiểm thử và kết cấu nền kiểm thử cần được kiểm tra bởi vì với kiểm thử này cả phần mềm và kết cấu nền đều có thể phức tạp và cần chú ý phụ thêm.

Bước thứ năm là báo cáo kết quả. Có nhiều cách báo cáo từ nhóm này sang nhóm khác bằng việc dùng kênh thích hợp. Trong hệ thông tin phức tạp, việc thực hiện kiểm thử tích hợp là cách duy nhất để đảm bảo rằng kết quả cuối cùng bao gồm tất cả các cấu phần từ mọi hệ con.

—-English version—-

Integration Testing

Today, information systems such as Enterprise Resource Planning (ERP), Customer Relation Management (CRM) and Supply Chain Management (SCM are very large, inter-linked through a number of applications and platforms, and spread over different organizations. These large and complex systems must be designed and tested carefully. If this kind of systems is only being tests by the traditional method such as unit test, functional test, then it is impossible to determine whether the whole system will work well or not. Finding defects after the entire system is fully implemented will be very costly, especially because several organizations will have to be involved in the finding and fixing problems. An integration test is needed as its objective is to gain insight into the quality of the implementation of the entire system. By adding an integration test to the traditional set of tests, many risks could be identified and fixed.

An integration test consists of several steps. The first step is determining a testing strategy. The purpose is to construct a “cooperating testing approach”, because there are often several organizations involved in the development of the total systems. Without a testing strategy, no one will be responsible for the entire systems, and there is a chance that systems will work well on their own but not in combination with other systems. Therefore, integration test is necessary to test the actual integration of the entire systems as an objective, and to make one central group responsible for testing. Another thing to consider in the strategy is that the functional working of systems should be proven before the start of the integration test. In this case the integration test can focus on testing the implementation of specifications and the testing of infrastructure. If this precondition is not met, the integration test is often become a mere functional test of the systems. It is also important that the scope for the integration test has to be clearly defined or else various unrelated things may be included in the integration test and make it more complex than it has to be.

Communication on the integration test is important. The people involved often do not know each other as they are working at different organizations with different systems, It is important that everybody understand and get involved in integration test to avoid any miscommunication or any problem later on. In the ideal situation, a testing environment must be established, which is identical to the production environment and is dedicated to the integration. Often the various environments are just tied together, which causes an unreliable outcome of the test.

The second step is about Planning. At this time a manager, responsible for the integration test must be assigned. This manager should make sure that all organizations involved must have one coordinator to work together to ensure the integration will work seamlessly. The integration manager has to know all the planning of the subsystems in order to setup the overall planning for the integration test. This integrated planning is mandatory. If one of the system is delayed, the sequence of the tests and priorities are affected, which causes a domino effect to the planning. This is especially critical for the integration, as a chain is just as strong as its weakest link. Thus, the planning for the integration test should be prepared including all dependencies and with enough time in case of delay.

The third step is about set up test-cases. The expertise and experience of the people supporting the test should be used to develop a common set of test cases. All testers have to agree on the set of test-cases to ensure the entire system will be tested. During preparations there will be issues so testers must quickly find solution which may impact the processes of one of the systems. It is recommended that integration manager establish a forum where all representatives, one from each organization meet. Such a forum guarantees that everyone knows the status of the integration test and possible problems before testing start.

The fourth step is to execute the integration test. This is a critical moment as it needs special attention. Because of the complexity of the test environment, it is important to perform an intake on the environment to make sure everything work perfectly. After that, testing can begin, and in these tests the traditional stages can be applied to the order of the tests. Regarding any issue that arises, integration issues have to be documented and accessible to involved parties. The moment of test execution must be carefully planned because of all the organizations involved, it is absolutely necessary to have support teams stand by, e.g. Infrastructure teams and developers to provide support. The last point of attention is that the version of the test object and the test infrastructure need to be checked because with this test both the software and the infrastructure are likely to be complex and needs extra attention.

The fifth step is reporting the results. There are several ways of reporting from one group to others using appropriate channel. In complex information systems, the execution of integration test is the only way to ensure that the end result consists of all components from all subsystems.