Boundary value testing…?

Boundary value analysis is a testing technique that focuses on testing the boundary conditions of a system. The main objective is to identify and test the values at the boundaries, which are often the most vulnerable points in a software application. These boundary testing is included with some limitations in types of input and output limits following to the other type of boundary that is relevant to the system being tested. 
The BVA concept is based on the assumption of values rather than testing within the range of acceptable values the errors are more likely to occur at the boundaries of input values This is because the boundary values are usually handled differently by the software application, and any discrepancies in the handling of these values can result in errors.
For example, let’s consider a software application that accepts input values in the range of 1 to 100. The boundary values, in this case, would be 1, 100, and values close to them, such as 2, 99, etc. Testing the boundary values would involve checking how the software application behaves when it receives input values at the edge of the acceptable range. This includes testing values such as 0, 101, -1, 102, and so on. BVA should not approached as a sole testing technique rather than an heuristic technique.

Decision table testing…?

Decision table testing is a precise methodology that permits analyzers to assess different mixes of sources of info and conditions, guaranteeing thorough test coverage for complex business rules. In this article, we will investigate choice table testing top to bottom, giving down to earth guides to represent its application and advantages in true situations.

Example 1: Loan Approval System
Let's consider a loan approval system that determines whether a customer is eligible for a loan based on their credit score, income, and loan amount. The decision table for this scenario would look like:


By using decision table testing, analyzers can efficiently assess various blends of conditions and come to informed conclusions about test inclusion. The viable models gave in this article exhibit the application and advantages of decision table testing in certifiable model.

Use case testing…?

It is a record of interactions between an actor and a system. In order to achieve user credentials, certain terms are required to follow like
•Interaction
.Actor
.System

WHO WORKS WITH USE CASES…
Use cases are made for posting conceivable client activities and checking planned framework usefulness. They have essential significance for:

Stakeholder’s…..who can utilize this archive to all the more likely handle programming necessities. For example, use cases can be accumulated into a diagram of programming capabilities and execution. Which can be introduced to the stakeholders to sum up accessible tasks.

Developers:
who can use cases as rules for putting together framework prerequisites. For instance, a utilization case directs the login capability. In this manner, an engineer needs to code the module liable for its effective finishing.

QA trained professionals…
who apply use cases as a reason for composing experiments. Since the previous characterize the interaction stream, calling attention to how things can veer off-track becomes more straightforward. At the point when you have a client/framework guide, deciding how and where potential issues can happen is substantially more effective.

Use case testing explanation with examples



LCSAJ…?
Technically it falls under white box testing
The expansion of LCSAJ is linear code sequence and jump

This level of the code is executed with the current test cases . It helps in planning new test cases, which can expand the inclusion of the code under test. When the code inclusion arrives at a specific level, we can stop the testing. Consequently, LCSAJ strategy helps in deciding when to stop the product testing

Each LCSAJ addresses a code segment that executes consecutively from the beginning stage to the ending point, and afterward breaks the successive stream to move the control stream.

Each line of code has thickness, i.e., the times a line number shows up in LCSAJs. For instance, the line number 7 has a thickness of 7 since it shows up in 7 LCSAJs.

100 percent LCSAJ inclusion will be accomplished assuming the test information covers all the above LCSAJs in the table.

Statement Coverage = Number of executable statements executed x 100
                    Total number of executable statements
Decision Coverage = Number of decisions exercised x 100
                    Total number of decisions