Automation Testing Insider

🚀 Build a Complete Selenium Automation Framework from Scratch – Step-by-Step!

2025-11-08T23:26:00.000+05:30

If you’ve ever wanted to build a powerful, scalable, and industry-level automation framework, this is your ultimate guide! 💡

Whether you’re a QA Engineer, Test Automation Enthusiast, or Developer, this hands-on framework walkthrough will take you from zero to automation hero — covering everything you need to know to design, implement, and maintain a robust Selenium Framework.

🎥 Watch the complete framework video here:

💻 What You’ll Learn

In this session, I’ll show you how to build a hybrid, data-driven Selenium Framework using the latest tools and practices.
This framework is built using:

Java + Selenium + TestNG + Maven
Log4j for Logging
Extent Reports for Beautiful Reporting
Docker + Jenkins + Selenium Grid for CI/CD and distributed testing
REST Assured integration for API validation
Parallel Execution, Retry Logic, and Thread-Safe Drivers

You’ll also understand how to:

Configure and execute your tests in Jenkins Pipelines
Run your tests in Docker containers
Perform cross-platform testing with Selenium Grid
Automate build notifications and email reports

📘 Framework Documentation (Exclusive Bundle)

Want to follow along with complete documentation and setup guides?
I’ve created a comprehensive bundle that includes everything you need to replicate the framework end-to-end, plus extra resources for CI/CD and Docker integration.

🧾 Course Bundle Includes:

Automation Framework Build – Complete Guide
Jenkins Setup & First Selenium Job (Freestyle Project)
Send Auto Email When Build is Done in Jenkins
Run Jenkins Job Automatically on Git Push
Selenium Grid Setup
Docker for Selenium Grid – Run Tests in Containers
Run Selenium Grid using Docker & Jenkins Pipeline
Selenium – Top 100 Questions and Answers

💰 Get full documentation access for just ₹299
👉 Download the Complete Framework Guide

🎯 Why You’ll Love This Framework

✅ End-to-end setup from scratch
✅ Easy to customize and reuse for any web app
✅ Covers both UI and API testing
✅ Real-time CI/CD and Docker integration
✅ Perfect for interviews and real-world projects

🔗 Get Started Now!

1️⃣ Watch the detailed video tutorial:
🎥 https://youtu.be/CpbuG3P9z7g?si=0_Jy18AVRSsoTF2a

2️⃣ Grab the documentation for just ₹299:
📘 https://atidigitalhub.myinstamojo.com/product/selenium-automation-framework-build-complete?referred_from=category

3️⃣ Start building your own Selenium Framework today!

🔥 Turn your automation skills into real project experience and master the tools top QA teams use every day.
If you find this helpful, don’t forget to like, share, and subscribe to my YouTube channel for more upcoming tutorials on Jenkins, Docker, API testing, and CI/CD pipelines.

Keywords: Selenium Framework, Java Selenium, Automation Framework, Test Automation Framework, Jenkins CI/CD, Selenium Grid, Docker for Selenium, Log4j, Extent Reports, REST Assured, TestNG, QA Automation, Selenium Tutorial, Automation Testing, End-to-End Testing, Selenium Framework Documentation.

API Terminologies Explained – HTTP, HTTPS, Methods, and Endpoints

2025-11-02T22:58:00.002+05:30

🌐 1️⃣ HTTP & HTTPS

🔸 What is HTTP?

HTTP (HyperText Transfer Protocol) is the foundation of communication on the web.
It defines how data is requested and delivered between a client (like Postman or browser) and a server.

When you type a URL or send an API request:

The client sends an HTTP request.
The server processes it and returns a response (data, status code, headers).

🧩 Example:


Request →  GET https://jsonplaceholder.typicode.com/posts/1
Response → 200 OK

🔸 What is HTTPS?

HTTPS (HTTP Secure) is the secure version of HTTP, where communication between client and server is encrypted using SSL/TLS.
This ensures:

🔒 Data privacy (cannot be intercepted easily)
✅ Authentication (verifies server identity)
🛡️ Integrity (data not altered in transit)

💡 In short:
HTTP = plain communication
HTTPS = secure & encrypted communication

📦 2️⃣ Resource & Payload

🔹 Resource

In an API, everything is treated as a resource — users, posts, products, or orders.
Each resource is identified by a unique URL (endpoint).

🧠 Example:

/users → represents a collection of users
/users/5 → represents a single user with ID = 5

So when you make a request:


GET https://dummyjson.com/users/5

You’re requesting the resource “User 5.”

🔹 Payload

The payload is the data sent to the server in the body of an HTTP request — usually with POST or PUT methods.

🧾 Example (POST request payload):


{
  "name": "Hitendra",
  "email": "hitendra@test.com",
  "role": "admin"
}

Here, this JSON object is the payload that the API receives and processes.

Tip:

GET requests don’t usually have payloads.
POST/PUT requests do.

🧮 3️⃣ HTTP Methods

HTTP methods define what action you want to perform on a resource.
Here are the most common methods used in API testing 👇

Method	Description	Example
GET	Retrieve data from a server	`GET /users`
POST	Send new data to the server (create resource)	`POST /users`
PUT	Update an existing resource	`PUT /users/3`
PATCH	Partially update a resource	`PATCH /users/3`
DELETE	Remove a resource	`DELETE /users/3`
HEAD	Same as GET but without body (for metadata)	`HEAD /users`

💬 Real-life analogy:

Action	Example	HTTP Method
View list of customers	“Show me all users”	GET
Add new customer	“Register a new user”	POST
Update user details	“Change email of user 3”	PUT/PATCH
Remove user	“Delete user 3”	DELETE

Sample HTTP post request:

🔗 4️⃣ URI, URL, URN, and Endpoint

These four terms often confuse beginners, so let’s simplify them 👇

🧱 URI (Uniform Resource Identifier)

A URI is a general term for identifying a resource — it can be a name, location, or both.
It’s the umbrella term that covers both URL and URN.

🌍 URL (Uniform Resource Locator)

A URL tells you where a resource is located on the web.
It includes the protocol, domain, and path.

🧾 Example:


https://api.github.com/users/hitendra

Here:

https → Protocol
api.github.com → Domain
/users/hitendra → Path to the resource

So this URL locates the user resource named “hitendra” in GitHub’s API.

🧾 URN (Uniform Resource Name)

A URN identifies a resource by name, not by its location.
It doesn’t include protocol or domain.

Example:


urn:isbn:9780141033570

This refers to a book by its ISBN number — not where it is stored.

📍 Endpoint

An Endpoint is the specific URL where an API resource can be accessed.
It’s the address you hit when making API calls.

Example:


Base URL: https://dummyjson.com
Endpoint: /products/10
Full URL: https://dummyjson.com/products/10

📊 Visual Summary Diagram


[Client] → [HTTP/HTTPS Request] → [Server]
        ↘ Resource (e.g., /users/5)
          ↘ Payload (if POST/PUT)
          ↘ Endpoint = Base URL + Resource Path

URI, URL, URN, Endpoint

🧠 Quick Recap

✅ HTTP – defines communication protocol
✅ HTTPS – secure version of HTTP
✅ Resource – entity (user, post, etc.)
✅ Payload – data sent to server
✅ HTTP Methods – actions on resources
✅ URI = identifier
✅ URL = locator
✅ URN = name
✅ Endpoint = actual callable address

API Testing – What to Verify, Its Advantages & Difference from Web Services

2025-11-02T22:25:00.004+05:30

🚀 API Testing – What to Verify, Its Advantages & Difference from Web Services

🧩 What Exactly Needs to Be Verified in API Testing?

When performing API Testing, the goal isn’t just to check if an endpoint works — it’s to validate how reliably and efficiently the API behaves under various conditions.

