InfyOm Blog

latest-post

How to integrate paypal payment gateway with Laravel / PHP ?

In this tutorial we are going to see to integrate the paypal payment gateway with checkout method using the Laravel.

We are going to use package : https://github.com/srmklive/laravel-paypal

Install the package

composer require srmklive/paypal:~3.0

Publish Assets

php artisan vendor:publish --provider "Srmklive\PayPal\Providers\PayPalServiceProvider"

Set Paypal credentials into config/paypal.php

return [
    'mode'    => env('PAYPAL_MODE', 'sandbox'), // Can only be 'sandbox' Or 'live'. 
    'sandbox' => [
        'client_id'         => env('PAYPAL_SANDBOX_CLIENT_ID', ''),
        'client_secret'     => env('PAYPAL_SANDBOX_CLIENT_SECRET', ''),
        'app_id'            => '',
    ],
    ......
    ......
];

Create Routes

routes/web.php

 Route::get('paypal-onboard', [PaypalController::class, 'onBoard'])->name('paypal.init');
 Route::get('paypal-payment-success', [PaypalController::class, 'success'])->name('paypal.success');
 Route::get('paypal-payment-failed', [PaypalController::class, 'failed'])->name('paypal.failed');

Create Controller

app\Http\Controllers\PaypalController.php

setCurrency('EUR');
        $provider->getAccessToken();
        $data = [
            "intent"              => "CAPTURE",
            "purchase_units"      => [
                [
                    "amount" => [
                        "value"         => 100,
                        "currency_code" => getCurrencyCode(),
                    ],
                ],
            ],
            "application_context" => [
                "cancel_url" => route('user.paypal.failed'),
                "return_url" => route('user.paypal.success'),
            ],
        ];

        $order = $provider->createOrder($data);

        return redirect($order['links'][1]['href']);
    }

    public function failed()
    {
        dd('Your payment has been declend. The payment cancelation page goes here!');
    }

    public function success(Request $request)
    {
        $provider = new PayPal();      // To use express checkout.
        $provider->getAccessToken();
        $token = $request->get('token');

        $orderInfo = $provider->showOrderDetails($token);
        $response = $provider->capturePaymentOrder($token);

        dump($orderInfo);
        dd($response);
    }
}

That's it. Enjoy.

September 01, 20221 minuteuserVishal Ribdiya

Posts

How to explain the tricks to close your next deal

Introduction

Persuasion is a method of communication aimed at influencing the attitudes, beliefs, or behaviors of others. In terms of sales, understanding usually occurs when a sales representative tries to convince a prospect that their product or service is the best solution to their problem.
Let's review the persuasion strategy you can implement today to close your next deal.

1. Personalize your message

If you want to explain the possibility of considering your product, resist the request to follow the general sales script. When you make excessive rehearsal noise or don’t share messages or information that seems to suit your prospect, your efforts go to one ear and go to the other.
This doesn't mean you need to fully wing your sales calls, it does mean you need to be prepared to adjust your message based on what interests you in the potential.

2. Focus on problem-solving

Instead of telling the prospect all the reasons why they should buy your product (which may feel pressure and emotion), focus on sharing all the reasons why your product can help them solve their problem. By focusing on their concerns and locating your offer as a solution, you are showing the value of your product without excessive pressure.

3. Give social proof

Letting your past customers sell to you - knowing when to take advantage of social proof can be a powerful persuasive trick.
While buyers may take your point as a sales representative with a grain of salt because they know you want to sell, they are more likely to trust a testimonial or story from a previous customer who was looking for a similar solution.

4. Assume goals

Picture: You feel ready to call your sales call. You think you have a solid understanding of who the prospects are and what they are looking for. Your notes have been typed and you are ready to close the deal.
Then during a call, potentially throws out several turns, asking you questions and mentioning objections that you weren’t prepared to account for - the dream of every sales rip. But don't go too far. This is a valuable learning experience.

5. Empower empowerment decision making

