Test Case/Test Plan Organization

(Steve) #1

Hello all,

New to the realm software testing, I moved into a QA role at my company back in March '18, and I’m starting to get a good handle on things.

One thing I am struggling with is how to efficiently organize my test scenarios/cases when there are duplicate checks that need to be performed.

Ex.
Test scenario: Make API call with missing fields
Test case 1: Field 1 is missing
Test case 2: Field 2 is missing
Etc…

Now within each test case I need to verify a few things

  1. Confirm call did not return data to user
  2. Did call return proper error
  3. Did API request get logged to server (verify the log entry contains all its required fields such as user, timestamp, endpoint, etc.).

Here is how I organize this currently:
Test scenario: Call API with field 1 missing
Test case 1: confirm no usable data sent back to user
Test case 2: confirm proper error was returned
Test case 3: confirm log entry created (expected result column shows each field that we expect to see in log entry).

The problem is, I end up with dozens of test scenarios, due to combinations of fields missing, each of which have practically all the same test cases (check no data, check error, check log entry). I’ve also tried shoving all 3 checks into the expected result column, for a given test case, but that turns into a giant mess that becomes hard to manage.

Is there a better way to do this?

Thank you!

Covering multiple scenarios while writing test cases for software testing
(Brian) #2

Of course, there is a better way to do this. There usually is.

My preferred method (when testing without automation) is to use a checklist. For this I assume that the test knows how to test the functionality and simply list:

  • Variations on the initial (happy path) scenario
  • The desired result from each variation

If there are multiple variables (i.e. you want to do pairs testing or some other variation on that), then a matrix may serve you better.

What I’m doing now, and it is working very well, is using BDD-like tests (Given, When, Then) and automating the tests. But the tests I’m working on now have so many variations that writing down each scenario is an exercise in pointlessness.

(Steve) #3

Thanks Brian.

I will do some digging on BDD testing and the like. My challenge is keeping the documentation clean and easy to follow, so those that perform validation, as the build moves up the production ladder, have something they can follow without the need for me to explain everyyhing.

Thanks!

(Vishal Dutt) #4

In this post, we will discuss about the organization of Test Case/Test Plan that can be implemented to provide quality assurance services in IT industry.

Test Plan: Test plan should be created based upon feature requirements with below mentioned coverage points:

  1. Environments to be covered: This includes OS/browser combination and mobile devices.
  2. External tools to be used in testing: It should specify the list of external software that will be used for testing the feature.
  3. Information about Database that needs to be covered should be provided.
  4. Details of application provided by client should be mentioned.
  5. Details about resourcing of engineers who will be covering the feature.
  6. The briefing of features that needs to be tested so that all areas are covered in Test cases.
  7. Details of regression features that needs to be tested along with new feature testing.
  8. Details of the areas that are not in scope or having limitation to be tested in QA environment.
  9. Dependencies and risk should be mentioned that can delay the deliveries.
  10. Effort estimate should be created based upon the amount of work to be done and its completion time.

Test Case: Followings points should be kept in mind before starting with test case creation process:

  1. All functional and UI related test cases should be covered.
  2. Negative scenarios should be covered.
  3. Test cases should be created in the form that it can be reused easily for future testing.
  4. Test cases to test Boundary values and Large data should be created.
  5. Test cases should be generic so that multiple environments can be covered using single test case by adding them in different cycle named accordingly under Test case management system (This will reduce the effort of TC creation).
  6. Test cases should be well documented so that it could serve as a training source for new testers.
  7. Test case should be accurate and correct so that it can be passed onto automation team.
  8. Priority of the test cases should be clearly defined so that in future if need arise high priority test cases can be picked for Sanity testing.

Hope this information will be helpful for you.