What is Boundary Value testing:

It is a functional testing technique. In this, we choose boundary values or conditions where the chances of getting errors are high, These boundary values are the input values which can be:

• minimum ( lying on the boundary)
• maximum (lying on the boundary)
• Just below from maximum ( below the boundary)
• Just above to minimum (above the boundary)
• At nominal

C Program to determine the previous date

Program:

#include<conio.h>
#include<stdio.h>

int
main ()
{
  int month, date, year, valid = -1, leap_year = -1, invalid_input = -1;
  printf ("please enter a date = ");
  scanf ("%d", &date);
  printf ("please enter a month = ");
  scanf ("%d", &month);
  printf ("please enter a year = ");
  scanf ("%d", &year);
  if ((date > 0 && date <= 31) && (month >= 1 && month <= 12)
      && (year >= 2000 && year <= 2050))
    {
      invalid_input = 1;
      // finding given input is a leap year or not
      if ((year % 4) == 0)
  {
    leap_year = 1;
    if ((year % 100) == 0)
      {
        if ((year % 400) == 0)
    {
      leap_year = 1;
    }
        else
    {
      leap_year = -1;
    }
      }
  }
      if (month == 2 && leap_year == 1 && date > 29)
  valid = -1;
      else if (month == 2 && leap_year == -1 && date > 28)
  valid = -1;
      else
  valid = 1;
    }

  if ((month == 6 || month == 4 || month == 9 || month == 11) && date > 30)
    valid = -1;

// validating & finding output


  if (valid == 1)
    {
      printf ("Entered date = %d-%d-%d", date, month, year);

      if (date == 1)
  {
    if (month == 1)
      {
        date = 31;
        month = 12;
        year--;
      }
    else if (leap_year = 1 && month == 3)
      {
        date = 29;
        month--;
      }
    else if (leap_year == -1 && month == 3)
      {
        date = 28;
        month--;
      }
    else if (month == 2 || month == 4 || month == 6 || month == 8
       || month == 9 || month == 11)
      {
        date = 31;
        month--;
      }
    else
      {
        date = 30;
        month--;
      }
  }
      else
  {

    date--;
  }
      printf ("\nPrevious date = %d-%d-%d \n", date, month, year);
    }

  if (valid == -1 && invalid_input == 1)
    printf ("\n Not a valid date");

  if (invalid_input == -1)
    printf ("\n Invalid Input");

  return 0;
}

Output:

Testing the program:

Invalid Date:

please enter a date = 31
please enter a month = 6
please enter a year = 2030

 Not a valid date

Previous Date:

please enter a date = 21
please enter a month = 6
please enter a year = 2030
Entered date = 21-6-2030
Previous date = 20-6-2030 

The basic difference between verification and validation testing is that, verification assures whether a product meets the specifications or not ,whereas, validation checks whether a product meets client’s requirement or not.

Difference between Validation and Verification Testing in Tabular form

Verification Testing	Validation Testing
Main objective is to assure that product meets the designed specifications	Main objective is to assure that product meets the client’ requirements
This is done during the development phase	This done after the development phase
This is carried out by the Quality Assurance (QA) team	This is carried out by the Quality Checking (QC) team
It is static and proactive in nature	It is dynamic and reactive in nature
It does not involves testing of codes	It involves testing of code
It tests the software thoroughly without executing the code	It tests the software by executing the code with the goal of finding defects and improve performance
The main goal of this testing method is to find bugs, ensuring the quality level of product and avoid defects.	The main goal is to ensure the software work properly and meeting all the requirement and specification mentioned by the client
It supports techniques such as Inspection, walkthrough, Reviews and more	It supports white box testing and black box testing techniques such as unit testing, integration testing, system testing, and Acceptance testing

Verification

“Are we building the product right?”

Definition: Verification is an approach of checking if the product that is being built is satisfying the imposed requirements and specifications, during the development phase.

Characteristics of Verification testing:

• Discovering errors in early stages
• Faster & Accurate
• Responsible for detecting bugs

Validation

“Are we building the right product?”

Definition: Validation is an approach of checking if the product, built, meets the needs and requirements of the client, after the end of the development phase.

