storj/docs/testplan

How To Create a Basic Testplan!

 

 

Why write Testplans?

We believe test plans are important, Testplans written as early as possible before implementation starts work like a checklist and as soon as we finish the implementation we can compare it to the test plan to check for any bugs. Also even before implementation is finished, if a developer can read a test plan beforehand they can prevent most bugs, hence why we believe that the earlier we write a test plan the more bugs we can prevent!

Hi! Here is a guide on how to write a basic testplan that will go over how to

• figure out a test name

• group similar test cases into something that we can turn into a task (test scenarios)

• add a description of what the test does

• add comments related to the test, comments that add links to additional information f.e blueprints, design drafts (even if they are private) or even comments requesting a feature that relates to the test!

• take all this info and place it into a neat testplan template!

 

 

Test Name

Let's say we have these tests in mind for the multinode dashboard UI

1. Seeing if creating a new node works with correct information

2. Seeing if creating a new node works with incorrect information

3. Seeing if creating a new node works with an already existing node with the same information

Now we can just simplify these tests and create test names for these test cases, so 1, 2 and 3 become

1. Add new node with correct information

2. Add new node with incorrect information

3. Add new node with existing node information

Test Scenarios

Using the aforementioned tests above we have these test cases in mind for the multinode dashboard UI

• Add new node with correct information

• Add new node with incorrect information

• Add new node with existing node information

 

Here we can see that we are able to group up these testcases into a task or test scenario, since each of these tests fall under the add a new node button we can just label these tests under the scenario New Node Button Functionality. We would also add a number ID to make the test plan easier to read

 

 

Test Description

Now building onto the test cases we can describe what should happen in each test (EXPECTED OUTCOME) case f.e using a conditional if-then statement. So we can take our previous test cases

1. Add new node with correct information

2. Add new node with incorrect information

3. Add new node with existing node information

and add a conditional statement so we can know how to test it and what to look for to consider the test as passing or failing

1. If a user clicks on add a new node button and inputs correct node info, then user should be able to see node ID, disk space used, disk space left, bandwidth used, earned currency, version and status of said node

2. If a user clicks on add a new node button and inputs incorrect node info, then user should not be able to see node ID, disk space used, disk space left, bandwidth used, earned currency, version, status of said node and instead a error message stating node information was incorrect

3. If a user clicks on add a new node button and inputs an existing node on their dashboard, then the user should just recieve an error message stating their node is already on the dashboard

So if we conduct test 2, and see that we aren't able to view the node ID, disk space used, disk spaced left, bandwidth used, earned currency, version, status of said node on the dashboard and NO error message stating the node information was incorrect, then the test failed

 

 

Comments

In this section of the testplan users can input their own comments, why said tests were added, improvements needed and what the actual outcomes for said tests are when it falls out of line towards expected outcomes f.e going back to test case 2. We see that although inputting incorrect node information doesn't allow us to see what the multinode dashboard usually allows us to see since the node information is incorrect in this case, we still weren't shown an error message stating node information was incorrect, so in this case the user can comment that the actual result was that although the user was not able to see information like the node ID, disk space used etc. the user was supposed to see the error message stating node information was incorrect but did not in this case

Testplan Template and How to Submit Testplan

By now if you have followed along thus far you should have a pretty awesome high level testplan! Once you have replaced each category under each column the next step

| Test Scenario      | Test Case     | Test Description   | Comments     |

| :----------------  | :------------ | :---------------   | :----------  |

| Test Scenario 1    | Test Case 1.1 | TC1.1 Description  | TC1.1 Comment  |

|                    | Test Case 1.2 | TC1.2 Descriotion  | TC1.2 Comment  |

| Test Scenario 2    | Test Case 2.1 | TC2.1 Description  | TC2.1 Comment  |

|                    | Test Case 2.2 | TC2.2 Descriotion  | TC2.2 Comment  |

is to head to testplan repo and open a pull request titled Test Plan on said feature by using our template here! If you think you are done writing your awesome test plan, head to the testplan repo and open a pull request with an appropriate title containing the keywords, Test Plan along with the Test Plan label.

Support

If you have any questions or suggestions please reach out to us on our community forum or file a support ticket at https://support.storj.io.