Two common methods used for software testing are static and dynamic testing. Now, although they are both testing methods, there are a lot of differences between them. First we need to define what each of them are. Static testing is when we test the software to look for errors or defects, but we are not going to actually execute the code. Now on the other hand, for dynamic testing we test the software by executing the code and see if there is any errors with inputs and overall function of the software. Static testing is conducted with specific documents related to the software and the goal is to find errors early on in the development cycle before the software gets too advanced. Dynamic testing executes the code and analyzes things such as the input and output of the software to determine the correct results. The goal for dynamic is to test the functional behavior of the code and also takes into account memory, CPU as well as the performance of the software put together. Static testing uses manual or automated testing of the documents by examining things such as the requirements for the software, the source, necessary test cases or any thing related to the overall design. Dynamic testing is more direct testing to whether the software works by using techniques such as black or white box testing and it confirms that the code works in the way it is desired to.

The main differences between static and dynamic is one thing we stated earlier about how static won’t be executed, whereas dynamic will. Another important factors is the stages with where these tests occur, as static happens early in the process of developing software, whereas dynamic is towards the end or completion stage. The goal of static testing is to prevent any bugs or errors from being produces, but dynamic tests finds bugs or errors that were created with the development of the software. Static testing is more simply known as the verification process, whereas dynamic testing is more about the validation process. Static testing is known to generally take shorter time, whereas dynamic will take a little bit longer due to the variance of test cases that need to be implemented. Overall, both of these testing methods are important in the development of software, but they occur at different stages and can be helpful to do both efficiently to lead to the least amount of error in the software.

Resources:

https://www.geeksforgeeks.org/difference-between-static-and-dynamic-testing/ https://www.guru99.com/static-dynamic-testing.html

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Christian Shadis

Self-Directed Blog Post #3

Two common testing techniques in Black-Box Software Testing are Boundary Value Testing (or Boundary Value Analysis) or Equivalence Partition Testing (or Equivalence Class Testing). Both techniques examine the output of a program given its inputs.

Consider a function eligibleForScholarship which accepts two inputs, SAT score (for simplicity, only considering 1600 scale) and GPA (on a 4.0 scale) and returns in dollars the total reward a student is eligible to receive. At CompUniversity, a student will receive a scholarship if their SAT score is at least 1200 and their GPA is at least 3.5. The amount of that scholarship is determined by the criteria in the table below.

In addition to the SAT reward, additional money is given based on GPA.

For example, a student with an SAT score of 1450 and GPA of 3.8 will receive $2500 plus an additional 20% for a total of $3000. A student with an SAT score of 1600 and a GPA of 3.49 will receive $0.

If software tester wanted to write test bases based on Robust Boundary Value Analysis, they would arrive at the following set of test cases:

Boundaries:
SAT Score upper bound: 1600 (physical limit)
SAT Score lower bound: 0 (physical limit)
GPA upper bound: 4.00 (physical limit)
GPA lower bound: 0.00 (physical limit)

Disadvantages of Boundary Value Testing:
There are possible outputs that this set of test cases never checks (e.g. $3000, $3750). Additionally, this set of test cases fails to test the behavior inside the program, instead focusing on outermost limits.

If the software tester instead wanted to write test cases based off of Strong Normal Equivalence Partitioning, they would arrive at the following set of test cases:

Disadvantages of Equivalence Partitioning:
This set of test cases does not successfully account for behavior at the boundaries of valid inputs, nor does it account for the behavior of the program with every possible combination of inputs.

The disadvantages of boundary value testing and equivalence partitioning can be addressed by instead implementing edge testing.

Edge Testing

In Edge testing, we want to examine any point at which behavior changes, and create test cases for all of those ‘boundaries’, along with values close to the boundaries on either side.

The SAT edge cases can be listed as {-1, 0, 1, 1199, 1200, 1201, 1399, 1400, 1401, 1599, 1600, 1601}.
The GPA edge cases can be listed as {-0.01, 0.00, 0.01, 3.49, 3.50, 3.51, 3.74, 3.75, 3.76, 3.89, 3.90, 3.91, 3.99, 4.00, 4.01}.

Test cases can now be created by taking all pairwise combinations of edge cases (Worst-case). There are too many test cases to list here without taking up unnecessary space, but now our tests account for each and every possible combination of inputs.

Edge testing combines the best attributes from Boundary Value testing and Equivalence Partitioning into one comprehensive technique. Edge testing successfully tests the upper and lower bounds for each input, and it successfully examining inner behavior at each partition.

Edge testing has a major drawback: the number of test cases needed. In this example, there are 12 * 15 = 180 test cases, but it has unrivaled behavior coverage. The decision of which testing technique to use depends largely on the program for which the tests are being developed, but for a smaller number of partitions in the inputs, edge testing is a relatively simple but comprehensive technique for testing all possible behavior.

Articles used for my research:
https://professionalqa.com/equivalence-class-testing
https://artoftesting.com/boundary-value-analysis
https://www.mindfulqa.com/edge-cases/
Class materials from CS-443 at Worcester State University

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

By Christian Shadis

CS-443 Self-Directed Blog Post #2

In this post, I will compare the implementations of Robust Boundary Value Testing and Equivalence Partitioning using simple examples and actual JUnit code.

