❔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

• It 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

What is the difference between Build and Release/Version?

🛠️ 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! ✅

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