Software Testing Techniques
Published: 2024-03-21 17:09:32

Software testing techniques:
  software testing techniques are methodologies used to evaluate tests on the software systems. These techniques ensure that the software meets the quality standards, functions correctly and satisfies user requirements. There are various software testing techniques, each suited to different purposes and stages of the software development life cycle. Some important testing techniques as follows
  1.Boundary value analysis
  2.Decision table testing
  3.Use Case testing
  4.LCSAJ testing

               **1.Boundary value analysis:**

    Boundary value analysis is a software testing technique used in manual testing. It is black box testing used to identify errors at the Boundaries rather than within a range of valid and invalid input values. It is based on the principle that input values at the boundaries of equivalence classes to uncover errors. here's a more detailed explanation as follows,
  **Identifying Boundaries** - In Boundary value analysis, tester first identify the boundaries of input values for a given input field. This boundaries include minimum and maximum acceptable values, as well as inside and outside those boundaries. for example we consider age textbox it should the values only 18-35
    minimum boundary=18
    maximum boundary=35
** Selecting test cases** - once the boundaries are identified, testers select the test cases that use values at these boundaries. These test cases include values that are just below ,just above and exactly at the boundaries. For example
   Testcase1:Input age just below minimum boundary-17
   Testcase2:Minimum boundary value-18
   Testcase3:Value just above the minimum boundary-19
   Testcase4:Value well within the valid range-27
   Testcase5:Maximum boundary value-35
   testcase6:Value just above the maximum boundary-36
**Executing Test cases** - Tester execute the selected testcases, paying close attention to how the the software behaves at the boundary values. They observe whether the software handles these boundary values correctly, such as accepting or rejecting them appropriately, performing calculations accurately and triggering expected response. For Example
  Testcase1:Input-17->expected result=not eligible
  Testcase2:Input-18->expected result=eligible
  Testcase3:Input-19->expected result=eligible
  Testcase4:Input-27->expected result=eligible
  Testcase5:Input-35->expected result=eligible
  Testcase6:Input-36->expected result=not eligible
 **Analyzing Results** - Tester analyze the results of the testcases to identify any unexpected behavior at the boundary values. They document any defects found and report them to the development team for resolution. For example
  Testcase1:User is correctly deemed ineligible
  Testcase2:User is correctly deemed eligible
  Testcase3:User is correctly deemed eligible
  Testcase4:User is correctly deemed eligible
  Testcase5:User is correctly deemed eligible
  Testcase6:User is correctly deemed ineligible
  **Refining testcases** - Based on the defects and any results found, testers may refine the test cases to ensure the comprehensive coverage of the boundary values. They may also adjust the boundaries if necessary based on system requirements gained during testing.
  For this example no adjustment are needed. However, if any discrepancies were found, adjustments to the boundary values or additional test cases might be necessary.
  **Documentation and reporting** - Any defects found during boundary value analysis are documented and reported to the development team. 
   Document the testcases, actual result and any discrepancies found during testing. report any defects to the development team for resolution.
This example demonstrates how boundary value analysis can be applied that a software application correctly handles boundary conditions, thereby improving the accuracy and reliability of the eligibility determination process.
By focusing on boundary value analysis, it helps to uncover defects that might not be found through other testing methods. It's particularly effective in testing numerical inputs, date ranges and other cases with defined boundaries. It can be applied at various level of testing, including unit testing, integration testing and system testing to improve quality and reliability of software systems.
 
             ** 2.Decision Table Technique:**

   Decision table technique is one of the widely use case design technique for black box testing. This is a systematic approach where various input combinations and their respective system behavior are captured in a table format.
 That is why it's also called as a cause-effect table. This technique is used to pick the test case in a systematic manner.it saves the testing time and gives good coverage to the testing area of the software application.
 Decision table technique is appropriate for the functions that have a logical relationship two and more than two inputs.
 This technique is related to the correct combination of inputs and determines the result of a various combination of inputs. To design the test cases by decision table techniques, we need consider conditions as input and actions as output.
Let's understand it by example,
 Most of us use an email account, and when you want to use an email account, for this you need to enter the email and its associated password.
 If both the email and password are correctly matched, the user will be directed to the email account's home page. otherwise , it will come back to the login page with an error message specified with "Incorrect Email" or "Incorrect Password".
 Lets see how a decision table is created for the login function in which we can login by using email and password. Both the email and the password are the conditions, and the expected result is action.
 
