❔Interview Questions

Interview Style Questions commonly asked

🔍 If you reported a defect to a developer and he rejected it, what shall you do?

👉 Communicate with him: The tester should communicate with the developer to understand why the defect was rejected. 🗣️ By having a conversation, the tester can gain a better understanding of the developer's perspective and reasoning.

For example, the tester could say something like:

"I noticed that you rejected the defect report that I submitted. Can you help me understand why you rejected it? I want to make sure that I'm reporting defects accurately and effectively."

👉 Return to the work products: If the tester is still convinced that the issue is a defect, they can return to the work products, such as the SRS or product backlog, to review the requirements and ensure that the behavior of the software aligns with them. 📝 This will help the tester determine if the issue is indeed a defect or if it is simply a misunderstanding of the requirements.

👉 Ask the product owner: If the tester is still unsure whether the issue is a defect, they can ask the product owner for clarification. 🤔 The product owner is responsible for defining the requirements and can provide guidance on whether the behavior of the software is aligned with them.

👉 Check the test environment: The tester can also check the test environment to see if the issue occurs in different environments. 🌍 If the issue occurs consistently in multiple environments, it may be more likely to be a defect.

👉 Escalate the issue: If the issue is still unresolved, the tester can escalate the issue to their supervisor or manager. 🔝 The supervisor or manager can help facilitate communication between the tester and the developer or product owner and help ensure that the issue is resolved appropriately.

👉 Accept that it is not a defect: Finally, if all other options have been exhausted, the tester may need to accept that the issue is not a defect. 😔 It's important for testers to be objective and not push for defects that don't exist.

💡 In summary, if a developer rejects a defect that a tester has reported, the tester should communicate with the developer, return to the work products, ask the product owner, check the test environment, escalate the issue, or accept that it is not a defect. It's important for testers to remain objective and seek clarification to ensure that issues are resolved appropriately. 🧐🗣️📝🤔🌍🔝😔

What is the relationship between a defect and a failure?

If a defect in the code is executed, this may cause a failure. However, it's important to note that not all defects will necessarily result in failure. Some defects require very specific inputs or preconditions to trigger a failure, which may occur rarely or never.

What's the difference between defect 🐛 priority 📈 and severity 🕸?

Me: 👍Priority is the order ⬆️ in which defects 🐞 should be fixed. Higher priority = fixed sooner.

👎Severity is the impact 💥 a defect has on the software. Higher severity = more impactful defect.

Interviewer: Can you give examples?

Me:

👍High priority ⚠️ & severity:

❌Submit button ❌ not working 🚫

👎Low priority ⏱️ & severity:

⚠️ Some non-critical ❌ crash 💥

👍Low priority ⏱️ & High severity:

❌ Company name 📝 misspelling😵‍💫

👎Low priority ⏱️ & severity:

🕚 Page loads slowly

Why prioritize defects?

Me: We prioritize to:

🔜Fix the most impactful and critical defects first

⏱️Use resources efficiently

💯Improve software quality the most

Why consider severity?

Me: Severity indicates:

📈 How badly a defect affects customers 👤

📉 How much it degrades the quality

So higher severity defects:

🙅‍♂️ Block customers🙅‍♀️ 💥Cause most issues 💯

Get the highest priority!

Interviewer: Any final thoughts?

Me: Consider both!💭

📈 High-priority defects fix issues fastest 🏎

🕸High severity exposes most risk 💣 and impact 💥

Proper prioritization balances ⚖️ urgency 🕒and importance 📈to maximize 📈software quality 💯 and customer ❤️satisfaction 🙌!

Explain the difference between priority and severity in a QA context.

Me: Sure! 😊 Priority refers to the importance of fixing a bug or issue, based on business needs and timelines. ⌛ Severity refers to the impact or seriousness of the bug itself. 🐞

Interviewer: Can you give an example?

