Software Quality Assurance and Testing English

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 01: Agreeing the expected result
Original fictional case: A fictional booking requirement says cancellation is allowed within 24 hours. One example permits cancellation exactly 24 hours before the event; another rejects it. Tester Maya and requirement owner Dev review the conflict. The equality case has not been settled. Time-zone handling is outside this discussion. Maya needs an agreed expected result before using a test to declare this exact boundary behavior correct or defective.
Language workshop: Exactly twenty-four hours: accept or reject?
Communication goal: Expose contradictory examples and obtain a clear equality rule without inventing a missing requirement.
Language guidance: The exact twenty-four-hour case has two conflicting expected outcomes. Neither the word within nor the current implementation resolves that conflict by itself. Request an explicit accept-or-reject decision for equality.
Useful expressions (preserve the supplied facts): The two examples disagree at exactly twenty-four hours. / One example allows the cancellation. / The other rejects the same case. / Should equality be accepted or rejected? / My interpretation is not yet an agreed rule. / Can the requirement owner clarify this point? / Current behavior does not settle intended behavior. / We need one expected result for this input. / I am asking about the endpoint itself. / Time-zone handling is outside this discussion. / Please update the conflicting example after the decision. / Link the test to the clarified requirement. / I cannot make a justified pass/fail judgment on this case yet. / The equality rule remains unresolved. / This is a clarification request, not a chosen outcome. / Record the intended result before finalizing the test expectation.
Vocabulary: requirement: Statement of behavior or capability the product should provide. / expected result: Outcome a test should produce under the agreed rule. / actual result: Outcome observed when the test is executed. / acceptance criterion: Condition used to judge whether a requirement is met. / ambiguity: Wording that permits more than one interpretation. / contradiction: Two statements that cannot both hold for the same case. / boundary: Point where an applicable rule or outcome changes. / equality case: Input exactly equal to the specified threshold. / inclusive limit: Limit that includes the endpoint itself. / exclusive limit: Limit that excludes the endpoint itself. / threshold: Value at which a rule changes or applies. / test oracle: Reference used to decide the expected outcome. / test basis: Information from which tests and expectations are derived. / Boolean condition: Condition with a true or false value. / business rule: Product behavior specified for a business purpose. / requirement owner: Person responsible for clarifying the relevant requirement. / decision record: Traceable statement of an agreed decision. / assumption: Belief used without current confirmation. / precondition: State required before a test action is performed. / postcondition: State expected after the relevant action. / traceability: Ability to link a test or result to its supporting requirement. / scope boundary: Limit on topics or behavior covered by the work. / pass/fail judgment: Conclusion comparing observed behavior with an agreed expectation. / clarification request: Specific question seeking missing or inconsistent information.
Speaking task: Read the two conflicting examples and the single equality question aloud. Do not choose an outcome that the case leaves unresolved. Swap roles for turns 9-16, stressing intended rule rather than current application behavior. Repeat the closing status and compare it with the brief: equality unresolved and time zones outside this discussion.
Partner: Maya: Tester / Dev: Requirement owner
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the clarification exchange without choosing the unresolved cancellation outcome.
Model for comparison AFTER my attempt, not a response to give me first: Maya: I'll link the updated expectation to that decision. Silently changing an example would hide why we chose the new outcome.
Dev: Preserve that traceability. Anyone reviewing the result should be able to see which rule was applied and why it replaced the conflicting interpretation.
Maya: For now: equality unresolved, expected result pending, time zones outside this discussion. I haven't selected accept or reject.
Dev: That is accurate. Defer the pass/fail judgment for this case until the intended outcome is recorded. The next step is a requirement decision, not an invented test result.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 01: Agreeing the expected result
Original fictional case: A fictional booking requirement says cancellation is allowed within 24 hours. One example permits cancellation exactly 24 hours before the event; another rejects it. Tester Maya and requirement owner Dev review the conflict. The equality case has not been settled. Time-zone handling is outside this discussion. Maya needs an agreed expected result before using a test to declare this exact boundary behavior correct or defective.
Language workshop: Exactly twenty-four hours: accept or reject?
Communication goal: Expose contradictory examples and obtain a clear equality rule without inventing a missing requirement.
Language guidance: The exact twenty-four-hour case has two conflicting expected outcomes. Neither the word within nor the current implementation resolves that conflict by itself. Request an explicit accept-or-reject decision for equality.
Useful expressions (preserve the supplied facts): The two examples disagree at exactly twenty-four hours. / One example allows the cancellation. / The other rejects the same case. / Should equality be accepted or rejected? / My interpretation is not yet an agreed rule. / Can the requirement owner clarify this point? / Current behavior does not settle intended behavior. / We need one expected result for this input. / I am asking about the endpoint itself. / Time-zone handling is outside this discussion. / Please update the conflicting example after the decision. / Link the test to the clarified requirement. / I cannot make a justified pass/fail judgment on this case yet. / The equality rule remains unresolved. / This is a clarification request, not a chosen outcome. / Record the intended result before finalizing the test expectation.
Vocabulary: requirement: Statement of behavior or capability the product should provide. / expected result: Outcome a test should produce under the agreed rule. / actual result: Outcome observed when the test is executed. / acceptance criterion: Condition used to judge whether a requirement is met. / ambiguity: Wording that permits more than one interpretation. / contradiction: Two statements that cannot both hold for the same case. / boundary: Point where an applicable rule or outcome changes. / equality case: Input exactly equal to the specified threshold. / inclusive limit: Limit that includes the endpoint itself. / exclusive limit: Limit that excludes the endpoint itself. / threshold: Value at which a rule changes or applies. / test oracle: Reference used to decide the expected outcome. / test basis: Information from which tests and expectations are derived. / Boolean condition: Condition with a true or false value. / business rule: Product behavior specified for a business purpose. / requirement owner: Person responsible for clarifying the relevant requirement. / decision record: Traceable statement of an agreed decision. / assumption: Belief used without current confirmation. / precondition: State required before a test action is performed. / postcondition: State expected after the relevant action. / traceability: Ability to link a test or result to its supporting requirement. / scope boundary: Limit on topics or behavior covered by the work. / pass/fail judgment: Conclusion comparing observed behavior with an agreed expectation. / clarification request: Specific question seeking missing or inconsistent information.
Speaking task: Read the two conflicting examples and the single equality question aloud. Do not choose an outcome that the case leaves unresolved. Swap roles for turns 9-16, stressing intended rule rather than current application behavior. Repeat the closing status and compare it with the brief: equality unresolved and time zones outside this discussion.
Partner: Maya: Tester / Dev: Requirement owner
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the clarification exchange without choosing the unresolved cancellation outcome.
Model for comparison AFTER my attempt, not a response to give me first: Maya: I'll link the updated expectation to that decision. Silently changing an example would hide why we chose the new outcome.
Dev: Preserve that traceability. Anyone reviewing the result should be able to see which rule was applied and why it replaced the conflicting interpretation.
Maya: For now: equality unresolved, expected result pending, time zones outside this discussion. I haven't selected accept or reject.
Dev: That is accurate. Defer the pass/fail judgment for this case until the intended outcome is recorded. The next step is a requirement decision, not an invented test result.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 01: Agreeing the expected result
Original fictional case: A fictional booking requirement says cancellation is allowed within 24 hours. One example permits cancellation exactly 24 hours before the event; another rejects it. Tester Maya and requirement owner Dev review the conflict. The equality case has not been settled. Time-zone handling is outside this discussion. Maya needs an agreed expected result before using a test to declare this exact boundary behavior correct or defective.
Language workshop: Exactly twenty-four hours: accept or reject?
Communication goal: Expose contradictory examples and obtain a clear equality rule without inventing a missing requirement.
Language guidance: The exact twenty-four-hour case has two conflicting expected outcomes. Neither the word within nor the current implementation resolves that conflict by itself. Request an explicit accept-or-reject decision for equality.
Useful expressions (preserve the supplied facts): The two examples disagree at exactly twenty-four hours. / One example allows the cancellation. / The other rejects the same case. / Should equality be accepted or rejected? / My interpretation is not yet an agreed rule. / Can the requirement owner clarify this point? / Current behavior does not settle intended behavior. / We need one expected result for this input. / I am asking about the endpoint itself. / Time-zone handling is outside this discussion. / Please update the conflicting example after the decision. / Link the test to the clarified requirement. / I cannot make a justified pass/fail judgment on this case yet. / The equality rule remains unresolved. / This is a clarification request, not a chosen outcome. / Record the intended result before finalizing the test expectation.
Vocabulary: requirement: Statement of behavior or capability the product should provide. / expected result: Outcome a test should produce under the agreed rule. / actual result: Outcome observed when the test is executed. / acceptance criterion: Condition used to judge whether a requirement is met. / ambiguity: Wording that permits more than one interpretation. / contradiction: Two statements that cannot both hold for the same case. / boundary: Point where an applicable rule or outcome changes. / equality case: Input exactly equal to the specified threshold. / inclusive limit: Limit that includes the endpoint itself. / exclusive limit: Limit that excludes the endpoint itself. / threshold: Value at which a rule changes or applies. / test oracle: Reference used to decide the expected outcome. / test basis: Information from which tests and expectations are derived. / Boolean condition: Condition with a true or false value. / business rule: Product behavior specified for a business purpose. / requirement owner: Person responsible for clarifying the relevant requirement. / decision record: Traceable statement of an agreed decision. / assumption: Belief used without current confirmation. / precondition: State required before a test action is performed. / postcondition: State expected after the relevant action. / traceability: Ability to link a test or result to its supporting requirement. / scope boundary: Limit on topics or behavior covered by the work. / pass/fail judgment: Conclusion comparing observed behavior with an agreed expectation. / clarification request: Specific question seeking missing or inconsistent information.
Speaking task: Read the two conflicting examples and the single equality question aloud. Do not choose an outcome that the case leaves unresolved. Swap roles for turns 9-16, stressing intended rule rather than current application behavior. Repeat the closing status and compare it with the brief: equality unresolved and time zones outside this discussion.
Partner: Maya: Tester / Dev: Requirement owner
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the clarification exchange without choosing the unresolved cancellation outcome.
Model for comparison AFTER my attempt, not a response to give me first: Maya: I'll link the updated expectation to that decision. Silently changing an example would hide why we chose the new outcome.
Dev: Preserve that traceability. Anyone reviewing the result should be able to see which rule was applied and why it replaced the conflicting interpretation.
Maya: For now: equality unresolved, expected result pending, time zones outside this discussion. I haven't selected accept or reject.
Dev: That is accurate. Defer the pass/fail judgment for this case until the intended outcome is recorded. The next step is a requirement decision, not an invented test result.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 02: Making a failure reproducible
Original fictional case: On fictional build Q12, tester Hana exports a saved selection of three items. The output omits the last selected item. She observes the omission in two attempts out of two. Developer Joel exports one item successfully. No other build or selection size has been checked. They compare conditions and prepare a handoff using the saved three-item selection, the export action, and the observed output without claiming every export fails.
Language workshop: Three selected, two exported, twice
Communication goal: Give a reproducible defect report and explain why a successful attempt with different input does not disprove it.
Language guidance: Two out of two describes Hana's observed attempts with the saved three-item selection on Q12. It is not a universal failure rate for every input, every session, or every build.
Useful expressions (preserve the supplied facts): I observed this on Q12. / I used the saved selection of three items. / I exported that selection. / The last selected item is missing from the output. / It occurred in two attempts out of two. / I have not tested other builds. / Your one-item attempt succeeded. / That uses a different selection size. / Please use the same saved selection. / The one-item result does not disprove this report. / I will attach the selection and actual output. / Follow the recorded action sequence. / Other selection sizes remain unchecked. / I am not claiming that every export fails. / Report the result with the same input and build. / The report includes the conditions, omission, and observed frequency.
Vocabulary: defect report: Record describing a suspected or confirmed product problem. / build identifier: Label identifying the software version under test. / reproduction steps: Ordered actions used to observe a reported problem. / saved selection: Retained set of items used as input. / test fixture: Prepared data or state for a test. / actual output: Data or behavior produced by the executed operation. / expected output: Data or behavior required for the test to pass. / omission: Absence of something that should be included. / selection size: Number of items included in the chosen input. / reproduction frequency: Observed failures relative to stated attempts and conditions. / denominator: Total count against which a proportion is measured. / environment detail: Relevant setting or configuration for an observation. / mutation testing: Checking test sensitivity using deliberately modified program variants. / evidence bundle: Group of supporting records for an investigation. / equivalent mutant: Modified variant with the same observable behavior for the relevant domain. / log excerpt: Relevant portion of recorded system events. / minimal reproduction: Smallest useful example retaining the observed problem. / counterexample: Example contradicting a universal claim under its relevant terms. / scope of evidence: Range of conditions actually supported by observations. / unverified condition: Condition whose behavior has not been checked. / reproduction run: Repeat intended to check the reported behavior. / input parity: Use of matching input in a comparison. / cannot reproduce: Status indicating failure to observe the report under stated attempts. / handoff note: Concise record transferring evidence and next steps.
Speaking task: Read the failure report using the actual build, saved selection, missing item, and two-out-of-two frequency. Swap roles for turns 3-10. Keep different input separate from a reproduction of the reported failure. Check the final handoff against turns 17-20. Include the saved evidence and untested conditions without guessing the cause.
Partner: Hana: Tester reporting the omission / Joel: Developer investigating the report
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the report using only the observed build, input, output, and frequency.
Model for comparison AFTER my attempt, not a response to give me first: Hana: If you reduce the input and the same omission remains, record that smaller case. We don't yet know the smallest failing selection.
Joel: That would establish a minimal reproduction. I'll start with the known saved selection before trying to remove anything from it.
Hana: My handoff will include both observations and the exact reproducer, with two attempts out of two and untested conditions listed.
Joel: That's the evidence bundle I need. I'll return the result under those conditions, not another unqualified cannot-reproduce label.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 02: Making a failure reproducible
Original fictional case: On fictional build Q12, tester Hana exports a saved selection of three items. The output omits the last selected item. She observes the omission in two attempts out of two. Developer Joel exports one item successfully. No other build or selection size has been checked. They compare conditions and prepare a handoff using the saved three-item selection, the export action, and the observed output without claiming every export fails.
Language workshop: Three selected, two exported, twice
Communication goal: Give a reproducible defect report and explain why a successful attempt with different input does not disprove it.
Language guidance: Two out of two describes Hana's observed attempts with the saved three-item selection on Q12. It is not a universal failure rate for every input, every session, or every build.
Useful expressions (preserve the supplied facts): I observed this on Q12. / I used the saved selection of three items. / I exported that selection. / The last selected item is missing from the output. / It occurred in two attempts out of two. / I have not tested other builds. / Your one-item attempt succeeded. / That uses a different selection size. / Please use the same saved selection. / The one-item result does not disprove this report. / I will attach the selection and actual output. / Follow the recorded action sequence. / Other selection sizes remain unchecked. / I am not claiming that every export fails. / Report the result with the same input and build. / The report includes the conditions, omission, and observed frequency.
Vocabulary: defect report: Record describing a suspected or confirmed product problem. / build identifier: Label identifying the software version under test. / reproduction steps: Ordered actions used to observe a reported problem. / saved selection: Retained set of items used as input. / test fixture: Prepared data or state for a test. / actual output: Data or behavior produced by the executed operation. / expected output: Data or behavior required for the test to pass. / omission: Absence of something that should be included. / selection size: Number of items included in the chosen input. / reproduction frequency: Observed failures relative to stated attempts and conditions. / denominator: Total count against which a proportion is measured. / environment detail: Relevant setting or configuration for an observation. / mutation testing: Checking test sensitivity using deliberately modified program variants. / evidence bundle: Group of supporting records for an investigation. / equivalent mutant: Modified variant with the same observable behavior for the relevant domain. / log excerpt: Relevant portion of recorded system events. / minimal reproduction: Smallest useful example retaining the observed problem. / counterexample: Example contradicting a universal claim under its relevant terms. / scope of evidence: Range of conditions actually supported by observations. / unverified condition: Condition whose behavior has not been checked. / reproduction run: Repeat intended to check the reported behavior. / input parity: Use of matching input in a comparison. / cannot reproduce: Status indicating failure to observe the report under stated attempts. / handoff note: Concise record transferring evidence and next steps.
Speaking task: Read the failure report using the actual build, saved selection, missing item, and two-out-of-two frequency. Swap roles for turns 3-10. Keep different input separate from a reproduction of the reported failure. Check the final handoff against turns 17-20. Include the saved evidence and untested conditions without guessing the cause.
Partner: Hana: Tester reporting the omission / Joel: Developer investigating the report
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the report using only the observed build, input, output, and frequency.
Model for comparison AFTER my attempt, not a response to give me first: Hana: If you reduce the input and the same omission remains, record that smaller case. We don't yet know the smallest failing selection.
Joel: That would establish a minimal reproduction. I'll start with the known saved selection before trying to remove anything from it.
Hana: My handoff will include both observations and the exact reproducer, with two attempts out of two and untested conditions listed.
Joel: That's the evidence bundle I need. I'll return the result under those conditions, not another unqualified cannot-reproduce label.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 02: Making a failure reproducible
Original fictional case: On fictional build Q12, tester Hana exports a saved selection of three items. The output omits the last selected item. She observes the omission in two attempts out of two. Developer Joel exports one item successfully. No other build or selection size has been checked. They compare conditions and prepare a handoff using the saved three-item selection, the export action, and the observed output without claiming every export fails.
Language workshop: Three selected, two exported, twice
Communication goal: Give a reproducible defect report and explain why a successful attempt with different input does not disprove it.
Language guidance: Two out of two describes Hana's observed attempts with the saved three-item selection on Q12. It is not a universal failure rate for every input, every session, or every build.
Useful expressions (preserve the supplied facts): I observed this on Q12. / I used the saved selection of three items. / I exported that selection. / The last selected item is missing from the output. / It occurred in two attempts out of two. / I have not tested other builds. / Your one-item attempt succeeded. / That uses a different selection size. / Please use the same saved selection. / The one-item result does not disprove this report. / I will attach the selection and actual output. / Follow the recorded action sequence. / Other selection sizes remain unchecked. / I am not claiming that every export fails. / Report the result with the same input and build. / The report includes the conditions, omission, and observed frequency.
Vocabulary: defect report: Record describing a suspected or confirmed product problem. / build identifier: Label identifying the software version under test. / reproduction steps: Ordered actions used to observe a reported problem. / saved selection: Retained set of items used as input. / test fixture: Prepared data or state for a test. / actual output: Data or behavior produced by the executed operation. / expected output: Data or behavior required for the test to pass. / omission: Absence of something that should be included. / selection size: Number of items included in the chosen input. / reproduction frequency: Observed failures relative to stated attempts and conditions. / denominator: Total count against which a proportion is measured. / environment detail: Relevant setting or configuration for an observation. / mutation testing: Checking test sensitivity using deliberately modified program variants. / evidence bundle: Group of supporting records for an investigation. / equivalent mutant: Modified variant with the same observable behavior for the relevant domain. / log excerpt: Relevant portion of recorded system events. / minimal reproduction: Smallest useful example retaining the observed problem. / counterexample: Example contradicting a universal claim under its relevant terms. / scope of evidence: Range of conditions actually supported by observations. / unverified condition: Condition whose behavior has not been checked. / reproduction run: Repeat intended to check the reported behavior. / input parity: Use of matching input in a comparison. / cannot reproduce: Status indicating failure to observe the report under stated attempts. / handoff note: Concise record transferring evidence and next steps.
Speaking task: Read the failure report using the actual build, saved selection, missing item, and two-out-of-two frequency. Swap roles for turns 3-10. Keep different input separate from a reproduction of the reported failure. Check the final handoff against turns 17-20. Include the saved evidence and untested conditions without guessing the cause.
Partner: Hana: Tester reporting the omission / Joel: Developer investigating the report
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the report using only the observed build, input, output, and frequency.
Model for comparison AFTER my attempt, not a response to give me first: Hana: If you reduce the input and the same omission remains, record that smaller case. We don't yet know the smallest failing selection.
Joel: That would establish a minimal reproduction. I'll start with the known saved selection before trying to remove anything from it.
Hana: My handoff will include both observations and the exact reproducer, with two attempts out of two and untested conditions listed.
Joel: That's the evidence bundle I need. I'll return the result under those conditions, not another unqualified cannot-reproduce label.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 03: Choosing cases at boundaries and across rules
Original fictional case: A fictional quantity form accepts whole numbers from 1 through 20 inclusive and rejects whole-number values outside that range. The proposed tests use only 5, 10, and 15. Tester Rosa and developer Amir review the gap. They propose boundary-focused values 0, 1, 2, 19, 20, and 21. Decimal handling is unspecified and outside the stated whole-number rule. The new tests are proposed, not executed results.
Language workshop: Five, ten, and fifteen never touch the limits
Communication goal: Explain missing boundary and rejection coverage while keeping unspecified decimal behavior separate from the whole-number rule.
Language guidance: One and twenty are accepted endpoints. Zero and twenty-one are adjacent rejected whole-number values. Two and nineteen check just inside the range. The existing five, ten, and fifteen do not test these edges.
Useful expressions (preserve the supplied facts): The rule concerns whole-number quantities. / One through twenty are accepted, including both endpoints. / Five, ten, and fifteen are interior values. / One should be accepted. / Zero should be rejected. / Twenty should be accepted. / Twenty-one should be rejected. / Two and nineteen check just inside the limits. / The current set never reaches either boundary. / Each added value tests a specific edge condition. / These are expected outcomes, not completed test results. / Decimal handling is not specified. / We have no agreed rounding rule. / Ask for the decimal policy separately. / Boundary cases improve coverage but do not prove the form defect-free. / Add the six boundary-focused cases and retain their expected outcomes.
Vocabulary: boundary value: Input at an edge where a rule changes. / boundary value analysis: Test design concentrating on rule edges and nearby values. / equivalence partition: Group of inputs expected to follow the same relevant rule. / valid partition: Input group accepted under the specified rule. / invalid partition: Input group rejected under the specified rule. / lower bound: Smallest value within a defined range. / upper bound: Largest value within a defined range. / inclusive range: Range containing both stated endpoints. / whole number: Number without a fractional part in the stated quantity context. / adjacent value: Nearest relevant value beside a boundary. / interior value: Input strictly between the relevant endpoints. / off-by-one error: Mistake that shifts a count or boundary by one unit. / acceptance region: Set of inputs the stated rule accepts. / rejection region: Set of inputs the stated rule rejects. / input domain: Set of inputs relevant to the defined problem. / decimal input: Input containing a fractional numeric value. / validation message: User-facing message explaining an input condition. / test case: Defined input, action, and expected outcome for a check. / case selection: Choice of checks to cover relevant behavior. / coverage item: Rule, value, or condition counted in a coverage assessment. / decision rule: Condition-to-outcome relationship. / decision table: Organized mapping of condition combinations to outcomes. / out-of-range value: Input below or above the accepted range. / unspecified behavior: Behavior for which no governing rule is supplied.
Speaking task: Read the six proposed boundary values in order, with their expected accept or reject results. Swap roles for turns 9-16. Stress should accept rather than passed, and keep decimal handling unresolved. Compare the final proposal with the brief: both endpoints and immediate neighbors, with no invented execution result.
Partner: Rosa: Tester reviewing case selection / Amir: Developer discussing the rule
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the expected-result exchange. These expectations come from the stated rule, not from completed test runs.
Model for comparison AFTER my attempt, not a response to give me first: Rosa: We can retain useful interior cases, but their count won't establish edge coverage. Three central examples still miss both endpoints.
Amir: Correct. Case selection is about the conditions exercised, not simply having several numbers in a list. The current values all occupy the interior.
Rosa: I'll submit the six cases and expected outcomes as a proposal, not a pass report. The separate decimal question remains open.
Amir: That is accurate coverage language. It improves the design while keeping both execution status and the missing decimal rule visible to the team.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 03: Choosing cases at boundaries and across rules
Original fictional case: A fictional quantity form accepts whole numbers from 1 through 20 inclusive and rejects whole-number values outside that range. The proposed tests use only 5, 10, and 15. Tester Rosa and developer Amir review the gap. They propose boundary-focused values 0, 1, 2, 19, 20, and 21. Decimal handling is unspecified and outside the stated whole-number rule. The new tests are proposed, not executed results.
Language workshop: Five, ten, and fifteen never touch the limits
Communication goal: Explain missing boundary and rejection coverage while keeping unspecified decimal behavior separate from the whole-number rule.
Language guidance: One and twenty are accepted endpoints. Zero and twenty-one are adjacent rejected whole-number values. Two and nineteen check just inside the range. The existing five, ten, and fifteen do not test these edges.
Useful expressions (preserve the supplied facts): The rule concerns whole-number quantities. / One through twenty are accepted, including both endpoints. / Five, ten, and fifteen are interior values. / One should be accepted. / Zero should be rejected. / Twenty should be accepted. / Twenty-one should be rejected. / Two and nineteen check just inside the limits. / The current set never reaches either boundary. / Each added value tests a specific edge condition. / These are expected outcomes, not completed test results. / Decimal handling is not specified. / We have no agreed rounding rule. / Ask for the decimal policy separately. / Boundary cases improve coverage but do not prove the form defect-free. / Add the six boundary-focused cases and retain their expected outcomes.
Vocabulary: boundary value: Input at an edge where a rule changes. / boundary value analysis: Test design concentrating on rule edges and nearby values. / equivalence partition: Group of inputs expected to follow the same relevant rule. / valid partition: Input group accepted under the specified rule. / invalid partition: Input group rejected under the specified rule. / lower bound: Smallest value within a defined range. / upper bound: Largest value within a defined range. / inclusive range: Range containing both stated endpoints. / whole number: Number without a fractional part in the stated quantity context. / adjacent value: Nearest relevant value beside a boundary. / interior value: Input strictly between the relevant endpoints. / off-by-one error: Mistake that shifts a count or boundary by one unit. / acceptance region: Set of inputs the stated rule accepts. / rejection region: Set of inputs the stated rule rejects. / input domain: Set of inputs relevant to the defined problem. / decimal input: Input containing a fractional numeric value. / validation message: User-facing message explaining an input condition. / test case: Defined input, action, and expected outcome for a check. / case selection: Choice of checks to cover relevant behavior. / coverage item: Rule, value, or condition counted in a coverage assessment. / decision rule: Condition-to-outcome relationship. / decision table: Organized mapping of condition combinations to outcomes. / out-of-range value: Input below or above the accepted range. / unspecified behavior: Behavior for which no governing rule is supplied.
Speaking task: Read the six proposed boundary values in order, with their expected accept or reject results. Swap roles for turns 9-16. Stress should accept rather than passed, and keep decimal handling unresolved. Compare the final proposal with the brief: both endpoints and immediate neighbors, with no invented execution result.
Partner: Rosa: Tester reviewing case selection / Amir: Developer discussing the rule
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the expected-result exchange. These expectations come from the stated rule, not from completed test runs.
Model for comparison AFTER my attempt, not a response to give me first: Rosa: We can retain useful interior cases, but their count won't establish edge coverage. Three central examples still miss both endpoints.
Amir: Correct. Case selection is about the conditions exercised, not simply having several numbers in a list. The current values all occupy the interior.
Rosa: I'll submit the six cases and expected outcomes as a proposal, not a pass report. The separate decimal question remains open.
Amir: That is accurate coverage language. It improves the design while keeping both execution status and the missing decimal rule visible to the team.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 03: Choosing cases at boundaries and across rules
Original fictional case: A fictional quantity form accepts whole numbers from 1 through 20 inclusive and rejects whole-number values outside that range. The proposed tests use only 5, 10, and 15. Tester Rosa and developer Amir review the gap. They propose boundary-focused values 0, 1, 2, 19, 20, and 21. Decimal handling is unspecified and outside the stated whole-number rule. The new tests are proposed, not executed results.
Language workshop: Five, ten, and fifteen never touch the limits
Communication goal: Explain missing boundary and rejection coverage while keeping unspecified decimal behavior separate from the whole-number rule.
Language guidance: One and twenty are accepted endpoints. Zero and twenty-one are adjacent rejected whole-number values. Two and nineteen check just inside the range. The existing five, ten, and fifteen do not test these edges.
Useful expressions (preserve the supplied facts): The rule concerns whole-number quantities. / One through twenty are accepted, including both endpoints. / Five, ten, and fifteen are interior values. / One should be accepted. / Zero should be rejected. / Twenty should be accepted. / Twenty-one should be rejected. / Two and nineteen check just inside the limits. / The current set never reaches either boundary. / Each added value tests a specific edge condition. / These are expected outcomes, not completed test results. / Decimal handling is not specified. / We have no agreed rounding rule. / Ask for the decimal policy separately. / Boundary cases improve coverage but do not prove the form defect-free. / Add the six boundary-focused cases and retain their expected outcomes.
Vocabulary: boundary value: Input at an edge where a rule changes. / boundary value analysis: Test design concentrating on rule edges and nearby values. / equivalence partition: Group of inputs expected to follow the same relevant rule. / valid partition: Input group accepted under the specified rule. / invalid partition: Input group rejected under the specified rule. / lower bound: Smallest value within a defined range. / upper bound: Largest value within a defined range. / inclusive range: Range containing both stated endpoints. / whole number: Number without a fractional part in the stated quantity context. / adjacent value: Nearest relevant value beside a boundary. / interior value: Input strictly between the relevant endpoints. / off-by-one error: Mistake that shifts a count or boundary by one unit. / acceptance region: Set of inputs the stated rule accepts. / rejection region: Set of inputs the stated rule rejects. / input domain: Set of inputs relevant to the defined problem. / decimal input: Input containing a fractional numeric value. / validation message: User-facing message explaining an input condition. / test case: Defined input, action, and expected outcome for a check. / case selection: Choice of checks to cover relevant behavior. / coverage item: Rule, value, or condition counted in a coverage assessment. / decision rule: Condition-to-outcome relationship. / decision table: Organized mapping of condition combinations to outcomes. / out-of-range value: Input below or above the accepted range. / unspecified behavior: Behavior for which no governing rule is supplied.
Speaking task: Read the six proposed boundary values in order, with their expected accept or reject results. Swap roles for turns 9-16. Stress should accept rather than passed, and keep decimal handling unresolved. Compare the final proposal with the brief: both endpoints and immediate neighbors, with no invented execution result.
Partner: Rosa: Tester reviewing case selection / Amir: Developer discussing the rule
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the expected-result exchange. These expectations come from the stated rule, not from completed test runs.
Model for comparison AFTER my attempt, not a response to give me first: Rosa: We can retain useful interior cases, but their count won't establish edge coverage. Three central examples still miss both endpoints.
Amir: Correct. Case selection is about the conditions exercised, not simply having several numbers in a list. The current values all occupy the interior.
Rosa: I'll submit the six cases and expected outcomes as a proposal, not a pass report. The separate decimal question remains open.
Amir: That is accurate coverage language. It improves the design while keeping both execution status and the missing decimal rule visible to the team.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 04: Explaining coverage and change risk
Original fictional case: A fictional account update passes a smoke test that signs in and opens the account page. The update changes a formatter used by account-save and by the existing export path. Neither of those paths has been tested. Tester Elena and team lead Sam have one hour for further checking. They need to prioritize evidence around the shared change without claiming full coverage or assuming the existing export path is unaffected.
Language workshop: The account page opens; the changed paths are unchecked
Communication goal: Explain limited smoke-test evidence and justify focused follow-up on both consumers of a changed formatter.
Language guidance: Opening the account page does not establish correct account-save formatting, and it does not exercise export. Both use the changed formatter. Existing behavior can need regression checking even when the visible update is described as an account change.
Useful expressions (preserve the supplied facts): Sign-in and opening the account page passed. / The shared formatter changed. / Account-save and export use that formatter. / Neither consumer path has been tested. / An account update can still affect export. / I would focus the next checks on the changed component's consumers. / We have one hour for further checking. / Those checks are planned, not completed. / Check the formatted result in each consumer path. / A smoke pass is not full regression coverage. / Export behavior after this change remains unverified. / List which checks ran and their results. / Keep any untested path visible. / The summary can support a recommendation without proving every risk absent. / There will still be residual risk. / Prioritize both affected paths and report the limits of the hour's work.
Vocabulary: smoke test: Small check set used to detect major basic failures. / regression testing: Checking existing behavior for problems introduced by change. / change impact: Potential effect of a modification on related behavior. / shared component: Component used by more than one path or feature. / formatter: Component converting values into a required representation. / consumer path: Execution route using a shared component. / account-save path: Route that persists an account update. / export path: Route producing output for external use. / coverage gap: Relevant behavior not yet checked. / risk-based testing: Selection of tests according to relevant likelihood and impact concerns. / test priority: Relative order or urgency assigned to checks. / timebox: Fixed amount of time allocated to work. / residual risk: Risk remaining after the checks or controls performed. / test scope: Behavior and conditions included in the checking effort. / execution evidence: Record of checks actually run and their results. / untested path: Execution route with no relevant test result yet. / dependency mapping: Identification of relationships between components and consumers. / functional impact: Effect on what users or systems can do. / test objective: Purpose a particular check is meant to serve. / selection rationale: Reason for choosing particular checks. / coverage claim: Statement about what the tests have exercised. / test summary: Concise account of scope, results, and limits. / branch coverage: Proportion of defined control-flow branches exercised by tests. / release recommendation: Evidence-based advice about proceeding with a release.
Speaking task: Read the narrow smoke result and identify both consumers of the changed formatter. Swap roles for turns 7-14. Keep the one-hour plan separate from completed execution evidence. Repeat the closing update, retaining both untested paths and the limit on coverage.
Partner: Elena: Tester / Sam: Team lead
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the testing update before the proposed follow-up checks have run.
Model for comparison AFTER my attempt, not a response to give me first: Elena: I'll also check the content, not merely that Save or Export can be clicked. Otherwise we'd repeat the smoke-test limitation.
Sam: Exactly. The test objective is the changed formatting behavior in each path. Make the assertion answer that question.
Elena: Current update: narrow smoke pass, save and export untested, shared formatter changed, one hour available, focused follow-up proposed.
Sam: That's an accurate test summary. The subsequent evidence can inform a recommendation without implying that every risk or release question is settled.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 04: Explaining coverage and change risk
Original fictional case: A fictional account update passes a smoke test that signs in and opens the account page. The update changes a formatter used by account-save and by the existing export path. Neither of those paths has been tested. Tester Elena and team lead Sam have one hour for further checking. They need to prioritize evidence around the shared change without claiming full coverage or assuming the existing export path is unaffected.
Language workshop: The account page opens; the changed paths are unchecked
Communication goal: Explain limited smoke-test evidence and justify focused follow-up on both consumers of a changed formatter.
Language guidance: Opening the account page does not establish correct account-save formatting, and it does not exercise export. Both use the changed formatter. Existing behavior can need regression checking even when the visible update is described as an account change.
Useful expressions (preserve the supplied facts): Sign-in and opening the account page passed. / The shared formatter changed. / Account-save and export use that formatter. / Neither consumer path has been tested. / An account update can still affect export. / I would focus the next checks on the changed component's consumers. / We have one hour for further checking. / Those checks are planned, not completed. / Check the formatted result in each consumer path. / A smoke pass is not full regression coverage. / Export behavior after this change remains unverified. / List which checks ran and their results. / Keep any untested path visible. / The summary can support a recommendation without proving every risk absent. / There will still be residual risk. / Prioritize both affected paths and report the limits of the hour's work.
Vocabulary: smoke test: Small check set used to detect major basic failures. / regression testing: Checking existing behavior for problems introduced by change. / change impact: Potential effect of a modification on related behavior. / shared component: Component used by more than one path or feature. / formatter: Component converting values into a required representation. / consumer path: Execution route using a shared component. / account-save path: Route that persists an account update. / export path: Route producing output for external use. / coverage gap: Relevant behavior not yet checked. / risk-based testing: Selection of tests according to relevant likelihood and impact concerns. / test priority: Relative order or urgency assigned to checks. / timebox: Fixed amount of time allocated to work. / residual risk: Risk remaining after the checks or controls performed. / test scope: Behavior and conditions included in the checking effort. / execution evidence: Record of checks actually run and their results. / untested path: Execution route with no relevant test result yet. / dependency mapping: Identification of relationships between components and consumers. / functional impact: Effect on what users or systems can do. / test objective: Purpose a particular check is meant to serve. / selection rationale: Reason for choosing particular checks. / coverage claim: Statement about what the tests have exercised. / test summary: Concise account of scope, results, and limits. / branch coverage: Proportion of defined control-flow branches exercised by tests. / release recommendation: Evidence-based advice about proceeding with a release.
Speaking task: Read the narrow smoke result and identify both consumers of the changed formatter. Swap roles for turns 7-14. Keep the one-hour plan separate from completed execution evidence. Repeat the closing update, retaining both untested paths and the limit on coverage.
Partner: Elena: Tester / Sam: Team lead
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the testing update before the proposed follow-up checks have run.
Model for comparison AFTER my attempt, not a response to give me first: Elena: I'll also check the content, not merely that Save or Export can be clicked. Otherwise we'd repeat the smoke-test limitation.
Sam: Exactly. The test objective is the changed formatting behavior in each path. Make the assertion answer that question.
Elena: Current update: narrow smoke pass, save and export untested, shared formatter changed, one hour available, focused follow-up proposed.
Sam: That's an accurate test summary. The subsequent evidence can inform a recommendation without implying that every risk or release question is settled.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 04: Explaining coverage and change risk
Original fictional case: A fictional account update passes a smoke test that signs in and opens the account page. The update changes a formatter used by account-save and by the existing export path. Neither of those paths has been tested. Tester Elena and team lead Sam have one hour for further checking. They need to prioritize evidence around the shared change without claiming full coverage or assuming the existing export path is unaffected.
Language workshop: The account page opens; the changed paths are unchecked
Communication goal: Explain limited smoke-test evidence and justify focused follow-up on both consumers of a changed formatter.
Language guidance: Opening the account page does not establish correct account-save formatting, and it does not exercise export. Both use the changed formatter. Existing behavior can need regression checking even when the visible update is described as an account change.
Useful expressions (preserve the supplied facts): Sign-in and opening the account page passed. / The shared formatter changed. / Account-save and export use that formatter. / Neither consumer path has been tested. / An account update can still affect export. / I would focus the next checks on the changed component's consumers. / We have one hour for further checking. / Those checks are planned, not completed. / Check the formatted result in each consumer path. / A smoke pass is not full regression coverage. / Export behavior after this change remains unverified. / List which checks ran and their results. / Keep any untested path visible. / The summary can support a recommendation without proving every risk absent. / There will still be residual risk. / Prioritize both affected paths and report the limits of the hour's work.
Vocabulary: smoke test: Small check set used to detect major basic failures. / regression testing: Checking existing behavior for problems introduced by change. / change impact: Potential effect of a modification on related behavior. / shared component: Component used by more than one path or feature. / formatter: Component converting values into a required representation. / consumer path: Execution route using a shared component. / account-save path: Route that persists an account update. / export path: Route producing output for external use. / coverage gap: Relevant behavior not yet checked. / risk-based testing: Selection of tests according to relevant likelihood and impact concerns. / test priority: Relative order or urgency assigned to checks. / timebox: Fixed amount of time allocated to work. / residual risk: Risk remaining after the checks or controls performed. / test scope: Behavior and conditions included in the checking effort. / execution evidence: Record of checks actually run and their results. / untested path: Execution route with no relevant test result yet. / dependency mapping: Identification of relationships between components and consumers. / functional impact: Effect on what users or systems can do. / test objective: Purpose a particular check is meant to serve. / selection rationale: Reason for choosing particular checks. / coverage claim: Statement about what the tests have exercised. / test summary: Concise account of scope, results, and limits. / branch coverage: Proportion of defined control-flow branches exercised by tests. / release recommendation: Evidence-based advice about proceeding with a release.
Speaking task: Read the narrow smoke result and identify both consumers of the changed formatter. Swap roles for turns 7-14. Keep the one-hour plan separate from completed execution evidence. Repeat the closing update, retaining both untested paths and the limit on coverage.
Partner: Elena: Tester / Sam: Team lead
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the testing update before the proposed follow-up checks have run.
Model for comparison AFTER my attempt, not a response to give me first: Elena: I'll also check the content, not merely that Save or Export can be clicked. Otherwise we'd repeat the smoke-test limitation.
Sam: Exactly. The test objective is the changed formatting behavior in each path. Make the assertion answer that question.
Elena: Current update: narrow smoke pass, save and export untested, shared formatter changed, one hour available, focused follow-up proposed.
Sam: That's an accurate test summary. The subsequent evidence can inform a recommendation without implying that every risk or release question is settled.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 05: Investigating inconsistent automated results
Original fictional case: On fictional build T8, an automated search check fails when it follows a cleanup check but passes when run alone. The cleanup removes a shared sample record that search expects. No code change occurs between these observations. Automation engineer Noah and tester Aisha compare the starting state and execution order. They need to remove the shared-data interference and verify the revised arrangement rather than simply rerun until the suite appears green.
Language workshop: Cleanup deletes what search expects
Communication goal: Describe an order-dependent automated failure and request isolated test data instead of treating reruns as a fix.
Language guidance: The search result differs with test order because cleanup removes its expected sample record. No code change is needed for this interference to matter. Compare the starting state, not just the build identifier.
Useful expressions (preserve the supplied facts): Both observations are on T8. / Search fails after cleanup. / Search passes when run alone. / No code changed between those observations. / Both checks depend on the sample record's state. / Cleanup removes the record search expects. / The observed pattern is order-dependent. / Was the required record present when search began? / A passing rerun does not fix isolation. / Which check creates and removes this record? / Give the checks independent data or a defined setup. / Keep the failed sequence and logs. / Do not remove the assertion merely to get green. / Check the revised arrangement in the relevant sequence. / The standalone pass does not prove the suite is reliable. / Resolve shared-data ownership and verify the resulting behavior.
Vocabulary: flaky test: Test showing inconsistent outcomes under apparently similar conditions. / order dependency: Dependence of a result on the sequence of test execution. / shared fixture: Prepared data or state used by multiple checks. / setup: Preparation establishing a test's starting conditions. / teardown: Work restoring or removing state after a test. / cleanup: Removal of data or resources no longer needed by a check. / test isolation: Independence of a test from other tests' state changes. / state leakage: Unintended influence of one test's state on another. / sample record: Prepared data item used for testing. / precondition: Required state before a check starts. / execution order: Sequence in which checks run. / standalone run: Execution of a check without the surrounding suite. / suite run: Execution of a group of related checks. / rerun: Another execution of an existing check. / false alarm: Failure signal not caused by the claimed product defect. / failure evidence: Records supporting an observed unsuccessful result. / test data ownership: Responsibility for creating and removing test records. / unique test data: Data assigned specifically to one test or execution. / deterministic setup: Preparation that establishes predictable required conditions. / environment state: Relevant current conditions in the test setting. / interference: Effect of one check on another's operation. / quarantine: Temporary separation of an unreliable check under a defined policy. / continuous integration: Frequent integration with automated checking; abbreviated CI. / verification run: Execution used to check whether a proposed correction works.
Speaking task: Read the two T8 outcomes with their execution order and starting data state. Swap roles for turns 7-16. Stress ownership of the sample record and preserving the search assertion. Compare the final report with the brief. The data arrangement is proposed, not yet verified.
Partner: Noah: Automation engineer / Aisha: Tester
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the automation report using the observed order and shared-record facts.
Model for comparison AFTER my attempt, not a response to give me first: Noah: After the revision, I'll run cleanup then search, as well as search alone, and capture the starting data and actual results.
Aisha: The verification run needs that original sequence. A standalone pass alone would leave the reported interaction unverified.
Noah: My handoff will show T8, unchanged code, deletion of the expected record, and the two observed outcomes. The revised arrangement is not yet verified.
Aisha: That names the environment state precisely. We can investigate the actual dependency instead of calling the result random and moving on.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 05: Investigating inconsistent automated results
Original fictional case: On fictional build T8, an automated search check fails when it follows a cleanup check but passes when run alone. The cleanup removes a shared sample record that search expects. No code change occurs between these observations. Automation engineer Noah and tester Aisha compare the starting state and execution order. They need to remove the shared-data interference and verify the revised arrangement rather than simply rerun until the suite appears green.
Language workshop: Cleanup deletes what search expects
Communication goal: Describe an order-dependent automated failure and request isolated test data instead of treating reruns as a fix.
Language guidance: The search result differs with test order because cleanup removes its expected sample record. No code change is needed for this interference to matter. Compare the starting state, not just the build identifier.
Useful expressions (preserve the supplied facts): Both observations are on T8. / Search fails after cleanup. / Search passes when run alone. / No code changed between those observations. / Both checks depend on the sample record's state. / Cleanup removes the record search expects. / The observed pattern is order-dependent. / Was the required record present when search began? / A passing rerun does not fix isolation. / Which check creates and removes this record? / Give the checks independent data or a defined setup. / Keep the failed sequence and logs. / Do not remove the assertion merely to get green. / Check the revised arrangement in the relevant sequence. / The standalone pass does not prove the suite is reliable. / Resolve shared-data ownership and verify the resulting behavior.
Vocabulary: flaky test: Test showing inconsistent outcomes under apparently similar conditions. / order dependency: Dependence of a result on the sequence of test execution. / shared fixture: Prepared data or state used by multiple checks. / setup: Preparation establishing a test's starting conditions. / teardown: Work restoring or removing state after a test. / cleanup: Removal of data or resources no longer needed by a check. / test isolation: Independence of a test from other tests' state changes. / state leakage: Unintended influence of one test's state on another. / sample record: Prepared data item used for testing. / precondition: Required state before a check starts. / execution order: Sequence in which checks run. / standalone run: Execution of a check without the surrounding suite. / suite run: Execution of a group of related checks. / rerun: Another execution of an existing check. / false alarm: Failure signal not caused by the claimed product defect. / failure evidence: Records supporting an observed unsuccessful result. / test data ownership: Responsibility for creating and removing test records. / unique test data: Data assigned specifically to one test or execution. / deterministic setup: Preparation that establishes predictable required conditions. / environment state: Relevant current conditions in the test setting. / interference: Effect of one check on another's operation. / quarantine: Temporary separation of an unreliable check under a defined policy. / continuous integration: Frequent integration with automated checking; abbreviated CI. / verification run: Execution used to check whether a proposed correction works.
Speaking task: Read the two T8 outcomes with their execution order and starting data state. Swap roles for turns 7-16. Stress ownership of the sample record and preserving the search assertion. Compare the final report with the brief. The data arrangement is proposed, not yet verified.
Partner: Noah: Automation engineer / Aisha: Tester
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the automation report using the observed order and shared-record facts.
Model for comparison AFTER my attempt, not a response to give me first: Noah: After the revision, I'll run cleanup then search, as well as search alone, and capture the starting data and actual results.
Aisha: The verification run needs that original sequence. A standalone pass alone would leave the reported interaction unverified.
Noah: My handoff will show T8, unchanged code, deletion of the expected record, and the two observed outcomes. The revised arrangement is not yet verified.
Aisha: That names the environment state precisely. We can investigate the actual dependency instead of calling the result random and moving on.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 05: Investigating inconsistent automated results
Original fictional case: On fictional build T8, an automated search check fails when it follows a cleanup check but passes when run alone. The cleanup removes a shared sample record that search expects. No code change occurs between these observations. Automation engineer Noah and tester Aisha compare the starting state and execution order. They need to remove the shared-data interference and verify the revised arrangement rather than simply rerun until the suite appears green.
Language workshop: Cleanup deletes what search expects
Communication goal: Describe an order-dependent automated failure and request isolated test data instead of treating reruns as a fix.
Language guidance: The search result differs with test order because cleanup removes its expected sample record. No code change is needed for this interference to matter. Compare the starting state, not just the build identifier.
Useful expressions (preserve the supplied facts): Both observations are on T8. / Search fails after cleanup. / Search passes when run alone. / No code changed between those observations. / Both checks depend on the sample record's state. / Cleanup removes the record search expects. / The observed pattern is order-dependent. / Was the required record present when search began? / A passing rerun does not fix isolation. / Which check creates and removes this record? / Give the checks independent data or a defined setup. / Keep the failed sequence and logs. / Do not remove the assertion merely to get green. / Check the revised arrangement in the relevant sequence. / The standalone pass does not prove the suite is reliable. / Resolve shared-data ownership and verify the resulting behavior.
Vocabulary: flaky test: Test showing inconsistent outcomes under apparently similar conditions. / order dependency: Dependence of a result on the sequence of test execution. / shared fixture: Prepared data or state used by multiple checks. / setup: Preparation establishing a test's starting conditions. / teardown: Work restoring or removing state after a test. / cleanup: Removal of data or resources no longer needed by a check. / test isolation: Independence of a test from other tests' state changes. / state leakage: Unintended influence of one test's state on another. / sample record: Prepared data item used for testing. / precondition: Required state before a check starts. / execution order: Sequence in which checks run. / standalone run: Execution of a check without the surrounding suite. / suite run: Execution of a group of related checks. / rerun: Another execution of an existing check. / false alarm: Failure signal not caused by the claimed product defect. / failure evidence: Records supporting an observed unsuccessful result. / test data ownership: Responsibility for creating and removing test records. / unique test data: Data assigned specifically to one test or execution. / deterministic setup: Preparation that establishes predictable required conditions. / environment state: Relevant current conditions in the test setting. / interference: Effect of one check on another's operation. / quarantine: Temporary separation of an unreliable check under a defined policy. / continuous integration: Frequent integration with automated checking; abbreviated CI. / verification run: Execution used to check whether a proposed correction works.
Speaking task: Read the two T8 outcomes with their execution order and starting data state. Swap roles for turns 7-16. Stress ownership of the sample record and preserving the search assertion. Compare the final report with the brief. The data arrangement is proposed, not yet verified.
Partner: Noah: Automation engineer / Aisha: Tester
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the automation report using the observed order and shared-record facts.
Model for comparison AFTER my attempt, not a response to give me first: Noah: After the revision, I'll run cleanup then search, as well as search alone, and capture the starting data and actual results.
Aisha: The verification run needs that original sequence. A standalone pass alone would leave the reported interaction unverified.
Noah: My handoff will show T8, unchanged code, deletion of the expected record, and the two observed outcomes. The revised arrangement is not yet verified.
Aisha: That names the environment state precisely. We can investigate the actual dependency instead of calling the result random and moving on.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 06: Separating impact from scheduling in triage
Original fictional case: An export defect omits the final row in one monthly workflow. A heading typo appears on every account page. Tomorrow's customer demonstration uses the account page, with no export planned. Tester Lina and product lead Marcus discuss triage. The export has a data-completeness impact; the typo has broad visibility and immediate demonstration relevance. No severity scale, final repair order, or approval to release either issue is supplied.
Language workshop: The missing export row and tomorrow's visible typo
Communication goal: Compare functional impact, reach, and timing without equating demonstration urgency with defect severity or release approval.
Language guidance: Monthly describes when the export workflow occurs; it does not make a missing row trivial. Every account page describes the typo's reach; it does not make its functional impact identical to missing export data.
Useful expressions (preserve the supplied facts): The export omits its final row. / The observed issue affects the monthly workflow. / The heading typo appears on every account page. / The demonstration uses the account page. / No export is planned for the demonstration. / Impact and scheduling urgency are different questions. / Monthly use does not make missing data harmless. / Broad visibility does not automatically mean greater functional harm. / The demonstration makes the typo immediately relevant. / Which severity definitions apply here? / We have not agreed the repair order. / Triage discussion is not release approval. / Please record the disposition for each issue. / We have not established an alternative export method. / Keep data completeness and presentation visibility in the comparison. / Discuss impact, timing, and authorization separately.
Vocabulary: triage: Structured review to classify issues and decide next handling. / severity: Degree of impact caused by a defect under the relevant scale. / priority: Relative urgency or order assigned to work. / functional impact: Effect on the ability to perform the intended task. / visibility: Extent to which users encounter or notice an issue. / reach: Range of users or surfaces affected. / frequency: How often the relevant event or workflow occurs. / data completeness: Presence of all required data items. / cosmetic defect: Presentation issue without an established functional failure here. / customer demonstration: Planned presentation of product behavior to a customer. / business timing: Importance arising from an event or deadline. / repair order: Sequence in which issues are scheduled for correction. / release blocker: Issue preventing release under the applicable criteria. / waiver: Explicit authorized acceptance of an exception. / risk acceptance: Authorized decision to proceed with identified exposure. / workaround: Alternative way to complete a task despite a defect. / affected workflow: Process in which the reported issue occurs. / stakeholder impact: Consequence for people who rely on the product. / defect classification: Assignment of an issue to a defined category. / scheduling constraint: Limit affecting when work can be performed. / decision owner: Person responsible for a specified decision. / evidence-based comparison: Comparison grounded in observed effects and stated context. / defer: Postpone work without claiming the issue is resolved. / disposition: Recorded decision about how an issue will be handled.
Speaking task: Read the triage comparison once for functional impact, then again for demonstration timing. Swap roles for turns 9-16. Keep classification, work order, and permission to release separate. Repeat the closing status without adding an invented workaround, severity scale, or approved repair order.
Partner: Lina: Tester / Marcus: Product lead
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the triage summary without assigning an unsupported rating or release decision.
Model for comparison AFTER my attempt, not a response to give me first: Lina: My comparison will show the missing row, the typo's reach, and the demonstration's actual scope. It won't invent consequences we haven't observed.
Marcus: That is an evidence-based comparison. It gives the team a clear basis for scheduling discussion without pretending a decision has already been reached.
Lina: I'll leave the repair order and release disposition pending. Strongly arguing for urgency doesn't mean I can announce an authorization.
Marcus: Good. Keep any risk acceptance separate and explicit. We can discuss urgency strongly without silently approving either defect for release.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 06: Separating impact from scheduling in triage
Original fictional case: An export defect omits the final row in one monthly workflow. A heading typo appears on every account page. Tomorrow's customer demonstration uses the account page, with no export planned. Tester Lina and product lead Marcus discuss triage. The export has a data-completeness impact; the typo has broad visibility and immediate demonstration relevance. No severity scale, final repair order, or approval to release either issue is supplied.
Language workshop: The missing export row and tomorrow's visible typo
Communication goal: Compare functional impact, reach, and timing without equating demonstration urgency with defect severity or release approval.
Language guidance: Monthly describes when the export workflow occurs; it does not make a missing row trivial. Every account page describes the typo's reach; it does not make its functional impact identical to missing export data.
Useful expressions (preserve the supplied facts): The export omits its final row. / The observed issue affects the monthly workflow. / The heading typo appears on every account page. / The demonstration uses the account page. / No export is planned for the demonstration. / Impact and scheduling urgency are different questions. / Monthly use does not make missing data harmless. / Broad visibility does not automatically mean greater functional harm. / The demonstration makes the typo immediately relevant. / Which severity definitions apply here? / We have not agreed the repair order. / Triage discussion is not release approval. / Please record the disposition for each issue. / We have not established an alternative export method. / Keep data completeness and presentation visibility in the comparison. / Discuss impact, timing, and authorization separately.
Vocabulary: triage: Structured review to classify issues and decide next handling. / severity: Degree of impact caused by a defect under the relevant scale. / priority: Relative urgency or order assigned to work. / functional impact: Effect on the ability to perform the intended task. / visibility: Extent to which users encounter or notice an issue. / reach: Range of users or surfaces affected. / frequency: How often the relevant event or workflow occurs. / data completeness: Presence of all required data items. / cosmetic defect: Presentation issue without an established functional failure here. / customer demonstration: Planned presentation of product behavior to a customer. / business timing: Importance arising from an event or deadline. / repair order: Sequence in which issues are scheduled for correction. / release blocker: Issue preventing release under the applicable criteria. / waiver: Explicit authorized acceptance of an exception. / risk acceptance: Authorized decision to proceed with identified exposure. / workaround: Alternative way to complete a task despite a defect. / affected workflow: Process in which the reported issue occurs. / stakeholder impact: Consequence for people who rely on the product. / defect classification: Assignment of an issue to a defined category. / scheduling constraint: Limit affecting when work can be performed. / decision owner: Person responsible for a specified decision. / evidence-based comparison: Comparison grounded in observed effects and stated context. / defer: Postpone work without claiming the issue is resolved. / disposition: Recorded decision about how an issue will be handled.
Speaking task: Read the triage comparison once for functional impact, then again for demonstration timing. Swap roles for turns 9-16. Keep classification, work order, and permission to release separate. Repeat the closing status without adding an invented workaround, severity scale, or approved repair order.
Partner: Lina: Tester / Marcus: Product lead
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the triage summary without assigning an unsupported rating or release decision.
Model for comparison AFTER my attempt, not a response to give me first: Lina: My comparison will show the missing row, the typo's reach, and the demonstration's actual scope. It won't invent consequences we haven't observed.
Marcus: That is an evidence-based comparison. It gives the team a clear basis for scheduling discussion without pretending a decision has already been reached.
Lina: I'll leave the repair order and release disposition pending. Strongly arguing for urgency doesn't mean I can announce an authorization.
Marcus: Good. Keep any risk acceptance separate and explicit. We can discuss urgency strongly without silently approving either defect for release.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 06: Separating impact from scheduling in triage
Original fictional case: An export defect omits the final row in one monthly workflow. A heading typo appears on every account page. Tomorrow's customer demonstration uses the account page, with no export planned. Tester Lina and product lead Marcus discuss triage. The export has a data-completeness impact; the typo has broad visibility and immediate demonstration relevance. No severity scale, final repair order, or approval to release either issue is supplied.
Language workshop: The missing export row and tomorrow's visible typo
Communication goal: Compare functional impact, reach, and timing without equating demonstration urgency with defect severity or release approval.
Language guidance: Monthly describes when the export workflow occurs; it does not make a missing row trivial. Every account page describes the typo's reach; it does not make its functional impact identical to missing export data.
Useful expressions (preserve the supplied facts): The export omits its final row. / The observed issue affects the monthly workflow. / The heading typo appears on every account page. / The demonstration uses the account page. / No export is planned for the demonstration. / Impact and scheduling urgency are different questions. / Monthly use does not make missing data harmless. / Broad visibility does not automatically mean greater functional harm. / The demonstration makes the typo immediately relevant. / Which severity definitions apply here? / We have not agreed the repair order. / Triage discussion is not release approval. / Please record the disposition for each issue. / We have not established an alternative export method. / Keep data completeness and presentation visibility in the comparison. / Discuss impact, timing, and authorization separately.
Vocabulary: triage: Structured review to classify issues and decide next handling. / severity: Degree of impact caused by a defect under the relevant scale. / priority: Relative urgency or order assigned to work. / functional impact: Effect on the ability to perform the intended task. / visibility: Extent to which users encounter or notice an issue. / reach: Range of users or surfaces affected. / frequency: How often the relevant event or workflow occurs. / data completeness: Presence of all required data items. / cosmetic defect: Presentation issue without an established functional failure here. / customer demonstration: Planned presentation of product behavior to a customer. / business timing: Importance arising from an event or deadline. / repair order: Sequence in which issues are scheduled for correction. / release blocker: Issue preventing release under the applicable criteria. / waiver: Explicit authorized acceptance of an exception. / risk acceptance: Authorized decision to proceed with identified exposure. / workaround: Alternative way to complete a task despite a defect. / affected workflow: Process in which the reported issue occurs. / stakeholder impact: Consequence for people who rely on the product. / defect classification: Assignment of an issue to a defined category. / scheduling constraint: Limit affecting when work can be performed. / decision owner: Person responsible for a specified decision. / evidence-based comparison: Comparison grounded in observed effects and stated context. / defer: Postpone work without claiming the issue is resolved. / disposition: Recorded decision about how an issue will be handled.
Speaking task: Read the triage comparison once for functional impact, then again for demonstration timing. Swap roles for turns 9-16. Keep classification, work order, and permission to release separate. Repeat the closing status without adding an invented workaround, severity scale, or approved repair order.
Partner: Lina: Tester / Marcus: Product lead
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the triage summary without assigning an unsupported rating or release decision.
Model for comparison AFTER my attempt, not a response to give me first: Lina: My comparison will show the missing row, the typo's reach, and the demonstration's actual scope. It won't invent consequences we haven't observed.
Marcus: That is an evidence-based comparison. It gives the team a clear basis for scheduling discussion without pretending a decision has already been reached.
Lina: I'll leave the repair order and release disposition pending. Strongly arguing for urgency doesn't mean I can announce an authorization.
Marcus: Good. Keep any risk acceptance separate and explicit. We can discuss urgency strongly without silently approving either defect for release.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Retrieve occupational vocabulary
1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation.
2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it.
3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment.
4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item.
5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 07: Reporting exploratory findings
Original fictional case: Tester Isha completes a twenty-minute exploratory session with the charter Investigate interrupted profile edits. Navigating away after a saved edit preserves the value. Navigating away during an unsaved edit loses it without warning. Whether a warning is required is unspecified. Mobile behavior was not explored. Isha debriefs with product analyst Owen, who needs a factual record and a clarification request rather than a claim that every profile edit is broken.
Language workshop: Saved edits persist; unsaved edits disappear silently
Communication goal: Report a timeboxed exploratory observation while separating behavior, an unresolved warning requirement, and untested mobile scope.
Language guidance: The saved and unsaved paths have different observations. Saved edits persist after navigation; unsaved edits are lost without warning. Do not merge them into all edits are lost or assume that loss of an unsaved change violates an unstated rule.
Useful expressions (preserve the supplied facts): The session investigated interrupted profile edits. / I explored for twenty minutes. / After saving, navigation preserved the value. / Navigating away during an unsaved edit lost the change. / No warning appeared in that sequence. / I did not observe all profile edits failing. / The warning requirement is unspecified. / Should leaving an unsaved edit trigger a warning? / The no-warning behavior remains a useful finding. / I have not assumed that every unsaved edit must persist. / I did not explore mobile behavior. / Link the warning decision to the session notes. / The observation is not yet a confirmed requirement violation. / Record whether save occurred before navigation. / These findings apply to the paths explored. / Saved value persists; unsaved change is lost without warning; requirement and mobile questions remain.
Vocabulary: exploratory testing: Investigation that adapts checks as the tester learns. / test charter: Statement guiding the purpose of an exploratory session. / focus containment: Keeping keyboard tab navigation within an open modal dialog. / timebox: Fixed time allocated to an investigation. / debrief: Discussion reviewing observations, limits, and follow-up. / session notes: Record of actions, observations, and questions from testing. / observation: Behavior directly seen during the investigation. / finding: Recorded result or question arising from investigation. / saved state: Data retained after a completed save under the observed behavior. / unsaved change: Edit not yet committed by the relevant save action. / navigation away: Leaving the current view or page. / persistence: Continued retention of data across the relevant transition. / warning prompt: Message alerting a user before a consequential action. / state transition: Change from one defined condition to another. / user journey: Sequence of actions a user takes toward an objective. / focus restoration: Returning keyboard focus to the required target after an interface closes. / requirement gap: Missing specification needed to judge intended behavior. / usability concern: Potential difficulty in understanding or using the product. / confirmed defect: Established departure from an applicable expectation. / follow-up question: Specific unresolved point for further investigation or clarification. / scope exclusion: Area explicitly not covered by the investigation. / mobile coverage: Evidence from checking behavior on mobile devices or conditions. / evidence trail: Records linking a finding to actions and observations. / session outcome: Bounded summary of findings and remaining questions.
Speaking task: Read the saved and unsaved navigation sequences separately, with the observed result after each. Swap roles for turns 7-14. Keep the warning requirement unresolved and mobile behavior untested. Check the final debrief against the supplied observations, not a broad claim that all profile edits fail.
Partner: Isha: Exploratory tester / Owen: Product analyst
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the exploratory report without converting an observation into an unsupported requirement judgment.
Model for comparison AFTER my attempt, not a response to give me first: Isha: After the owner decides the warning rule, we can test against it. Until then the original observation stays attached to the clarification request.
Owen: That keeps confirmed defect separate from an unresolved finding. The eventual decision may change the classification without changing what you actually observed.
Isha: My summary will retain saved-value persistence, unsaved loss without warning, the missing warning rule, and no mobile coverage.
Owen: Good. That is a bounded session outcome. It gives the next reviewer concrete evidence and one answerable follow-up question, rather than a broad label they have to reconstruct.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Choose grammar that preserves the meaning
1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness.
2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait.
3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay.
4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise.
5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 07: Reporting exploratory findings
Original fictional case: Tester Isha completes a twenty-minute exploratory session with the charter Investigate interrupted profile edits. Navigating away after a saved edit preserves the value. Navigating away during an unsaved edit loses it without warning. Whether a warning is required is unspecified. Mobile behavior was not explored. Isha debriefs with product analyst Owen, who needs a factual record and a clarification request rather than a claim that every profile edit is broken.
Language workshop: Saved edits persist; unsaved edits disappear silently
Communication goal: Report a timeboxed exploratory observation while separating behavior, an unresolved warning requirement, and untested mobile scope.
Language guidance: The saved and unsaved paths have different observations. Saved edits persist after navigation; unsaved edits are lost without warning. Do not merge them into all edits are lost or assume that loss of an unsaved change violates an unstated rule.
Useful expressions (preserve the supplied facts): The session investigated interrupted profile edits. / I explored for twenty minutes. / After saving, navigation preserved the value. / Navigating away during an unsaved edit lost the change. / No warning appeared in that sequence. / I did not observe all profile edits failing. / The warning requirement is unspecified. / Should leaving an unsaved edit trigger a warning? / The no-warning behavior remains a useful finding. / I have not assumed that every unsaved edit must persist. / I did not explore mobile behavior. / Link the warning decision to the session notes. / The observation is not yet a confirmed requirement violation. / Record whether save occurred before navigation. / These findings apply to the paths explored. / Saved value persists; unsaved change is lost without warning; requirement and mobile questions remain.
Vocabulary: exploratory testing: Investigation that adapts checks as the tester learns. / test charter: Statement guiding the purpose of an exploratory session. / focus containment: Keeping keyboard tab navigation within an open modal dialog. / timebox: Fixed time allocated to an investigation. / debrief: Discussion reviewing observations, limits, and follow-up. / session notes: Record of actions, observations, and questions from testing. / observation: Behavior directly seen during the investigation. / finding: Recorded result or question arising from investigation. / saved state: Data retained after a completed save under the observed behavior. / unsaved change: Edit not yet committed by the relevant save action. / navigation away: Leaving the current view or page. / persistence: Continued retention of data across the relevant transition. / warning prompt: Message alerting a user before a consequential action. / state transition: Change from one defined condition to another. / user journey: Sequence of actions a user takes toward an objective. / focus restoration: Returning keyboard focus to the required target after an interface closes. / requirement gap: Missing specification needed to judge intended behavior. / usability concern: Potential difficulty in understanding or using the product. / confirmed defect: Established departure from an applicable expectation. / follow-up question: Specific unresolved point for further investigation or clarification. / scope exclusion: Area explicitly not covered by the investigation. / mobile coverage: Evidence from checking behavior on mobile devices or conditions. / evidence trail: Records linking a finding to actions and observations. / session outcome: Bounded summary of findings and remaining questions.
Speaking task: Read the saved and unsaved navigation sequences separately, with the observed result after each. Swap roles for turns 7-14. Keep the warning requirement unresolved and mobile behavior untested. Check the final debrief against the supplied observations, not a broad claim that all profile edits fail.
Partner: Isha: Exploratory tester / Owen: Product analyst
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the exploratory report without converting an observation into an unsupported requirement judgment.
Model for comparison AFTER my attempt, not a response to give me first: Isha: After the owner decides the warning rule, we can test against it. Until then the original observation stays attached to the clarification request.
Owen: That keeps confirmed defect separate from an unresolved finding. The eventual decision may change the classification without changing what you actually observed.
Isha: My summary will retain saved-value persistence, unsaved loss without warning, the missing warning rule, and no mobile coverage.
Owen: Good. That is a bounded session outcome. It gives the next reviewer concrete evidence and one answerable follow-up question, rather than a broad label they have to reconstruct.
END REFERENCE

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the prompt.

