Hi All,
I have got a doubt regarding the difference between String Testing, Scenario Testing and Integration Testing. Where does each of this start and finish. Especially in the component I work for (Project System), it might be a bit difficult to distinguish this and it might be the right example (for difficult) to think on when trying to give answer.
I have been searching for the answer in the community and there are a lot of posts here and there referring to any kind of testing, from unit testing to regression testing. I think it would be great if we can all work on having a single post that explains the differences between: Unit Testing, String Testing, Assembly Testing, Scenario Testing, Integration Testing, User Acceptance Testing and Regression Testing.
I am giving my two sense here to try and build from it, but especially on String, Scenario and Integration I would like you to come in.
- Unit Testing: The most basic form of testing. You do this testing to test your configuration items. For example in PS, you configure your project profile and then you unit test that you can select it when creating a project definition and it defaults the information as per configuration. Or in FI you configure your company code and then in the front end you test that you can select that company code when trying to do a posting. You finish the test when you see you are able to save the transaction without any errors relevant to that configuration item you are testing. However, because in PS the SAP component is highly integrated, there is very little or nothing you can do with no integration with other components, ie, to create the Project Definition, your first object, you would already need some FI, MM and SD basic configuration to be there, depending on your business requirements: Company Code, Profit Center, Cost Center, Business Area, Functional Area, Plant, Sales Organization, Distribution Channel, Division... So you would somehow be doing integration testing because if any of those objects was not properly configured, you would not be able to create the Project Definition.
- String Testing: You test some configuration items within your component one after the other. Many times when trying to do Unit Testing you will see yourself forced to go straight to String Testing. For example, you cannot test the creation of a WBS Element if you don´t create a Project Definition first, so to create a WBS Element in Unit Testing you have somehow jumped to String Testing. A more meaningful String Test in PS would be the creation of the Project Definition, WBS Element, Network, Activity, Activity Element. You wouldn´t include the creation of the Material Component because then you would be jumping to Integration Testing already (with MM).
- Assembly Testing: Here you test your SAP component with the RICEFWs (Reports, Interfaces, Enhancements, Forms and Workflows) that were required by business in you area. For some of them you will have to do some Integration Testing in order to be able to test, like for instance an interface that sends Actual Costs (FI, MM, CO) or Commitments (CO) from SAP to an external system. For others you just need to have gone through your Unit Testing, ie, testing an enhancement that adds a new customer tab and customer field to the Project Definition.
- Scenario Testing: for this testing we need business to start getting more involved and define for us the scenarios they want to test. An scenario in an international company can be to do a purchase from one groups company code to another groups company code, in different currency, account assigning it to a WBS Element or Network Activity, and settling it to an Asset Under Construction, checking how the values come right in the expected currency at the correct exchange rates. In PS, again, you would most definately need integration with other SAP components to do Scenario Testing.
- Integration Testing: the intention of this testing is to make sure that all the SAP components work and talk well between each other. Therefore this would be full business process end to end. Something very similar to Scenario Testing, but maybe not trying to catch a specific scenario a business user might have in mind as complex, but simply making sure you are able to put things (SAP modules) together in a business process.
- User Acceptance Testing: this would be a test executed by the user for him to check that the solution is delivered according to his requirements and expectations. Once he gives acceptance, it is good to go to the Production environment and a critical milestone is achieved. Scenario Tests or Integration Tests can be reused here.
- Regression Testing: this is the test we would do when we are going to make changes to a Productive system, in other words, in a system where users are already transacting on a daily basis. This can come motivated by the upcoming of a new business into Production system and all the transports (many modifying already live objects) that it brings through, by implementation of a SAP support package, etc. We want to make sure that by incorporating these changes, we won´t be impacting the Productive divisions and users, in other words, we won´t break anything that is already working fine. These tests can probably resemble very well the Integration Tests, and will be focused in those that can better assess that functionalities that we are going to modify, won´t be affected.
As you can see above, I am not clearly able to detail the differences between Scenario Testing and Integration Testing. And also maybe on the others too, my understanding is not what a best practice would be of each of the different possible test. Therefore I ask you, experts, to come into the discussion and add or correct where needed with your view. Maybe also detailing clearly who is responsible to fabricate and who is responsible to execute each set of tests would help.
Thanks a lot.
Cheers,
George O
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.