Here are the key elements every tester should verify:

1️⃣ Response Status Codes

Each API response carries an HTTP status code that tells you if the request was successful or failed.
Examples:

✅ 200 OK – Request successful
❌ 400 Bad Request – Invalid request
🔒 401 Unauthorized – Authentication required
🚫 404 Not Found – Resource doesn’t exist
💥 500 Internal Server Error – Server-side issue

2️⃣ Response Body Validation

Validate whether:

The data returned matches expected values.
Field names, data types, and structures align with the API specification.
No missing or extra fields are returned.

Example:
If the API should return:


{
  "id": 101,
  "name": "John Doe",
  "email": "john@example.com"
}

You must confirm all keys and data types (int, string, etc.) are accurate.

3️⃣ Response Time & Performance

APIs must respond quickly and consistently.
⏱️ Ideally, response times should be under 1–2 seconds for most business APIs.
You can measure this in Postman or automation frameworks like RestAssured.

4️⃣ Authentication & Authorization

APIs often use tokens or keys to ensure secure access.
Verify that:

Unauthorized requests are rejected.
Valid tokens grant correct access levels.
Session expiry or token invalidation works properly.

5️⃣ Error Handling

Good APIs fail gracefully.
Ensure error messages are:

Readable and consistent.
Contain useful information without exposing sensitive data.

Example:
❌ Avoid → "SQL Exception: syntax error near 'user_id'"
✅ Prefer → "Invalid input: user_id must be a number"

6️⃣ Schema & Contract Validation

Use schema validation tools to confirm the API structure remains consistent even after new releases — helping you catch breaking changes early.

📊 API Verification Flow (Conceptual Diagram)


[Request Sent] 
      ↓
[Server Receives Request]
      ↓
[Process Business Logic]
      ↓
[Generate Response → Validate:
  ✓ Status Code
  ✓ Response Body
  ✓ Headers
  ✓ Time
  ✓ Schema]
      ↓
[Return Response to Client]

⚡ Advantages of API Testing

API testing provides early and fast feedback before UI layers are even built.
Here’s why every QA professional should focus on API-level validation:

Advantage	Description
1️⃣ Faster Execution	No GUI needed — APIs run directly at the service layer.
2️⃣ Early Bug Detection	You can test logic before the UI exists, reducing rework.
3️⃣ Language Independent	APIs exchange data in JSON/XML — any client can test them.
4️⃣ Reusable Test Automation	Once automated, API tests can run in CI/CD pipelines easily.
5️⃣ Improved Coverage	You can test scenarios difficult to perform via UI.
6️⃣ Better Stability	APIs rarely change compared to frontend elements, giving stable tests.

🧠 Tip: Combine API and UI testing to create a hybrid automation framework, ensuring both layers are verified for complete application coverage.

🌐 Difference Between API and Web Services

Many testers use “API” and “Web Service” interchangeably — but there’s a subtle difference.

Feature	API	Web Service
Definition	Interface that allows communication between two software components.	A specific type of API that operates over the web (HTTP, SOAP, REST).
Communication Medium	Can use any protocol — HTTP, HTTPS, TCP, etc.	Works only via the web using HTTP/HTTPS.
Data Format	Can exchange data in JSON, XML, or any format.	Usually XML (SOAP) or JSON (RESTful).
Dependency	Can exist without the internet (e.g., OS APIs, Library APIs).	Requires internet/network to communicate.
Example	Java SDK API, Database API, REST API.	SOAP-based weather service, RESTful booking service.

In short:
👉 Every Web Service is an API, but not every API is a Web Service.

💬 Summary

✔ API testing verifies status codes, data, schema, performance, and security.
✔ It helps detect defects early, ensures data consistency, and supports faster releases.
✔ Understanding the difference between APIs and Web Services helps you design better testing strategies.

API Testing Introduction

2025-11-02T22:15:00.003+05:30

🧪 What is API Testing?

API Testing is the process of verifying whether APIs work as expected — focusing on functionality, reliability, performance, and security.

Unlike UI testing, it doesn’t involve a browser or frontend.
Instead, you directly send requests (GET, POST, PUT, DELETE) and validate responses (status codes, response time, and data).

Key checks during API testing:

✅ Is the response status code correct? (e.g., 200, 404, 401)
✅ Is the response time within the limit?
✅ Are all fields and data types correct?
✅ Is authentication/authorization working properly?
✅ Are error messages meaningful?

⚙️ How to Perform API Testing?

You can perform API Testing using manual tools or automation frameworks.

🔹 Manual API Testing

Tools like Postman, Swagger, or Insomnia help testers send requests and analyze responses without writing code.

Basic flow:

Launch Postman
Create a new request
Enter the API endpoint (URL)
Select the method (GET/POST/PUT/DELETE)
Add headers or authentication if needed
Click Send
Validate the response body, status code, and time

🔹 Automated API Testing

Automation tools like:

RestAssured (Java)
Requests + Pytest (Python)
Karate DSL
Postman + Newman

These help run regression suites, integrate with CI/CD (Jenkins, GitHub Actions), and generate reports automatically.

🔍 Types of APIs

Type	Description	Example
Open APIs (Public APIs)	Available to everyone; used by third parties.	Google Maps, OpenWeather API
Internal APIs (Private APIs)	Used only within an organization for internal systems.	HRMS ↔ Payroll System
Partner APIs	Shared between specific business partners; require access tokens.	Travel site ↔ Airline partner
Composite APIs	Combine multiple endpoints in one call.	Fetch order + shipping + payment info in one response

📘 Quick Recap

✅ API = Communication Bridge between two systems
✅ API Testing = Validating request & response
✅ Can be done manually (Postman) or automated (RestAssured, Python, etc.)
✅ Focus on status codes, response data, time, and security
✅ APIs can be Public, Private, Partner, or Composite

🧠 Pro Tip

Start practicing with free APIs like:
🔹 https://reqres.in
🔹 https://jsonplaceholder.typicode.com
🔹 https://dummyjson.com
These are perfect for learning GET, POST, PUT, DELETE methods.

Latest Technology Trends in Software Testing

2022-12-28T19:00:00.002+05:30

Software testing is an essential part of the software development process, and it has evolved significantly over the years as new technologies and approaches have emerged. Here are some of the latest technology trends in software testing:

Artificial intelligence (AI) and machine learning (ML): AI and ML are being increasingly used in software testing to improve the efficiency and effectiveness of the testing process. For example, AI can be used to analyze test results and identify patterns that may indicate defects or other issues. ML can be used to create and execute test cases based on machine learning algorithms, which can help to identify previously unknown defects or test scenarios that may have been overlooked by human testers.
Continuous testing: Continuous testing is an approach that involves running automated tests continuously throughout the software development process. This helps to identify and fix defects early in the development process, which can reduce the overall cost of testing and improve the quality of the software. Continuous testing requires the use of automation tools and a culture of collaboration and continuous integration.
Test-driven development (TDD): TDD is a software development approach in which tests are written before the code is written. The goal of TDD is to ensure that the code meets the specified requirements and is of high quality. TDD can help to improve the quality of the software and accelerate the development process by identifying and fixing defects early in the development process.
Agile and DevOps: Agile and DevOps are software development methodologies that emphasize rapid iteration and continuous delivery of software. They both rely on automation to accelerate the development and testing process. Agile development is based on short development cycles (called "sprints") in which teams work to deliver incremental improvements to the software. DevOps is a culture and set of practices that emphasizes collaboration and communication between software developers and IT operations teams.
Cloud-based testing: Cloud-based testing involves using cloud-based platforms and tools to conduct software testing. This can help to reduce the cost and complexity of testing by eliminating the need to maintain on-premises testing infrastructure. Cloud-based testing also enables organizations to scale their testing efforts up or down as needed and to access a wide range of testing environments and configurations.
Mobile testing: The increasing use of mobile devices has led to the development of specialized tools and approaches for testing mobile applications. Mobile testing involves verifying that the software functions correctly on different mobile devices and operating systems. It may also involve testing the software's performance and usability on different mobile networks and under different conditions.
Internet of Things (IoT) testing: IoT testing involves verifying the functionality and performance of software that runs on IoT devices. This may include testing the software's ability to communicate with other devices and systems, as well as its ability to handle large volumes of data. IoT testing may also involve testing the security and privacy of the software.