After all, you want your customers to buy from you because they really want to, not because they feel pressured. And let’s be realistic - including your prospects, don’t like to tell anyone what to do, so you’ll avoid being too direct in your approach. As a sales representative, it is your job to provide the context and information that makes your product a thought-provoking product.

6. Make personal connections

It's a basic rule of human interaction - we're all ready to trust and engage with people we really love on a deeper level. While buyers can choose your product or brand as a sales representative, you are the main source of human engagement representing your company.

7. Don’t rush into the process

Last but not least, don't rush your prospect through the sales process. We get it - you have goals on a regular basis. However, effective persuasion should seem natural to the prospect. They do not feel pressured or rushed to sign the dotted line. This doesn’t mean you can’t implement a sense of urgency or be on time - in fact making a little sense of urgency (such as paying a special price for a limited time) can be an effective trick.
October 16, 20203 minutesauthorAnkit Kalathiya
Bug Life Cycle

Introduction to Bug Life Cycle

The fault life cycle or defect life cycle is the specific set of states that a fault goes through before it is closed or resolved. When a fault is detected - by a tester or someone else on the team - the life cycle provides a tangible way to track the progress of a bug fix, and during the fault's life, multiple individuals touch it - directly or indirectly. Troubleshooting is not necessarily the responsibility of a single individual. At different stages of the life cycle, several members of the project team will be responsible for the error. This blog will help you understand how many cases the error goes through vary from project to project. The life cycle diagram covers all possible situations.

What’s The Difference Between Bug, Defect, Failure, Or Error?

Bug: If testers find any mismatch in the application/system in the testing phase then they call it a Bug.

As I mentioned earlier, there is a contradiction in the usage of Bug and Defect. People widely say the bug is an informal name for the defect.

Defect: The variation between the actual results and expected results is known as a defect.

If a developer finds an issue and corrects it by himself in the development phase then it’s called a defect.

Failure: Once the product is deployed and customers find any issues then they call the product a failure product. After release, if an end-user finds an issue then that particular issue is called a failure

Error: We can’t compile or run a program due to coding mistakes in a program. If a developer is unable to successfully compile or run a program then they call it an error.

Software Defects Are Basically Classified According To Two Types:

Severity

Bug Severity or Defect Severity in testing is a degree of impact a bug or a Defect has on the software application under test. A higher effect of bug/defect on system functionality will lead to a higher severity level. A Quality Assurance engineer usually determines the severity level of a bug/defect.

Types of Severity

In Software Testing, Types of Severity of bug/defect can be categorized into four parts:

Critical: This defect indicates complete shut-down of the process, nothing can proceed further

Major: It is a highly severe defect and collapses the system. However, certain parts of the system remain functional

Medium:/ It causes some undesirable behavior, but the system is still functional

Low: It won't cause any major break-down of the system

Priority

Priority is defined as the order in which a defect should be fixed. The higher the priority the sooner the defect should be resolved.

Priority Types

Types of Priority of bug/defect can be categorized into three parts:

Low: The Defect is an irritant but a repair can be done once the more serious Defect has been fixed

Medium: During the normal course of the development activities, defects should be resolved. It can wait until a new version is created

High: The defect must be resolved as soon as possible as it affects the system severely and cannot be used until it is fixed

(A) High Priority, High Severity

