How to Use ChatGPT for Software Testing Effectively

 1. Test Case Generation

 Generate test cases based on requirements or user stories.
 Prompt: "Generate test cases for a login page with email and password validation."

2. Test Data Creation

 Generate sample test data for manual or automated testing.
 Prompt: "Provide sample test data for user registration with fields: Name, Email, Phone, and Password."

3. Automation Script Assistance

 Generate or debug Selenium, Python, or Java automation scripts.
 Prompt: "Write a Selenium script in Java to automate login functionality."

4. API Testing with Postman

 Generate API test cases and validate responses.
 Prompt: "Create test cases for a REST API with endpoints: /users, /users/{id}, and /login."
 

5. Bug Reporting Assistance

 Format bug reports with steps to reproduce, expected results, and actual results.
 Prompt: "Write a bug report for a login issue where an incorrect password does not show an error message."

6. Performance Testing Support

 Guide on JMeter or LoadRunner for performance testing.
 Prompt: "How to create a JMeter test plan for a login API?"

7. SQL Query Assistance

 Write SQL queries to fetch test data or validate results.
 Prompt: "Write an SQL query to find all users who registered in the last 30 days."

8. CI/CD Pipeline Testing

 Help with GitHub Actions, Jenkins, or other CI/CD tools.
 Prompt: "How to write a GitHub Actions YAML file for running Selenium tests?"

9. Security Testing Help

 Provide security testing guidelines and common vulnerabilities.
 Prompt: "What are common OWASP security risks for a web application?"

10. Debugging Assistance

 Identify and fix issues in test scripts or applications.
 Prompt: "Why is my Selenium script failing to locate an element using XPath?"

Mobile Testing Interview Questions

 1. Common challenges in mobile application testing

•   Executing test cases with various operating systems
•   Screen size fragmentation
•   Testing applications on different mobile networks

2. Planning to perform end-to-end mobile testing

•   Is the application successfully installed across various mobile models, gadgets, and operating systems?
•   Does the application launch smoothly with or without a network?
•   Does the application perform well on different kinds of devices and network scenarios?
•   How does the application respond when it is used? (i.e. response speed and time)

3. Common bugs that would often be found during the mobile testing process?

•   Critical: Your phone system crashes when testing a particular feature in your device
•   Issues with Buttons and Links
•   Not Optimized for Landscape
•   Unfriendly Error Messages

4. Emulator in mobile testing

•   This is software for testing mobile apps without a live handset.
•   Emulators are useful for early-stage testing but may not replicate real-world conditions accurately.

API Testing Interview Questions - Part 1

 1. API

  API is an application programming interface that acts as an intermediate between two applications. API is a collection of functions and procedures.

2. API Methods:

  GET - GET requests are used to retrieve the information from the given URL.

  POST - To send the new data to an api.

  PUT - This method is used to update the existing data.

  DELETE - This is used to remove or delete the existing.

  PATCH - Partially updated resource.

3. What is the difference between the 201 and 204 Status codes?

• 201 - The request was successful, and a new resource was created.
• 204 - The request was successful, but there is no response body. When an update or delete operation is successful.

4. What is the difference between 401 and 403 Status Code?

• 401 - Unauthorized. without logging in or with invalid credentials.
• 403 - Forbidden. When a logged-in user tries to access a restricted area without the required permissions.

5. What is the difference between Query Parameters and Path Parameters?

• Both Query Parameters and Path Parameters are used to send data in API requests.

6. How does an API Work?

• Client request -> Server Processing -> Response - Client Handling

7. Main types of API?

• Public API
• Private API
• Partner API
• Comboste API

8. What must be checked when performing API testing?

• Accuracy of data
• HTTP status codes
• Data type, validations, order, and completeness
• Authorization checks
• Implementation of response timeout
• Error codes in case the API returns, and

9. How do you handle dynamic data in API testing?

• Data Parameterization: Using data-driven tests where input values are generated dynamically from a data source (e.g., database, files).

10. What are the major challenges faced in API testing?

• Output verification and validation.

11. Difference b/w RESTful API and SOAP API?

• RESTful API and SOAP API lie in their architectural styles and message formats.