TASK: Interactive workplace role-play
1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies.
2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time.
3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain.
4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance.
5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay.
Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions.

Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait.

When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim.

Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry.

REFERENCE
Course: Software Quality Assurance and Testing English
Professional audience: Software quality assurance analysts, manual testers, test engineers, automation engineers, and test leads
Scope: All products, builds, requirements, observations, and decisions are fictional. This book teaches workplace English, not certification content or a complete testing method. Actual requirements, test policies, evidence standards, privacy safeguards, and release authority take precedence. The exercises authorize no live-system changes. A proposed check has no result until executed, and an observed result applies only to its stated conditions.
Lesson 07: Reporting exploratory findings
Original fictional case: Tester Isha completes a twenty-minute exploratory session with the charter Investigate interrupted profile edits. Navigating away after a saved edit preserves the value. Navigating away during an unsaved edit loses it without warning. Whether a warning is required is unspecified. Mobile behavior was not explored. Isha debriefs with product analyst Owen, who needs a factual record and a clarification request rather than a claim that every profile edit is broken.
Language workshop: Saved edits persist; unsaved edits disappear silently
Communication goal: Report a timeboxed exploratory observation while separating behavior, an unresolved warning requirement, and untested mobile scope.
Language guidance: The saved and unsaved paths have different observations. Saved edits persist after navigation; unsaved edits are lost without warning. Do not merge them into all edits are lost or assume that loss of an unsaved change violates an unstated rule.
Useful expressions (preserve the supplied facts): The session investigated interrupted profile edits. / I explored for twenty minutes. / After saving, navigation preserved the value. / Navigating away during an unsaved edit lost the change. / No warning appeared in that sequence. / I did not observe all profile edits failing. / The warning requirement is unspecified. / Should leaving an unsaved edit trigger a warning? / The no-warning behavior remains a useful finding. / I have not assumed that every unsaved edit must persist. / I did not explore mobile behavior. / Link the warning decision to the session notes. / The observation is not yet a confirmed requirement violation. / Record whether save occurred before navigation. / These findings apply to the paths explored. / Saved value persists; unsaved change is lost without warning; requirement and mobile questions remain.
Vocabulary: exploratory testing: Investigation that adapts checks as the tester learns. / test charter: Statement guiding the purpose of an exploratory session. / focus containment: Keeping keyboard tab navigation within an open modal dialog. / timebox: Fixed time allocated to an investigation. / debrief: Discussion reviewing observations, limits, and follow-up. / session notes: Record of actions, observations, and questions from testing. / observation: Behavior directly seen during the investigation. / finding: Recorded result or question arising from investigation. / saved state: Data retained after a completed save under the observed behavior. / unsaved change: Edit not yet committed by the relevant save action. / navigation away: Leaving the current view or page. / persistence: Continued retention of data across the relevant transition. / warning prompt: Message alerting a user before a consequential action. / state transition: Change from one defined condition to another. / user journey: Sequence of actions a user takes toward an objective. / focus restoration: Returning keyboard focus to the required target after an interface closes. / requirement gap: Missing specification needed to judge intended behavior. / usability concern: Potential difficulty in understanding or using the product. / confirmed defect: Established departure from an applicable expectation. / follow-up question: Specific unresolved point for further investigation or clarification. / scope exclusion: Area explicitly not covered by the investigation. / mobile coverage: Evidence from checking behavior on mobile devices or conditions. / evidence trail: Records linking a finding to actions and observations. / session outcome: Bounded summary of findings and remaining questions.
Speaking task: Read the saved and unsaved navigation sequences separately, with the observed result after each. Swap roles for turns 7-14. Keep the warning requirement unresolved and mobile behavior untested. Check the final debrief against the supplied observations, not a broad claim that all profile edits fail.
Partner: Isha: Exploratory tester / Owen: Product analyst
Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required.
Optional second-round challenge: Complete the exploratory report without converting an observation into an unsupported requirement judgment.
Model for comparison AFTER my attempt, not a response to give me first: Isha: After the owner decides the warning rule, we can test against it. Until then the original observation stays attached to the clarification request.
Owen: That keeps confirmed defect separate from an unresolved finding. The eventual decision may change the classification without changing what you actually observed.
Isha: My summary will retain saved-value persistence, unsaved loss without warning, the missing warning rule, and no mobile coverage.
Owen: Good. That is a bounded session outcome. It gives the next reviewer concrete evidence and one answerable follow-up question, rather than a broad label they have to reconstruct.
END REFERENCE