פרק #63 | קריטריון יציאה בעולם האג׳ייל עם איגור גולדשמידט
״קריטריון יציאה״ בעולם האג׳ייל עם איגור גודשמידט
🧠 Main Themes Discussed:
-
The Importance of Community in QA
Igor emphasizes the role of professional communities in knowledge sharing.
He mentions the proactive involvement of the Israeli QA community, including webinars, meetups, TikTok, articles, podcasts, etc.
He presents Israeli efforts at international conferences (e.g., STQB) and notes global recognition of Israel's contributions to software testing.
-
Igor's Background
Focuses on providing QA/testing frameworks for startups.
Writes articles based on real-life experience and field challenges.
Member of the international academic team of a global testing organization.
🧰 Main Topic: Exit Criteria
❓ What is Exit Criteria?
A set of conditions or actions that must be completed before advancing to the next phase (e.g., feature completion, release, sprint).
Examples: all planned tests are executed, critical bugs are resolved, monitoring is in place, sufficient automation coverage.
🔁 Common Confusion:
Often confused with Acceptance Criteria:
Exit Criteria: A QA/testing-focused gate to move forward.
Acceptance Criteria: Business/development-focused requirements for accepting a story or task.
🧭 The Problem:
Many teams treat exit criteria as a checklist — a "tick box" exercise — which leads to poor understanding and superficial QA.
✔️ Igor's Approach:
Exit criteria should be a living, collaborative tool.
Created with the entire team (devs, testers, managers) for clarity and shared responsibility.
It should reflect real quality control, not just formal documentation.
🧪 Agile & Quality Engineering Connections
🔄 Shift in Mindset:
Move from the traditional "QA owns quality" to a team-wide quality ownership model.
Shift Left approach: Developers take on unit, integration, and UI testing.
Testers become more like quality coaches/gatekeepers, focusing on strategy rather than just executing test cases.
🧱 Tools and Practices:
Exit Criteria = Acceptance Tests = Shared understanding.
Not every step is manual testing – criteria can be automated, observable, or integrated into CI/CD pipelines.
🧩 Key Takeaways:
Exit Criteria is not just technical – it's cultural.
Its real value is helping teams stop, reflect, and align.
It's about clarity, not control – knowing when a feature or release is truly ready.
Checklists are good, but only if they reflect meaningful, agreed-upon quality goals.
🧠 Final Reflections:
Exit Criteria should empower teams – not burden them.
It's not just a QA tool; it's a team alignment mechanism.
When used properly, it improves collaboration, quality ownership, and development velocity — especially in fast-paced environments like startups.
״קריטריון יציאה״ בעולם האג׳ייל עם איגור גודשמידט
🧠 Main Themes Discussed:
- The Importance of Community in QA
Igor emphasizes the role of professional communities in knowledge sharing.
He mentions the proactive involvement of the Israeli QA community, including webinars, meetups, TikTok, articles, podcasts, etc.
He presents Israeli efforts at international conferences (e.g., STQB) and notes global recognition of Israel's contributions to software testing.
- Igor's Background
Focuses on providing QA/testing frameworks for startups.
Writes articles based on real-life experience and field challenges.
Member of the international academic team of a global testing organization.
🧰 Main Topic: Exit Criteria
❓ What is Exit Criteria?
A set of conditions or actions that must be completed before advancing to the next phase (e.g., feature completion, release, sprint).
Examples: all planned tests are executed, critical bugs are resolved, monitoring is in place, sufficient automation coverage.
🔁 Common Confusion:
Often confused with Acceptance Criteria:
Exit Criteria: A QA/testing-focused gate to move forward.
Acceptance Criteria: Business/development-focused requirements for accepting a story or task.
🧭 The Problem:
Many teams treat exit criteria as a checklist — a "tick box" exercise — which leads to poor understanding and superficial QA.
✔️ Igor's Approach:
Exit criteria should be a living, collaborative tool.
Created with the entire team (devs, testers, managers) for clarity and shared responsibility.
It should reflect real quality control, not just formal documentation.
🧪 Agile & Quality Engineering Connections
🔄 Shift in Mindset:
Move from the traditional "QA owns quality" to a team-wide quality ownership model.
Shift Left approach: Developers take on unit, integration, and UI testing.
Testers become more like quality coaches/gatekeepers, focusing on strategy rather than just executing test cases.
🧱 Tools and Practices:
Exit Criteria = Acceptance Tests = Shared understanding.
Not every step is manual testing – criteria can be automated, observable, or integrated into CI/CD pipelines.
🧩 Key Takeaways:
Exit Criteria is not just technical – it's cultural.
Its real value is helping teams stop, reflect, and align.
It's about clarity, not control – knowing when a feature or release is truly ready.
Checklists are good, but only if they reflect meaningful, agreed-upon quality goals.
🧠 Final Reflections:
Exit Criteria should empower teams – not burden them.
It's not just a QA tool; it's a team alignment mechanism.
When used properly, it improves collaboration, quality ownership, and development velocity — especially in fast-paced environments like startups.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.