Overall, these are just a few examples of the latest technology trends in software testing. It is important for organizations to stay up-to-date on these trends and to evaluate which ones are the best fit for their specific testing needs. By adopting the latest technologies and approaches, organizations can improve the efficiency and effectiveness of their testing efforts and deliver high-quality software to their customers.

Agile and DevOps, test automation, artificial intelligence for testing

2022-12-27T19:00:00.009+05:30

Agile and DevOps are software development methodologies that emphasize rapid iteration and continuous delivery of software. They both rely on automation to accelerate the development and testing process.

Agile is a project management approach that emphasizes flexibility and rapid iteration. It is based on the Agile Manifesto, which values "individuals and interactions over processes and tools" and "working software over comprehensive documentation." Agile development is often characterized by short development cycles (called "sprints") in which teams work to deliver incremental improvements to the software.

DevOps is a culture and set of practices that emphasizes collaboration and communication between software developers and IT operations teams. It aims to reduce the time and effort required to deliver software by automating and streamlining the build, test, and deployment process.

Test automation is the use of software to automate the process of testing software. It involves creating and executing automated test cases to validate the functionality and performance of the software. Test automation can help to accelerate the testing process and improve the accuracy and reliability of test results.

There are many benefits to using test automation in the context of Agile and DevOps. For example:

Speed: Automated test cases can be run much faster than manual tests, which can help to accelerate the development and testing process.

Accuracy: Automated test cases are less prone to human error than manual tests, which can help to improve the accuracy and reliability of test results.

Coverage: Automated test cases can be designed to test a wide range of scenarios and edge cases, which can help to improve the coverage of the testing process.

Repeatability: Automated test cases can be run multiple times without the need for human intervention, which can help to ensure that the software is tested consistently and thoroughly.

Artificial intelligence (AI) can be used to enhance the process of testing software in a number of ways. For example, AI can be used to analyze test results and identify patterns that may indicate defects or other issues. This can help to improve the efficiency and effectiveness of the testing process by identifying potential issues more quickly and accurately.

AI can also be used to create and execute test cases based on machine learning algorithms. These algorithms can analyze the software and identify test scenarios that may have been overlooked by human testers. This can help to identify previously unknown defects and improve the coverage of the testing process.

In the context of Agile and DevOps, test automation and AI can be used to support the rapid iteration and continuous delivery of software. By automating the testing process and using AI to analyze and optimize test results, organizations can reduce the time and effort required to test software and accelerate the development and delivery process.

However, it is important to note that test automation and AI are not a substitute for human testing. While they can be very useful tools, they are not able to replicate the creativity and critical thinking skills of human testers. As such, it is important to use a combination of automated and manual testing to ensure that the software is thoroughly tested and of high quality.

Overall, the combination of Agile and DevOps, test automation, and AI can help organizations to develop and deliver high-quality software more efficiently and effectively. By leveraging these technologies, organizations can improve their ability to respond to changing market needs and deliver value to customers more quickly. However, it is important to carefully evaluate the suitability of these technologies for a given project and to use them in combination with human testing to ensure the best results.

What is Codeless Automated Testing?

2022-12-26T19:25:00.003+05:30

Codeless automated testing is a testing approach that allows testers to create and execute automated test cases without the need to write code. Instead of writing code, testers use a visual interface or a set of pre-defined commands to create and execute test cases.

One of the main benefits of codeless automated testing is that it allows testers with limited coding skills to create and execute automated tests. This can help to accelerate the testing process and make it more accessible to a wider range of testers. For example, a tester who is not familiar with programming languages can still create and run automated tests using a codeless testing tool.

Another benefit of codeless automated testing is that it can reduce the time and effort required to maintain test cases. Since no code needs to be written, there is less need to update and maintain test cases as the software changes. This can help to reduce the overall cost of testing and make it more efficient.

There are several different tools and platforms available for codeless automated testing. These tools typically provide a visual interface or a set of pre-defined commands that testers can use to create and execute test cases. Some common features of codeless automated testing tools include:

Record and playback functionality: This allows testers to record their actions as they test the software manually, and then play them back automatically to create an automated test case.

Object recognition: This allows the tool to identify and interact with specific elements on the screen, such as buttons or input fields.

Test case management: This allows testers to organize and manage their test cases, including the ability to create and edit test cases, view test results, and track defects.

Test data management: This allows testers to create and manage test data, including the ability to create and edit test data, view test results, and track defects.

Integration with other tools: Many codeless automated testing tools can be integrated with other tools and platforms, such as defect tracking systems, continuous integration systems, and test management systems. This can help to streamline the testing process and make it more efficient.

While codeless automated testing can offer many benefits, it is important to note that it may not be suitable for all testing scenarios. In some cases, writing custom code may be necessary to fully test the software. For example, custom code may be required to test complex logic or to interact with third-party systems or APIs. Additionally, codeless automated testing may not provide the same level of flexibility and control as code-based automated testing.

Despite these limitations, codeless automated testing can be a useful approach for testers who want to create and execute automated tests without the need to write code. It can help to accelerate the testing process and make it more accessible to a wider range of testers, while also reducing the time and effort required to maintain test cases.

In conclusion, codeless automated testing is a valuable tool for testers who want to create and execute automated tests without the need to write code. It can help to accelerate the testing process and make it more efficient, while also making it more accessible to a wider range of testers. However, it is important to carefully evaluate the suitability of codeless automated testing for a given testing scenario, as it may not always be the best fit.

There are several codeless automation tools available in the market, each with its own unique features and capabilities. Some of the more popular codeless automation tools include:

Selenium IDE: This is an open-source browser extension that allows testers to record and play back test cases in the browser. It supports a wide range of browsers, including Chrome, Firefox, and Safari.

TestComplete: This is a commercial automated testing tool that allows testers to create and execute test cases for desktop, web, and mobile applications. It features an easy-to-use visual interface and supports a wide range of programming languages.

TestProject: This is an open-source automated testing platform that allows testers to create and execute test cases for web, mobile, and API applications. It features a visual interface and integrations with popular defect tracking and continuous integration tools.

UiPath: This is a commercial robotic process automation (RPA) platform that allows users to automate repetitive tasks by creating and executing automated workflows. It features a visual interface and integrations with a wide range of applications and systems.

Katalon Studio: This is a free, open-source automated testing platform that allows testers to create and execute test cases for web, mobile, and API applications. It features a visual interface and supports a wide range of programming languages.

Testim: This is a commercial automated testing platform that allows testers to create and execute test cases for web and mobile applications. It features a visual interface and integrations with popular defect tracking and continuous integration tools.

These are just a few examples of the many codeless automation tools available in the market. It is important to carefully evaluate the features and capabilities of each tool to determine which one is the best fit for your specific testing needs.

Defect/Bug Life Cycle

2022-07-23T22:50:00.007+05:30