12. API Endpoint - Refers to a specific URL or URI

13. Purpose of authentication:

• Verify the requester's identity before granting access to protected resources.

14. Authentication methods used in API Testing:

• Token-based authentication - A token to the client after successful authentication.
• Basic authentication - sending the username and password 

Manual Testing Interview Questions – Part 1

1. Authentication and authorization?

• Authentication (Auth): Verifies the user's identity.
• Authorization: Determines the user's permissions.Defines what actions the user can perform.

   
2. Retesting and Regression testing?

• Retesting involves testing a specific bug or issue after it has been fixed by the developer.
•  Regression testing involves testing the fixed bug and the surrounding areas that may have been affected by the fix. verify that the software works as expected after changes?

  Retesting - Testing only the affected area.
  Regression Testing - Testing the affected as well as the unaffected areas.
  
3. Black Box, White Box, Gray Box Testing:

•  Black box: Focuses on external behaviour and user interactions. No knowledge of internal code or structure required. Typically performed by testers, QA engineers, or end-users. Examples: Functional testing, User Acceptance Testing (UAT), Exploratory testing.
• White Box: Focuses on internal code structure and logic. Requires knowledge of programming languages and code. Typically performed by developers. Examples: Unit testing, Integration testing, Code reviews.
• Gray Box: Combines elements of black box and white box testing. Requires some knowledge of programming and code. Typically performed by testers with programming skills or developers. Examples: API testing, Database testing, Security testing.

  
4. Severity: Refers to the impact or effect of a defect on the application's functionality. Measures the defect's damage or risk
     Priority: How soon will the defect be fixed?
  
5. Test scenarios focus on what to test, while test cases focus on how to test. Test scenarios define end-to-end functions to be tested, while test cases provide instructions on how to test specific features.

6. Alpha, Beta, Gamma Testing:
  Alpha: Conducted by the in-house testing team. Focus on functionality.
  Beta: Conducted by external customers, end-users, or a select group. Focus on real-world usage.
  Gamma: Conducted by end-users and customers. For the final validation, focus on business requirements and user expectations.
  
7. Equivalence Partitioning:

• Equivalence partitioning is a black-box testing technique that divides input data into partitions.
• Test cases that cover all possible input scenarios reduce the number of test cases.

 Example:  Age (1-100)
   Valid ages: 1-100
   Invalid Ages:
       Below 1 (e.g., 0, -1)
       Above 100 (e.g., 101, 150)
       Non-numeric input (e.g., "abc")

8. Smoke and Sanity testing

• Smoke testing - Focusing on Major functionalities in the software through positive test cases.
• Sanity testing - Focusing on Major functionalities in the software through positive and negative test cases.

9. Usability testing - Easy to use.

10. BUG - Caused by a programming error.
      ERROR - Mismatch between expected and actual output.
      DEFECT - When the actual output differs from customer expectations, it is considered a defect.
      MISTAKE - An error made by the user.

11. Adhoc/Monkey testing - testing an application randomly without following the requirements. Here we check negative scenarios.

12. Compatibility testing - testing an application with different hardware and software.

13. Globalisation testing - testing an application which is developed for different languages.

14. Reliability testing - testing the functionality of an application for a long duration of time.

15. Accessibility testing - testing the application which is developed for physically challenged people.

16. Acceptance testing - testing the business scenarios of an application, which is done by the customer.

17. Aesthetic testing - Testing the beauty of the application. checking colour combination, font style, font size and attractiveness of an application.

18. Functional, integration and system testing are mandatory for every testing application.

19. Smoke, sanity, exploratory and ad-hoc testing are situation-based testing.

20. Recovery testing - Later, close the application and open it again, and see whether all the previous data is still available or not.

21. SDLC - It is the Software Development Life Cycle

 It has different stages:

• Requirement Analysis
• Designing
• Coding
• Testing
• Deployment
• Maintenance

22. Agile Model - When a customer wants an application very fast, with less time, we go for this model.

23. STLC - Software Testing Life Cycle

  It has different stages:

• Requirement Analysis
• Test Planing
• Test Designing
• Test Environment Setup
• Test execution
• Test Cycle Closure

24. Scrum terminology

Scrum is a version of agile.