You would also like :

Difference between static testing and dynamic testing

The basic difference between static and dynamic testing is that Static testing doesn’t involve code execution, whereas , dynamic involves code execution to find bugs.

Difference between Static Testing and Dynamic Testing in Tabular form

Static Testing	Dynamic Testing
It tests the software thoroughly without executing the code	It tests the software by executing the code with the goal of finding defects and improve performance
It focuses on documentation	It focuses on the testing of software operation
It refers to Verification testing	It refers to validation testing
The main goal of this testing method is to find bugs, ensuring the quality level of product and avoid defects.	The main goal is to ensure the software work properly and meeting all the requirement and specification mentioned by the client
It is less time consuming and costly than Dynamic testing when it comes to testing changed product	It is time consuming and costly when it comes to test changed product. However, it can be reduced using the inspection process
It evaluates defects but not the failure	It evaluates defects as well as a failure too
It supports techniques such as Inspection, walkthrough, Reviews and more	It supports white box testing and black box testing techniques such as unit testing, integration testing, system testing, and Acceptance testing
It mainly concentrates on defect prevention	It mainly concentrates on defect correction

Static Testing

It is a testing technique in which changed code and its documentation is reviewed to ensure whether the implementation is made properly or not.

It involves requirement verification, design review, and code review. It has nothing to do with code execution. Its objective is to analyze the specification of software thoroughly.

In this technique, defect in software is discovered without program execution. The main goal of this testing method is to find bugs, ensuring the quality level of product and avoid defects.

It can be classified in the following parts:

• Review ( It is performed to find any type of defect in documents)
• Static analysis ( It is performed with a set of tools in order to avoid possible defects that can be raised in software)

Characteristics of Static testing :

• Discovering errors in early stages
• Faster & Accurate
• Responsible for detecting bugs

Dynamic Testing

It is a testing technique in which code is executed with a set of test cases to improve performance. It is done on software code in order to detect defects and code quality.

It is used to evaluate the final software and deals with the input and output of the software, checking whether the output as per expectations or not.

It can be classified in the following parts:
Black-box testing
White-box testing

Related Post:

Difference between validation and verification testing?

Same as path testing make flow graph.

Now, make Decision-to-Decision table in which consecutive nodes are counted as an individual.

On the basis of above table, create DD graph.

After DD graph, it is time to figure out du and dc paths. For this, create ‘ defined node and used at node’ table to view variable’s definition and initialization.

From above table, find du and dc paths.

Based on du and dc paths create test cases, covering each and every variable definition and usage.

Test ID	a	b	c	Expected Output	Program Output	Tested Outcome
1	5	10	5	Not a triangle	Invalid Input	Fail
2	10	9	5	Scalene triangle	Scalene triangle	Pass
3	5	1	5	Isosceles triangle	Isosceles triangle	Pass
4	5	5	5	Equilateral Triangle	Equilateral Triangle	Pass
5	-1	5	5	Invalid Input	Invalid Input	Pass

In this, we will drive test cases using Data flow testing approach by considering the Quadratic equation example. The first step is to create a flow graph from the code of the Quadratic Equation.

Using the flow graph, create a Decision to Decision Graph ( DD Graph) by converting each set of consecutive nodes into a single node.

Replace these numbers with correspondent DD nodes.

Create a Defined and Used node table to get a clear view of variable usage.

On the basis of the above table, we will generate du and dc path respectively.

All the ‘Y’ in the above table are DC path and ‘Path nodes’ are DU paths.

Now, create the test cases from input provided by the user in such a way that all the paths get covered.

Test ID	a	b	c	Expected Output	Program Output	Tested Outcome
1	0	5	5	Not Quadratic	Not Quadratic	Pass
2	1	5	5	Real	Real	Pass
3	9	5	5	Imaginary	Imaginary	Pass
4	5	10	5	Equal	Equal	Pass
5	-1	5	5	Invalid Input	Invalid Input	Pass

Here’s is the triangle problem code.

In path testing, first we create the flow graph of the triangle problem based on the program which shows the flow and possible paths.

