Difference between two phases of STLC, Integration testing and System testing

Question

This question might have been asked already but none of them really relate to real-time scenarios in testing industry (when you are seated and need to execute test cases).

So, I have got one module to write test cases on it and then execute them. Similarly I write test cases for another module.

Dev sends these modules to me on different qa environments to test. For example, Module1 on qaserver1 and module2 on qaserver2. Once both modules pass testing I test them together on the staging server. This is integration testing i.e. we are testing that on integrating both modules they are working fine, TOGETHER.

Now, next phase of testing comes which is system testing --- what is SYSTEM TESTING, how are test cases for SYSTEM TESTING are different than usual test cases. I mean what we do, we execute the same test cases those we wrote for modules. We do not write separate test cases for system testing. Why do we need to write separate test cases, and how they are different from UNIT test cases (module1 test cases and module2 test cases).

Answer 1

What is System Testing? End to end testing of the application to ensure application behavior is in compliance with the requirements.

How is it different from Integration Testing? If you only have a couple of modules then there's no difference as the unit and integration tests would cover everything. But if you have several modules then things will be different. Consider a situation where I have 10 different modules. I run unit tests on each of them. Then I run integration on the inter-related/inter-dependent modules(say mod2 depends on mod1, mod3 and mod4 on mod2 and so on). In this case I wont be testing integration on say mod1 and mod10 since they are independent of each other.

Now comes System testing. In system testing you sort of take a couple of steps back so as to able to see the bigger picture. Here you are concerned with the functioning of the application as a complete system with no rusty/missing parts in between. Here you might find that even though mod1 and mod10 are not directly dependent on each other, they are indirectly so. Say mod1 passes its output to mod2 which uses it and then passes its own output to mod3 and so on, making mod1 and other mods indirectly dependednt on each other. Its only here that you might find scenarios that you couldn't have guessed earlier. This is also the stage where you spend a lot of time Re-Testing and Regression testing.

Do you need to write separate test cases for System Testing? Depends. Like I said, with fewer modules the line between Integration and System testing blurs. With several modules you will have to come with broader scenarios eg. mod1 is for logging in, mod2 is for taking text input from user, mod3 is for saving it in the DB, mod4 and mod5 do blah blah, mod6 allows user to print data from DB in a file. A typical System testing test case would be-"Verify whether user can print data to a file". This test case would cover both the unit(mod1,2,3), Integration(mods1&2, mods2&3, mods3&6) test cases, but by the time you start System testing you will have already created and executed the Unit and Integration test cases.

Hope this helps.

Answer 2

Here's my perspective:

Unit Testing tests a single unit - usually at the routine level (that is, only one unit of code such as a function is tested). Unit tests are typically code-based, written by developers, and executed whenever the application is compiled or built.

Module Testing tests a single chunk of functionality in isolation, such as testing the features of a single page in a web application. This sounds like what you're calling unit testing.

Integration Testing tests that newly added/modified features work in the context of the application. This is very similar to module testing, but can be a bit larger in scope, such as when you're testing two modules interacting. I've also seen this level called feature testing. I personally consider it feature testing when tests are covering whether the feature works as it should, and integration testing when tests are checking whether the feature was properly integrated into the system and all the required changes are present.

System Testing tests end-to-end flow through the entire application, including data storage, the impact of new features on existing features (things like making sure that a new data type is handled in other places it can be used, that data isn't lost when moving between the new features and existing features, and so forth), and the overall look and feel of new features (particularly whether the look and feel works for new users and whether it fits the rest of the application).

There's quite a bit of overlap between all classes of testing because the main difference is the scope of the testing. I've seen any tests written by a developer to be run at compile-time be considered unit tests even though they exercise multiple routines within the code. In my opinion, it doesn't really matter.

It helps to know what the usual definitions are, but ultimately the goal is to learn as much about how the application behaves with the new features as you can in the time you have. If classifying your tests by scope helps with this, then do it.

For your second question, why do you need to write separate tests for the highest level of testing, the reason to write separate tests is that you are looking for different information. At the lower levels you are looking at how the new feature works in isolation. At higher levels you're looking at how information flows through the application and how it's stored.

Example: testing a web store

Consider a web store application. Here are some examples of the kinds of things that would be tested at each level.

Unit Tests

Typical unit tests might be:

• Calling the AddToCart routine and verifying that the items have been added in the given quantity.
• Calling the CalculateTotal routine for a known set of items in a shopping cart and verifying that the total matches the expected result.
• Calling the RetrieveItems routine and verifying that the list of items returned matches what it should be (if this is run against a database containing the item list, it could be considered a module test or integration test)

They're all testing a single discrete function.

Module Tests

Typical module tests might be:

• Opening the product list page and checking that all the products you expect are on the list
• Checking that each product allows you to enter a quantity and add it to the shopping cart
• Checking that all the information you expect to see about each product is displayed in the format it should be displayed in.
• Checking that everything that should be in a shopping cart is displayed

Here, you're focusing on one small chunk of function and don't really care where the data comes from or how it got to the page.

Integration Testing

Typical integration tests might be:

• Entering different quantities of items on the list page, then adding them to the shopping cart and checking that the shopping cart displays those items.
• Modifying the quantities of items in the shopping cart then selecting Checkout and verifying that the total you're being charged matches the total shown by the shopping cart after you'd modified the items in it.

You're still working more or less in isolation, but you're dealing with the communication between two or more modules.

System Testing

The tests I'd be running here would be things like:

• Cancel sale
  1. Browse items and make some selections, then add them to my shopping cart.
  2. Check the database to make sure my selection is stored as a temporary/potential order.
  3. Edit my shopping cart. Check that my changes are saved to the database.
  4. Cancel my order. Check that the database throws away my selection.
• Complete sale as a known customer
  1. Browse items and make some selections, then add them to my shopping cart.
  2. Check the database and make sure my selection is stored as a temporary order.
  3. Log on to the web store.
  4. Check that my temporary order in the database is updated with my customer details.
  5. Select check out. Make sure that my saved payment information is pre-loaded and selected by default.
  6. Select the default payment option and complete the purchase. Check that my order is updated to be a real order and flagged as unfulfilled.

Here I'm testing the process from beginning to end and making sure that each part does what I expect it to.

Answer 3

mainly here you need to write new test cases which are care for data base integration between the two modules, and you have to notice if any changes made on "module 1 " could affect " module 2".

the most important thing to notice here is the data cycle, BIG QUESTION you should know its answer " does data from module 1 used in module 2 or the other way around? and if it must, does it stored correctly?"

that's my point of view for merging, hope it was helpful.

Answer 4

Wikipedia has good articles:

• http://en.wikipedia.org/wiki/System_testing
• http://en.wikipedia.org/wiki/Integration_testing
• http://en.wikipedia.org/wiki/System_integration_testing
• http://en.wikipedia.org/wiki/Continuous_integration

Difference is IMHO very subtle if any. Integration is testing interaction between modules (so few modules not under testing might be replaced by test doubles). In system testing, there is no such substitutions.