❔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! ✅
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
Last updated