Testing Posts

Software testing is a process of checking and validating the functionality of an application to determine if it meets specified requirements. It is about finding application faults and verifying where the application is operating according to the end-user needs.

Important Software Testing Techniques:-

• Boundary Value Analysis (BVA)
• Equivalence Class Partitioning
• Decision Table based testing.
• State Transition
• Error Guessing
• Boundary Value Analysis (BVA)

1. The marginal cost assessment is based entirely on trying the boundaries between partitions. It includes maximum, minimum, internal, or external barriers, typical values, and error values. It is generally seen that numerous errors occur at the obstacles of the defined input values as opposed to the center.

2. It is also known as BVA and offers a selection of test entities that train limit values. This black container test method improves equivalence partitioning. This software program trying one approach is based on the principle that if a machine works well for these exact values, it will paint error-free for all values that are between the two limits.

Let's see one example:

Input condition is valid between 1 and 10 Boundary values 0,1,2 and 9,10,11

Equivalence Class Partitioning

The equal class phase lets you divide a hard and fast check state into separate sections which are taken into consideration identical. The equal class division software program test technique breaks the input area of a program into a class of information, so a test case has to be designed.

Let’s see one example:

Input conditions are valid between

1 to 10 and 20 to 30

Hence, there are five equivalence classes

--- to 0 (invalid)

1 to 10 (valid)

11 to 19 (invalid)

20 to 30 (valid)

31 to --- (invalid)

You select values from each class, i.e.,

-2, 3, 15, 25, 45

Decision Table Based Testing

The decision table is known as the cause and effect table. This testing technique is suitable for input features that have a logical relationship between inputs. In this technique, combinations of inputs are processed. In order to identify the test case with the decision table, it is necessary to consider the terms, actions, and procedures. Conditions are taken as input and actions as output.

Testing Using The Decision Table In The Login Form

CONDITIONS - CASE 1, CASE 2, CASE 3, CASE 4

| EMAIL | F | T | F | T | PASSWORD | F | F | T | T | OUTPUT | ERROR | ERROR | ERROR | HOME SCREEN

CASE 1: Email And Password Wrong: Error Message Displayed.

CASE 2: Email True And Password Wrong, Error Message Displayed.

CASE 3: Email Wrong And Password True, Error Message Displayed.

CASE 4: Email And Password True, Redirect to Home screen

State Transition Testing Technique

In-State Transition technique changes in input conditions change the state of the Application Under Test (AUT). This testing technique allows the tester to test the behavior of an AUT. The tester can perform this action by entering various input conditions in a sequence. In-State transition technique, the testing team provides positive as well as negative input test values for evaluating the system behavior.

Presently We Make A Diagram For Forgot Password/OTP Proces

1. First Enter the Right Number In This Text Box and Click RESET PASSWORD Button. One OTP Comes On Mobile Number.
2. To reset the secret word you should experience the "OTP'' framework. The first run-through the client enters is "OTP '', they will be permitted to go to the secret phrase change page.
3. In the event that the client enters mistaken "OTP '' unexpectedly and second, the framework will request the third time "OTP'' is entered.
4. In the event that "OTP'' is valid, it will be permitted to go to the secret phrase change page, in any case, if the OTP is off base the third time, an Error Message Displayed Like "Your OTP has expired!!".

State Transition Table

ATTEMPT CORRECT PIN INCORRECT PIN

| [B1] Start | B5 | B2

| [B2] First attempt | B5 | B3

| [B3] Second attempt | B5 | B4

| [B4] third attempt | B5 | B4

| [B5] Access granted | - | -

| [B6] Account blocked | - | -

Error Guessing Technique

Error guessing is a software testing technique based on guessing the error that can appear in the code. The technique relies heavily on experience, with the test analysts using their experience to guess the problematic part of the test application. Therefore, test analysts need to be competent and experienced in order to better guess errors. The technique counts a list of possible errors or error-prone situations. Then the tester writes a test case to uncover these errors. To design test cases based on this software testing technique, the analyst can use the experience to identify the conditions.

This technique can be used at any level of testing and for testing the common mistakes like:

• Divide by zero
• Inserting blanks in text fields
• Pressing the enter button without entering values
• Uploading files that exceed the maximum limits
• Exception null pointer.
• Invalid parameters

Let’s see one example:

Suppose there is a requirement that the phone number be numeric and not less than 10 characters. And the software application has a phone number.

The following are the error estimation techniques:

1. What will be the result if the cellphone number is left blank?
2. What is the result if a character other than a digit is entered?
3. What is the result if fewer than 10 digits are entered?

• Before you begin testing any app/website, you should know the concepts of the product, what problems the product solves and how are users going to use it.
• Here the steps to rectify the concept of product 
  • Identifying customer needs.
  • Defining the problem and objectives.
  • Drafting and analysis.
  • Ask for detailed design and drawings.
  • Testing.
  • Final successful delivery.

• ‘’First how we know to understand the requirements here the steps mentioned below’’
• There are mainly two types of requirements: 1. Functional 2. Non-functional
• What are Functional Requirements?
• Functional requirements define the basic system behavior. Essentially, they are what the system does or must not do, and can be thought of in terms of how the system responds to inputs. Functional requirements usually define if/then behaviors and include calculations, data input, and business processes.

• What are the Non-Functional Requirements?
• While functional requirements define what the system does or must not do,
• non-functional requirements specify how the system should do it. Non-functional requirements do not affect the basic functionality of the system Even if the non-functional requirements are not met.
• the system will still perform its basic purpose.

• This will help to customize or change the task from the bug
• This will give ease to know the bug
• It will give a glance at the task and the flow in which it is working
• This will help you prioritize where to look for potential bugs

• Understand the Learners: To write concrete and effective scenarios you must understand your learners and know their needs and expectations.
• Create Real Life and Relevant Situations: Make your scenarios as real as possible.
• Motivate the Learner: A well-written scenario should motivate the learner to action.
• ‘’How to write the test cases’’ 
  • Title Must be strong
  • Include a Strong Description with Assumptions & Preconditions
  • Keep the Test Steps Clear and Concise
  • The result must be Expected
  • Also, Make is Reusable

• This will ensure, that in case something goes wrong in production, it would be any business-critical flows
• Reason to do: for uncertain changes of code, some regression will occur in code, if we didn't check & deployed in the server.to rid the problem in the product needs to check the critical flow twice.

• If you test with the developer, you may miss out on edge cases due to the developer's bias or perspective. So make sure you test the app/website once while the developer is not with you.

• It always helps to communicate any doubt that you have
• As the perspective varies and as well as a method so in case of any doubt ask the developer and correct it.
• Also communicate with the product lead in case of doubt so the better output can be generated of the task with minimal bugs and well-defined task