1)BOUNDARY VALUE ANALYSIS:

Boundary Value Analysis is based on testing the boundary values of valid and invalid partitions. The behavior at the edge of the equivalence partition is more likely to be incorrect than the behavior within the partition, so boundaries are an area where testing is likely to yield defects.

It checks for the input values near the boundary that have a higher chance of error. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition.

1.A boundary value for a valid partition is a valid boundary value.
2.A boundary value for an invalid partition is an invalid boundary value.

For each variable we check-

1.Minimum value.
2.Just above the minimum.
3.Nominal Value.
4.Just below Max value.
5.Max value.

Example: Consider a system that accepts ages from 18 to 56.
Boundary Value Analysis(Age accepts 18 to 56)

Invalid

(min-1)
17

Valid

(min, min + 1, nominal, max – 1, max)

18, 19, 37, 55, 56

Invalid

(max + 1)

Valid Test Cases: Valid test cases for the above can be any value entered greater than 17 and less than 57.

Enter the value- 18.
Enter the value- 19.
Enter the value- 37.
Enter the value- 55.
Enter the value- 56.
Invalid Cases: When any value less than 18 and greater than 56 is entered.

Enter the value- 17.
Enter the value- 57.

2)Decision table technique in Black box testing:

The decision table technique is one of the widely used case design techniques for black box testing. This is a systematic approach where various input combinations and their respective system behavior are captured in a tabular form.

That's why it is also known as a cause-effect table. This technique is used to pick the test cases systematically; it saves 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 between two and more than two inputs.

This technique is related to the correct combination of inputs and determines the result of various combinations of input. To design the test cases by decision table technique, we need to consider conditions as input and actions as output.

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 email and password are correctly matched, the user will be directed to the email account's homepage; otherwise, it will come back to the login page with an error message specified with "Incorrect Email" or "Incorrect Password."

Now, let's see how a decision table is created for the login function in which we can log in by using email and password. Both the email and the password are the conditions, and the expected result is action.

EMAIL (1) T T F F

PASSWORD (2) T F T F

EXPECTED RESULT ACCOUNT PAGE INCORRECT INCORRECT INCORRECT
(ACTION ) PASSWORD EMAIL EMAIL

In the table, there are four conditions or test cases to test the login function. In the first condition if both email and password are correct, then the user should be directed to the account's Homepage.

In the second condition if the email is correct, but the password is incorrect then the function should display Incorrect Password. In the third condition if the email is incorrect, but the password is correct, then it should display Incorrect Email.

Now, in fourth and last condition both email and password are incorrect then the function should display Incorrect Email.

In this example, all possible conditions or test cases have been included, and in the same way, the testing team also includes all possible test cases so that upcoming bugs can be cured at testing level.

To find the number of all possible conditions, the tester uses 2n formula where n denotes the number of inputs; in the example, there is the number of inputs is 2 (one is true and the second is false).

Number of possible conditions = 2^ Number of Values of the second condition
Number of possible conditions =2^2 = 4

While using the decision table technique, a tester determines the expected output, if the function produces expected output, then it is passed in testing, and if not then it is failed. Failed software is sent back to the development team to fix the defect.

3)USE CASE TESTING:

Use case testing is a type of black box testing technique that helps you to identify test cases that form part of the entire system on a transaction basis from start to finish. It is used for functional testing to find defects in a developed system.

It is important in identifying gaps related to your software application that could have been missed during component testing. With use case testing, you can determine the software quality through end to end testing methodology.

Below are a 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 paths or scenarios for better system understanding.

One example of a use case in software testing is conducting regression testing. This involves retesting previously implemented features to ensure that recent changes or bug fixes haven't introduced new issues. It helps maintain the overall quality and stability of the software during development and updates.

4)LCSAJ TESTING:

LCSAJ stands for Linear Code Sequence and Jump. LCSAJ testing is a white-box testing methodology used to determine the code coverage, i.e., what percentage of the code is executed with the existing test cases. It helps in designing new test cases, which can increase the coverage of the code under test. Once the code coverage reaches a certain level, we can stop the testing. Hence, LCSAJ methodology also helps in determining when to stop the testing of software.

White-box testing is a software testing technique in which we test the internal structure and the software code under test.

A single LCSAJ has the following three components:

Start of the segment, which can be a branch or the start of the program
The end of the segment, which can be the end of a branch or the 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#

TESTING TECHNIQUES