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 an 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 crash when testing 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 201 and 204 Status Code?

• 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 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 area.
  
3. Black Box, White Box, Gray Box Testing:

•  Black box: Focuses on external behavior 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 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, 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, reducing 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 Major functionalities in the software through positive test cases.
• Sanity testing - Focusing 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 requirements. Here we check negative scenarios.

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

13. Globalization 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 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 requirement given by the customer.
• Sprint - It is the duration time taken to work on 1 or more user stories. Each sprint can be either 2/3/4 weeks, it depends upon the customer 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, that 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 release 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.