System Integration Testing: Agile Perspective

System Integration Testing: Agile Perspective Vaibhav Sharma KrithikaSanthanam Infosys Limited (NASDAQ: INFY)

Abstract “Integrated whole is more than sum total of individual parts” – Anonymous • System Integration Testing aims at finding the defects that are introduced by virtue of bringing the individual modules together to make an “Integrated whole”. • With the ever increasing number of technologies available and the heterogeneity of the technologies involved, it has become absolutely imperative to have a rigorous System Integration testing in place to come up with software that meets the functional and non-functional requirements. • System Integration testing for Agile projects is especially cumbersome and tricky as the requirements remain far from clear.

Abstract (cont..) • Agile projects start with a given set of minimal requirements but as the project progresses and matures, more complexity is incorporated with each iteration or sprint. • Each iteration has its own set of expectations from the System Integration perspective that may or may not be explicitly foretold to the testing team. Main Database DB-1 DB-3 App-2 APP2 App-1 App-3 Main Application

Overview of a typical system • Initially in the development process Application App-1 is created which is used to add and edit the value from database DB-1. • App-2 which retrieves the data from the Main Database which may in turn get the data from other serving databases. • App-3 is also developed that may deal with the authorization and permission for different category of the users. App-3 is fed by DB-3. • As is apparent from the schema, App-1 is not the only application that affects DB-1. Its interaction with Main Database which in turn is determined by App-2 may also affect the outcome of events. This also holds true for the App-2 and App-3.

Challenges in testing Agile system from System Integration perspective • Testing a changing product in an environment where the requirements are dynamic can be quite frustrating for the Quality Assurance team. • The problem is augmented in the situations where requirements are not very well defined and the expectations are anything but clear. • System integration testing is done to identify the defects that have arisen due to the integration of sub-systems rather than the defects in a particular module. • Quality assurance team may be left in limbo as far as the nature and the source of the defect is concerned.

Problem Statement 1: Data Inconsistency • Typical to later phases of development. • It is said that except universe there is no such thing as a perfect closed system. Every thing however independent cannot act on its own and needs an outlet to the external environment. This remain true both in physical reality and in cyber reality. Main Database DB-1 DB-3 de novo creation of data App-1 App-3 Main Application

Continue.. Testing team is carrying out the testing of Main application but subordinate applications may also be active and may also be in process of affecting data. Quality Assurance team is supposed to carry out the testing of the Main Application which is taking the data from the Main Database. At the same time App-1 and App-3 may also be active and are changing data dynamically in DB-1 and DB-3 which in turn is affecting the data in Main Database. QA team may raise defects, root cause of which may lie with the modification of the data by other applications.

Proposed Solution… The best possible way to evade the problem of Data Inconsistency is to have the separate environment for the QA team and the access of all other teams (Developers, other QA teams and client) should be revoked from all the applications and databases that may directly or indirectly affect the data present in the Main Database. de novo creation of data, meaning testing team carries out the creation of data during execution, can reduce the risk of other applications changing the data to be used by the testing team drastically. A strict nomenclature should also be followed while creating the data which minimizes the probability of same data being created and leading to confusion.

Problem Statement 2: Indexing and Time lag Application Indexed Un-Indexed Table 1 Table 2 Indexing of the database table improves the data retrieval speed drastically. Indexing may not be possible either because of space constraints as indexed database is significantly more than a database without any index. Having indexes on too many columns can actually result in slowing of the data retrieval speed.

Continue… heterogeneity of the data sources may lead to conflicting results. It results in ‘sometimes’ being introduced in the defects like ‘Sometimes the data is being displayed while at other times it is not displayed. Happens due to different rate at which indexed and non-indexed tables are updated. Fields that are retrieving the value from the indexed tables will get the data far more quickly than the fields that are relying on non-indexed tables for its data.

Proposed Solution… The best way to deal with the situation is to have a detailed list of the UI fields that are coming from indexed and non-indexed tables. Dynamic nature of the application may render the above strategy un-feasible. Have the data check only after the threshold time is met i.e. all the fields have retrieved the data by that time so as to avoid any confusion. That time may be set based on the experience of the testing team. To increase the efficiency, first carry out the execution steps and once all the steps have been completed than only start with the verification part.

Problem Statement 3: Defect due to integration of upstream system App-1 App-2 App-3 App-4 Main Application Main Application is an integration of App-2, App-3 and App-4. App-1 is an upstream system that gives data or is in some other way affecting the interaction of App-2 and App-3 and hence Main Application.

Continue… To check the fidelity of the data flow to Main Application, testing team is provided the access to App-2, App-3 and App-4. App-1 which is upstream of App-2 may not be accessible. A defect in integration of App-1 may lead to a bug in Main application but it might be very difficult to identify.

Proposed Solution… User can emulate the data that is delivered from App-1 to App-2 and App-3. Pre-requisite here is that all the applications on standalone basis are defect free and bug is introduced only because of the integration with other systems. For a given input identify expected final output as well as the transient output from each system to other system. Since user has access to App-2 so user can provide input to App-2 which is expected output of App-1 and check for the output of Main Application. If the output is right that it can be categorically said that there in a defect in the integration of upstream system.

Conclusion… While working on project that follow agile methodology, we were confronted with issue where defects were not reproducible. This motivated us to identify the root causes of the defects which was far more subtle and complex. We identified the best practices that can zero down the defect cause at the fundamental level rather than the superficial one. These best practices go a long way in providing enough information to the developers as to where to look for the cause of the problem and in the process improving the efficiency of not just our team but also of development team.

References • Infosys project experience • Infosys resources (www.infosys.com)

Q&A: Vaibhav_Sharma09@infosys.com, Krithika_Santhanam@infosys.com 17

System Integration Testing: Agile Perspective