Testing a Feature: A concise approach

Any change in the existing program that enhances it's functionality is called as a "Feature"

For a feature to work effectively, it has to be properly tested. Testing ensures that the software is working correctly, and that it meets its requirements. It ensures that the product does what it says on the box.

Software testing has usually two concepts to it

Manual vs Automation Testing:

Most of the Software development cycles usually look towards Automation as it can do more testing in less time and with good efficiency. However not everything can be automated and manual testing is also often required as it ensures far greater test coverage

Black Box vs White Box:

In Black box testing the access to programme is “need-to-know” basis. However, in White box testing, we have additional control in order to test individual functions.

Testing a real world application

Testing a real world application consists of the following or more steps
Step 1: Understanding the scenario
Let us assume you want to test an API endpoint
Endpoint: “/users/save”
This API takes the parameters “Name” and “Age” in a form of post request as

    {
        "name":"My Name",
        "age":22
    }

The API then saves the data in a cloud based SQL database

Step 2: Defining use cases
Generally, the convention that I follow in order to test a functionality is as follows”

• The Positive Case: At the first you need to understand the basic flow of the application and how it works.

  • One positive case is saving the data how it should go.

• The Illegal Values: Testing Illegal values is another thing you should check. A proper software should test the values against real world possible scenarios

  • One case can be entering the age as a negative number
  • Another case can be entering the age in float value e.g 2.2 or 14.5

• The Extremities: Testing Extreme values is also of utmost importance.

  • One case can be sending a different type in age eg:

      {
          "name":"My Name",
          "age":true
      }
  

  • Another case can be not sending age at all
  • Another case can be sending extra parameters in the request

  {
      "name":"My Name",
      "age":44,
      "exra_params":"Yes! Extra params"
  }
  

• User Acceptance Testing

  • Not useful in every case but certain feedback from a non tech perspective is of utmost importance since some real world cases can still get missed

• Compatibility and away user functional check

  • Another case testing includes checking if the software is compatible with the previous versions of codes
  • Another cases you should check (particularly for this case) is if the data is getting saved in the SQL database as well by the software

Step 3: Defining the Expected Result
Defining the expected results are usually need to know basis depending upon the responses you get from the software. However the responses should have a uniform approach in all the negative cases. A major test is that in any of the negative test cases, the software should handle the case gracefully
For example:-

• Instead of giving a generic error like
  

      {
          "status":false,
          "error":"some error!"
      }
  

  The user response should be like
  

      {
          "status":false,
          "error":"Value of age should not be negative"
      }
  

Step 4: Writing Test Code
Once all the previous steps are done, it is time to write the automation test cases
A normal test case in javascript would look something like

const request={
    "name":"My Name",
    "age":15
}
test("Test Positive API Flow", (request) => {
    expect(request.status).toBe(true);
});
//expecting that API gets saved and status is returned as true

Hope it gives the readers a basic workflow of testing a new feature