• Epic - It is a complete set of requirements given by the customer.
• Sprint - It is the duration of time taken to work on 1 or more user stories. Each sprint can be either 2/3/4 weeks, depending on the customer's decision.
• Sprint planning meeting - It is a meeting which is conducted before the sprint starts.
• Sprint backlog - It is a user story which is not completed in that particular sprint and is carried into the next sprint.
• Sprint review meeting - In this meeting, the scrum master will check whether all the user stories are completely developed and tested, and it is ready to be released to the customer or not.

25. Requirement Traceability Matrix:

• It is a document which is prepared to check whether every requirement has at least one test case or not. RTM maps all the requirements with the test cases.

Real-Time Software Testing Interview Questions - Part 2

1. Retesting - Testing only the affected area.

2. Regression Testing - Testing the affected as well as the unaffected area.

3. When will you stop the Testing?

• When every bug is fixed.
• When all the test cases are executed and they are passed.
• Minor bugs are deferred.

   

4. When will you start Testing?

• Once the developer completes unit testing.
• Once everything is ready (test environment, test cases, test data).

   

5. Alpha testing - Selective customers will test the new version/software in the development organization's environment.

6. Beta testing - Customers will use this newly developed software in their own environment.

7. Smoke testing - Focusing on Major functionalities in the software through positive test cases.

8. Sanity testing - Focusing on Major functionalities in the software through positive and negative test cases.

9. Quality Assurance - Process-oriented and Verification.

10. Quality Control - Product-oriented and Validation.

11. Waterfall Model :

• When we have the software already and we want to implement new small features which are very clear- in these cases, we can go with the waterfall model.
• Disadvantage: Once we moved to the next phase, we never come back to the previous phase.

    

12. Model - Implementation of SDLC.

Low Severity and High Priority Bugs in E-commerce Web Application

1. Typo on the Checkout Confirmation Page

Description: A misspelled word on the checkout confirmation page.

Severity: Low

Priority: High

2. Logo Displaying Incorrectly on Homepage

Description: The company logo appears stretched or pixelated.

Severity: Low

Priority: High

3. Incorrect Customer Support Email Address on the Contact Us Page

Description: The email address provided for customer support is incorrect.

Severity: Low

Priority: High

4. Broken Social Media Links in Footer

Description: Links to social media pages in the footer are broken.

Severity: Low

Priority: High

5. Non-functional Promo Code Input Box

Description: The input box for promo codes in the checkout process does not work.

Severity: Low

Priority: High

High Severity Low Priority Bugs in E-Commerce Web Application

1. Payment Gateway Failure in Specific Currency
High Severity: Users cannot complete purchases using a particular currency.
Low Priority: This currency is rarely used by the customer base.
Technical: When users select a rarely used currency, the payment gateway integration fails due to incorrect API calls or missing currency configuration.
Simple: Users can't pay in a specific, rarely-used currency.

2. Crash When Filtering Products by a Rare Attribute

High Severity: The website crashes, disrupting user experience.

Low Priority: The attribute filter is rarely used by customers.

Technical: Filtering by an uncommon attribute triggers a crash, possibly due to a null reference or unhandled exception.

Simple: The site crashes when filtering by a rarely used feature.

3. Incorrect Discount Calculation for Bulk Orders

High Severity: Users are charged incorrect amounts.

Low Priority: Bulk orders are rare.

Technical: The discount logic has a bug when calculating bulk order discounts, leading to incorrect pricing.

Simple: Bulk orders get the wrong discounts.

4. Failure to Load Product Images on Secondary Pages

High Severity: Product images do not load, affecting user experience.

Low Priority: Occurs on less frequently visited pages.

Technical: Image URLs or CDN issues prevent images from loading on less-visited pages.

Simple: Product images don't show up on certain pages.

5. Inability to Apply Multiple Coupons on Checkout

High Severity: Users cannot avail of multiple discounts.

Low Priority: Only a few users use multiple coupons.

Technical: The checkout process doesn't handle multiple coupon codes due to a bug in the discount application logic.

Simple: Users can't use more than one coupon at a time.

6. Error in Wishlist Functionality for Out-of-Stock Items