Defect Life Cycle:

Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime.
It varies from organization to organization and also from project to project as it is governed by the software testing process and also depends upon the tools used.
Defect Life Cycle is a cyclic process, which describes how a defect or bug passes through different stages from the identification stage to the Fixing stage. it begins when a tester finds or logs a bug and it ends when the bug is fixed.
If Developer reject a defect understand the reason why defect is rejected , if developer is correct we can close the defect or else we can discuss it with test lead or project lead and than reopen the defect.

Some of the familiar values used for defects, during their life cycle are :

New : New defect is reported.
Open : The developer is currently working on the defect.
Fixed : The code changes are completed and the defect is resolved .
Deferred : Developers will fixed the defect later.
Duplicate : The defect is same like one of the previous defect. When previous is fixed it also fixed.
Retest : the tester starts the task of retesting the defect to verify if the defect is fixed or not.
Rejected : Developers did not accept the defect .
Close : After re test if defect is working correctly .
Reopen : After re test if defect is still exist then we reopen the defect.
Not a Bug : If the defect does not have an impact on the functionality of the application, then the status of the defect gets changed to “Not a Bug”.
There are others of course, and some groups might use combinations of these values (such as Closed-Fixed, Closed-WontFix, etc.).

Defect Report | Priority and Severity

2022-07-16T22:59:00.010+05:30

Defect Report:

If application is not working as expected we can report that as defect in defect report.
A defect report is a document that has concise details about what defects are identified, what action steps make the defects show up, and what are the expected results instead of the application showing error (defect) while taking particular step by step actions.
Defect Reporting, Defect Tracking, and Status Tracking is called Defect Management. Some companies use Manual Process (Excel workbook), and some companies use Tool-based processes for Defect Management.
Defect Management Tools Examples: Bugzilla / Issue-Tracker / PR-Tracker etc.
Important fields of a Defect Report template:
Defect Id : It is a unique number for every defect we found while testing.
Summary : Full description of the defect .
Detected By : Name of the tester who found the defect .
Assigned to : Currently the defect is assign to whom. When a tester found a defect the it has to assign to any developer.
Severity : Severity defines how impactful a bug can be to the system. It can values either high or medium or low specifies the seriousness of the defect.
Priority : Priority indicates how soon the bug should be fixed. It can values either high or medium or low specifies the importance of the defect or functionality. The defect are fixed based on priorities.

Defect Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect in order to better track and understand the actual progress of the defect lifecycle.
Build version : It show currently build version in which we are testing. We can check this from release note document.
Module : In which module the defect is found.
Environment : The defect is found in which environment like : Test environment, UAT or Production environment.
Defect Type : Specify the type of defect like functional , network , data , performance or UI ( User Interface) etc.
Reproduceable : It has value either YES or NO:

YES: Every time the defect is occurring .
NO: Most of the time its working correctly, only few cases it is failing and not able to reproduce

( If the defect is non reproduceable we can take screen shot of the defect and report it along with the defect.)
Reproduce Steps : Specify the navigation steps to reproduce the defect.

Test Execution Process | Environment setup

2022-07-16T22:48:00.005+05:30

Test Execution:

Test execution is the process of executing the test cases and comparing the expected and actual results.
After developers finish the coding and give the build to the tester , tester will conduct the testing and validate the application as per the requirement.
The developers will prepare the below document and give to the testing team during the build release :

SRN (software release note)
DD (Deployment Document)

Tester deploy the build in test environment a per the instruction in the release document note .
The build is deployed in the test environment either by tester or developer or n/w team.

As we know after build release 1st test should be performed is sanity test .
After Sanity test is pass we will continue test execution and validate all the functionality.
Test execution can be done either manual aur automation.
Testing performed by tester without using any tools is called manual testing.
Testing conducted with the help of tool is called automation testing.
During execution validate all the test cases and specify actual result and status.
If the status is fail we can report that as defect to the developers.

SRN (software release note)

A release note refers to the technical documentation produced and distributed alongside the launch of a new software product or a product update.
It briefly describes a new product or specific detail level changes included in a product update.
A software release notes template is a simple document that companies use to document any changes to their product. Elements of release notes template are like :
Build version , build location , requirement in build , Precondition , environment , deployment steps , known issue , defect files , prepare by.

Requirement Traceability Matrix

2022-07-16T22:33:00.003+05:30

Traceability Matrix:

In this document the test cases are mapped to the corresponding requirement to ensure the coverage of test cases, to find any gap between requirement and test cases.
It is also known as Requirement Traceability Matrix (RTM) or Cross Reference Matrix (CRM).
It is prepared before the test execution process.
This document is designed to make sure that each requirement has a test case.
The test engineer will prepare TM for their respective assign modules, and then it will be sent to the Test Lead. Then test lead consolidate all and prepare one TM document for project.

Goals of Traceability Matrix:

It allows you to see if a requirement is fully documented or not. A requirement traceability matrix can even call attention to missing requirements.
It ensures that the software completely meets the customer's requirements.
A traceability matrix can help in the effort to provide proper and consistent documentation for your team.
It helps in detecting the root cause of any bug.

Types of Traceability Matrix:

The traceability matrix can be classified into three different types which are as follows:

Forward Traceability
Backward or reverse Traceability
Bi-directional Traceability

Forward Traceability:

Forward traceability is used to map the requirements to the test cases.

Not only this will establish that every requirement is being tested from top to bottom, but it will also assist in confirming that a project’s trajectory is sound.
The main objective of this is to verify whether the product developments are going in the right direction.

Backward or reverse Traceability:

You can make a backward traceability matrix by mapping test cases with the requirements.

The reverse or backward traceability is used to check that we are not increasing the space of the product by enhancing the design elements, code, test other things which are not mentioned in the business needs.
The main objective of this that the existing project remains in the correct direction.

Bi-directional Traceability:

Bidirectional traceability essentially combines forward and backward traceability into one document.

This type is useful because it establishes that each requirement has relating test cases.
It also evaluates the modification in the requirement which is occurring due to the bugs in the application.

Test Case Review Process and Guidelines

2022-07-16T22:15:00.005+05:30

Test Case Review :

Test case review process is an important process to follow in software testing. Test case should be effective and also follow the standards to write test case.
After preparation of the test cases review are conduct to ensure the completeness and correctness of the test case, proper flow, and maximum test coverage.
The test lead or project manager have to approve the test cases.
During this review process, if the reviewer found any mistake, he/she writes it in a separate document, which is known as Review document and sends it back to the author.

Test Case Review Techniques :

Self-review: This is carried out by the tester who wrote the test cases. By looking at SRS/FRD, he/she can see if all of the requirements are met or not.
Peer review: Before test lead the test cases reviewed by another team member who is not familiar with the system is called peer review. Maker and Checker are two other names for the same thing.
Supervisory review: This is done by a team lead or project manager who is higher in rank than the tester who wrote the test cases and has an extensive understanding of the requirements and system.

Common mistakes which are check during Test Case Review :

Incomplete Test Cases. Missing negative test cases. No Test Data. Inappropriate/Incorrect Test data.
Spelling errors can sometimes cause a lot of confusion or make a statement difficult to grasp.
While review process, it is very important to check whether all the standards and guideline are properly followed.
If proper template is followed then it becomes easy to add/modify test cases in future and test case plan looks organized.
If the grammar is incorrect, the test case can be misinterpreted, leading to incorrect findings.
Test cases should have a very simple language which is easy to understand.
Replication: It refers to the duplicate test cases removal. It is possible that two or more test cases test the same thing and can be merged into one, this would save time and space.
Test case which are uselessness due to change in requirements or some modifications. Such test cases must be removed.

Test Case Repository :

