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.

Easy Steps to Navigate a Site Like a Pro

Manually exploring a site involves checking its various features, functionality, and usability. Here's a comprehensive checklist:

Home Page:

1. Verify page layout and design
2. Check the navigation menu and links
3. Validate search functionality (if present)
4. Review hero section/content

Inner Pages:

1. About Us
2. Contact/Support
3. FAQ
4. Blog (if present)
5. Terms and Conditions
6. Privacy Policy

Features and Functionality:

1. User registration/login
2. Payment gateway integration (if applicable)
3. Search filters and sorting
4. Product/service details pages
5. Reviews and ratings (if present)
6. Commenting system (if present)

User Experience (UX):

1. Responsive design (mobile, tablet, desktop)
2. Page loading speed
3. Navigation and menu usability
4. Content readability
5. Error handling and messaging

Security:
1. HTTPS encryption
2. Password hashing and storage
3. Input validation and sanitization
4. CSRF protection
5. Secure payment processing

Accessibility:
1. Screen reader compatibility
2. Keyboard navigation
3. High contrast mode
4. Closed captions (if video content)

Browser and Device Compatibility:
1. Test on multiple browsers (Chrome, Firefox, Safari, Edge)
2. Test on different devices (desktop, laptop, mobile, tablet)
3. Verify consistency across devices and browsers

Other:

1. Social media integration
2. Newsletter subscription
3. Contact form functionality
4. Map integration (if present)
5. Third-party services integration (e.g., analytics)

Global vs Environment vs Collection Variables in Postman – Key Differences Explained

Global Variables:

• Stored globally across all requests and collections.
• It can be accessed from any request or collection.
• Use cases: API keys, common headers, or base URLs

Environment Variables:

• Stored within a specific environment (e.g., dev, staging, prod).
• It can be accessed only from requests within the same environment.
• Use cases: Environment-specific settings, such as URLs, credentials, or timeouts.

Collection Variables:

• Stored within a specific collection.
• It can be accessed only from requests within the same collection.
• Use cases: Collection-specific settings, such as API endpoints, headers, or query parameters.

Selenium XPath in detail

What is XPATH?

• It is an XML path.
• It is one of the locator types in selenium.
• It uses path expression to navigate in XML documents and to identify a node or number of nodes.
• XPath is used to handle complex and dynamic paths.

 

Types of XPATH in Selenium:

  1. Absolute XPath
  2. Relative XPath
 

What is Absolute XPath?

• Absolute path starts from <HTML> tag.
• It uses / ( forward slash ).
• It is used to identify any element direct way by consider all the tag starts from <HTML> tag.
• It is much more faster than "Relative xpath" as it holds the direct path to the target node/tag/element from start <Html> tag.
• But we will mostly use this one if it holds a long string path and is difficult to maintain or handle. It is not a shortend path.

 

What is Relative XPath?

• It uses //  ("forward double slash").
• It will consider any node/element/tag as a refernce point from where either we can traverse forard or reverse direction to identify target node/tag.
• It is mostly used as we are considering any node as a reference node (stable node) from a DOM.

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.

Selenium Interview Questions and Answers - PART 2

1. WebDriver is interface or class?

• WebDriver is an interface in Selenium.

2. If we do not add a driver exe file what will happen and what kind of exception will be generated?

• If the driver executable is not added, Selenium won't be able to communicate with the browser, and a WebDriverException will be thrown.

3. What is the difference between close and quit?

• close(): Closes the current browser window.
• quit(): Closes all the browser windows and ends the WebDriver session.

4. Difference between get and navigate().to() ?

• get(): Loads a new web page in the current browser window.
• navigate().to(): This does the same as get() but allows for additional navigation options like back, forward, and refresh.

5. Difference between findElement and findElements?

• findElement: Returns a single WebElement or throws  NoSuchElementException if not found.
• findElements: Returns a list of WebElements. If no elements are found, it returns an empty list.

6. How do you get all the links on the current page? Which locator will you use other than XPath?

• You can use the CSS selector a to find all links.

List<WebElement> links = driver.findElements(By.cssSelector("a"));

7. Methods of WebDriver?

• Some common methods are: get() , getCurrentUrl() , getTitle(), findElement() , findElements() , getPageSource() , close() , quit(), navigate() , manage() .

8. What is the use of the getCurrentPageSource method?

• It returns the source code of the current page.

9. When do we go for the findElements method and what is the return type?

• Use findElements when you expect multiple elements. It returns a list of WebElements.

10. Why do we get WebDriverException?

• This exception is thrown when WebDriver is unable to interact with the browser. Possible reasons include incorrect WebDriver setup, browser crashes, or network issues.