Me: Sure! A spelling error on a page has low severity, but if it's on the homepage it may be a high priority to fix quickly. 📄

A crash in the payment process is high severity but may be a low priority if few users are impacted. 💳

Interviewer: So priority is more business focused?

Me: Exactly. 🎯 Priority considers business goals, deadlines, and resource costs. A cosmetic bug may be low severity but high priority to fix before launch. 🌟

Severity looks purely at the technical impact of the bug, regardless of business needs. A data loss bug is high severity regardless of priority. 🚫

Interviewer: Makes sense. Anything else to note?

Me: Yes, the same bug can have different priorities and severity. 🧐

A crash during checkout has high severity but may be a low priority if it impacts a niche feature.🛒

But after a marketing push, it could become a high priority to fix that same crash. 📢

🙋‍♂️ Please enlist the various basic components of the defect report format.

✅👥Defect detected by - Tester's name

✅📆Defect detected on - Date and time

✅🆔 Defect ID and ✍️Name - Unique identifier and descriptive name

✅👥 Defect resolved by- Developer's name

✅📆 Defect resolved on -Date fixed

✅⚙️ Module Name -Feature or area defect relates to

✅📈 Priority and ⚠️ Severity - Level of business impact and urgency

✅📚Project Name -Which application defect was found in

✅📷 Defect Snapshot- Screenshot, stack trace, or log

✅📝 Steps to reproduce - Exact actions to see the issue again

✅📝 Expected result - What should have happened

✅📝 Actual result - What actually happened

✅📝 Additional details - Browser, OS, device info, etc.

So in summary, a defect report format includes:

✅ Who found issue➕who fixed it🛠

✅ Dates 📅 and unique ID for issue tracking

✅ Project name and affected module

✅ Priority, severity, and business impact of the issue📈

✅ Visual evidence of issue📷

✅ Steps to reproduce, expected vs. actual results

By including these details❗, a standardized defect report format ensures issues are properly logged 📝and communicated to developers for resolution!

💻 A defect that could have been removed during the initial stage is removed in a later stage. When a defect is found in a later stage that could have been removed during the initial stage, it can have a significant impact on the cost of the project. 🤔 How does this affect the cost?

The cost of defects identified during Software Testing completely depends on the impact of the defects found. 💰 The earlier the defect is found, the easier and less costly it is to fix these defects. For instance, if there is a defect found in the project requirement specifications and analysis, then it is relatively cheaper to fix it. 💡

Similarly, if defects or failures are found in the design of the software, then the product design is corrected and then re-issued. However, if these defects somehow get missed by testers and if they are identified during the user acceptance phase, then it can be way too expensive to fix such types of errors. 💸

What are the valuable steps to resolve issues while testing?

👩‍💻😄 1)📝Record -️ Log issues descriptively in a 📒test management tool.

Document:

✔️ Steps to reproduce

✔️ Actual result

✔️ Expected result

✔️ Severity level 📈

✔️Assignee

💬 2) 📢Report

Communicate the issue to:

✔️ Developer in charge of that feature

✔️Project manager

✔️ Testing lead

⚙️ 3) 🛠Control

Establish an issue management process:

✔️Templates for logging issues📝

✔️ Workflow (new ➡️ in progress➡️resolved ➡️closed)

✔️Issue prioritization based on severity and business impact📈

😄4) 👍Follow up

Ensure issues are:

✔️Assigned to someone with accountability

✔️Actively worked on 🛠

✔️Resolutions are tested❗

✔️ Issues are properly closed ✔️

5) 📆Reproduce

Retest issues after fixes to validate they're truly resolved❗

So in summary, effectively resolving issues involves:

❗ Accurately logging details upfront📝

❗ Communicating to the right teams💬

❗Establishing processes for logging✍️, prioritizing📈,assigning👥 and resolving issues🛠

❗Following up💬 to ensure issues don't fall through the cracks

❗ Reproducing❗ tests after resolution to validate fixes✅