Skip to main content

Test Case Vs Test Scenarios

Test Scenario is ‘What to be tested’ and Test Case is ‘How to be tested’.

Difference between Test case and Test scenario:
  • Test case consist of a set of input values, execution precondition, expected results and executed post condition, developed to cover certain test condition. While Test scenario is nothing but a test procedure.
  • A Test Scenarios has one or many relations with Test Case, meaning a scenario can have multiple test cases. Each time we have to write test cases for test scenario. So before testing first prepare test scenarios then create two different test cases for each scenario.
  • Test cases are derived (or written) from test scenario. The scenarios are derived from used cases.
  • Test Scenario represents a series of actions that are associated together. While test Case represents a single (low level) action by the user.
  • Scenario is thread of operations where as Test cases are set of input and output given to the System.
Test Case Template
  • A test case can have the following elements. Note, however, that normally a test management tool is used by companies and the format is determined by the tool used.
  • Test Suite ID – The ID of the test suite to which this test case belongs.
  • Test Case ID – The ID of the test case.
  • Test Case Summary – The summary / objective of the test case.
  • Related Requirement – The ID of the requirement this test case relates/traces to.
  • Prerequisites – Any prerequisites or preconditions that must be fulfilled prior to executing the test.
  • Test Procedure – Step-by-step procedure to execute the test.
  • Test Data – The test data, or links to the test data, that are to be used while conducting the test.
  • Expected Result – The expected result of the test.
  • Actual Result – The actual result of the test; to be filled after executing the test.
  • Status – Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed and ‘Blocked’ if testing is blocked.
  • Remarks – Any comments on the test case or test execution.
  • Created By – The name of the author of the test case.
  • Date of Creation – The date of creation of the test case.
  • Executed By – The name of the person who executed the test.
  • Date of Execution – The date of execution of the test.
  • Test Environment – The environment (Hardware/Software/Network) in which the test was executed.
Importance of Scenario Testing
As you know that exhaustive testing of any software application is not possible because of the following reasons:
  • Large number of data combinations.
  • Large number of possible paths in software.
It is because of this fact you always prioritize your testing efforts and focus on the most important areas, for that you use techniques like Boundary value analysis(BVA), Equivalence partitioning(EP), Risk based testing etc. however these techniques still do not guarantee bug free product.
By scenario testing you figure out the most important end-to-end transactions or the real use of the software applications which ensures that the software is working for the most common user scenarios. It helps in finding lot of defects which cannot be found with other types of testing.
Scenario testing is very important for complex transactions and for studying end-to-end functioning of the program.
Test cases are most important part of Software Development Life Cycle and without the one, it’s tough to track, understand, follow and reason out something. But in the era of Agile, test cases are being replaced fast with test scenarios.
Scenario testing is done by creating test scenarios which replicate the end users usage. A test scenario can be an independent test case or a series of test cases that follow each other. Test scenario is just a story which explains the usage of the software by any end user.

Comments

Post a Comment

Popular posts from this blog

Mobile Application Testing Checklist

1. DEVICE SPECIFIC CHECKS 1.1  Can the app be installed on the device? 1.2 Does the app behave as designed/desired if there is an incoming call? 1.3 Does the app behave as designed/desired if there is an incoming SMS? 1.4 Does the app behave as designed/desired if the charger is connected? 1.5 Does the app behave as designed/desired if the charger is disconnected? 1.6 Does the app behave as designed/desired if the device goes to sleeping mode 1.7 Does the app behave as designed/desired if the device resumes from sleeping mode 1.8  Does the app behave as designed/desired if the device resumes from lock screen? 1.9    Does the app behave as designed/desired if the device is tilted? 1.10  Does the app behave as designed/desired if the device is shaken? 1.11 Does the app behave as designed/desired if a local message is coming from another app (think   of: calendar reminders, to-do task etc.). 1.12 Does the app behave as designed/desired if a push message i...
Post a Comment
Read more

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension. 2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file. 3. Check for date format if exported Excel file contains the date columns. 4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page. 5. The exported file should have columns with proper column names. 6. Default page sorting should be carried in the exported file as well. 7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages. 8. Check if the data displayed on a page and exported Excel file is the same. 9. Check export functionality when pagination is enabled. 10. Check if export button is showing proper icon according to the exported file type E.g . Excel file icon for xls files 11. ...
Post a Comment
Read more

Software Testing Tips

Here are some of the Best Testing Practices which I learned by Experience:  1) Learn to analyze your test results thoroughly. Do not ignore any test result. The final test result may be ‘pass’ or ‘fail’, but troubleshooting the root cause of ‘fail’ will give you the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions. 2) Learn to maximize the test coverage each time you test any application. 100% test coverage might not be possible but still, you can always try to reach near it. 3) In order to ensure maximum test coverage, break your application under test (AUT), into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts. E.g : Lets assume that you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing ...
Post a Comment
Read more