User Acceptance Test

User Acceptance Test

User Acceptance Testing (UAT) is one of the last stages of the software development life cycle. It is performed after the software has been thoroughly tested. It is sometimes known as End User Testing.

User Acceptance Testing (UAT) is a type of testing performed by the end user or the client to verify/accept the software system before moving the software application to the production environment. UAT is done in the final phase of testing after functional, integration and system testing is done.

The main Purpose of UAT is to validate end to end business flow. It does not focus on cosmetic errors, spelling mistakes or system testing. User Acceptance Testing is carried out in a separate testing environment with production-like data setup. It is kind of black box testing where two or more end-users will be involved.

UAT is performed by –

• Client
• End users

     

API Testing

API Testing

API stands for Application Programming Interface which acts as an intermediate of communication between two applications. Due to this intermediary role of API (Application Programming Interface) two applications talk to each other and performs the required actions efficiently.

API contains a set of rules and guidelines based on which the applications are developed. So in simple we can say an API acts as an interface between two software applications so that two software applications can communicate with each other. 

API testing is a type of software testing that focuses on the functionality, reliability, and performance of application programming interfaces (APIs). APIs act as a bridge between different software systems, allowing them to communicate and exchange data with each other.

API testing is important because it helps ensure that the different systems that make up an application are working together correctly and that the data being exchanged is accurate and secure. It is also important because it helps identify and fix issues before the application is deployed to production.

           

Example:

Suppose you are searching for a hotel room through an online travel booking site. Using the site’s online form, you will fill the necessary information like the city you want to stay in, check-in and check-out dates, number of guests, and number of rooms. Then you click “search.”. But what’s going on between entering your information to receiving your hotel choices? APIs, that’s what! The site aggregates information from many different hotels.

 When you click “search,” the site then interacts with each hotel’s API, which delivers results for available rooms that meet your criteria. And all this happens in seconds because of an API, which acts like a messenger that runs back and forth between applications, databases, and devices.

Alpha and Beta Testing

 Alpha Testing

• Alpha testing performed by Testers who are usually internal employees of the organization.
• Alpha Testing performed at developer’s site.
• Reliability and Security Testing are not performed in-depth Alpha Testing.
• Alpha testing involves both the white box and black box techniques.
• Alpha testing requires a lab environment or testing environment.
• Long execution cycle may be required for Alpha testing.
• Critical issues or fixes can be addressed by developers immediately in Alpha testing.
• Alpha testing is to ensure the quality of the product before moving to Beta testing.  

Beta Testing

• Beta testing is performed by Clients or End Users who are not employees of the organization.
• Beta testing is performed at a client location or end user of the product.
• Reliability, Security, Robustness are checked during Beta Testing.
• Beta Testing typically uses Black Box Testing.
• Beta testing doesn’t require any lab environment or testing environment. The software is made available to the public and is said to be real time environment.
• Only a few weeks of execution are required for Beta testing.
• Most of the issues or feedback is collected from Beta testing will be implemented in future versions of the product.
• Beta testing also concentrates on the quality of the product, but gathers users input on the product and ensures that the product is ready for real time users.

Smoke, Sanity and Regression Testing

Smoke Testing

• Performed on initial builds.
• Tests the stability of a new build.
• Covers end-to-end basic functionalities.
• Executed by testers & sometimes also by developers.
• A part of basic testing.

Sanity Testing

• Performed on stable builds.
• Tests the stability of a new functionality or code changes in the existing build.
• Covers certain modules, in which code changes have been made.
• Executed by testers.
• A part of regression testing.

Regression Testing

• Performed on stable builds.
• Tests the functionality of all affected areas after new functionality /code changes in the existing build.
• Covers detailed testing targeting all the affected areas after new functionalities are added.
• Executed by testers, mostly via automation.
• Regression Testing is a superset of Smoke and Sanity Testing.

Integration and E2E Testing

Integration Testing

Integration testing is defined as a type of testing where software modules or systems are integrated logically and tested as a group. A typical software project consists of multiple software modules, coded by different programmers. 

The purpose of this level of testing is to expose defects in the interaction between these software modules when they are integrated.

 Integration Testing focuses on checking data communication amongst these modules against the requirement of the system specification.

End To End Testing(E2E)

End to end testing (E2E testing) refers to a software testing method that involves testing an application’s workflow from beginning to end. This method basically aims to replicate real user scenarios so that the system can be validated for integration and data integrity.

Essentially, the test goes through every operation the application can perform to test how the application communicates with hardware, network connectivity, external dependencies, databases, and other applications. Usually, E2E testing is executed after functional and system testing is complete.

Software systems nowadays are complex and interconnected with numerous subsystems. If any of the subsystems fails, the whole software system could crash. This is a major risk and can be avoided by end-to-end testing.

Difference between Test Case and Test Scenario

Test Case

• Test Case is basically "how to test" the application.

• For evaluating all of an application's functionality, test cases contain specified test procedures, data, and expected results.

• The majority of test cases are derived from test scenarios. A single Test Scenario might provide several test cases.

Test Scenario

• Test Scenario is basically "what to test" the application.

• A test scenario is a high-level document that defines the functionality to be tested from beginning to end.

• BRS, SRS, and other test artifacts are used to create test scenarios.

  

   Example:-

   Test Scenario: Checking the functionality of Login button

   Test Case:

– TC1: Click the button without entering user name and password.

– TC2: Click the button only entering User name.

– TC3: Click the button while entering wrong user name and wrong password. 

Difference between Use Case and Test Case

 Use Case

•  Use case is a representation of actions which describes the behavior of system   to do a particular task.
•  Use cases are prepared on requirements.
•  The objective of Use case is to ascertain a certain output after the set of               operations.
•  End result is important and all steps are to be executed together in a use case.
•  Requirement documents are required.

Test Case

•  Test case contains the test data, set of instructions to follow and a results of       following the instructions.
•  Test cases are prepared on Use cases.
•  The objective of test case is to ensure that system is working fine for each given         instruction and yields the required result.
•  All steps are important and may have a separate result.
•  Test Data, Test Scripts are required.