Email               T         T          F             F
(condition1)
Password            T         F          T             F
(condition2)
Expected Result   Account   Incorrect   Incorrect   Incorrect
(action)           page     Password     email       email
  

 In the table there are four conditions as testcases to test the login function. In the first condition if both  the email and  password are incorrect, then the user should be directed to the account's home page.
 In the second condition if the email is correct, but the password is incorrect then the function should display "Incorrect password" error message.
 In the third condition if the email is incorrect, but the password is correct. then it should display "Incorrect email id" error message.
 Now in fourth and last condition both email and password are incorrect then the function should display "Incorrect email id" error message.
 In this examples, all possible conditions have been included and in the same way the testing team also incudes all possible test cases so that upcoming bugs can be cured at testing level.
 While using the decision table techniques, a tester determines the expected output, if the function produces expected output, then it is passed in the testing and if not then it is failed. Failed software is send back to the development team to fix the defects.
 **Advantages** 
    When the system behavior is different for different input not the same for a range of inputs, both equivalent partitioning and boundary values analysis won't help but a decision table can be used.
  The representation is simple so that it can be easily interpreted and is used for development and business as well.
  This table will help to make effective combinations and can ensure better better coverage for testing.
  Any complex business conditions can be easily turned into decision tables.
  In a case we are going for 100% coverage typically when the input combinations are low, this technique can ensure the coverage.
 Decision table is one of the most effective and full proof design testing techniques.
 Tester can use decision table testing to test the result of several input combinations and software states.
 It gives the developers to state and analyzes complex business rules
 Decision table technique is the most preferred black box testing and requirements management.
 A decision table is used for modelling complex business logic. They can first be converted to test cases and test scenarios through decision table testing.
 This technique provides comprehensive coverage of all test cases that can significantly reduce the rework on writing test cases and test scenarios.
 Decision tables guarantee coverage of all possible combinations of condition value which are called completeness property.
 Decision table can be used iteratively. The table results created in the first testing iteration can be used for next and so on.
 Decision tables are easy to understand and everyone can use and implement this design and testing method, scenarios and testcases without prior experience.
 Multiple conditions, scenarios and results can be viewed and analyzed on the same page by both developers and testers.                     
**Disadvantages**
   The main disadvantage is that when the number of inputs increases the table become more complex.

              **3.Use Case Testing**

     Use case testing is a functional testing technique that helps in identifying and testing scenarios on the whole system, it is a start to end transactions. It helps to identify the gaps in the software that might not be identified by testing individual components. It can be written in a document or made as a visual with the help of a use case model.
 Use case serves the following purpose:
   Manages scope requirements related to the project.
   Helps to establish the requirements.
   depict different ways by which a user can interact  with the system.
   visualize the system architecture.
   Helps to evaluate the potential risks and system dependencies.
   Communicates complex technical requirements to relevant stakeholders easily.

Project managers need to know all the required details related to applicable use cases to quickly communicate the strategy to stakeholders and bridge the gap between business and the technical requirements.
For example if you are a project manager for an e-commerce firm and your companies latest product ideas is to introduce a subscription-based model for premium customers to avail of more discounts and cashback on online shopping.
Creating a use case for this application with the required scenario helps the stakeholders and project team the customer behavior, customer interaction, understanding the gaps and the requirements of the project.  
       **Example of use case in Real time scenario**
   Let us take an example of an online food delivery application which is the primary use case where individuals can use the online app to place orders. The app can be used to receive orders, track orders, Process payments and communicate with the restaurant which is delivering the orders.
Following are the use case for the food delivery application
**Use case description** - A user can order food online.
**System** - Online food delivery application.
**Pre condition** - The user needs to access the system online with valid credentials.
**Primary actor** - Customer ordering food online and making payments.
**Main Scenario** - The customer can explore available restaurant options and place an order based on convenience and food preferences. The possible use case can be a customer and restaurant employee interacting using the food delivering application.
**Expected flow** - The expected outcomes of each interaction can also be tracked. This helps the development teams to understand the overall system functionalities so that they can execute the coding requirements in a much better way.
**Post Condition** - The system sends out the notification of the order details with the payments made.
Pointers to consider for the use case documentation:
  It becomes important to mention all the required details to execute the use case successfully. we tend to give too many details about a particular use case. So providing relevant details is recommended so all the required use cases are covered.
  Select the desired model in which you want to depicts the use case scenarios.
  Write all the necessary process steps correctly and sequentially to avoid confusion who is going through it. The intent is to make the steps self-explanatory with concise information.
  Specify non-functional requirements that can add value to the use case. 
Below are the few characteristics of use case testing:
 It helps to organize the functional requirements so that requirements can be referred to when required.
 Describes the main flow and alternate flow of events.
 Captures the goals and behavior requirements of different actors.
 Capture the scenarios for better system understanding.