A test case repository is a centralized location where all the baseline test cases (written, review, and approved) are stored.
Test repository comprises test cases that encompass all key possibilities of permutations and combinations in workflow execution and transaction, ensuring that all variations in system and user interactions are covered.
A test case repository is used to store the approved test cases only.
Any test engineer wants to test the application, then he/she needs to access the test case only from the test case repository.
If we do not require any test case, we can drop them from the test case repository.
Each version have a separate test case repository.

Test Design Testing Techniques

2022-06-03T22:28:00.006+05:30

Test Design Testing Techniques :

1. BAV (Boundary Value Analysis):

The technique specify to validate the boundary validation.
It is based on testing at the boundaries.
We will be testing both the valid and invalid input values in the BVA.

Conditions are like :

Min Max

Min-1 Max-1

Min+1 Max+1

The above 6 conditions are enough.

BAV (Boundary Value Analysis ) Example:

Password field accept 6-32 character then we only test for :-

Min : 6 Max : 32

Min-1 : 5 Max-1 : 31

Min+1 : 7 Max+1 : 33

These 6 conditions are enough for password field testing.

2. ECP (Equivalence Class Partition):

The technique specify to test for valid and invalid combination.
The idea behind this technique is to divide a set of test conditions into groups or sets that can be considered the same.
It is a black-box testing technique or specification-based testing technique in which we group the input data into logical partitions called equivalence classes.

ECP Example:

Any mail id field accepts alpha and numeric data :

Valid Data Invalid Data

A – Z All special character

a – z

0 – 9

If a Text field accept 1000 -1500 the partition should be:

Valid Data Invalid Data

1000 – 1500 a – z

A – Z

Numbers < 1000

Numbers > 1500

All special character

3. Decision Table Based Testing:

Decision table testing is a software testing technique used to test system behavior for different input combinations.
In this methodology the various input combinations and the accompanying system behavior (Output) are tabulated.
This is a systematic approach.
Decision Table Testing is a Black Box test design technique (behavioral or behavior-based technique).
When a system has complex business rules, then the decision table testing technique helps in identifying the correct test cases.

Example: How to Create a Login Screen Decision Base Table

Let's make a login screen with a decision table. A login screen with User id and Password Input boxes and submit button.

The condition is simple if the user provides correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed.

T – Make sure to use Correct username/password

F – Incorrect username/password

E – An error message is displayed

H – The home screen is displayed

Interpretation:

Case 1 – Username and password both were correct, and the user navigated to homepage

Case 2 – Username was correct, but the password was wrong. The user is shown an error message.

Case 3 – Username was wrong, but the password was correct. The user is shown an error message.

Case 4 – Username and password both were wrong. The user is shown an error message.

While converting this to test case, we can create 2 scenarios :

First one :

Enter correct username and correct password and click on Submit button, and the expected result will be the user

Should be navigated to homepage.

Second one from the below scenario:

Enter Correct username and incorrect password and click on Submit button, and the expected result will be the user should get an error message.
Enter incorrect username and incorrect password and click on Submit button, and the expected result will be the user should get an error message.
Enter incorrect username and correct password and click on Submit button, and the expected result will be the user should get an error message.

As they essentially test the same rule.

4. State Transition:

State transition testing helps to analyze behavior of an application for different input conditions.
In this test outputs are triggered by changes to the input conditions or changes to 'state' of the system.
In other words, tests are designed to execute valid and invalid state transitions.
Testers can provide positive and negative input test values and record the system behavior. It is the model on which the system and the tests are based.
It is a black box testing which is used for real time systems with various states and transitions involved.

When to Use State Transition?

This can be used when a tester is testing the application for a finite set of input values.
When we have sequence of events that occur and associated conditions that apply to those events
This will allow the tester to test the application behavior for a sequence of input values.

When to Not Rely On State Transition?

When the testing is not done for sequential input combinations.
If the testing is to be done for different functionalities like exploratory testing.

Example:

Let’s consider an Login page function where if the user enters the invalid password three times the account will be locked.

In this system, if the user enters a valid password in any of the first three attempts the user will be logged in successfully. If the user enters the invalid password in the first or second try, the user will be asked to re-enter the password. And finally, if the user enters incorrect password 3rd time, the account will be blocked.

In the table when the user enters the correct PIN, state is transitioned to S5 which is Access granted. And if the user enters a wrong password he is moved to next state. If he does the same 3rd time, he will reach the account blocked state.

5. Error Guessing Testing:

Testing is conducted by performing invalid operations and validate the error massage is displaying or not .
The Error massage should meaningful to understand.
It is a type of testing method in which prior experience in testing is used to uncover the defects in software. It is an experience based test technique in which the tester uses his/her past experience or intuition to gauge the problematic areas of a software application.

Example:

We need to test a program which read’s a file. What happen if the program gets a file which is empty OR The file does not exist???
Enter blank space into text fields
Use max limits of files to be uploaded

Please watch below video for more details:

All you need to know about test cases

2022-06-03T22:09:00.012+05:30

Test Case Design

Test case design refers to how you set-up your test cases. It is important that your tests are designed well, or you could fail to identify bugs and defects in your software during testing.
It is responsibility of a tester to design the test cases.
To design the test cases tester should :
Understand the requirement
Identify the scenario
Design the test case
Review the test case
Update the test case based on review

How to create good test cases

Test Cases need to be simple steps, transparent and easy to understand.
Each and every test case should be traceable and it should be linked to “Requirement ID”.
Test cases should have only necessary and valid steps(Brief And Short) .
Implement Testing Techniques – Positive And Negative Test Cases
Test cases should be written in such a way that it should be easy to maintain.
Test cases should cover the usability aspects in terms of ease of use.
Different set of test cases should be prepared for the basic performance testing like multi-user operations and capacity testing.
Test cases for Security aspects should be cover for example user permission, session management, logging methods.

Test cases Design Format:

Follow below steps to create Test cases

Test Case Id : It is a unique number to represent each test cases. It’s good practice to follow some naming convention for better understanding and discrimination purposes. Like Tc_proj_module_number(001)

For example: Tc_Yahoo_Inbox_001

Test Scenario : A Test Scenario is defined as any functionality that can be tested. It is a collective set of test cases which helps the testing team to determine the positive and negative characteristics of the project. Test Scenarios are derived from test documents such as BRS and SRS.

Test Cases : A Test Case is a set of actions executed to verify a particular feature or functionality of your application. Test Cases are focused on what to test and how to test. Test Case is mostly derived from test scenarios.

Precondition : The condition to be satisfied to test the requirement. Conditions that need to meet before executing the test case.

Priority : The importance of the test case is called priority. It is a parameter to decide the order in which defects should be fixed. Priority means how fast defect has to be fixed.

Test Steps : Test Steps describe the execution steps. To execute test cases, you need to perform some actions. Each step is marked pass or fail based on the comparison result between the expected and actual outcome.

Test Data: It is data created or selected to satisfy the execution preconditions and inputs to execute one or more test cases. We need proper test data to execute the test steps.

Expected result : The output result as per customer requirement (As per SRS or FRS). The result which we expect once the test cases were executed.

Post Condition : Conditions that need to achieve when the test case was successfully executed.

Actual Result : The output result in the application once the test case was executed. Capture the result after the execution. Based on this result and the expected result, we set the status of the test case.

Status : The status as Pass or Fail based on the expected result against the actual result. If the actual and expected results are the same, mention it as Passed. Else make it as Failed. If a test fails, it has to go through the bug life cycle to be fixed.

Other important fields of a test case template:

Project Name: Name of the project the test cases belong to.

Module Name: Name of the module the test cases belong to.

Reference Document: Mention the path of the reference documents (if any such as Requirement Document, Test Plan , Test Scenarios, etc.,)

Author (Created By) : Name of the Tester who created the test cases.

Date of Creation: When the test cases were created.

Date of Review: When the test cases were reviewed.