High Severity: Users cannot add out-of-stock items to their wishlist.

Low Priority: Out-of-stock items are a small portion of the catalogue.

Technical: The wishlist feature crashes or misbehaves when adding out-of-stock items due to lack of proper handling.

Simple: Can't add out-of-stock items to a wishlist.

7. Mismatch in Product Specifications on Detailed View

High Severity: Detailed view shows incorrect specifications.

Low Priority: Rarely visited detailed specifications page.

Technical: The product detail page shows incorrect specs due to outdated or incorrect data fetching logic.

Simple: Wrong details are shown on the product page.

8. Search Function Fails for Long Strings

High Severity: Users can't search with long keywords.

Low Priority: Most users use short search queries.

Technical: Long search queries cause database or server errors, possibly due to input length limits or inefficient query handling.

Simple: Searching with long phrases doesn't work.

9. Incorrect Display of User Loyalty Points

High Severity: Users see the wrong loyalty points balance.

Low Priority: The loyalty points program has low participation.

Technical: The loyalty points calculation or display logic has errors, showing incorrect balances.

Simple: Users see the wrong loyalty points balance.

10. Failure to Load Reviews for Products with No Reviews

High Severity: Page crashes if a product has no reviews.

Low Priority: Most products have at least one review.

Technical: The review section crashes when there are no reviews, likely due to poor handling of empty datasets.

Simple: Page crashes if there are no reviews.

Must-Have Security Test Cases for Your Web Application

1. Try to directly access the bookmarked web page without logging into the system.

2. Verify that the system should restrict you from downloading the file without signing in to the system.

3. Verify that previously accessed pages should not be accessible after logging out i.e. Sign out and then press the Back button to access the page accessed before.

4. Check the valid and invalid passwords, password rules say it cannot be less than 8 characters, user ID and password cannot be the same etc.

5. Verified that important i.e. sensitive information such as passwords, ID numbers, credit card numbers, etc should not be displayed in the input box when typing. They should be encrypted and in asterisk format.

6. Check Is bookmarking disabled on secure pages? Bookmarking Should be disabled on secure pages.

7. Check Is Right Click, View, Source disabled? The source code should not be visible to the user.

8. Check if your server locks out an individual who has tried to access your site multiple times with invalid login/password information?

9. Verify the timeout condition, after a timeout, the user should not be able to navigate through the site.

10. Check Are you prevented from doing direct searches by editing content in the URL?

11. Verify that the restricted page should not be accessible by a user after session time out.

12. ID/password authentication, the same account on different machines cannot log on at the same time. So at a time, only one user can log in to the system with a user ID.

13. ID/password authentication methods enter the wrong password several times and check if the account gets locked.

14. Add or modify important information (passwords, ID numbers, credit card numbers, etc.). Check if it gets reflected immediately or caching the old values.

15. Verify that the Error Message does not contain malicious info so that hackers will use this information to hack the website.

The Different Types of Logs and How to Use Them

 

9 Types of API Testing to Improve Your Website Performance

 

Exploring the Different Types of Software Testing

 Overview of web app testing scope

1. Functional Testing

2. Usability Testing

3. Performance Testing

4. Security Testing

5. Compatibility Testing

6. Interface Testing

How to Quickly Refresh Your Browser in Selenium Java

1. Navigate the refresh method
driver. navigate().refresh();

2. Get the current URL

driver.get(driver.getCurrentUrl());

3. Javascript Executor
JavascriptExecutor executor=(JavascriptExecutor) driver;
executor.executeScript("location.reload()");

4. Robot class
Robot robot=new Robot();
robot.keyPress(KeyEvent.VK_F5);
robot.keyRelease(KeyEvent.VK_F5);

Exploring the Common API Terminology You Need to Know