11. Absolute and Relative XPath?

• Absolute XPath: Starts from the root and follows a complete path (e.g., /html/body/div ).
• Relative XPath: Starts from the middle of the HTML DOM structure (e.g., //div[@id='example'] ).

API Status Codes with Real Time Examples

HTTP 500 Series Status Codes:

• HTTP status codes in the 500 series are server error responses.

1. 500 Internal Server Error

• It occurs when a server meets with an unexpected condition. It indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. The exact cause of the error is not specified in the response, making it a generic error message.

Example:

• Imagine you are using an online banking application. You have logged in successfully and want to transfer money to a friend. You fill out the form with the necessary details and hit the 'Transfer' button. Instead of processing the transaction, the application shows a '500 Internal Server Error message.

Cause:

• This could be due to several reasons, such as a bug in the application code, an issue with the server configuration, or a problem with the database connection. For instance, if the code that processes the transaction has a programming error or the database server is down, the web server might not be able to complete your request, resulting in this error.

2. 501 Not Implemented

• It indicates that a server doesn’t recognize the requested method or is unable to process that type of request.

Example:

• Suppose you are using a RESTful API to manage your online store inventory. You send a request using a new HTTP method called 'PATCH' to update part of the inventory data.

Cause:

• If the server you are communicating with has not been programmed to handle the PATCH method, it will return a 501 Not Implemented error. The server might only support GET, POST, PUT, and DELETE methods, and hence does not understand or implement the PATCH method.

  
3. 502 Bad Gateway

• It happens when a server receives an invalid response from the upstream server.

Example:

• You are trying to access a news website. The website's server needs to fetch the latest news articles from another server (an upstream server).

Cause:

• If the upstream server is down or returns a corrupted response, the main server cannot retrieve the necessary data and responds with a 502 Bad Gateway error. This typically happens in complex server architectures where one server relies on another to get the required information.

  
4. 503 Service Unavailable

• It indicates that the server is temporarily down for maintenance or overloaded.

Example:

• A popular e-commerce website announces a flash sale. As the sale goes live, thousands of users try to access the website simultaneously.

Cause:

• The sudden surge in traffic overwhelms the server, which cannot handle the volume of requests, leading to a 503 Service Unavailable error. Alternatively, if the website administrators are performing maintenance, they might take the server offline temporarily, resulting in this error.

  
5. 504 Gateway Timeout

• It occurs when a server doesn’t receive a response on time from the upstream server.

Example:

• You are using an online travel booking site to book a flight. The site needs to check availability with the airline's server.

Cause:

• If the airline's server takes too long to respond, the booking site's server might time out while waiting for the response, resulting in a 504 Gateway Timeout error. This usually occurs in distributed systems where one service depends on another for data.

 
6. 505 HTTP Version Not Supported

• It indicates that the server doesn’t support the HTTP protocol version used in the request.

Example:

• You are using an old web browser to access a modern web application.

Cause:

• If your browser sends a request using HTTP/1.0, but the server only supports HTTP/1.1 or HTTP/2, it will respond with a 505 HTTP Version Not Supported error.

  

HTTP 400 Series Status Codes:

• HTTP status codes in the 400 series are client error responses. These indicate that the request made by the client (e.g., a web browser) was incorrect or cannot be processed by the server. 

1. 400 Bad Request

• The server cannot understand the request due to malformed syntax.

Example:

• You try to search for a product on an e-commerce website, but you accidentally enter invalid characters in the search box. The server doesn't understand your request and returns a 400 Bad Request error.

  
2. 401 Unauthorized

• The request requires user authentication. The client must authenticate itself to get the requested response.

Example:

• You try to access your email account without logging in. The server responds with a 401 Unauthorized error, asking you to log in first.

  
3. 403 Forbidden

• It is sent when a user doesn’t have permission to access the requested page.

Example:

• You try to access a restricted page on a company's internal website without the necessary permissions. Even if you are logged in, you get a 403 Forbidden error because you don't have the right access level.

  
4. 404 Not Found

• The server cannot find the requested resource. This is the most common error.

Example:

• You click on a broken link or type in a URL that doesn't exist on a website. The server returns a 404 Not Found error because the page you're looking for cannot be found.

  
5. 405 Method Not Allowed

• The request method is known by the server but is not supported by the target resource.

Example:

• You try to submit data using a GET request instead of a POST request on a form submission page. The server responds with a 405 Method Not Allowed error.

  
6. 408 Request Timeout

• The server did not receive a complete request message within the time that it was prepared to wait.

Example:

• Your internet connection is slow, and it takes too long to send a request to a website. The server times out and returns a 408 Request Timeout error.

  
7. 429 Too Many Requests

• The user has sent too many requests in a given amount of time ("rate limiting").

Example:

• You try to log in to your account multiple times in quick succession, and the server temporarily blocks further requests, returning a 429 Too Many Requests error.

Important Things to Test Ecommerce Applications

•  E-commerce applications have many users worldwide, dealing with finance, marketing, retail & wholesale, manufacturing, and auctions.

1. Testing E-commerce Application’s Functionality

An e-commerce web or mobile application has four important elements in its structure, and they are:

• Main Pages – Homepage, Product page, Special Offers, About Us page, Sitemap pages, Privacy Policy page, Press Releases page, etc.
• Category / Product Type Pages – The product page includes options such as product size, colour, and type. There is a sorting feature to filter out products based on price, model, size, etc. There is also the “Add to Cart” or “Add to Wishlist” feature present in the category pages.
• Product Description Page – Consists of the product title, description, product images, related products, Add to Cart feature, Product comparison, additional product info, etc.
• Shopping Cart – Products list view, removing the product from the list, cash on delivery option, Select delivery option, card payment, pay now option, etc.

2. Testing E-commerce Application Workflow

• Login and Signup options
• Search functionality
• Product review posting feature
• Sorting feature
• Applying filters for choosing the desired product(s)
• Add/remove functionality in the shopping cart
• Check out process
• Order number and invoice generation
• Payment gateway and payment processing

3. Payment Gateway Functionality

  Another important functionality to test is the payment gateway and you have to conduct multiple tests to ensure it functions properly and provides security while doing online transactions. Here are the checkout and payment processes that you need to test:

• You need to check the product price is correct, the shipping charge, VAT, and discount codes are applied and the price the customer has to pay is the right amount. You can test this payment process by making changes to the final list of products, applying different discount coupon codes, and choosing a different region to see the change in shipping charges.
• You need to check whether the payment is processed correctly, by using all kinds of payment methods such as net banking, Credit/Debit card, PayPal, etc. You can check all these using dummy accounts and demo debit/credit card numbers. Also, you need to check whether the orders are cancelled, and the payment ID sent back.
• Check whether the invoices and emails generated after the payment process are sent.
• You need to also ensure the refund process, email, and refund receipt all are working properly.

4. Other Common Things to be Tested

• There are other common things in your e-commerce application you need to test and they include website content, webpage format, website accessibility, cookies, social buttons, adding/deleting content, removing/adding links, web standards, analytics, and making changes to shipping settings.

5. Performing Security and Vulnerability Assessments

6. Checking Compatibility with Web Browsers

7. Testing for Mobile Responsiveness

8. Checking Performance and SEO-related Things

9. Social Media Integration

Get Ahead with These Real-Time Software Testing Interview Questions (Part 1)

1. What are the three types of authentication?

• Authentication is crucial to security, ensuring that only authorized users gain access to systems, applications, and data. There are three main types of authentication methods:

Something You Know:

• This type of authentication relies on information that the user knows.
• Examples: Passwords, PINs, security questions, or passphrases.
• Advantages: Easy to implement and use.
• Disadvantages: Can be vulnerable to social engineering, phishing attacks, or being guessed.

Something You Have:

• This type of authentication depends on something the user possesses.
• Examples: Physical tokens, smart cards, mobile devices, security keys, or one-time password (OTP) generators.
• Advantages: Adds a layer of security that is more difficult to breach compared to just using passwords.
• Disadvantages: Can be lost, stolen, or damaged, and may require additional hardware.

Something You Are:

• This type of authentication uses the inherent characteristics of the user.
• Examples: Biometric authentication methods such as fingerprints, facial recognition, iris scans, voice recognition, or behavioural biometrics.
• Advantages: Provides a high level of security since biometric traits are unique to individuals.
• Disadvantages: It can be more expensive to implement and may have privacy concerns; some biometric systems can be tricked or spoofed.

2. What is a critical bug?

• A critical bug is a bug that impacts a major functionality of the application. This means affecting a large area of the functionality or breaking any functionality; there is no other method to overcome this problem. The application cannot be delivered to the end user unless the critical bug is fixed.
• For example, on a shopping website like Amazon, the following bugs will be classified as critical:

            Cannot log in to your account.

            Cannot checkout.

            The system crashes after payment.

            The product's price is not displayed.

Major:

• A major defect is a defect that leads to the failure of a crucial part of the application.
• For example, on a shopping website like Amazon, the following bugs will be categorized as major:

            Search results do not match the search query.

            Cannot use debit cards during checkout. (But can use credit cards and other payment options).

            Product reviews are not displayed.

Minor:

• A minor defect is a defect that causes problems in some unimportant or niche functionality of the system.
• For example, on a shopping website like Amazon, the following bugs will be deemed minor:

            Cannot search past orders that are more than a year old.

            Cannot compare more than three products at a time.

            Thumbnails of product photos uploaded by users are unclear.

3. What are the impacts caused by a failure in white box testing?

• White-box testing is a software testing method that focuses on the internal structure of the code.
• This type of testing is often used to identify defects in the code, such as logic errors, syntax errors, and data-handling errors.
• If defects are not identified and fixed early in the development process, they can be more expensive to fix later on. This is because it may take longer to find the root cause of the defect, and the fix may require changes to more code.

4. What bugs mainly come in Web testing?

• Issues in the navigation of the application - The flow of the site is not consistent.
• Usability - The application is not user friendly and the interface is not easy to understand, or navigate and is not extractive.
• Cosmetic Issues and GUI Issues - Cross browser application does not have a consistent look and feel, and Field level validations are not working.
• Functional Issues.
• Performance issues - How much time it takes to display the page to the user.
• Load - How much load an application can handle at any point in time.
• Stress - At how much load the application will crash.
• Flow of data - Information which is entered by the user is stored in the correct format.

5. What is Usability testing in web testing?

• Designers should always remember that the experience of the user on their website must be as pleasant as possible. How the user interacts with the website is very important.
• While doing usability testing of a web application:

           Font of the fields.

           Colour of the validation messages and fields.

           Mandatory fields should be in an asterisk symbol.

           Alignment of the fields.

           Showing the Next/previous link in a data grid if the application count reaches 10.

           Navigational link.

           All pages should have a heading consistently.

           User-friendly validation messages in each and every operation.

           Size, shape and arrangements of Iframe, panel, tables, text boxes, radio buttons etc.

6. What are the typical problems in web testing?

• Security: Authentication Issues, data not encrypted, User privileges leaks, SQL injection can done, cross side scripting, cookie testing etc.
• Session Issues: Session of page not maintained.
• GUI issues: Page resize issues, alignment of page, page refresh issues, look & feel, broken links, bad hyperlinks, spelling etc.
• Pages on the website are not properly validated and do not conform to industry standards (CSS, HTML/XHTML).
• The application's business logic is not proper.
• User inputs are not properly validated.
• User inputs do not meet technical specifications.
• Error messages are not generated or are incorrect.
• Web page design (fonts, colour scheme, layout) does not meet requirements.
• Broken links.
• Feeds do not work properly.
• Pages are not accessible to the visually impaired.
• Copyright information is incorrect.
• Images have not been optimized or do not otherwise meet requirements.
• Cookies don't work properly.
• Web clients can't handle some of the messages returned by the server.
• Pages don't render properly with some operating systems and/or browsers.
• Data obtained through web pages are not captured and/or stored properly in the database.
• It takes too long for some pages to render.
• Performance lags when there are numerous simultaneous users.
• Users have inappropriate access to roles or content.
• User problems with login (password strength, failure to track login attempts, etc).
• Concurrency issues (session problems) when multiple users are on the same page and/or when a single user is on multiple windows of the same page.
• The server log does not properly track transactions.
• The website does not properly use SSL.

7. There are 3 mandatory fields and 3 optional fields: How many possible test cases can be written?

• Submit the page with empty optional fields and verify whether the validation messages are shown for optional fields.
• Each time leave any one of the optional fields, submit the page and verify whether the validation messages are shown.
• Submit the page with empty mandatory fields and verify whether the validation messages are shown for mandatory fields.
• Each time leave any one of the mandatory fields, submit the page and verify whether the validation messages are shown.

8. Examples of Severity and Priority of all combination

       Priority is how soon the issue needs to be resolved. Severity defines the impact of the issue.

• High severity low priority: Logo of the company.
• High severity high priority: Submit button of login page not working or page not displaying.
• Low severity high priority: Cosmetic error or spelling mistake on the login page. It's a small bug but has high priority as it's on the main login page.
• Low severity low priority: spelling mistakes in text of home screen.

9. What is RTM? How is it useful in testing?

• The Requirement Traceability Matrix (RTM) captures all requirements proposed by client or development team. Used to check all testcases are covered, so that no functionality should miss.

10. The exact difference between alpha and beta testing

• Alpha Testing: Pre-release testing by end-user representatives at the developer site.
• Beta Testing: Done by a selective group of users (Normal Users). For example: Apps like Yahoo Messenger, and Firefox release their beta version to users and get their feedback.

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.