For the purposes of this post, you have been elected ChairBee of HoneyComb Council in your neighborhood’s local beehive. Your main job is to determine whether a worker bee has produced enough honey to retire. There are two criteria by which you base your decision, age and number of flowers pollinated. As a bee, your brain was incapable of making this complex of a decision every time a bee requests retirement, so you decided to write a Java program to do the heavy lifting for you.

Your function needs two inputs: the number of flowers pollinated, and the age of the bee in days. Your decision is based on these conditions: A bee is eligible to retire at age 18, but only if they have pollinated at least 20 flowers.

boolean readyToRetire(int age, int flowersPollinated) throws IllegalArgumentException{

   if(age < 0 || age > 50)
      throw new IllegalArgumentException();
   if(flowersPollinated < 0 || flowersPollinated > 200)
      throw new IllegalArgumentException();
   if(age >= 18 && age <= 50) {
      if(flowersPollinated < 20) 
         return false;
      else
         return true;
   }

   else
      return false;
}

Being the good little former working bee you are, you decide that no program is worth its weight in beetles (joke of an insect, really) if it doesn’t have a JUnit Test Suite to go along with it. You decide that you want to develop test cases with one of two methods: Boundary Value Testing or Equivalence Partitioning.

Boundary Value Testing

There are physical and arbitrary limits implemented on each input of the function. The age of a bee, obviously, cannot be a negative number, and for a creature with a life expectancy of 28 days, you cannot expect it to live past 50 days. Our acceptable inputs for age are 0 <= age <= 50. Likewise, a negative number of flowers being pollinated is impossible, and a bee in our hive is extremely unlikely to pollinate close to 150 flowers, let alone 200. Our acceptable inputs for flowers pollinated are 0 <= flowers <= 200. Thus, we implement a physical limit of 0 to both age and flowers pollinated, and arbitrary upper limits of 50 and 200, respectively.

In Robust Boundary Value testing, we take each boundary of an input, and one step in the positive and negative directions, and test each against the nominal (or ideal) value of the other input. We arrive at the following test cases:

Now we write JUnit 5 Test cases for each row in the table above. We will assume the readyToRetire function is inside a Bee class.

@Test
void test1(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(-1, 30); } );
}

@Test
void test2(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(0, 30);
   assertFalse(result);
}

@Test
void test3(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(1, 30);
   assertFalse(result);
}

@Test
void test4(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(49, 30);
   assertTrue(result);
}

@Test
void test5(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(50, 30);
   assertTrue(result);
}

@Test
void test6(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(51, 30); } );
}

@Test
void test7(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 30);
   assertTrue(result);
}

@Test
void test8(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(20, -1); } );
}

@Test
void test9(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 0);
   assertFalse(result);
}

@Test
void test10(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 1);
   assertFalse(result);
}

@Test
void test11(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 199);
   assertTrue(result);
}

@Test
void test12(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 200);
   assertTrue(result);
}

@Test
void test13(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(20, 201); } );
}

Equivalence Class Partitioning

Equivalence class partitioning arises from the foundational concept that with this function, there will be one of three results. An Exception will be thrown, true will be returned, or false will be returned. Based on our information about the criteria for deciding if a bee can retire, the behavior of the function can be modeled with a table.

Each cell in this table is an equivalence class and can represent a test case in the JUnit Test Suite. With your bee work ethic, you decide to implement Strong Robust Equivalence Testing, which is the most thorough method, and uses every cell in the table above as a test case.

@Test
void test1(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(51, -1); } );
}

@Test
void test2(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(20, -1); } );
}

@Test
void test3(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(15, -1); } );
}

@Test
void test4(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(-1, -1); } );
}

@Test
void test5(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(51, 10); } );
}

@Test
void test6(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 10);
   assertFalse(result);
}

@Test
void test7(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(15, 10);
   assertFalse(result);
}

@Test
void test8(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(-1, 10); } );
}

@Test
void test9(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(51, 30); } );
}


@Test
void test10(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(20, 30);
   assertTrue(result);
}

@Test
void test11(){
   Bee testBee = new Bee();
   boolean result = testBee.readyToRetire(15, 30);
   assertFalse(result);
}

@Test
void test12(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(-1, 30); } );
}

@Test
void test13(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(51, 201); } );
}

@Test
void test14(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(20, 201); } );
}

@Test
void test15(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(15, 201); } );
}

@Test
void test16(){
   Bee testBee = new Bee();
   assertThrows(IllegalArgumentException.class, 
               () -> { testBee.readyToRetire(-1, 201); } );
}

Conclusion

We now have JUnit 5 Test Suites for both testing methods (boundary value testing and equivalence class testing). You are now prepared to serve your term as ChairBee knowing every decision will be made correctly, and having peace of mind that your test cases verified all desired behavior.

Equivalence class testing, at least with examples like this one, is a more thorough and robust technique that tests the programs behaviors as well as its input bounds, whereas boundary value testing focuses only on the extremes for each input. Each technique has its pros and cons, but I hope this simple example shed some light on implementing the theory behind boundary-value testing and equivalence class testing in JUnit 5.

From the blog CS@Worcester – Christian Shadis&#039; Blog by ctshadis and used with permission of the author. All other rights reserved by the author.