1. REST (Representational State Transfer): An architectural style for designing networked applications, typically using HTTP as the underlying protocol.
2. SOAP (Simple Object Access Protocol): A protocol for exchanging structured information in web services using XML-based messages.
3. JSON (JavaScript Object Notation): A lightweight data-interchange format that is easy for humans to read and write, and easy for machines to parse and generate.
4. OAuth (Open Authorization): An open standard for authorization that allows users to grant access to their protected resources without sharing their credentials.
5. SDK (Software Development Kit): A set of tools, libraries, and documentation that developers use to build applications for a specific platform or programming language.
6. SDK Client: A software component or library that provides an interface for interacting with an API from within an application.
7. API client: A program or tool that interacts with an API on behalf of a user or system.
8. API key: A secret token or credential to authenticate a user or system when accessing an API.
9. Authentication: The process of verifying the identity of a user or system attempting to access an API.
10. Authorization: The process of determining whether a user or system has permission to access a specific resource or perform a particular action.
11. Endpoint: A URL that represents a specific resource or action within an API.
12. HTTP verb/method: The type of request being made (e.g., GET, POST, PUT, DELETE) that determines the action to be taken on a resource.
13. Rate Limiting: The process of restricting the number of requests a client can make to an API within a given time period to prevent abuse or ensure fair usage.
14. Webhooks: A mechanism for receiving real-time notifications from an API by sending HTTP requests to a specified URL when a specific event occurs.
15. CORS (Cross-Origin Resource Sharing): A mechanism that allows resources (e.g., fonts, JavaScript) on a web page to be requested from another domain outside the domain from which the resource originated.
16. API Gateway: A server that acts as an entry point for client requests and provides various features such as routing, authentication, and rate limiting for backend APIs.
17. Bearer Token: A type of access token used in authentication, where the token is presented by the client to access protected resources.
18. GraphQL (Graph Query Language): A query language and runtime for APIs that provide a flexible and efficient approach to request and manipulate data.
19. Versioning: The practice of assigning a version number to an API to manage changes, additions, or removals of functionality over time.
20. Payload: The data transmitted in a request or response body, typically in formats like JSON or XML.
21. Pagination: The process of dividing a large data set into smaller pages or chunks to improve performance and limit the amount of data transferred in a single response.
22. Content-Type: An HTTP header that specifies the media type of the data being sent or received in a request or response.
23. API Documentation: Comprehensive and structured information about an API, including endpoints, request/response formats, parameters, and example usage.
24. API Key: A unique identifier or token provided to a client application for authentication and authorization purposes when making API requests.
25. Query parameter: A way to pass additional information to an API endpoint through the URL query string.
26. Asynchronous API: An API design pattern where the client can send a request to the server and receive a response at a later time, without blocking the client's execution until the response is received.

The Ultimate Guide to Software Testing in One Image

 

What is the difference between Mistake, Error, Bug, Defect, Fault and Failure?

Testing is the process of identifying defects, where a defect is any variance between actual and expected results. “A mistake in coding is called an Error, an error found by a tester is called a Defect, a defect accepted by the development team then is called Bug, build does not meet the requirements then it Is Failure.”

Although the terms "mistake," "error," "bug," "defect," "fault," and "failure" are often used interchangeably in everyday language, in the world of software development and quality assurance, they have distinct meanings. Here are some definitions to help differentiate between them:

1. Mistake: 

• A mistake is a human action that produces an incorrect result. In software development, this could be a coding mistake, such as a typo or a logic error, made by a developer.

2. Error: 

• An error is a deviation from the expected behaviour of a program, which can occur due to a mistake made by a developer or because of some other external factor, such as hardware malfunction or network failure.

3. Bug: 

• A bug is a specific type of error that is caused by a fault in the code, which can be as simple as a missing semicolon or as complex as a race condition. Bugs are typically discovered during testing or after the software has been released.

4. Defect: 

• A defect is a flaw in the software that causes it to deviate from its intended behaviour. This could be due to a design flaw, a coding mistake, or an error in the requirements specification.

5. Fault: 

• A fault is a defect that exists in the software but has not yet been activated or triggered. For example, a race condition in the code may not cause a problem until the software is run on a specific hardware configuration.

6. Failure: 

• A failure is an event in which the software does not behave as expected, resulting in a loss of service or data. Failures can be caused by errors, bugs, defects, or faults, and can occur at any stage of the software development process.

What Is The Difference Between Regression Testing And Smoke Testing?

Regression testing and smoke testing are both types of software testing, but they serve different purposes and have different characteristics.

Regression Testing:

• Regression testing is the process of testing a software application to ensure that any new changes or modifications to the code have not introduced new defects or broken existing functionality. 
• It involves running a set of previously executed test cases to check if any new errors have been introduced or if the changes made to the code have affected the existing functionality. Regression testing is usually done after code changes or bug fixes.

Smoke Testing:

• Smoke testing, on the other hand, is a preliminary level of testing that checks the basic functionality of an application. 
• It is usually performed to ensure that the build or the application is stable and ready for further testing. 
• Smoke testing is done to ensure that the most critical functionalities of the application are working fine, and the application is not completely broken.

Sanity Testing:

• Sanity testing is similar to smoke testing, but it is performed after smoke testing to verify that the defects found in smoke testing have been fixed and that the critical functionalities are still working fine. 
• Sanity testing is also used to ensure that the new features added to the application are working as expected, and the application is ready for further testing.

In summary, regression testing checks for any new errors or defects that might have been introduced after code changes, while smoke testing and sanity testing ensure that the basic and critical functionalities of the application are working fine. Smoke testing is done before further testing, while sanity testing is done after smoke testing to ensure that the application is ready for further testing.

How To Test Software - Get Functional Defects

1. User Interface Issues

• Poorly designed user interfaces can cause several defects, such as non-responsive buttons, broken links, or incorrect field validations.

2. Data Integrity Issues

• Defects in data integrity may occur when the system doesn't validate the data or doesn't store it correctly. An example of this is if a user enters an email address with an incorrect format, and the system accepts it.

3. Functionality Issues

• Functionality defects occur when the system doesn't meet the business requirements. For example, if a banking application doesn't allow users to transfer funds between accounts or a social media platform doesn't enable users to create a new post.

4. Integration Issues

• Integration defects arise when different modules or systems don't work well together. An example of this is if a CRM system doesn't synchronize data with a marketing automation system.

5. Boundary and Limits Issues

• Boundary and limits issues may arise when the system doesn't handle inputs or outputs correctly that are at the boundaries or limits of the system. For instance, if a system doesn't allow negative values for certain inputs.

6. Business Logic Issues 

• Business logic defects occur when the system doesn't correctly implement the business rules or logic. For example, if a discount code isn't applied correctly or if a system calculates taxes incorrectly.

7. Compatibility Issues

• Compatibility defects may occur when the system doesn't work correctly with different browsers or operating systems. For example, if a website works fine on Google Chrome but doesn't display correctly on Mozilla Firefox.

8. Localization Issues

• Localization defects occur when the system doesn't support various languages or regions. For instance, if a website's interface is not translated into Spanish, which is a required language for the user.

9. Accessibility Issues

• Accessibility defects may arise when the system doesn't provide easy access to all users, such as people with disabilities. For example, if a website doesn't offer a screen reader or keyboard shortcuts.

10. Usability Issues

• Usability defects occur when the system doesn't provide a user-friendly experience. For instance, if a user has difficulty finding the right button or menu item or if the user manual is hard to understand.

 Functional defects can impact the quality and performance of a system, leading to a negative user experience. As testers, it is crucial to identify these defects early in the software development lifecycle to prevent them from affecting the system's overall quality.

The Most Famous Software Failures of All Time

 1. Memory Failure - Tesla Recalls 135,000 Vehicles

•  Tesla will recall a maximum of 135,000 cars to fix computer memory issues in the touchscreen that could cause a loss of some features notified the electric car manufacturer to the U.S NHTSA (National Highway Traffic Safety Administration).
•  The manufacturer said that the touchscreen’s flash memory reached the end of its lifespan. It can trigger failures of the software components of the centre monitor and can unintentionally lead to the loss of external turn signal lighting, rearview camera display, and defog/defrost control settings.

2. HSBC’s Significant IT Outages

• One of the famous software failure examples. HSBC experienced a big IT outage in January 2016 and millions of bank customers were unable to access online accounts. The bank took almost two days to recover and get back to normal service. The Chief Operating Officer of HSBC (COO) claimed that this was the result of a ‘unique technological problem’ within internal systems.

3. Prison Break

