> For the complete documentation index, see [llms.txt](https://qatesting.gitbook.io/qa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://qatesting.gitbook.io/qa/manual-testing/sdlc/interview-questions.md).

# Interview Questions

## What would you do if you don't have clear written user requirements to test the software?

You: There are still ways to test the software even if the user requirements are not clear. Here are some possible approaches:

First, **work with whatever little documentation you can get your hands on.** 📝 Even if you don't have complete and clear requirements, you may still have some documentation that provides context or guidance for how the software should function. Use whatever documentation you have to guide your testing efforts.

Second, **use the older/current version of the application as a reference to test the future release of a software product.** 🔙 If the software being tested is an update or a new version of an existing application, use the older/current version as a reference to test the new release. This can help you understand the expected functionality and identify any differences or improvements in the new version.

Third, **talk to the project team members**. 💬 Reach out to the project team members, such as the developers and product owners, to gather more information about the software being tested. They may be able to provide additional context or guidance on how the software should function.

Fourth, **use exploratory testing to test the application when it is ready**. 🔍 Exploratory testing is a type of testing that involves exploring the software and learning about its functionality as you go. This approach can be useful when requirements are unclear, as it allows testers to identify issues and areas for improvement based on their observations and experience using the software.

## **When can you say your story is ready to develop/ groom enough to deliver?**

Answer: Ready is a stable state of Scrum that is linked to a user story. As per the Definition of Ready (DOR), a user story has to satisfy some conditions before picking it up for a sprint i.e. to be in the ready state. So, the conditions that are essential for the development/grooming of a user story specify if the user story is ready to develop/groom enough to deliver or not.

Basically, the following questions should be answered to consider a user story ready:

**Why:** Is it clear what the business or stakeholders are trying to achieve?

**What**: Is the goal or outcome of the user story clear?

**How**: Is the strategy for the implementation of the user story clear? Is the story small enough?

The conditions for the user story are defined by the scrum master in coordination with the product owner. Although the conditions vary for the different projects, some of the common conditions for user stories are –

* **It is clear and well-written in a format to identify user type, function, and benefits**
* **It is self-contained i.e., independent of another user story inherently**
* **It is small so that can be delivered in a single sprint**
* **It has defined acceptance criteria for all the functional requirements and appropriate non-functional requirements**
* I**t should have been estimated by the scrum team**
* **All the external blocking dependencies should have been resolved before starting the sprint**

The resources/team have all the skills required to deliver the sprint.

## What are the types of documents needed for QA, QC, and Testing?

**🙋‍♂️ Test Plan:**

* Outlines the scope, approach, resources, and schedule for testing
* Defines test strategy, objectives, and entry/exit criteria

**📜 Functional Requirements Document:**

* Specifies the features and functionality that the product must have
* Used as a base to develop test cases

**📜 Design Documents:**

* Details of how the product will be designed and built
* Used to verify that the final product meets design specifications

**📝 Test Strategy:**

* Defines the high-level approach for testing the product
* Includes the types of testing to be done

**📝 Test Cases:**

➡ Test procedures to be performed ➡ Expected results ➡ Pass/fail criteria

**📝 Defect Reports:**

* Used to log any issues found during testing
* Helps prioritize and track defects

**📝 Test Metrics:**

* Data collected during testing
* Used to measure test coverage, effectiveness, and efficiency

🗒 Other Useful Documents:

* **Data specifications**
* **Test policies**
* **Use cases**
* **Test methodologies**
* **Template test documents**

## <mark style="background-color:yellow;">What is the difference between Build and Release/Version?</mark>

🛠️ **Builds** 🛠️

* Compile code into **executable programs** 👨‍💻
* **Integrate** code from different modules 🧩
* Run **unit tests** to validate code ✅
* Output is **tested artifacts** ready for release 📦

🚀 **Releases** 🚀

* Take build **artifacts** and **package** them 🎁
* **Prepare installers** and docs for users 💻
* **Deploy** to download channels for use 📥
* **Major** releases have big new features 🆕
* **Minor** releases are smaller changes 🛠️

Summary:

* 🛠️ Builds transform code into tested programs
* 🚀 Releases deliver those programs to users
* Builds come **first** 🥇
* Releases come **after** successful builds 🏁

As a QA automation engineer, we help **test builds** 🧪 and **release** quality software! ✅

<table data-full-width="true"><thead><tr><th width="143"></th><th>Build</th><th>Release</th><th>Version</th></tr></thead><tbody><tr><td>What it is</td><td>Daily code work</td><td>Tested code ready for customers</td><td>Specific release given to customers</td></tr><tr><td>Created from</td><td>Individual code pieces</td><td>Combines multiple builds after testing</td><td>Based on release passed to customers</td></tr><tr><td>Numbering</td><td>No numbers usually</td><td>Gets a release number like 1.0</td><td>Increments with changes, like 1.1, 2.0</td></tr><tr><td>Examples</td><td>Code on Monday</td><td>Monday and Tuesday code as 1.0</td><td>Customers get improved 1.1 code</td></tr><tr><td>Purpose</td><td>For developers to add code</td><td>Thoroughly tested code for customers</td><td>Track software updates over time</td></tr><tr><td>Frequency</td><td>Daily as code is added</td><td>Less often after extensive testing</td><td>When important changes are ready</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://qatesting.gitbook.io/qa/manual-testing/sdlc/interview-questions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.