Reviewed By: Name of the Tester who created the test cases.

Executed By: Name of the Tester who executed the test case.

Date of Execution: When the test case was executed.

Comments: Include value information which helps the team.

Please refer below video on test cases:

Please refer below video on real time test case template:

Test Strategy Vs Test Plan

2022-06-03T21:54:00.006+05:30

Test Strategy:

A test strategy is an outline that describes the testing approach of the software development cycle.
Test strategy is a set of guidelines that explains test design and determines how testing needs to be done.
The creation and documentation of a test strategy should be done in a systematic way to ensure that all objectives are fully covered and understood by all.
It should also frequently be reviewed, challenged and updated as the organization and the product evolve over time.

Test Strategy Vs Test Plan:

Test Plan	Test Strategy
A test plan for software project can be defined as a document that defines the scope, objective, approach and emphasis on a software testing effort.	Test strategy is a set of guidelines that explains test design and determines how testing needs to be done.
Test plan include- Introduction, features to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and schedule, etc.	Test strategy includes- objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, etc.
Test plan is carried out by a testing manager or lead that describes how to test, when to test, who will test and what to test	A test strategy is carried out by the project manager. It says what type of technique to follow and which module to test
Test plan narrates about the specification.	Test strategy narrates about the general approaches.
It is done to identify possible inconsistencies in the final product and mitigate them through the testing process.	It is a plan of action of the testing process on a long-term basis.
It is used on a project level only.	It is used on an organizational level.
Test plan can change.	It is used by multiple projects and can be repeated a lot of times.
It is used by one project only and is very rarely repeated.	Test strategy cannot be changed.
Test planning is done to determine possible issues and dependencies in order to identify the risks.	It is a long-term plan of action. You can abstract information that is not project specific and put it into test approach

Please refer below video more details:

What is Test Planning and How to Create Test Plan?

2022-06-03T21:16:00.006+05:30

Test Planning:

Initially when we get the project it is responsibility for a test lead or senior tester to prepare the test plan for the project.
A test plan is the foundation of every testing effort.
A Test Plan refers to a detailed document that catalogs the test strategy, objectives, schedule, estimations, deadlines, and the resources required for completing that particular project.
A good test plan clearly defines the testing scope and its boundaries. You can use requirements specifications document to identify what is included in the scope and what is excluded.
By creating a clear test plan all team members can follow, everyone can work together effectively.

The steps to prepare the test plan :-

Criteria
Prepare test plan
Get approval

1. Criteria:-

To prepare test plan the test lead /senior tester should have the below details:
Development schedule
Project release date
Services to be provided to customer
Understand the project requirement
Understanding of the complexity of the project
Scop of testing
No. of resources required
Type of testing to be conducted

2. Prepare Test Plan :

A Test Plan is a detailed document that describes the test strategy, objectives, schedule, estimation, deliverables, and resources required to perform testing for a software product.
The test plan serves as a blueprint to conduct software testing activities as a defined process, which is minutely monitored and controlled by the test manager.

Test Plan document has the below details :

Introduction
Features to be tested ( In scope)
Features not to be tested (Out of scope)
Pass/ Fail criteria
Entry and Exit criteria
Approach
Schedule
Test factor
Recourses
Training plans
Configuration management
Test Deliverable
Test Environment
Risk and Mitigation Plan
Approval

3. Prepare Test Plan : Once test plan is ready it should be approved from test manager

Lets talk about different sections on a test plan in detail:

Introduction :- Specify the purpose / Requirement of the project.

Feature to be tested :- Specify the requirement which is need to be tested.

Feature not to be Tested :- Specify the requirement which is out of the scope of testing. We dose not need to test.

PASS / FAIL Criteria (Suspension Criteria):- If the below criteria is satisfied we can suspend the build from testing:

The build is not deployed
The sanity test is fail
The build is unstable
Wrong build is given

(Note: If the build is suspended the developer have to immediately resolve the issue and give the modified build)

Entry and Exit Criteria:- Specify the condition to start and stop the testing . for every level of testing there is entry and exit criteria

For example :-

System testing Entry Criteria :-

Integration testing should be completed
All the major defect found in the integration test should be fixed
The test environment should be ready , Required access should be provided
The Development should be completed (All Coding part)

System testing Exit Criteria :-

All the functionalities are tested
No new defect are found
No risk in the project
All the defects are fixed
The testing scheduled are completed

Approach :- Specify the process followed in the project like

Planning  Design  Execution  Reporting

Schedules:- Specify the testing . The testing scheduled are prepared based on development schedules.

Resources :- Specify the list of team, resources and there responsibilities like testing team, development team, project managers etc.

Training plans :- Specify any training plan is required for the resources.

Configuration Management :- Specify hoe to manage all the project related documents , codes, testing documents etc.so these documents are accessible to all the team members.

There are tools are available like :

VSS Visual source safe

CVS  Concurrent version system for configuration management.

The tool provide security, version control (Each time the documents are updated a new version is created )

Test Deliverables :- Specify the list of documents to be submitted to the customer during testing or after testing Documents are like :

Test Plan
Test Case documents
Test execution result
Defect report
Review report
Test summary report etc.

Test Environment :- Specify the Hard ware configuration details, the additional software required in the test environment to access the application and conduct the testing.

Risk And Mitigation Plan:- Specify the challenges in the project and the solution to resolve the challenges.

The different risks are :

Required documents are not available
Estimations are not correct
Delay in project deliverables
Lack of skilled resources
Lack of team coordination's ETC.

Approval :- After preparation of the plan the project manager and customer have to review and approve the plan.

Note :- During the planning phase it is the responsibility of test lead to recruit the tester based on the skills required for the project .

Please refer the below video for more details on test plan:

What is Software Testing Life Cycle?

2022-06-03T21:00:00.004+05:30

The Software Testing Life Cycle (STLC) is a term that refers to the process of testing software. The Software Testing Life Cycle (STLC) is a set of actions that are carried out during the testing process to guarantee that software quality objectives are satisfied.

Any Project has to follow the below phases from beginning of a project to end of the project in Testing :

1. Requirement Analysis :- It is tester’s responsibility

Study the requirements
Identify types of tests to be performed
Prepare RTM
Automation feasibility analysis

2. Test Planning :- It is test lead’s responsibility

Understand the project
Scop of testing
Identify the resource
Schedules
Deliverables
Approach
Effort Estimations

3. Test Case Design :- It is Tester’s Responsibility

Design/Script the Test cases
Review testcases
Update test cases based on review and baseline test cases
Create test data

4. Test Execution :- It is tester’s responsibility

5. Defect Reporting and Tracking:- It is Tester’s Responsibility

6. Test Closer :- It is tester and Test Lead’s responsibility

Stop testing based on :-

All functionalities are tested
No new defect are found
Schedule are conducted
No risk in the project
Test Closure Report

Please watch below video on STLC process:

Monkey and Gorilla Testing

2022-06-03T20:48:00.000+05:30

Monkey Testing

Monkey testing is a type of software testing in which a software or application is tested using random inputs with the sole purpose of trying and breaking the system.
Monkey testing tests the whole system, There are no rules in this type of testing.
Monkey testing is usually implemented as random, automated unit tests.
Monkey testing is also known as Random testing, Fuzz Testing or Stochastic Testing.
Monkey testing is a crucial testing method that is done to authenticate the functionality of the product application.
Monkey testing is a kind of black box testing.

Gorilla Testing

Gorilla testing is a software testing technique that repeatedly applies inputs on a module to ensure it is functioning correctly and that there are no bugs.
Gorilla testing is a manual testing procedure and is performed on selected modules of the software system with selected test cases.
Gorilla testing is not random and is concerned with finding faults in a module of the system.
Gorilla Testing is also known as Torture Testing, Fault Tolerance Testing or Frustrating Testing.
Gorilla Testing is a manual testing and it is repetitively performed.
Gorilla testing is a kind of white box testing.

