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.

Importance of screenshots

Importance of screenshots attached when logging a defect

  Screenshots and video recordings: Attaching a screenshot of the defect and its video recording can help you to locate the issue quickly.

 Expected vs. actual results: Convey what should be the expected results and what is the actual result to help the developer get a clear picture of what's expected and what's not.

   

              

Log defects

Log Defects   

  Defect logging is simply finding bugs and defects in the application that is being tested. The testing team checks for potential issues and logs the defects along with their status and priority before assigning it to the development team.

   ▪  Defect ID - Unique identification number for the defect.

▪ Defect Description - Detailed description of the defect including information about the module in which defect was found.

▪ Version - Version of the application in which defect was found.

▪ Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.

▪ Date Raised - Date when the defect is raised

▪ Reference- where you Provide reference to the documents like . requirements, design, architecture or may be even

screenshots of the error to help understand the defect

▪ Detected By - Name/ID of the tester who raised the defect

▪ Status - Status of the defect , more on this later

▪ Fixed by - Name/ID of the developer who fixed it

▪ Date Closed - Date when the defect is closed

▪ Severity which describes the impact of the defect on the application

▪ Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively

                                 

STLC

STLC

  The Software Testing Life Cycle (STLC) is a systematic approach to testing a software application to ensure that it meets the requirements and is free of defects. STLC has different phases.

.

1:Requirement Analysis

  Requirement Analysis is the first step of the Software Testing Life Cycle (STLC). In this phase testers  understands the requirements like what is to be tested. If anything is missing or not understandable then the testers meets with the stakeholders to better understand the detailed knowledge of requirements.       

2:Test Planning.

 Test Planning is the most efficient phase of the software testing life cycle where all testing plans are defined. In this phase manager of the testing, team calculates the estimated effort and cost for the testing work. This phase gets started once the requirement-gathering phase is completed.

 3:Test Case Development

 The test case development phase gets started once the test planning phase is completed. In this phase testing team notes down the detailed test cases. The testing team also prepares the required test data for the testing. When the test cases are prepared then they are reviewed by the testers team.

4. Test Environment Setup

 Test environment setup is a vital part of the STLC. Basically, the test environment decides the conditions on which software is tested. This is independent activity and can be started along with test case development. In this process, the testing team is not involved. either the developer or the customer creates the testing environment.

5. Test Execution

 After the test case development and test environment setup test execution phase gets started. In this phase testing team starts executing test cases based on prepared test cases in the earlier step.

6. Test Closure

 Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-related activities are completed and documented. The main objective of the test closure stage is to ensure that all testing-related activities have been completed and that the software is ready for release.

 At the end of the test closure stage, the testing team should have a clear understanding of the software’s quality and reliability, and any defects or issues that were identified during testing should have been resolved. The test closure stage also includes documenting the testing process and any lessons learned so that they can be used to improve future testing processes.

Requirement Analysis

 Requirement Analysis Phase

•   Analysis and feasibility study of the requirements is done in this phase.
•   The detailed software requirements are documented. This document is called software      Requirement Specification(SRS).
•   In this role business Analyst, Project Manager, Team Lead...etc. are involved in this          phase analyzing the requirement.

SDLC

 SDLC

    SDLC is a software development lifecycle. It is a systematic and step by step approach to develop a software. It describes different phases involved in the development process.

1:Requirement Analysis

Collect the requirements from the customer and prepare certain documents. Each and everything will be documented. Business people like project manager, product manager are speak to customer collect the requirements and prepare SRS document, in that document they will mention all the requirements what customers need.

Ex; Opening account in bank, we need name, date of birth, photo, address proof, Identity proof, minimum deposit, customer signature

2:System Design

Based on the documents  the designers will prepare the design document. Designers divide the the entire requirement into high level modules and low level modules based on the application. 

Ex: We need to sorted out each and every module like login page, Home page, transfer money, saving money.

3:Implementation

Design phase completed the developer will develop the software based on the design document.

Ex:  Based on design document they have some input and then they will develop software.

4:Testing

After completion of development the testing phase start, In this phase testers involved and test the software .Testers check the application all the functionality is working or not. 

Ex: In the login page ,they will use some input and check the application. 

5:Deployment

To install the software in customer environment then start using the software.

Ex: The application fulfill all the requirements and run properly.

6:Maintanance

Any issues in the deployment side are resolved in this phase.

                                                                                                                                                            

Use case

 Use case

   Describes the system behavior. It explains the functionality or requirement, the customer requirement or project requirement can be specify in the use cases

   Use case is a representation of which describes the behavior of system to do a particular task and accomplish the goal. It is a technique that helps to identify test cases and also it is a description of particular use of the system by a user .

Example:

   

Purpose of tester

 The purpose of a tester in a software development team

      After build the product, the testers detects if any bugs in the product in parallel with the development team. Because of the testing , preventing bugs, reducing development and improving performance and finally they give the quality product to customer.

        

Testing and production environment

Why production and test environment have to be similar 

The software you developed should be meet customers requirements, in which three cases testing environment similar to production environment

1: Software should be similar on both environment.

2: Hardware should be similar on both environment.

3: Data which is used for the business should be similar on both environment.

otherwise it challenging to identify issues.

Software development environments

Software Environment

     Environment refers to the collection of hardware and software tools a system developer uses to build software .

Different environments in a software development team

  There are  four types of environment in software development.  

1:Development environment

     In this environment developers design, program and debug the software .

2:Testing environment

    Testing teams can use this environment to check and fix bugs.

3:Staging environment

    It is a exact replica of production environment to run more tests that check for bugs and errors before you deploy the applications to the live.

4:Production environment

   This is the live environment where the users will access the software you build. It interacts with the users directly.

   

Client and Server

 CLIENT

       A client is a computer hardware device or software that accesses a service made available by a server. In the simple way of understanding ,a client is a computer or from where we are trying to access the application 

Example: Through browser we are able to browse the different website we are able to access, that is client.

SERVER

      A server is a physical computer dedicated to run services to serve the needs of other computers. The server is often(but not always)located on a separate physical computer. In the simple way of understanding ,a server is basically where the applications are installed.

Example: When we browse something we are getting all this information where exactly these information is available ,that is server.