Top 15 "Manual Testing" Interview Questions and Answer :)

Q 1: What's the difference between QA and testing?

Ans.:  *TESTING means "quality control"

*QUALITY CONTROL measures the quality of a product    

*QUALITY ASSURANCE measures the quality of processes used To create a quality product.

Q 2: What is black box/white box testing?

Ans.: Black-box and white-box are test design methods.  Black-box test design Treats the system as a "black-box", so it doesn't explicitly use Knowledge of the internal structure.  Black-box test design is usually Described as focusing on testing functional requirements.  Synonyms for Black-box include:  behavioral, functional, opaque-box, and Closed-box. White-box test design allows one to peek inside the "box", And it focuses specifically on using internal knowledge of the software to guide the selection of test data.  Synonyms for white-box include: Structural, glass-box and clear-box. While black-box and white-box are terms that are still in popular use, Many people prefer the terms "behavioral" and "structural".  Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn't strictly forbidden, but it's still discouraged. 

 Q 3: What's the difference between load and stress testing?

Ans.: Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions and to determine weather it can handle peak usage periods. Stress testing is a form of testing which is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. For example, a web server may be stress tested using scripts, bots, and various denials of service tools to observe the performance of a web site during peak loads. Stress testing a subset of load testing.

Q 4: What is a 'Walk-Through'?

Ans.: A 'walk-through' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.

Q 5: Who is responsible for integration testing?

Ans: Team leader along with developers.

Q 6: Is performance testing part of System testing?

Ans: Yes

Q 7: Is system testing perform before unit testing?

Ans : No

Q 8: What is software Test plan? Mention major items of a test plan document.

Ans: A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:

1. Objective

2. Product Details

•           Product Identification

•           Features to be tested

•           Features not to be tested

•           Acceptance Criteria 

3. Test Plan

•           Test Item

•           Test Deliverable 

•           Testing Process

•           Overview of test cycle

•           Formal Review Points

•           Test Environment

•           Resource

•           Security

•           System Test Setup

•           Schedule

•           Test Procedure

•           Entrance Criteria

•           Suspension Criteria

•           Resumption Criteria

•           Exit Criteria

•           Error Measurement / Management System

•           Error Reporting

•           Error Classification

4. Testing Types

•           Types of testing to be performed for the project.

5. Appendix

•           Defect Summary

•           Reference Documents

 Q 9: What should be the entry criteria and Deliverable's for system testing?

Ans: Although this is subjective and specific to project, but generally the entry criteria should be:

•           All human resources must be available and assigned the task.

•           Unit test cases should be prepared before coding.

•           All developed code must be unit tested.

•           System test cases should be prepared before start of system testing.

•           All test hardware and environments must be in place, and free for System test use.

Deliverables should be the integration tested build along with installation guide and release notes.

           

Q 10: How can it be known when to stop testing?

Ans: This can be difficult to determine. Many modern software applications are so Complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:

•           Deadlines (release deadlines, testing deadlines, etc.)

•           Test cases completed with certain percentage passed

•           Test budget depleted

•           Coverage of code/functionality/requirements reaches a specified point

•           Bug rate falls below a certain level

•           Beta or alpha testing period ends

Q 11: What is the priority and severity of the bug? Explain with example a scenario, With high priority and low severity and vice versa.

Ans.: Severity of a bug describes the impact of a bug.

Blocker           Blocks development and/or testing work

Critical:           Crashes, loss of data, severe memory leak

Major:            Major loss of function

Minor:            Minor loss of function, or other problem where easy workaround is present

Trivial:            Cosmetic problem like misspelled words or misaligned text

Enhancement: Request for enhancement

Priority describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done. The available priorities range from P1 (most important) to P5 (least important.)

Example: Any look and feel issues like spelling mistake on an UI is less severe, but if the product is going for beta testing, priority of bug to fix is higher.

Similarly any exception coming on a particular operation has high severity, but that module is not to be delivered right now, so this bug can have low priority.

Q 12: Explain various States of bug, can a bug be new after it is resolved?

Ans:     Mainly a bug can be in either open state or it can be in end state.Open state comprises of Unconfirmed, New, Assigned and Reopened. End State comprises of Resolved, Verified and Closed. No a bug can not be new after it is resolved, it should have state Reopen.

Q 13: What is word deferred means in terms of bug life cycle? When a bug is Deferred?

Ans: Deferred means postponing the resolution of the bug. When any bug is found valid, but due to skill or time restrictions, it is planned to resolved later, bug is send to deferred stated.

Q 14:  What are the various points a tester should ensure before entering a bug?

Ans:     1. Make sure the bug has not been previously reported.

            2. Be sure you’ve reproduced your bug using the latest build released.

Q 15: Explain any two qualities of a useful bug report.

Ans: A useful bug report has two qualities:

1. Reproducible :  If the developer can’t see it or conclusively prove that it exists, he’ll mark it as “WORKSFORME” or “NOTREPRODUCIBILE”. Every relevant details you can provide helps.

2. Specific :  The quicker the engineer can isolate the issue to a specific problem, the more likely it’ll be expediently fixed.