Verification and Validation — Pillars of Software Testing

Is the software or a product tested?

What are the words that pop into your mind, when you hear it?
1. Functionality is working as expected
2. No critical issues
3. Customer ready
4. According to the client’s expectation
5. No blockers
6. Basic functionality working fine
7. Smooth customer journey
8. Meeting the business criteria
9. No unresolved hight priority or high severity bug
…. And many more

All of the above can be achieved when focussed on the following thumb rule. Make sure the software/product has been

• VERIFIED
• VALIDATED

Now the question arises what is meant by verification and validation?

Verification is “What to test” and Validation is “How to test”

Consider the following requirement:
User should be able to sign up from the home page

Provided user stories for the above requirement are :
User story 1:
Given the user is on the home page
And sign up button is displayed
When the user taps on sign up button
Then sign up form is displayed
And form fields are displayed
Sign up form needs to have the following fields:

Form Fields

User story 2:
Given the user enters valid details in the form
When the user taps on submit button
Then “success” message is displayed

User story 3:
Given user enters invalid details in the form
When the user taps on submit button
Then “please try again” message is displayed

First Step — Verification:

The first question that pops into mind as a tester should be what needs to be tested?
In order to verify the requirements, we need to make sure that all the stated functionalities are implemented.

1. We have a signup form as per approved design
2. We have form fields as stated above
3. User can submit the form successfully with valid values and with the success message
4. User will get an error message when trying to submit the form with invalid values

Second step — Validation:

By just verifying the above scenarios, the quality of the product cannot be guaranteed because we have only identified what needs to be tested . For validation, we need to make sure that the implemented requirements are working as expected as well. For this purpose, we need to :

1. Validate the required fields. Come up with different scenarios to validate the error messages for the required fields. e.g Leave the required fields empty and tap on sign up, an error should be displayed.
2. Validate the data type. Enter only alphabets and tap OK, if the data type for that field is a string it should accept but if the data type is Int it should give an error .
3. The above scenario needs to be tested in combination with min and max value defined.
   E.g enter values less than 2 and greater than 50 in the name field. Tap okay and then verify the error messages.

What happens when there are no requirements?

The above mentioned scenario was an ideal scenario, where a tester has all the required information to verify and validate. Now that might not happen every time when functionality needs to be implemented.

Assume we only have the one line requirement and no user stories to clarify it i.e

User should be able to sign up from home page while submitting the form with name, age email, phone number, password and confirm password fields.

Following brainstorming practices would help :

1. For instance take the phone number field. Since phone numbers can only have numerics, test cases to verify error on phone number field will be
   * Verify the error when user enters alphabets
   * Verify the error when user enters special characters
   * Verify the error when user enters both alphabets and special characters.

2. Now if you want to test with min and max data [which we are assuming are not defined] just go with a generic maximum digit for a phone number which is 15 and then create your test data around it.

3) If there is no UI, then how error message should look like? Should it look like the error messages on all other existing forms or is there anything else the developer has implemented. Team discussion required for this action point.

The scenarios identified will then be documented properly in the form of test cases

One important tip:
Make sure that when you sign off the product, mention what has been tested with much detail as possible in the ticket . Especially in a situation where the requirement was ambiguous.
In order to make sure that everyone is on the same page, discuss your assumptions (if any) with the team.

For any kind of queries, suggestion and feedback please feel free to contact me on my email address nidasaleem333@gmail.com