Quality assurance: discussing problems and hypothetical solutions
B2
90 min
Premium
1
Think about these questions before reading the article. Share your ideas with a partner.
Describe a time you bought a new product or started using a new app that had a significant flaw. What was the problem, and how did it affect your opinion of the brand?
Think about a project you've worked on (at school, work, or personally) that didn't go as planned. If you could go back and change one decision from the beginning, what would it be and why?
In business, there's often a conflict between releasing something quickly and making sure it's perfect. Which do you think is more damaging in the long run: a delayed launch or a flawed one? Explain your reasoning.
2
Project Post-Mortem
Listen to the dialogue. Notice how the vocabulary and grammar from the lesson are used.
3
Answer these questions in your own words, based on the ideas presented in the article.
01What is the likely purpose of a 'post-mortem' meeting in a business context like the one described?
Sample answerIt seems to be a meeting you have after a project is finished, especially if there were problems. The goal is to analyze what went wrong and figure out how to avoid the same mistakes in the future.
02Based on the vocabulary mentioned, what is the relationship between a 'defect' and a 'robust' product?
Sample answerThey are opposites. A robust product is strong and reliable, so it would have very few or no defects. Finding a defect means the product isn't as robust as it should be.
03How might the grammar focus, mixed conditionals, be useful for discussing a failed project in a 'post-mortem' meeting?
Sample answerYou could use it to talk about how a different action in the past would have changed the current situation. For example, 'If we had conducted more tests, we wouldn't be having this problem now.' It's perfect for suggesting improvements.
04Considering all the terms mentioned, why would 'user acceptance testing' be a critical step in a 'release cycle'?
Sample answerBecause it's probably the final check before the product goes public. Real users test it to find any last-minute defects. Skipping it could mean releasing a product with problems, which would damage the company's reputation.
4
Key vocabulary for problem analysis
Vocabulary
These expressions will help you discuss project issues and solutions more effectively.
Examples
To iron out the kinks — to solve the small problems or fix the details in a plan, system, or product.
Usage note: This is a common, slightly informal idiom used in business and project management. It's perfect for discussing the final stages of development before a product is released.
A recurring issue — a problem that happens repeatedly.
Usage note: Use this to be more precise than just saying 'a problem'. It's common in technical reports and meetings to describe persistent defects.
To flag something as a concern — to identify and draw attention to something as a potential problem or risk.
Usage note: This is a professional and diplomatic way to raise a problem in a meeting. For example: 'I need to flag the lack of user feedback as a concern.'
In hindsight — looking back at a situation in the past, often with a new understanding of it.
Usage note: This phrase is perfect for 'post-mortem' meetings. It's often used at the start of a sentence to introduce a reflection on a past mistake, e.g., 'In hindsight, we should have started testing earlier.'
To get to the root of the problem — to find the main, fundamental cause of an issue, not just its symptoms.
Usage note: This idiom emphasizes the need for deep analysis. It's useful when you want to suggest a thorough investigation before implementing a quick fix.
5
Complete the sentences with words from the box. One word is extra.
Word bank
01In , we should have allocated more resources to testing before the launch.
02This isn't the first time the server has crashed; it's a issue that our engineers need to investigate immediately.
03The new software is almost ready, but we need a few more days to all the minor bugs.
04Instead of just patching the surface-level errors, we must get to the of the problem to prevent it from happening again.
05I'd like to this as a potential concern: if we release now, we risk damaging our reputation with a faulty product.
6
Grammar: Mixed conditionals
Grammar
Mixed conditionals let us talk about how a different action in the past could have changed the present situation. This is very useful when analysing what went wrong in a project and imagining a better current outcome, as mentioned in the article.
Examples
If we had implemented more robust testing, we wouldn't be dealing with so many defects now.
This structure connects a hypothetical past action (implementing testing) with its unreal present result (not dealing with defects).
The release cycle would be on schedule if the team hadn't discovered that critical bug last month.
The 'if' clause uses the past perfect (hadn't discovered), and the main clause uses 'would + base verb' to describe the present result.
If I had read the project brief more carefully, I would know what to do in this meeting.
This type of conditional is perfect for expressing regret or analysing past mistakes and their current consequences.
Key points
Structure: If + past perfect (had done), would/wouldn't + base verb (be/do).
Use this to link an unreal or hypothetical past condition to an unreal present result.
Common mistake: Avoid using 'would' in the 'if' clause. Incorrect: If we would have done more testing...
7
Find the mistake
The following sentences are about quality assurance and project management. Each one has a small error.
Each sentence contains one error. Find and correct it.
01If we would have done more user acceptance testing, we wouldn't have so many customer complaints now.
Corrected version
If we would have had done more user acceptance testing, we wouldn't have so many customer complaints now.
02We need to iron up the kinks in the new software before the official launch.
Corrected version
We need to iron up out the kinks in the new software before the official launch.
03This is a recur issue that we have seen in the last three release cycles.
Corrected version
This is a recur recurring issue that we have seen in the last three release cycles.
04The team needs to perform a thorough root cause analyse to prevent this from happening again.
Corrected version
The team needs to perform a thorough root cause analyse analysis to prevent this from happening again.
05In hindsight, we should have flagged this issue as a concern on an earlier stage.
Corrected version
In hindsight, we should have flagged this issue as a concern on at an earlier stage.
06If the initial testing had been more robust, the system is more stable now.
Corrected version
If the initial testing had been more robust, the system is would be more stable now.
07Getting to the root of the problem often require a lot of investigation.
Corrected version
Getting to the root of the problem often require requires a lot of investigation.
8
Useful phrases: Analysing what went wrong in a project meeting
Vocabulary
In a 'post-mortem' or project review meeting, it's important to discuss problems constructively. These phrases will help you analyse issues, take responsibility, and suggest improvements without blaming your colleagues.
Examples
The goal here isn't to point fingers, but to improve our process. — sets a constructive tone for the meeting.
Register: neutral. Use this at the beginning of the meeting to ensure everyone feels safe to speak openly. It focuses the team on solutions, not blame.
Let's walk through the timeline to see where things went off track. — proposes a structured way to analyse the problem.
Register: neutral. This is a great way to start the analysis by focusing on events and processes rather than on people's mistakes.
I can't help but wonder if we underestimated the complexity here. — gently speculates about a potential cause.
Register: neutral/slightly informal. A polite and non-confrontational way to introduce a hypothesis about the root cause. You can replace the part after 'if' with any other idea.
On reflection, I should have raised this concern earlier. — takes personal responsibility for an oversight.
Register: neutral. Use this to show accountability. It often encourages others to be more open and helps build a culture of trust and honesty.
A key takeaway for me is the need for more rigorous checks. — states a lesson learned and implies a future action.
Register: neutral/slightly formal. This phrase effectively shifts the focus from the past problem to a future solution, framing it as a personal learning point.
Moving forward, how can we build a better safety net? — shifts the conversation towards future prevention.
Register: neutral. Use this to pivot the discussion from analysing what went wrong to creating a concrete plan for the future. 'Safety net' is a useful metaphor for preventative measures.
9
Project post-mortem analysis
Read the summary of a project review meeting and fill in the blanks.
Fill in each blank with the correct word from the word bank.
Word bank
During the project post-mortem, the team agreed that, in , they should have dedicated more resources to the final testing phase. The project manager recalled that the lead developer did the tight schedule as a concern weeks ago. If they had listened then, they probably wouldn't be fixing the same bug that customers keep reporting. The main takeaway was the need to get to the of these problems much earlier in the development cycle. For the next project, they will implement a stricter QA process to out all the kinks before the release date.
10
Words to take with you
Vocabulary
These expressions are not in the article but will help you discuss this topic more fluently.
Examples
Bottleneck — a point in a process where the flow is restricted, causing delays and slowing down the entire system.
Use this noun to identify the specific part of a project or workflow that is causing problems. For example: 'The main bottleneck was in the testing phase; we didn't have enough people to check the code.'
To streamline a process — to make a system or process more efficient and effective by simplifying it or removing unnecessary steps.
This verb phrase is perfect for suggesting improvements. You can talk about streamlining workflows, communication, or procedures. Example: 'We need to streamline our approval process to avoid future delays.'
Scope creep — when the goals or requirements of a project expand from its original plan, often in an uncontrolled way.
This is a key term in project management. Use it to explain why a project took longer or cost more than expected. For example: 'The project went over budget mainly due to scope creep; the client kept adding new features.'
To drop the ball — an informal idiom meaning to make a mistake or fail to fulfill a responsibility, often through carelessness.
This is a common way to admit a mistake or point out where something went wrong in an internal meeting. Example: 'I think we dropped the ball by not communicating the changes to the design team earlier.'
A viable solution — a solution that is practical, workable, and has a good chance of being successful.
Use this collocation when proposing or evaluating ideas for improvement. It sounds professional and shows you've considered the practical aspects. For example: 'Increasing the testing time is a viable solution, but we need to check if it fits the budget.'
11
Analysing project problems
Complete the sentences you might hear in a project review meeting.
Match each item on the left with the correct item on the right.
Drag or click to match
Definitions
12
Discuss these questions with a partner. Try to use vocabulary from the lesson.
Imagine you're on a team with a tight deadline. You notice a potential flaw, but flagging it as a concern will definitely cause a delay. Is it better to speak up, or to stay quiet and hope to iron out the kinks after the launch? Justify your answer.
Think about the work or study culture in your country. When a project has a recurring issue, is the priority usually to get to the root of the problem, or to avoid blame? How does this affect a company's ability to improve over time?
In hindsight, many famous product failures seem obvious. Think of a product that had major problems after its release. What do you believe was the root of the problem, and what should the company have done differently when the issues were first flagged?