Once the flow graph is created, with the help of it list all the consecutive nodes and assign an alphabet to them.

After creating DD Table, it’s time to generate DD graph through which Cyclomatic complexity and the possible path will be gathered.

Using DD graph ( Decision to Decision graph ), calculate the cyclomatic complexity which tells all the independent paths.

Cyclomatic complexity = E – N + 2P

= 20-16+2

=6

Possbile paths are:

-A,B,C,D,E,F,G,K,L,M,O,P
-A,B,C,D,E,F,H,I,K,L,M,O,P
-A,B,C,D,E,F,H,J,K,L,M,O,P
-A,B,C,D,K,L,M,O,P
-A,B,C,D,K,L,M,N,O,P
-A,B,K,L,M,O,P

Based on these paths, we will create Test cases.

Test ID	a	b	c	Expected Output	Program Output	Tested Outcome
1	5	10	5	Not a triangle	Invalid Input	Fail
2	10	9	5	Scalene triangle	Scalene triangle	Pass
3	5	1	5	Isosceles triangle	Isosceles triangle	Pass
4	5	5	5	Equilateral Triangle	Equilateral Triangle	Pass
5	-1	5	5	Invalid Input	Invalid Input	Pass
6	5	5	11	Invalid Input	Invalid Input	Pass

The first step is to create a flow graph using quadratic equation program.

After creating the flow graph, it’s time to make a Decision-to-Decision Graph (DD Graph). List one by one consecutive nodes and assign an alphabet.

Generate a DD graph.

Now, calculate cyclomatic complexity which represent the number of possible paths,

=E − N + 2P

=16-13+2

=5

After calculating cyclomatic complexity, generate independent paths.

– A,B,D,F,H,I,J,L,M
– A,B,D,F,G,I,J,L,M
– A,B,D,E,I,J,L,M
– A,B,C,I,J,L,M
– A,B,C,I,J,K,L,M

The last step is to formulate test cases based on the calculated independent paths.

Test ID	a	b	c	Expected Output	Program Output	Tested Outcome
1	0	5	5	Not Quadratic	Not Quadratic	Pass
2	1	5	5	Real	Real	Pass
3	9	5	5	Imaginary	Imaginary	Pass
4	5	10	5	Equal	Equal	Pass
5	-1	5	5	Invalid Input	Invalid Input	Pass

If you’re curious to see the “Triangle Problem “ code, then the link is here with tested test cases.

Decision Table Based Testing

In Decision table based testing,  Condition stubs and Action stubs are viewed as inputs and outputs. Here, we’ll be applying this Structural testing technique to create test cases:

Let’s create the decision table first,

On the basis of above decision table, we have these test cases for testing:

Test ID	a	b	c	Expected Output	Program Output	Tested Outcome
1	5	10	5	Not a triangle	Not a triangle	Pass
2	10	5	5	Not a triangle	Not a triangle	Pass
3	5	5	10	Not a triangle	Not a triangle	Pass
4	10	9	5	Scalene triangle	Scalene triangle	Pass
5	5	1	5	Isosceles triangle	Isosceles triangle	Pass
6	1	5	5	Isosceles triangle	Isosceles triangle	Pass
7	-	-	-	Not Possible	Not Possible
8	5	5	1	Isosceles triangle	Isosceles triangle	Pass
9	-	-	-	Not Possible	Not Possible
10	-	-	-	Not Possible	Not Possible
11	5	5	5	Equilateral Triangle	Equilateral Triangle	Pass

If you’re interested to see “Quadratic Equation Problem “ code, then the link is here with tested test cases.

Decision Table Based Testing

In Decision table based testing,  Condition stubs and Action stubs are recognized as inputs and outputs. Here, we’ll be using this black box testing technique to generate test cases:

Let’s create the decision table first,

Now, we will accordingly create test cases based on the above decision table.

Test ID	a	b	c	Expected Output	Program Output	Tested Outcome
1	0	5	5	Not Quadratic	Not Quadratic	Pass
2	1	5	5	Real	Real	Pass
3	9	5	5	Imaginary	Imaginary	Pass
4	5	10	5	Equal	Equal	Pass