Test Suite, Test Case, Test Plan, What’s the Difference?

A regular use of a test case could be to leverage the same script for analyzing multiple settings. As an example, if you’d like to test an authentication script on three distinct browsers, such as Chrome, Firefox, and Edge, you could create three separate iterations within that test case. In a test case named Test Web Browsers you may include three testing situations:

• Iteration 1: login script with Chrome
• Iteration 2: login script with Firefox
• Iteration 3: login script with Edge

If each test case reflects a component of a scenario, like the functionality simulating completion of a sale, make use of a test suite. For example, a test suite may comprise five test cases, each having a separate test script:

• Test case 1: Login
• Test case 2: Add New Services to Cart
• Test case 3: Complete Order of Services
• Test case 4: Log-out
• Test case 5: Fulfill Service Request

Test suites could identify gaps inside a testing cycle where the successful conclusion of a single test case has to occur before starting another test case. As an example, you can’t add new services to a cart until you log into the application. When you execute a test suite in a consecutive manner, you may decide to block the suite execution in case one test case doesn’t pass. Preventing further execution is of good use if executing a test case in a test suite is contingent upon prior test cases passing.

Test suites are created based on the scope of the test plan, or based on where one is at in the test cycle. They could contain any kind of tests, functional or Non-Functional. Test suites can also be helpful for these kinds of tests:

• Smoke tests: A selection of test cases which ensure the application’s basic functionality is working. On average, smoke tests are the initial testing that’s conducted after changes are made to the application under test.
• Regression tests: A group of test cases which can be utilized to ensure breaking code changes have not occurred.
• End to end tests: A collection of test scripts which cross a product’s bounds and make sure the integration between systems is exercised and confirmed.
• Functional tests: A group of test cases that are dedicated to particular requirements. Implementing this kind of test, using a test suite, means several areas of a particular feature are all tested.
• Build pipeline tests: A group of test cases that do a simple validation on all of the functional areas in the software. The scenarios need to be executed after every product build and until the build is promoted for use with a larger customer base.

In AccelaTest, you can create custom Test Suites, and nest test suites, by clicking the “Create Directory” button and giving your directory a name, such as “Regression Tests.” Don’t have your free AccelaTest account yet? Sign up now – did we mention Test Case Management is completely free?

A Test Plan a dynamic comprehensive record defining the test strategy, objectives, schedule, estimation, deliverables, and resources necessary to complete testing for a software product. Test Plans help determine the time required to confirm the quality of the software under test. The test plan acts as a blueprint to perform testing tasks in a specified process, that will be tracked and monitored with the test manager.

According to ISTQB definition: “Test Plan is a document describing the scope, approach, resources, and schedule of intended test activities.”

Although you’ll be able to execute a test without an associated test script, it is best to associate each test case with a test script.

You may write manual test scripts to be run by an individual tester, or you can automate a few of the directions in the test script. You can link automated functional test scripts, load test scripts, and even security test scripts to a test case.

In many cases, you might need to make use of test suites to combine related test cases. As an example, you may work with a suite to execute a pair of automated regression test cases, or to run a pair of test cases which comprise an end-to-end scenario. With a test suite, you’re able to organize, start, and then track the execution of associated test cases which compose the bigger scenario that’s tested by the test suite. You might even associate more than one test script with a test case.

However, you certainly should only associate multiple scripts when each test script gives another way to test the scenario in the test case. For instance, a test case may require multiple scripts to test the scenario in several different test environments. Or you have manual and automated scripts which could be utilized to run the test case.

Don’t use test cases to group test scripts which perform frequent functions as doing so may cause erroneous data regarding test results and attempted scenarios. As an example, should you execute a test case for a particular test plan, iteration, or test environment and define a unique functional script every time, the previous result of this test execution simply captures the results of the previous script execution.

In certain cases, you might also need to make use of test suites to group related test cases. As an example, you may make use of a suite to execute a few automated regression test cases, or run multiple automated E2E scenarios. With a test suite, it is possible to organize, start, and track the progress of a test case execution.

Don’t have an test management tool yet? We all accept testing is vital to successfully deploying software. Both manual test cases and automated test cases are imperative to deploying software. Why not automatically automate your manual test bed by using AccelaTest’s free tools? Or, you can explore the best test management tools currently available on the market.