•  An error that happened in December 2015 resulted in more than 3,200 US prisoners being released before their announced date of release. The software was developed to track the actions of prisoners and was released in 2002. The problem has been around for about 13 years and an average inmate has been released almost 49 days in advance.

4. The Explosion of the Ariane 5

•  On June 4, 1996, an Ariane 5 rocket launched by the ESA (European Space Agency) exploded just forty seconds after its launch from Kourou in French Guiana. The rocket was on its inaugural voyage, after a decade of development costing $8 billion and the result of this bug was the loss of $370 million.
•  The reason behind its failure was an integer Overflow, which is a widespread bug in computer programming. In this case, an attempt was made to set a 64-bit number in 16-bit space.

5. PayPal accidentally credits man $92 quadrillion

•  When Chris Reynolds opened his PayPal e-mail statement, the Pennsylvania PR executive’s account balance was $92,233,720,368,547,800.
•  The amount is significant in the world of 64-bit numbers suggesting a programming error. The error was quickly recognized, and his account had returned to zero by the time he logged in.
•  PayPal offered to give an unspecified amount of money to a cause of Reynolds’ choice.

6. Windows Calculator Bug

•  This bug exists in most Windows versions(except in Windows 10), including Windows XP, Windows 7, Windows Vista, and Windows 8. You can check it in your OS if you have one of these versions.
•  Steps: Open Windows Calculator, type 4 and take the square root, you will get two then subtract two from it. Instead of the result from zero, you will see different outputs on different versions of Windows.
•  The cause for the bug is the way calculator manages sqrt operations. The results are saved as floating-point numbers instead of integers, and the precision errors when it comes to floating-point calculations are the result that you can see.
•  Microsoft acknowledged this bug in the calculator app, and they fixed it in Windows 10 Build 17639.

7. Gangnam Style music video ‘broke’ YouTube

•  YouTube’s counter before used a 32-bit integer, which is a unit used to represent data in computer architecture. This 32-bit integer determines the maximum number of possible views it can count was 2,147,483,647.
•  The Gangnam Style video exceeded the maximum value, and we got the below famous Gangnam Style YouTube bug.
•  Nowadays, YouTube uses a 64-bit integer for its video counter, which means videos have a maximum viewer count of 9.22 quintillion.

How to Write a Good Bug Report: A Comprehensive Guide

1. Clear Summary:

•  Summarize the bug clearly.
•  The summary should give the bug's full picture in a single sentence.

2. One Issue = One Bug:

•  Do not combine multiple issues in one bug.
•  Because different bugs can be assigned to different developers to fix.

3. Clear & Detailed Description:

•  Expand the summary in description-simple and precise.
•  Provide as much information as possible.

4. Steps To Reproduce:

•  How can you reproduce the bug - mention it in bullet points.
•  Clear enough developers would reproduce and fix quickly.

5. Expected & Actual Results:

•  What is the requirement & what is happening?
•  The developer knows what is the issue by looking at it.

6. Additional Details As Notes:

•  Write about your additional observations.
•  Helps developers to analyze & hence fix bugs quickly.

7. Environment Details:

•  Where have you tested - QA/PRD/CHROME ETC.
•  Developer compares this with other environments.

8. Build Number:

•  In which version of the application you found the bug.

9. PRIORITY:

•  How soon the bug should be fixed.
•  Can be HIGH/LOIW/MEDIUM.

10. SEVERITY:

•  Impact on the product.
•  Can be CRITICAL/MAJOR/MINOR/TRIVIAL.

11. Screenshot/Screen Recording:

•  Evidence of the bug.
•  Can be screenshots or screen recordings.

12. Link the related test case and or story:

•  Link bug to story/test case you are testing.
•  Can be 'Associated With' OR 'Blocked By'.

13. LOGS:

•  Attach log file or snippet of log.
•  This is a mine of data for developers.

14. Avoid Duplicates:

•  Check if already bug is reported by someone. 

What Type of Test Cases Should Not Be Automated?

1. User Interface (UI) testing

2. Exploratory testing

3. Usability testing

4. Ad hoc testing

5. Performance testing

• Test cases that require human judgment, exploration, or unpredictability may not be suitable for automation. Additionally, test cases highly dependent on an application's user interface, performance, or usability may be better suited for manual testing.