Here is description of basic software testing methods, which are often used during testing. Note the methods are not Pricefx specific, but examples of real testing situations are. Please keep in mind that main benefits of using those methods are:

• reduce the amount of test cases needed to cover the functionality

• improve the confidence that everything what should be tested was tested - it can be very useful especially for complex user stories

Boundary values

Description: When correct behavior is described for one range of values, also values on the edge of the range and outside of the range should be tested

1. using boundary values method means you will be focused also on checking warning or error messages and that the behavior on the interval edges is correct

2. Example:

   • Parameter Amount is defined as:

     • Type of parameter: Integer

     • Valid range for new orders: 0 to 100 boxes

     • In case the Amount is in valid range, the value is used for calculation of the final price, otherwise a warning message is displayed

   • Tested values based on Boundary values should be: -1, 0, 100, 101

Open

1. it can be useful especially when you are testing a parameter is valid only in certain range and the application should behave differently for other values - show warning or error message

2. You should consider using Boundary values in these cases:

   • checking calculations in LPG

   • submitting a new quote, agreement or rebate

   • recalculating after update of parameters

Equivalence partitioning

Description: The main idea behind Equivalence partitioning is that it is possible to limit the number of needed tests if there is the same behavior when input parameters belong to the same particular range

1. Example:

   • Parameter Amount is defined as:

     • Type of parameter: Integer

     • Valid range for new orders: 0 to 100 boxes

     • In case the Amount is in valid range, the value is used for calculation of the final price, otherwise a warning message is displayed

   • Tested values based on Equivalence partitioning should be: -10, 30, 125 (invalid value below valid range, valid value in the defined range, invalid value above valid range)

   • Open

     

      

   • You should consider using Equivalence partitioning in these cases:

     • checking calculations based on values in Company parameters tables

     • working with products in the same category/industry

     • submitting quotes with different business roles

Decision table

Description: Decision table is very good especially when there is pretty complex description of the functionality and when it is obvious the behavior is depending on the settings of some parameters or conditions. In this case it is good idea to describe the expected behavior in one table, in which there will be one row for each condition. The main benefit here is that we are lowering probability that we miss some combination of condition - expected result which should be tested.

1. Example:

   • Visibility of different part of the application is different based on order which business role is the user logging into the application:

     •  

   • • different visibility/behavior for different business roles

     • complex calculations when different parameters can be taken into account

     • workflows for different business roles

State transitioning diagram

Description: Especially for complex tests, one simple picture can be more efficient than a lot of texts and this is the idea behind State transitioning. It is also useful for customers to describe E2E processes which they are covering by UAT test cases.

1. • complex approval process

   • complex process of creating (new quote, agreement, rebate)

   • there is need to check al very complex calculation which depend on a lot of parameters

Exploratory testing

Description: Testing is done based on tester’s knowledge and previous experience, not based on prepared test cases. Sometimes it can be very useful because it is possible to find some important bugs quickly, on the other hand documentation of exploratory testing is usually very limited

1. Exploratory testing can be added to testing based on test cases especially when:

   • quick functionality check is needed (for example immediately after deployment on qa partition)

     • you should start from top priority functionalities

     • check correct data

     • don’t be limited just to previous testing, try testing around

   • when allocation for QA Analyst is very limited and there is no time for preparing test cases - this should be always discussed with PM as this situation is increasing project risks

   • when there is just limited time for testing because of a project milestone - in that case it might help when QA Analyst or other roles are checking the functionality based on their experience