Pre requisite for building use case plan:
 Complete and thorough understanding of the system functionality.
 Evaluating the associated risks and dependencies in the initial project stages so they can be tackled when needed.
 Establish a proper communication plan and share it well in advance with required stakeholders.
 Timely and prompt communication about changes in requirements.
 Involved of all the key stakeholders so that all the required inputs are collected well in advance.
        **Advantages of use case testing** 
   It helps in understanding the system requirements with utmost precision and clarity.
   It depicts the sequence of steps describing the interaction between actual user and system.
   It simplifies the overall complexities involved in the system as you can focus on one task at a time.
   Testing team is thinking from user's perspective so any issues related to the end user experience can be easily identified.
   use case are written with details related to pre conditions, post conditions, business rules, overall flow and exceptions. That help the testing team design and cover the required test cases easily.
      **Disadvantages of use case testing**
  Use cases cover only the functional requirements and we cannot test non functional requirements which could be significant challenge in the long run.
  The use cases are written from the user's perspective. There could be scenarios in the system that are not supported from the end user's perspective and might be missed in the use case documentation. In such a way the test coverage is not exactly 100%  for the module to be tested. 

           **4.LCSAJ Testing** 

   LCSAJ stands for linear code sequence and jump, a white box testing technique to identify code coverage which begins at the start of the program and ends at the end of the program. LCSAJ consists of testing and is equivalent to statement coverage. 
   It helps in designing new testcases which can increase the coverage of code under test. Once the coverage reaches the certain level we can stop the testing. Hence LCSAJ methodology also helps in determining when to stop the testing of a software.
 "White box testing" is a software testing technique in which we test the internal structure and the software code under test.
 This refers to the sequence of executable statements in the code ignoring any control flow constructs like loops. It represents the linear execution path through the program from the entry point to exit point without considering any loops
 In jump testing the focus is on ensuring that every possible branch in the code executed and tested. This includes both forward jumps and backward jumps. The goal is to ensure that all possible paths through the code are exercised during testing.
 By combining these two concepts LCSAJs testing aims to ensure thorough coverage of both linear code sequences and all possible branches within the code. It helps identify potential issues related to control flow such as missing or incorrect conditions in conditional statements, incomplete loop iterations and unintended jumps behavior.
 LCSAJ testing is a valuable technique for assessing the robustness and reliability of software programs particularly in ensuring comprehensive coverage of control flow structures and minimizing the risk of undiscovered defects related to control flow logic.

**A single LCSAJ following three components:**
   Start of the segment which can be start of the program.
   End of the segment which can be end of the program.
   A specific target line.
The code executes sequentially from the start of the segment until the end of the segment and then the control flow breaks the sequential execution and jumps to the target line.
   
                   Start 
                     |
                     | (sequential execution)
                     |
                    end
                     |
                     | (control flow jumps)
                     |
                   Target
                    line
        **Test Effectiveness Ratio(TER)**
certain metrics are used to check the code coverage. These metrics can help us to determine if the testing is enough or not. This metrics are called Test effectiveness ratio.
There are three TER metrics
 **TER-1** - Number of statements executed by the test data, divided by the total number of statements.
 **TER-2** - Number of control flow branches executed by the test data, divided by the total number of control flow branches.
 **TER-3** - Number of LCSAJs executed by the test data, divided by the total number of LCSAJs.
These TERs are determined using the test data. Moreover these TERs follows a hierarchy that is if TER is 100%,this means that TER-1 and TER-2 are also 100%.
               **Example Scenario**
 To provide a clear understanding of LCSAJ testing lets consider an example scenario and how LCSAJ testing might be applied to it.
 Suppose we have a simple program to calculate the factorial of given number using a recursive function. Here's the code 

Def factorial(n)
{
if(n==0)
 return 1;
else
 return n*factorial(n-1);

int number=5;
result=factorial(number);
print("Factorial of", number, "is", result);
}
**Linear code sequence:** 
  The linear code sequence in this example starts from the top of the program and follows through to the bottom executing each statement in sequence. In this case it would be
     Declaration of the 'factorial' function,
     Assignment of the 'number' variable,
     Calling the 'factorial' function with 'number' as an argument,
     Printing the result.
**Jump Testing**
 jump testing involves ensuring that all possible branches and loops are exercised. In this example:
    For the 'factorial' function we have a conditional statement(if n==0) that branches the control flow. we need to test both branches(when 'n==0' and when 'n!=0') to ensure complete coverage.
   Since the 'factorial' function is recursive we also need to test multiple iterations of the recursive call to ensure that the recursion works correctly and terminates as expected.
**LCSAJ Testing**
 LCSAJ testing combines both linear code sequence and jump testing. In this example:
   We ensure that the linear code sequence(execution from top to bottom) is followed correctly.
   We also verify that all possible jumps and branches within the code(like the conditional statement and recursive calls) are exercised.
          **Applying LCSAJ Testing**
To perform LCSAJ testing on this example:
  We would design test cases to cover both branches of the conditional statement in the 'factorial' function. one where 'n==0'and another where 'n!=0'.
  We would also design test cases to cover different values of 'number' including edge cases like negative number.
  Additionally we would design test cases to verify the behavior of the recursive function for different input values ensuring it to terminates correctly and produces the expected results.
By applying LCSAJ testing we aim to ensure thorough coverage of both linear code sequences and all possible jumps within the code, thereby improving the reliability and robustness of the software.