Difference between monkey and gorilla testing:

Monkey	Gorilla
Monkey testing is a type of software testing which is performed based on some random inputs without any test cases and checks the behaviour of the system and confirms whether it crashes or not.	Gorilla Testing is a type of software testing which is performed on a module based on some random inputs repeatedly and checks the module’s functionalities and confirms no bugs in that module.
In Monkey Testing, no test case is used to test the application as it is a part of random testing.	It is performed repeatedly as it is a part of manual testing.
The Monkey Testing approach is primarily used in System Testing.	The Gorilla Testing approach is mainly used in Unit Testing.
Monkey testing is implemented on a whole system.	Gorilla testing is implemented on few selective components of the system.
No software knowledge is required in order to execute the monkey testing.	It requires minimum software knowledge in order to execute the gorilla testing.
The main objective of Monkey Testing is to check whether system crashes or not.	The main objective of Gorilla testing is to check whether the module is working properly or not.
Monkey testing is also known as Random testing, Fuzz Testing or Stochastic Testing.	Gorilla Testing is also known as Torture Testing, Fault Tolerance Testing or Frustrating Testing.
There are three types of Monkey Testing i.e. Dumb Monkey Testing, Smart Monkey Testing and Brilliant Monkey Testing.	While there is no such different types of Gorilla Testing available.
The implementation of Monkey testing does not require any planning or preparation.	The Gorilla testing cannot implement without any preparation or planning.

Please refer below video on monkey and gorilla testing:

Complete Software Testing Hierarchy | Software Testing Levels |Different Testing Types with Details

2022-05-08T22:01:00.005+05:30

Complete Software Testing Hierarchy

Software Testing Hierarchy

Please refer the below video on Complete Software Testing Hierarchy:

Retesting and Regression Testing

2022-05-08T21:53:00.003+05:30

Re-testing

Testing the same functionality with different combination of input data is called retesting.
Retesting essentially means to test something again.
In simple words, Retesting is testing a specific bug after it was fixed.
Retesting ensures that the issue has been fixed and is working as expected.
It is a planned testing with proper steps of verification
In some cases the entire module is required to be re-tested to ensure the quality of the module.

Why and when we perform Retesting

Retesting is used when there is any specific error or bug which needs to be verified.
It is used when the bug is rejected by the developers then the testing department tests whether that bug is actual or not.
It is also used to check the whole system to verify the final functionality.
It is used to test even the entire module or component in order to confirm the expected functionality.

Advantages

Retesting ensures that the issue has been fixed and is working as expected.
It improves the quality of the application or product
It requires less time for verification because it’s limited to the specific issue or any particular feature.
If the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.

Disadvantages

It requires new build for verification of the defect.
Once the testing is started then only the test cases of retesting can be obtained and not before that.
The test cases for re-testing cannot be automated.

Regression Testing

If any changes are done in the existing build this test is conduct on the modified build to verify the changes are working correctly or not and because of this changes there are no side effect.
In Regression Test the change functionality + dependent functionality are tested .
The purpose of the regression testing is to find the bugs which may get introduced accidentally because of the new changes or modification.
This also ensures that the bugs found earlier are NOT creatable.
This helps in maintaining the quality of the product along with the new changes in the application.

When To use Regression Testing

Any new feature is added to an existing feature.
The codebase is fixed to solve defects.
Any bug is fixed
Changes in configuration.

Advantages

It helps the team to identify the defects and eliminate them earlier in the software development life cycle.
It ensures continuity of business functions with any rapid change in the software.
Regression testing can be done by using the automation tools.
It helps us to make sure that any changes like bug fixes or any enhancements to the module or application have not impacted the existing tested code.

Disadvantages

If regression testing is done without using automated tools then it can be very tedious and time consuming because here we execute the same set of test cases again and again.
Regression testing has to be performed for every small change in the code as even a small portion of code can create issues in the software.
It takes time to complete the tests and this slows down the agile velocity.
It's expensive and the cost is hard to justify.

Re-testing vs Regression Testing:

Re-Testing	Regression Testing
Retesting is about fixing specific defects that you've already found.	Regression testing is about searching for defects.
Retesting is done only for failed test cases.	Regression testing is performed for passed test cases.
Retesting is used to ensure the test cases which failed in last execution are fixed.	Regression testing is to ensure that changes have not affected the unchanged part of product.
Verification of bugs are included in the retesting.	Verification of bugs are not included in the regression testing.
Retesting is of high priority so it’s done before the regression testing.	Regression testing can be done in parallel with retesting.
Retesting the test cases cannot be automated.	Regression testing test cases can be automated.
In case of retesting the testing is done in a planned way.	In case of regression testing the testing style is generic.
Test cases of retesting can be obtained only when the testing starts.	Test cases of regression testing can be obtained from the specification documents and bug reports

Please refer the below video on complete video on Retesting and Regression Testing:

What is Adhoc Testing? Difference between Adhoc testing and Exploratory Testing

2022-05-08T21:39:00.006+05:30

Adhoc Testing

When a software testing performed without proper planning and documentation, it is said to be Adhoc Testing.
Ad hoc Testing is an informal or unstructured software testing type that aims to break the testing process in order to find possible defects.
Ad hoc testing is performed without a plan of action and any actions taken are not typically documented.
Ad Hoc Testing implies learning of the software before its testing.
Ad hoc Testing is done by executing the random scenarios and it is a form of negative testing which ensures the perfection of the testing.

Why do we do adhoc testing?

The main aim of ad hoc testing is to find any defects through random checking.
This can uncover very specific and interesting defects, which are easily missed when using other methods.
Ad hoc testing can be performed when there is limited time to do exhaustive testing and usually performed after the formal test execution.
Ad hoc testing will be effective only if the tester has in-depth understanding about the System Under Test.

Advantages:

This method is very simple and can be performed without any training.
It can be used when time period is limited.
This can uncover very specific and interesting defects, which are easily missed when using other methods.
This testing can be performed any time during Software Development Life Cycle Process (SDLC)

Disadvantages:

This method is not recommended, when more scientific methods are available.
The actual testing process is not documented since it does not follow a particular test case.
It is difficult for the tests to regenerate an error in ad hoc testing.

Adhoc testing Vs Exploratory Testing

Adhoc Testing	Exploratory Testing
Ad Hoc Testing implies learning of the software before its testing.	Exploratory Testing, you learn and test the software simultaneously.
Documentation is not a basic need of this type of testing. The QA team always attends the testing without specific documentation.	Documentation is mandatory in Exploratory Testing. To assure the quality it’s necessary to documents the detail of the testing.
Ad hoc is about the perfection of the testing.	Exploratory Testing is more about the learning of the application.
Ad hoc Testing helps to find innovative ideas from the research.	It helps to develop the application.
Ad hoc is a technique of testing an application; this provides a significant role in the software Production.	This is an approach of testing that combines the learning test results and creates a new solution.
It mostly works on the business concerns and increases the knowledge about the application.	It categorizes the problems and compare them from the problems found in past. This helps to reduce the time consumption.
Adhoc testing is not important to execute by an expert software testing engineer.	This always needed to be done by expert.
It works on negative testing mostly.	This testing works on positive testing niche.

Please refer the below video on complete video on Adhoc testing:

What is Exploratory Testing?

2022-05-08T20:29:00.007+05:30