An error occurs on the basic functionality of the application and will not allow the user to use the system. (E.g. A site maintaining the student details, on saving record if it doesn't allow saving the record then this is a high priority and high severity bug.)

(B) High Priority, Low Severity

High Priority and low severity status indicate defects have to be fixed on an immediate basis but do not affect the application while High Severity and low priority status indicate defects have to be fixed but not on an immediate basis.

(C) Low Priority Low Severity

A minor low severity bug occurs when there is almost no impact on the functionality, but it is still a valid defect that should be corrected. Examples of this could include spelling mistakes in error messages printed to users or defects to enhance the look and feel of a feature.

(D) Low Priority High Severity

This is a high severity error, but it can be prioritized at a low priority as it can be resolved with the next release as a change request. On the user experience. This type of defect can be classified in the category of High severity but Low priority.

Bug Life Cycle

2020-12-18-5fdca76589590

New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.

Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to the developer team

Open: The developer starts analyzing and works on the defect fix

Fixed: When a developer makes a necessary code change and verifies the change, he or she can make bug status as "Fixed."

Pending retest: Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the tester's end, the status assigned is "pending retest."

Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to "Re-test."

Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is "verified."

Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to "reopened". Once again the bug goes through the life cycle.

Closed: If the bug no longer exists then the tester assigns the status "Closed."

Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to "duplicate."

Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to "rejected."

Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then the status "Deferred" is assigned to such bugs

Not a bug: If it does not affect the functionality of the application then the status assigned to a bug is "Not a bug".

Defect Life Cycle Explained

2020-12-18-5fdca75fd9a1a

  1. The tester finds the defective status assigned to the defect.

  2. A defect is forwarded to the project manager for analysis.

  3. The project manager decides whether a defect is valid.

  4. Here the defect is invalid. The status is "Rejected".

  5. The project manager assigns a rejected status.

  6. If the bug is not resolved, the next step is to check that it is in scope.

Suppose we have another function - email functionality for the same application, and you find a problem with it. However, it is not part of the current version if such errors are assigned as a deferred or deferred status.

  1. Next, the manager checks to see if a similar error has occurred earlier. If so, a duplicate status is assigned to the error.

  2. If not, the bug is assigned to the developer, who starts correcting the code.

  3. During this phase, the defect is assigned a status in the process,

  4. Once the code is fixed. A defect is assigned a status fixed.

  5. Next, the tester tests the code again. If the test case is passed, the defect is closed. If the test cases fail again, the bug is reopened and assigned to the developer.

  6. Consider a situation where, during the first release of the flight reservation, an error was detected in the fax order, which has been fixed and the status of closed has been assigned. The same error occurred again during the second upgrade version.

In such cases, a closed defect is opened again.

"That's all to Bug Life Cycle"

October 13, 20206 minutesauthorBhumi Khimani
Export annotations of PDFTron using jquery

Here we will learn how to export annotations drawn using PDFTron.

Events for export annotation

When we draw any annotation "annotationChanged" event will be fired, then we cache that event and we can export that annotation using "exportAnnotations".

When we draw annotations we'll save them in the database and when we reload the same document we can retrieve saved annotations from the database and can again show them, we will learn that in my next blog post.

Here is an example of how to save an annotation in a database.

Example

WebViewer
   (
     { path: 'path_to_the_PDFTron_'lib'_folder_on_your_server',     
      css: 'webviewer_css',     
      licenseKey: 'YOUR_PDF_TRON_LICENSE_KEY',     
      initialDoc: 'YOUR_FILE URL' //url of a file to load 
     }, 
    document.getElementById('viewer')
   )     
  .then(function (instance) {        
       let docViewer = instance.docViewer;        
       let annotManager = instance.annotManager;                 
       annotManager.on('annotationChanged', 
       (annots, action, e) => {             
            if (e.imported) return;
            annotManager.exportAnnotations({
                links: false,
                widgets: false,
                annotList: annots
            }).then(function (xfdfStrings) {

                annots.forEach(function (annot) {
                    if (action === "delete") {
                        deleteAnnotation(annot.mu);
                    } else {
                        saveAnnotation(annot.mu, xfdfStrings);
                    }
                });

                if (action === "add") {
                    annotManager.selectAnnotation(annots[0]);

                    if (annots[0] !== 'Comment') {
                        // to open comment box

document.getElementById('viewer').childNodes[0].contentWindow.document.querySelector
('div[data element="annotationCommentButton"]').click();
                    }
                }
            });
        });
    });

let saveAnnotation = function (annotationId, annotationXfdf) {
    let saveAnnotationUrl = '';
    if (fromExtension) {
        saveAnnotationUrl = YOUR_PROJECT_URL/annotations/${annotationId};
    } else {
        saveAnnotationUrl = YOUR_PROJECT_URL/annotations/${annotationId};
    }

    $.ajax({
        url: saveAnnotationUrl,
        type: 'POST',
        data: {annotation: annotationXfdf},
        success: function (result) {
            console.log(result);
        },
        error: function (result) {
            console.log(result);
        }
    });
};

let deleteAnnotation = function (annotationId) {

    let deleteAnnotationUrl = '';
    if (fromExtension) {
        deleteAnnotationUrl = YOUR_PROJECT_URL/annotations/${annotationId};
    } else {
        deleteAnnotationUrl = YOUR_PROJECT_URL/annotations/${annotationId};
    }

    $.ajax({
        url: deleteAnnotationUrl,
        type: 'DELETE',
        success: function (result) {
            console.log(result);
        },
        error: function (result) {
            console.log(result);
        }
    });
};
October 10, 20201 minuteauthorMonika Vaghasiya
How to create different type shape in android java

Hello, wonderful friends today in this blog on learning in android XML files creating different types of shape creating. A shape is an XML file that defines a geometric shape, including strokes, colors, and gradients

First Creating .xml file:

  1. Open android studio
  2. Go to drawable
  3. Right-click drawable menu

Follow below image steps:

2020-12-18-5fdc731fe3b6a

Now friend starts coding:

  • Creating a capsule shape flow below code:
<?xml version="1.0" encoding="utf-8"?> 
<shape xmlns:android="http://schemas.android.com/apk/res/android" android:shape="rectangle" >
<corners
android:bottomLeftRadius="30dp"
android:bottomRightRadius="30dp"
android:radius="60dp"
android:topLeftRadius="30dp"
android:topRightRadius="30dp"/>

Corners:

The below image is showing the shape corner radius

Solid:

Solid means shape inner color “#CFCFCF”

Padding:

There is always developer confusion between padding and margin. Both provide extra space/gap inside or outside the container. In simple words, margin means to push outside, whereas padding means to push inside.

Size:

It's very simple shape width - height

October 07, 20201 minuteauthorPankaj Valani
How To Integrate onesignal push notification in Android

Step: 1 Create a new Project in Android Studio

First, create a new Android Studio project and add the dependencies and plugin. First set up OneSignal in your project.
Add OneSignal dependency and plugin to your build.Gradle app-level.

apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'
dependencies {
    implementation 'com.onesignal:OneSignal:3.12.6'
}
end add OneSignal dependency to your build.Gradle project-level.

buildscript {
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:4.1.0'
        classpath 'gradle.plugin.com.onesignal:onesignal-gradle-plugin:[0.12.4, 0.99.99]'
    }
}

Step: 2 Create a new OneSignal Project

  • login your OneSignal Account than create an app

    alt


  • Enter Your Android Application Name & Select platform Google Android(FCM)

    alt


  • Generate a Firebase Server Key Read the documentation.
  • Enter your Firebase Server Key & Firebase Sender ID.

alt


alt


alt

Step: 3 Add Your Created Onesignal App ID

Add OneSignl default config to your build.Gradle app-level.
android {
    compileSdkVersion 30
    buildToolsVersion "30.0.2"

    defaultConfig {
        applicationId "com.myapplication.app"
        minSdkVersion 17
        targetSdkVersion 30
        versionCode 1
        versionName "1.0.0"
        multiDexEnabled true
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        manifestPlaceholders = [onesignal_app_id: "Enter Your App ID",]
    }

    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

The next step is to create the class MyApplication & Declare the class MyApplication in AndroidManifest.xml.

import android.app.Application;
import android.content.Context;
import androidx.multidex.MultiDex;
import com.onesignal.OneSignal;

public class MyApplication extends Application {
    public static Context context;
    @Override

    public void onCreate() {
        super.onCreate();
        context = getApplicationContext();
        context = this;         
        OneSignal.startInit(this) .inFocusDisplaying(OneSignal.OSInFocusDisplayOption.Notification)
                .unsubscribeWhenNotificationsAreDisabled(true)
                .init();
    }

    public static Context getContext() {
        return context;
    }
}
Declare the class MyApplication in AndroidManifest.xml.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.myapplication.app">
<uses-permission android:name="android.permission.INTERNET"/
<uses-permission
android:name="android.permission.ACCESS_NETWORK_STATE" />

    <application
        android:name="com.myapplication.app.MyApplication"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:requestLegacyExternalStorage="true"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">

        <activity
    android:name="com.myapplication.app.activity.SplashActivity"
            android:screenOrientation="portrait">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

alt

October 01, 20201 minuteauthorVivek Beladiya
How create a sitemap for your Gatsby site

We are adding a sitemap in our all site pages for making sure search engines (such as Google) can find and crawl them all.

So, I will show you how to set a sitemap on the Gatsby site.

Using gatsby-plugin-sitemap

To generate an XML sitemap, you will use the gatsby-plugin-sitemap package.

Install the package by running the following command: npm install gatsby-plugin-sitemap

How to configure

Once the installation is complete, you can now add this plugin to your gatsby-config.js, like so:

Configure siteUrl and add this {resolve: gatsby-plugin-sitemap} into the plugins array. code looks like

module.exports = {
  siteMetadata: {
    title: `InfyOm Technologies`,
    description: `InfyOm Technologies`,
    keyword: `InfyOm Technologies`,
    author: `@gatsbyjs`,
    siteUrl: `http://infyom.com`
  },
  flags: {
    PRESERVE_WEBPACK_CACHE: true,
  },
  plugins: [
    {resolve: `gatsby-plugin-sitemap`},
  ],
}

Above is the minimal configuration required to have it work. By default, the generated sitemap will include all of your site’s pages.

You can exclude a path using the exclude option. you need to configure its

  • output (string) The file path and name. Defaults to /sitemap.xml.
  • exclude (array of strings) An array of paths to exclude from the sitemap.

code looks like,

module.exports = {
  siteMetadata: {
    title: `InfyOm Technologies`,
    description: `InfyOm Technologies`,
    keyword: `InfyOm Technologies`,
    author: `@gatsbyjs`,
    siteUrl: `http://infyom.com`
  },
  flags: {
    PRESERVE_WEBPACK_CACHE: true,
  },
  plugins: [
    {
    resolve: `gatsby-plugin-sitemap`,
    options: {
      output: `/some-other-sitemap.xml`,
        exclude: [`/category/*`, `/path/to/page`],
        }
    },
  ],
}

NOTE: This plugin only generates an output when run in production mode! To test your sitemap, run: gatsby build && gatsby serve

Now we are done and open the sitemap using your domain. for ex. https://abc.com/sitemap.xml

September 28, 20201 minuteauthorShailesh Ladumor
Employee Morale: Play significant role in Business Development  Part-3
As we discussed earlier that we cannot measure Employee Morale directly but we need to look at other organizational aspects. Let’s discuss which aspect we can use and how we can measure employee morale.

Measurement of Morale 

  • Observation 
  • Survey 
  • Periodic Interview
  • Attitude Measurement  
  • Opinion Analysis
  • Morale Indicators
    • Productivity
    • Absenteeism
    • Turnover
    • No. of accident
  • Use suggestion Box 

Observation

We can observe things like how employees are performing their role, their work attitude, and behavior at the workplace. These things can be done by superior by observing subordinates. However the observation method is not used frequently to measure Employee Morale as it has many demerits like overburden on employees, Superior may be bias etc.

Survey

We can use the Survey method to check morale levels in the organization. We can design  questions according to our purpose of measuring morale & Organizational Goals.

Periodic Interview

Management can ensure the efficiency of work by taking regular interviews in the organization. Management can do the job satisfaction survey to know the level of Morale in the organization.

Attitude Measurement 

The attitude survey is also known as the morale Survey. We can use the questionnaire or can take face-to-face personal interviews with employees. If the employee strength is high then we can use a random sampling method. We can design the question about their job, co-workers, Supervision, and Organization. But we need to pre-decide the questions & keep them in written documents. 

Opinion Analysis

We can do opinion analysis as well. We can ask for various quotations from employees regarding existing Policies, Strategies, Rules, and Regulations in the organization. 

Morale Indicators

We can use morale indicators like Productivity, Absenteeism, Turnover. No. of Accident etc. low Productivity, high Absenteeism, and high Turnover are signs of low morale in the organization. On the other hand, the high Productivity, low Absenteeism, low Turnover rate are the sign of high Employee Morale in organization. 

Use Suggestion Box

We can use a Suggestion Box where the employees can give their Inputs related to their work and workplace. By doing this we came to know about the employees’ likes & dislikes.

Importance of High Morale

We cannot underestimate morale at our workplace as we know that happy employees are more productive. Job satisfaction matters to keep the workforce happy. Happy employees bring success to organizations by their efficient work, loyalty, and commitment which has a direct impact on organizational growth and profitability.

Demerits of Low Employee Morale

The low morale leads to many problems in the organization as the employees are not happy with their work. high turnover, absenteeism, unclear expectation from both side Employees as well as Employer, increase in grievances and complain, lack of peaceful industrial relation, increase accident rate, Increase in industrial disputes, etc. there all problem decreased the profitability, competency in market & Goodwill, so the workforce with low morale seems dangerous for the organization.

To open up, we can say that we need to take care of our employees, make them happy and they will take care of our business. For this, we need to maintain high morale in our organization.


September 25, 20203 minutesauthorMariyam Bemat
Software Testing Types

Different Types Of Software Testing

Given below is the list of some common types of Software Testing:

Accessibility Testing:

The purpose of accessibility testing is to determine whether the software or application is accessible to people with disabilities or not. Here disability means deaf, color-blind, mentally disabled, blind, elderly, and other disabled groups. Various checks are performed, such as font size for the visually impaired, color and contrast for color blindness, etc.

Ad-Hoc Testing:

The name itself suggests that this test will be conducted on an ad hoc basis, i.e. without reference to the test case and also without a plan or documentation for such type of test. The aim of this test is to find the flaws and breaks the application is executed by executing any sequence of application or random functionality. Ad hoc testing is an informal way of finding bugs and can be done by anyone on the project. It is difficult to identify bugs without a test case, but sometimes it is possible that bugs found in ad hoc tests were not identified using existing test cases.

Alpha Testing:

It is the most common type of test used in the software industry. The objective of this test is to identify all possible problems or defects before launching it to the market or to the user. Alpha Testing takes place at the end of the software development phase but before Beta Testing. Still, minor design changes can be made as a result of such testing. Alpha testing is done on the developer's site. An internal virtual user environment can be created for this type of test.

API Testing:

API testing is done for the system, which has a collection of APIs that should be tested. During the test, a test of the following things is examined: explore the boundary conditions and ensure that the test harness varies the parameters of the API calls in order to verify functionality and expose faults. Parameters. Checks the API behavior that is considering external environment conditions such as files, peripheral devices, etc. Check the sequence of API calls and check if the APIs produce useful results from subsequent calls.

Beta Testing:

Beta tests, also known as user tests, are carried out by the end-users at the end user's location to verify the usability, functionality, compatibility, and reliability tests to provide input on the design, functionality, and usability of a product. These inputs are not only critical to the success of the product but also an investment in future products if the data collected is effectively managed.

Boundary Testing:

Boundary value analysis is a type of black box or specification-based testing technique in which tests are performed using the boundary values.

Example:

An exam has a pass boundary at 50 percent, merit at 75 percent, and distinction at 85 percent. The Valid Boundary values for this scenario will be as follows:

49, 50 - for pass
74, 75 - for merit
84, 85 - for distinction

Boundary values are validated against both valid boundaries and invalid boundaries.

The Invalid Boundary Cases for the above example can be given as follows:

0 - for lower limit boundary value
101 - for upper limit boundary value

Bottom-Up Integration Testing:

Each component at the lower hierarchy is tested individually and then the components that rely upon these components are tested.

Bottom-Up Integration - Flow Diagram

2020-12-14_5fd6f466c1813

The order of Integration by Bottom-down approach will be:

4,2
5,2
6,3
7,3
2,1
3,1

Top-Down Integration Testing:

Top-down integration testing is an integration testing technique used in order to simulate the behavior of the lower-level modules that are not yet integrated. Stubs are the modules that act as temporary replacements for a called module and give the same output as that of the actual product.

The replacement for the 'called' modules is known as 'Stubs' and is also used when the software needs to interact with an external system.

2020-12-14_5fd6f4bf2e648

The above diagrams clearly state that Modules 1, 2, and 3 are available for integration, whereas below modules are still under development that cannot be integrated at this point in time. Hence, Stubs are used to test the modules. The order of Integration will be:

1,2
1,3
2,Stub 1
2,Stub 2
3,Stub 3
3,Stub 4

Unit Testing:

Unit testing, which is a testing method by which individual units are tested to determine if there are any issues on the part of the developer themselves. It is concerned with the functional health of the independent units.

The main aim is to isolate each unit of the system to identify, analyze and fix the defects.

Unit Testing - Advantages:

Reduces errors in the newly developed functions or reduces errors when changing the existing functionality.

Reduces test costs as errors are detected at a very early stage.

Improves the design and allows for better code redesign. Unit tests also show the quality of the build when integrated into Build.

Unit Testing Life Cycle:

2020-12-14_5fd6f5139750d

Unit Testing Techniques:

  • Black Box Testing - Using which the user interface, input, and output are tested.
  • White Box Testing - used to test each one of those functions' behavior.
  • Gray Box Testing - Used to execute tests, risks, and assessment methods.

System Testing:

System testing (ST) is a black-box testing technique performed to assess the complete system's compliance with specified requirements. In system testing, the functionalities of the system are tested from an end-to-end perspective. System testing is generally carried out by a team that is independent of the development team to measure the quality of the system in an unbiased manner. Includes functional and non-functional tests.

Types of System Tests:

2020-12-14_5fd6f54692474

Sanity Testing:

Sanity testing, which is a software testing method that the testing team performs for some basic tests. The goal of the core test is to perform it whenever a new test architecture is received. Terms such as smoke test, build validation test, basic acceptance test, or health test are used interchangeably, however, each of them is used under a slightly different scenario,

The sanity test is usually unwritten and helps to identify missing dependent functions. It is used to determine if the app partition is still working after making a slight change.

The general health test can be both narrow and profound. A mind test is a narrow regression test that focuses on one or several domains of functions.

Smoke Testing:

The smoke test is a testing technique that is inspired by the hardware test, which checks for smoke from hardware components once the hardware is turned on. Similarly, in the context of software testing, the smoke test refers to testing the basic functionality of the build. If the test fails, the build is declared unstable and is NOT tested again until the build smoke test is passed.

Smoke Testing - Features:

  • Identify the business-critical functions that a product must perform.
  • Design and run the basic functions of the application.
  • Make sure the smoke test passes each and every build to continue testing.
  • Smoke testing enables obvious errors to be revealed, saving time and effort.
  • Smoking testing can be manual or automated.

Interface Testing:

Interface testing is performed to assess whether systems or components are passing data and properly controlling each other. It is to check if all interactions between these modules are working properly and errors are handled properly.

Interface Testing - Checklist

  • Check that communication between systems is done correctly
  • Check if all supported hardware/software has been tested
  • Check if all related documents are supported/open on all platforms
  • Check security requirements or encryption when communicating between application server systems

Regression Testing:

Regression testing for a black-box testing technique consists of re-executing those tests that are affected by code changes. These tests should be performed as much as possible throughout the software development life cycle.

Types of Regression Tests:

  • Final Regression Tests: - A "final regression testing" is performed to validate the build that hasn't changed for a period of time. This build is deployed or shipped to customers.
  • Regression Tests: - A normal regression testing is performed to verify if the build has NOT broken any other parts of the application by the recent code changes for defect fixing or for enhancement.

Selecting Regression Tests:

  • Requires knowledge of the system and its effects on the existing functions.
  • Tests are selected based on the area of ​​common failure.
  • Tests are chosen to include the area where code changes have been made multiple times.
  • Tests are selected based on the criticality of the features.

Regression Testing Steps:

  • Regression tests are the ideal cases of automation that result in better Return On Investment (ROI).
  • Select the regression tests.
  • Choose an apt tool and automate regression testing.
  • Verify applications with checkpoints.
  • Manage regression testing and update as needed.
  • Schedule tests.
  • Integrate with builds.

Load Testing:

Load testing is a performance testing technique using which the response of the system is measured under various load conditions. The load testing is performed for normal and peak load conditions

Load Testing Approach:

  • Evaluate performance acceptance criteria.
  • Identify critical scenarios.
  • Design the workload model.
  • Identify target load levels.
  • Design the tests.
  • Run the tests.
  • Analyze the results

Objectives of Load Testing:

  • Response time.
  • Resource usage rate.
  • Maximum user load.
  • Work-related metrics

Stress Testing:

Stress testing is a non-functional testing technique performed as part of performance testing. During stress testing, the system is monitored after overloading the system to ensure that the system can withstand the stress. System recovery from this phase (after stress) is very critical as it is very likely to occur in the production environment.

Reasons for performing stress tests:

  • This allows the test team to monitor the performance of the system during failures.
  • To check if the system saved data before crashing or NOT.
  • To check if the system is printing messages Significant error during a failure or if it has printed random exceptions
  • To check whether unexpected failures do not lead to safety issues

Stress Tests - Scenarios:

  • Monitor the behavior of the system when the maximum number of 'users are logged in at the same time
  • All users performing critical operations at the same time
  • All users accessing the same file
  • Hardware issues such as the downed database server or some of the servers in a downing farm breakdown.

Compatibility Testing:

Compatibility testing is non-functional testing conducted on the application to evaluate the application's compatibility within different environments. It can be of two types - forward compatibility testing and backward compatibility testing.

  • Operating system Compatibility Testing - Linux, macOS, Windows
  • Database Compatibility Testing - Oracle SQL Server
  • Browser Compatibility Testing - IE, Chrome, Firefox
  • Other System Software - Web server, networking/ messaging tool, etc.

Localization Testing:

Localization testing is a software testing technique by which software behavior is tested for a specific region, locality, or culture. The purpose of conducting the localization test for a program is to test the appropriate linguistic and cultural aspects of a particular site.

Software Testing Methods

There are various methods for testing software. These methods are chosen by testers based on their requirements and methodologies. But three fundamental software testing methods are used in every project development.

Types of Software Testing Methods and Levels

  • White Box Testing
  • Black Box Testing
  • Grey Box Testing

White Box Testing & Levels

The White Box Test is also known as the Open / Clear Box Test / Glass Box Test. From a developer's perspective, it is known as Code Oriented Testing / Structural Testing. In This type of testing, technical tests can be performed within the internal structure, logical design, and implementation of different modules. Here, the tester uses preferred input/exercise paths via code to determine the correct or exact output. is known as code-oriented testing, it contains technical tests and script-based tests as part of its testing phase.

White Box Testing Levels

  • Unit Testing
  • Integration Testing
  • System Testing

Black Box Testing & Levels

This test is known as a behavior test, in which the software tests the internal structure, design, and implementation, as well as the user interface and UX of the software under test, which is not known to the tester. Black box tests are both functional and non-functional, but most of the time they are functional. This testing technique is known as black-box testing because the software or product is not known/confirmed to the tester in advance.

Using this technique of testing to find errors in these mentioned categories:

  • Software malfunction.
  • Error in the interface.
  • Errors in concepts.
  • Errors related to the database.
  • Performance or behavior errors.
  • Errors in product startup or termination

Black Box Testing Levels

  • Integration Testing
  • System Testing
  • Acceptance Testing

Grey Box Testing & Levels

This software testing technique combines the concept of black box and white box testing. In the gray box test, the inside of your product is partly known to the tester. This has partial access to data structures residing internally to design different test cases, but at the same time testing from a user's perspective or as a black box tester.

“Still There are various methods for testing software. These methods are chosen by testers based on their requirements and methodologies.”

September 18, 202011 minutesauthorBhumi Khimani