Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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).

share|improve this question
    
Possible duplicate of : sqa.stackexchange.com/questions/5131/… –  Peter Masiar May 14 at 14:33

4 Answers 4

up vote 0 down vote accepted

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.

share|improve this answer
    
Yes. Answer to Following question would clear a lot. Are you trying to say that if I am doing re-testing and regression testing then in one way I am doing system testing, coz both regression and re-testing would include execution of those test cases those have already been passed, but executed again because we have got newer modules deployed??? –  paul May 14 at 11:34
    
Partially, yes. Re-testing and Regression testing can be called as subsets of System testing. –  Yash May 14 at 14:33

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.

share|improve this answer
    
1. So we dont do system testing very often and we dont do it before/after sprint release. 2. We dont need to write special test cases for system testing, we simply execute same test cases that have already executed, but this time we execute them again with newly deployed modules. AM I RIGHT? –  paul May 14 at 11:40
    
Not necessarily @paul. System testing should happen as soon as the pieces are there. End to end test cases won't be the same as integration test cases, although they might use some of the same steps. –  Kate Paulk May 14 at 12:14
    
So we ending up at the base question here now. If we need to give 2 big sprints (5-8 modules in each sprint) in a month, and each would require system testing (means end to end testing = execution of tests from 001 to 2000) then how we going to signoff sprint. This way each sprint would take at least a month (Dont say that we should automate :) ) –  paul May 14 at 12:29
    
If you can't automate, you need to prioritize - pick which of those tests cover the most ground (you'll probably find you can use sets of them - say tests 1, 15, 73, 995, and 1201 in a single scenario test). –  Kate Paulk May 14 at 16:44

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.

share|improve this answer

Wikipedia has good articles:

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.