Exploratory Testing?

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution.
Exploratory testing allows you to think outside the box and come up with scenarios that might not be covered in a test case.
In simple word it is a type of software testing where Test cases are not created in advance but testers check system on the fly.
It focuses on discovery and relies on the guidance of the individual tester to uncover defects that are not easily covered in the scope of other tests.
It doesn't restrict the tester to a predefined set of instructions.
This is a test approach that can be applied to any test technique, at any stage in the development process.

When should we do Exploratory Testing?

In many software cycles, an early iteration is required when teams don’t have much time to structure the tests. Exploratory testing is quite helpful in this scenario.
When testing mission-critical applications, exploratory testing ensures you don’t miss edge cases that lead to critical quality failures.
It is especially useful to find new test scenarios to enhance the test coverage.
It helps review the quality of a product from a user perspective.

Advantages of Exploratory testing

It requires limited preparation, which allows you to save time and quickly jump to execution.
In Exploratory Testing, you can generate your own test scenarios on the fly, which will allow you to dive deeper into the functional aspects of the product.
This test is much less time-consuming.
It allows you to think outside the box and come up with scenarios that might not be covered in a test case.
This allows the tester to find defects that are beyond the scope of the listed scenarios.
This is an approach that is most useful when there are no or poor specifications and when time is severely limited.

Disadvantages of Exploratory testing

In exploratory testing, once testing is performed it is not reviewed.
Difficult to document each procedure.
It is difficult to reproduce the failure.
It is not easy to say which tests were already performed.
Limited by testers’ skills set.
Reporting is difficult without planned scripts.

Please refer the below video on complete video on Exploratory Testing:

What is Positive and Negative Testing?

2022-05-08T20:21:00.004+05:30

Positive Testing

Positive Testing is a type of testing which is performed on a software application by providing the valid data as an input.
Positive testing is a type of software testing that is performed by assuming everything will be as expected.
It is performed with the assumption that only valid and relevant things will occur.
In this type, testing performed within the boundaries and this testing checks that the product /application is behaving as per the specification document with a valid set of test data.

Negative Testing

Negative testing is a method of testing an application or system that ensures that the plot of the application is according to the requirements and can handle the unwanted input and user behavior.
It is also known as error path testing or failure. And it helps us to identify more bugs and enhance the quality of the software application under test .
Negative testing uses invalid input data, or undesired user behaviors, to check for unexpected system errors.
We can say that the negative testing is executing by keeping the negative point of view in simple terms.

Difference between positive testing and negative testing:

Positive Testing	Negative Testing
Positive Testing means testing the application or system with valid data.	Negative Testing means testing the application or system with invalid data.
It is always done to verify the known set of test conditions.	It is always done to break the project or product with unknown set of test conditions.
It ensures software is normal.	It ensures 100% defect free software.
It doesn’t cover all possible cases.	It covers all possible cases.
It can be performed by people having less knowledge.	It can be performed by professionals.
Positive testing is implemented only for the expected conditions.	Negative testing is implemented only for unexpected conditions.
It is less important as compare to negative testing.	It is more important as compare to positive testing.
Positive testing can be implemented on every application.	Negative testing can be implemented when the possibilities of unpredicted conditions.

Please refer the below video on complete video on Positive and Negative Testing:

Complete Article on Smoke and Sanity Testing

2022-05-08T20:09:00.003+05:30

Smoke Testing:

Smoke test is also known as Build Verification Testing OR Build Acceptance Testing.
Smoke testing is the preliminary check of the software after a build and before a release.
It is a type of acceptance testing, provide an initial check that a new software build and its critical functionality are stable or not.
Smoke testing is a group of tests that are executed to verify if the critical functionalities of a particular build are working fine as expected or not.

How to do Smoke Testing:

The development team deploys the build in QA. We will need to perform setup steps.
Then the subsets of test cases are taken, and then testers run test cases on the build.
The QA team test the application against the critical functionalities. These series of test cases are designed to expose errors that are in build.
After the smoke test, we need to clean up. This might include stopping a server, deleting files, or emptying database tables. This could also be done before the initial setup step to ensure that the environment is clean before any tests are started.

Why We Perform Smoke Testing:

Smoke Testing is done whenever the new functionalities of the software are developed and integrated with the existing application.
It ensures that all critical functionalities are working correctly.
It reveal simple failures but severe enough to , reject a prospective software release.
It helps to find issues in the early phase of testing.

Smoke Testing Example

A web page for insurance add a claim status page. Tester would apply smoke test to verify that the existing build works on fundamental level , such as user can login in or not and navigate to claim status page or not , and retrieve the status report of specific claim without the app crashing.

Sanity Testing:

Sanity Testing is a subset of regression testing.
After receiving the software build, sanity testing is the 1st test to ensure that the code changes introduced are working as expected.
If any defect found in test we can reject the build and stop the testing.
After Sanity test complete the status either Pass Or Fail has to be reported to the developers.
The test is conducted for very short period of time (15-30 min Max)

How to do Sanity Testing

Unlike other types of testing, sanity does not need a handful of techniques, You do not need to write test cases for sanity testing because you want to perform quick and speedy testing.
The first thing in Sanity Test is to identify the new functionalities, changes or any bug fixes.
Then we will check the newly implemented changes if they are working fine or not .
At Last we will randomly check a few related functionalities to see if they are also working as expected.
If it all goes good, then the release can be passed for further testing or if any one functionality is not working as per requirement or got failed we can reject the build and stop the testing.

Why We Perform Sanity Testing

It is also known as Surface Level Testing, this must be done to quickly evaluate the quality of regressions made to the software.
Sanity is done to determine if new module additions to an existing software build are stable enough to pass to the next level of testing or not.
If sanity test is pass we can continue further testing, if its fail we can reject the build and stop the testing so developers and fix the changes ASAP.

Sanity Testing Example

A web page for loan provider returns a 404 error for personal loan page. The developers fix the issue and submit the build for testing. The QA professional perform a sanity test to determine whether the basic functionality and navigation for that specific page is working as intended or not.

Smoke Vs Sanity

Smoke	Sanity
Smoke Testing is performed to ascertain that the critical functionalities of the program are working fine.	Sanity testing is done at random to verify that each functionality is working as expected.
Smoke testing is usually documented and scripted.	Sanity testing is not documented and is unscripted.
Smoke Testing has a goal to verify “stability”.	Sanity Testing has a goal to verify “rationality”.
Testing is done by both developers or testers.	Sanity Testing is done by only testers.
Smoke testing is a subset of acceptance testing.	Sanity testing is a subset of Regression Testing.
This is a wide and High Level testing.	This is a wide and shallow testing.
It is a well elaborate and planned testing.	This is not a planned test and is done only when there is a shortage of time.
Smoke testing exercises the entire system from end to end.	Sanity testing exercises only the particular component of the entire system.

Please refer the below video on complete video on Smoke and Sanity Testing:

What is Error Guessing Testing Technique?

2022-05-08T19:50:00.003+05:30

Error Guessing Testing

Testing is conducted by performing invalid operations and validate the error massage is displaying or not .
The Error massage should meaningful to understand.
It is a type of testing method in which prior experience in testing is used to uncover the defects in software. It is an experience based test technique in which the tester uses his/her past experience or intuition to gauge the problematic areas of a software application.

Error Guessing Testing example:

We need to test a program which read’s a file. What happen if the program gets a file which is empty OR The file does not exist?
Enter blank space into text fields
Use max limits of files to be uploaded

Advantages of Error Guessing Testing

It uncovers those defects which would otherwise be not possible to find out, through formal testing.
To expand the test coverage.
It does not follow any specific rules.

Disadvantages of Error Guessing Testing

Only experienced testers can perform this testing. You can’t get it done by freshers.
It also cannot guarantee that the software has reached the expected quality benchmark.

Please refer below video on Error Guessing Testing: