Intermediate
#ISO-25010
#quality-attributes
#maintainability
#reliability
Software Quality Attributes Vocabulary
5 exercises — master ISO 25010 quality attribute vocabulary: maintainability, reliability, portability, performance efficiency, and architectural trade-offs.
0 / 33 completed
1 / 33
A product requirements document lists "maintainability" as a non-functional requirement citing ISO 25010. A developer asks: "What exactly does the standard say maintainability includes?" Which answer correctly names the ISO 25010 sub-characteristics of maintainability?
ISO/IEC 25010 (Systems and Software Quality Requirements and Evaluation) provides the authoritative vocabulary for software quality attributes used in requirements engineering, architecture decisions, and quality assurance.
ISO 25010 Maintainability sub-characteristics:
Why this vocabulary matters in practice:
When writing non-functional requirements, specifying "the system shall be maintainable" is meaningless unless you reference which sub-characteristic you mean and how you will measure it. E.g. "Modifiability: any single feature change shall not require modification of more than 3 modules" is a testable NFR.
Key vocabulary:
• Non-functional requirement (NFR) — a quality attribute constraint rather than a functional capability
• ISO 25010 — the international standard defining the software quality model
• Quality attribute — a measurable or testable property of a software system
ISO 25010 Maintainability sub-characteristics:
| Sub-characteristic | Definition | Typical measurement |
|---|---|---|
| Modularity | Changes to one component have minimal impact on others | Coupling metrics, component cohesion |
| Reusability | An asset can be used in more than one system | Library usage metrics, API surface |
| Analysability | Effectiveness of diagnosing deficiencies or failure causes | MTTR, log coverage, observability tooling |
| Modifiability | Can be modified without introducing defects or degrading quality | Change failure rate, regression test results |
| Testability | Effectiveness of establishing test criteria and running validation | Branch coverage, cyclomatic complexity |
Why this vocabulary matters in practice:
When writing non-functional requirements, specifying "the system shall be maintainable" is meaningless unless you reference which sub-characteristic you mean and how you will measure it. E.g. "Modifiability: any single feature change shall not require modification of more than 3 modules" is a testable NFR.
Key vocabulary:
• Non-functional requirement (NFR) — a quality attribute constraint rather than a functional capability
• ISO 25010 — the international standard defining the software quality model
• Quality attribute — a measurable or testable property of a software system
2 / 33
An architect writes in an Architecture Decision Record: "This approach has implications for system reliability as defined by ISO 25010." What does ISO 25010 define as reliability, and how is it measured in practice?
ISO 25010 reliability has four distinct sub-characteristics, each with measurable indicators — understanding them enables precise engineering conversations about system dependability.
ISO 25010 Reliability sub-characteristics:
Reliability vs Availability — an important distinction:
A system can be highly available (rarely fully down) but have low reliability (frequent partial failures, degraded modes, data inconsistencies). ISO 25010 captures this by treating availability as just one sub-characteristic of the broader reliability concept.
Practical example:
A payment processing system might have 99.95% availability but poor fault tolerance (a single database node failure causes incorrect charge amounts rather than a clean error). Availability looks good; fault tolerance is failing.
Key vocabulary:
• MTBF — Mean Time Between Failures; average time a system runs without failure
• RTO — Recovery Time Objective; maximum acceptable restoration time
• RPO — Recovery Point Objective; maximum acceptable data loss (in time)
• Chaos engineering — deliberately injecting failures to test fault tolerance
ISO 25010 Reliability sub-characteristics:
| Sub-characteristic | Definition | Measurement |
|---|---|---|
| Maturity | Meets needs for reliability under normal operation | MTBF (Mean Time Between Failures) |
| Availability | Accessible and operational when required | Uptime %; SLA compliance |
| Fault tolerance | Operates despite hardware or software faults | Graceful degradation tests; chaos engineering results |
| Recoverability | Recovers data and state after interruption | RTO/RPO; MTTR |
Reliability vs Availability — an important distinction:
A system can be highly available (rarely fully down) but have low reliability (frequent partial failures, degraded modes, data inconsistencies). ISO 25010 captures this by treating availability as just one sub-characteristic of the broader reliability concept.
Practical example:
A payment processing system might have 99.95% availability but poor fault tolerance (a single database node failure causes incorrect charge amounts rather than a clean error). Availability looks good; fault tolerance is failing.
Key vocabulary:
• MTBF — Mean Time Between Failures; average time a system runs without failure
• RTO — Recovery Time Objective; maximum acceptable restoration time
• RPO — Recovery Point Objective; maximum acceptable data loss (in time)
• Chaos engineering — deliberately injecting failures to test fault tolerance
3 / 33
A developer proposes a new feature. The architect responds: "This creates a portability concern — it tightly couples us to vendor-specific APIs." What does portability mean as an ISO 25010 quality attribute?
ISO 25010 portability captures the architectural property of flexibility to change infrastructure, cloud providers, or deployment environments — a critical consideration in vendor lock-in risk assessments.
ISO 25010 Portability sub-characteristics:
Vendor lock-in as a portability risk:
When a system calls vendor-specific APIs (e.g. AWS Lambda-specific invocation patterns, Azure-specific bindings), migrating to a different cloud provider requires significant rework. Mitigation strategies:
• Abstract vendor APIs behind a domain interface (Adapter/Facade pattern)
• Prefer standards-based APIs over proprietary ones when capability is equivalent
• Document vendor-specific dependencies explicitly in architecture decision records (ADRs)
Key vocabulary:
• Vendor lock-in — architectural dependency that makes switching vendors costly or impractical
• Portability — the degree to which a system can be transferred to a different environment
• Adapter pattern — a design pattern that wraps vendor-specific code behind a stable interface
ISO 25010 Portability sub-characteristics:
| Sub-characteristic | Definition | Example |
|---|---|---|
| Adaptability | Can be adapted to different hardware/software/operating/usage environments | Containerised deployment; environment config via env vars |
| Installability | Can be effectively and efficiently installed or uninstalled in a specified environment | Helm chart deployment; clean uninstall scripts |
| Replaceability | Can replace another specified software product for the same purpose in the same environment | Implementing a standard interface (e.g. S3 API) that other tools also implement |
Vendor lock-in as a portability risk:
When a system calls vendor-specific APIs (e.g. AWS Lambda-specific invocation patterns, Azure-specific bindings), migrating to a different cloud provider requires significant rework. Mitigation strategies:
• Abstract vendor APIs behind a domain interface (Adapter/Facade pattern)
• Prefer standards-based APIs over proprietary ones when capability is equivalent
• Document vendor-specific dependencies explicitly in architecture decision records (ADRs)
Key vocabulary:
• Vendor lock-in — architectural dependency that makes switching vendors costly or impractical
• Portability — the degree to which a system can be transferred to a different environment
• Adapter pattern — a design pattern that wraps vendor-specific code behind a stable interface
4 / 33
In a quality review meeting, a PM asks: "What is the difference between performance efficiency and reliability as quality attributes? Aren't they the same thing?"
Performance efficiency and reliability are distinct ISO 25010 quality characteristics that can vary independently — understanding the difference prevents requirements confusion in project planning.
ISO 25010 Performance Efficiency sub-characteristics:
Four quadrants — performance vs reliability combinations:
• High performance, high reliability → ideal production system
• High performance, low reliability → fast but fragile; failures are quick and frequent
• Low performance, high reliability → slow but stable; rarely fails, never fast
• Low performance, low reliability → technical debt priority target
How this matters in architecture decisions:
A caching layer (e.g. Redis) improves performance efficiency (reduces P99 latency) but can introduce reliability concerns (cache stampede on cold start, stale data issues). The architect must consciously manage the trade-off between the two attributes.
Key vocabulary:
• Performance efficiency — resources used relative to work performed under stated conditions
• P99 latency — the 99th percentile response time; 99% of requests complete within this duration
• Quality attribute trade-off — the architectural reality that improving one attribute often degrades another
ISO 25010 Performance Efficiency sub-characteristics:
| Sub-characteristic | Definition | Metric example |
|---|---|---|
| Time behaviour | Response and processing times; throughput under normal conditions | P99 latency <200ms; 1000 req/s throughput |
| Resource utilisation | Amounts and types of resources used to perform functions | CPU <70% at peak; <4GB RAM at steady state |
| Capacity | Degree to which maximum limits meet requirements | Supports 10,000 concurrent users |
Four quadrants — performance vs reliability combinations:
• High performance, high reliability → ideal production system
• High performance, low reliability → fast but fragile; failures are quick and frequent
• Low performance, high reliability → slow but stable; rarely fails, never fast
• Low performance, low reliability → technical debt priority target
How this matters in architecture decisions:
A caching layer (e.g. Redis) improves performance efficiency (reduces P99 latency) but can introduce reliability concerns (cache stampede on cold start, stale data issues). The architect must consciously manage the trade-off between the two attributes.
Key vocabulary:
• Performance efficiency — resources used relative to work performed under stated conditions
• P99 latency — the 99th percentile response time; 99% of requests complete within this duration
• Quality attribute trade-off — the architectural reality that improving one attribute often degrades another
5 / 33
A tech lead uses the phrase "quality attribute trade-off" in an Architecture Decision Record. A junior developer asks what this means. What is the correct explanation?
Quality attribute trade-offs are an architectural reality — no system can simultaneously maximise all ISO 25010 quality attributes, and the architect's job is to make these trade-offs explicit and intentional.
Common quality attribute tensions:
Architecture Decision Record structure for trade-offs:
① Context: the forces competing in this decision
② Decision: the chosen architectural option
③ Trade-offs accepted: which quality attributes are degraded and by how much
④ Consequences: what follow-up work is required to mitigate the downside
The ATAM method (Architecture Tradeoff Analysis Method):
ATAM is a structured framework for analysing quality attribute trade-offs in architecture reviews, commonly used in government and defence software procurement.
Key vocabulary:
• Quality attribute trade-off — accepting degradation in one quality attribute to improve another
• Architecturally Significant Requirement (ASR) — a requirement that materially constrains the architectural design
• Architecture Decision Record (ADR) — a document capturing the context, decision, and trade-offs of an architectural choice
Common quality attribute tensions:
| Trade-off | Example |
|---|---|
| Security ↔ Usability | MFA and session timeouts improve security but increase friction for the user |
| Performance ↔ Maintainability | Hand-optimised SQL is faster but harder to understand and modify safely |
| Reliability ↔ Performance | Synchronous replication improves durability but adds latency to every write |
| Portability ↔ Performance | Abstracting away vendor APIs sacrifices access to performance-optimised features |
| Maintainability ↔ Performance | Caching improves performance but adds complexity to cache invalidation logic |
Architecture Decision Record structure for trade-offs:
① Context: the forces competing in this decision
② Decision: the chosen architectural option
③ Trade-offs accepted: which quality attributes are degraded and by how much
④ Consequences: what follow-up work is required to mitigate the downside
The ATAM method (Architecture Tradeoff Analysis Method):
ATAM is a structured framework for analysing quality attribute trade-offs in architecture reviews, commonly used in government and defence software procurement.
Key vocabulary:
• Quality attribute trade-off — accepting degradation in one quality attribute to improve another
• Architecturally Significant Requirement (ASR) — a requirement that materially constrains the architectural design
• Architecture Decision Record (ADR) — a document capturing the context, decision, and trade-offs of an architectural choice
6 / 33
Sarah: "Hey team, I'm working on this new API endpoint for user profile updates. The response is coming back with a 502 error intermittently. It's really frustrating!"
Mark (Code Reviewer): "I noticed the logging isn't very detailed here. We need to add more information about the request parameters and server-side errors to help debug this." What quality attribute is Mark primarily addressing with his comment?
Mark is focusing on Maintainability because detailed logging allows developers to easily understand the request parameters involved in the error. The incorrect options address different aspects of code quality: robustness deals with handling errors, performance concerns response time, and security focuses on data protection. Adding more logging directly contributes to making the codebase easier for others (and Sarah) to debug and fix.
7 / 33
During a Slack discussion about the upcoming release of a new microservice, Alex says: 'I'm worried this service is going to be incredibly difficult to update later. It has a ton of dependencies and complex logic.' His concern primarily relates to which quality attribute?
Alex's statement directly addresses maintainability, a key quality attribute focused on the ease with which software can be modified over its lifecycle. The other options – performance, security, and insufficient capacity— relate to different aspects of service operation but don't capture the core concern about future adaptability. A system with many dependencies and complex logic will naturally require more effort for updates, making maintainability a critical consideration.
8 / 33
PR Description:
"Implemented a new feature to allow users to upload profile pictures. Initial tests seem successful, but I'm concerned about the long-term maintainability of this code. It's quite complex and relies heavily on third-party image processing libraries."The question focuses on maintaining code quality over time. Option 1 correctly identifies that concern regarding future maintainability is being raised. The incorrect options either focus solely on immediate functionality (Option 3), ignore maintainability concerns entirely (Option 2), or misinterpret the PR's content. A good PR description should acknowledge potential long-term challenges.
9 / 33
Liam: "I'm seeing some weird spikes in latency when processing large data sets through this service. It seems to be struggling under load." Chloe (another developer) replies: "Have you considered the impact on *scalability*? We need to ensure the system can handle increasing volumes without significant performance degradation."
Which of the following best describes the core meaning behind Chloe's comment, relating to a quality attribute?Chloe is focusing on
scalability, which is a crucial quality attribute concerning how well a system can handle increased load. The key misconception here is that scalability isn't just about speed; it's fundamentally about the system's ability to *grow* and adapt without breaking down or experiencing significant performance drops under pressure. The other options represent different aspects of software quality – technical debt focuses on code design, robustness deals with error handling, and insufficient simply acknowledges a problem hasn't been identified.10 / 33
Sarah: "Hey team, I'm working on this new API endpoint for user profile updates. The response is coming back with a 502 error intermittently. It's really frustrating!"
Mark (Code Reviewer): "I noticed the logging isn't very detailed here. We need to add more information about the request parameters and server-side errors to help debug this." What quality attribute is Mark primarily addressing with his comment?
Mark is focusing on Maintainability because detailed logging allows developers to easily understand the request parameters involved in the error. The incorrect options address different aspects of code quality: robustness deals with handling errors, performance concerns response time, and security focuses on data protection. Adding more logging directly contributes to making the codebase easier for others (and Sarah) to debug and fix.
11 / 33
During a Slack discussion about the upcoming release of a new microservice, Alex says: 'I'm worried this service is going to be incredibly difficult to update later. It has a ton of dependencies and complex logic.' His concern primarily relates to which quality attribute?
Alex's statement directly addresses maintainability, a key quality attribute focused on the ease with which software can be modified over its lifecycle. The other options – performance, security, and insufficient capacity— relate to different aspects of service operation but don't capture the core concern about future adaptability. A system with many dependencies and complex logic will naturally require more effort for updates, making maintainability a critical consideration.
12 / 33
PR Description:
"Implemented a new feature to allow users to upload profile pictures. Initial tests seem successful, but I'm concerned about the long-term maintainability of this code. It's quite complex and relies heavily on third-party image processing libraries."The question focuses on maintaining code quality over time. Option 1 correctly identifies that concern regarding future maintainability is being raised. The incorrect options either focus solely on immediate functionality (Option 3), ignore maintainability concerns entirely (Option 2), or misinterpret the PR's content. A good PR description should acknowledge potential long-term challenges.
13 / 33
Liam: "I'm seeing some weird spikes in latency when processing large data sets through this service. It seems to be struggling under load." Chloe (another developer) replies: "Have you considered the impact on *scalability*? We need to ensure the system can handle increasing volumes without significant performance degradation."
Which of the following best describes the core meaning behind Chloe's comment, relating to a quality attribute?Chloe is focusing on
scalability, which is a crucial quality attribute concerning how well a system can handle increased load. The key misconception here is that scalability isn't just about speed; it's fundamentally about the system's ability to *grow* and adapt without breaking down or experiencing significant performance drops under pressure. The other options represent different aspects of software quality – technical debt focuses on code design, robustness deals with error handling, and insufficient simply acknowledges a problem hasn't been identified.14 / 33
Sarah: "Hey team, I'm working on this new API endpoint for user profile updates. The response is coming back with a 502 error intermittently. It's really frustrating!"
Mark (Code Reviewer): "I noticed the logging isn't very detailed here. We need to add more information about the request parameters and server-side errors to help debug this." What quality attribute is Mark primarily addressing with his comment?
Mark is focusing on Maintainability because detailed logging allows developers to easily understand the request parameters involved in the error. The incorrect options address different aspects of code quality: robustness deals with handling errors, performance concerns response time, and security focuses on data protection. Adding more logging directly contributes to making the codebase easier for others (and Sarah) to debug and fix.
15 / 33
During a Slack discussion about the upcoming release of a new microservice, Alex says: 'I'm worried this service is going to be incredibly difficult to update later. It has a ton of dependencies and complex logic.' His concern primarily relates to which quality attribute?
Alex's statement directly addresses maintainability, a key quality attribute focused on the ease with which software can be modified over its lifecycle. The other options – performance, security, and insufficient capacity— relate to different aspects of service operation but don't capture the core concern about future adaptability. A system with many dependencies and complex logic will naturally require more effort for updates, making maintainability a critical consideration.
16 / 33
PR Description:
"Implemented a new feature to allow users to upload profile pictures. Initial tests seem successful, but I'm concerned about the long-term maintainability of this code. It's quite complex and relies heavily on third-party image processing libraries."The question focuses on maintaining code quality over time. Option 1 correctly identifies that concern regarding future maintainability is being raised. The incorrect options either focus solely on immediate functionality (Option 3), ignore maintainability concerns entirely (Option 2), or misinterpret the PR's content. A good PR description should acknowledge potential long-term challenges.
17 / 33
Liam: "I'm seeing some weird spikes in latency when processing large data sets through this service. It seems to be struggling under load." Chloe (another developer) replies: "Have you considered the impact on *scalability*? We need to ensure the system can handle increasing volumes without significant performance degradation."
Which of the following best describes the core meaning behind Chloe's comment, relating to a quality attribute?Chloe is focusing on
scalability, which is a crucial quality attribute concerning how well a system can handle increased load. The key misconception here is that scalability isn't just about speed; it's fundamentally about the system's ability to *grow* and adapt without breaking down or experiencing significant performance drops under pressure. The other options represent different aspects of software quality – technical debt focuses on code design, robustness deals with error handling, and insufficient simply acknowledges a problem hasn't been identified.18 / 33
Sarah: "Hey team, I'm working on this new API endpoint for user profile updates. The response is coming back with a 502 error intermittently. It's really frustrating!"
Mark (Code Reviewer): "I noticed the logging isn't very detailed here. We need to add more information about the request parameters and server-side errors to help debug this." What quality attribute is Mark primarily addressing with his comment?
Mark is focusing on Maintainability because detailed logging allows developers to easily understand the request parameters involved in the error. The incorrect options address different aspects of code quality: robustness deals with handling errors, performance concerns response time, and security focuses on data protection. Adding more logging directly contributes to making the codebase easier for others (and Sarah) to debug and fix.
19 / 33
During a Slack discussion about the upcoming release of a new microservice, Alex says: 'I'm worried this service is going to be incredibly difficult to update later. It has a ton of dependencies and complex logic.' His concern primarily relates to which quality attribute?
Alex's statement directly addresses maintainability, a key quality attribute focused on the ease with which software can be modified over its lifecycle. The other options – performance, security, and insufficient capacity— relate to different aspects of service operation but don't capture the core concern about future adaptability. A system with many dependencies and complex logic will naturally require more effort for updates, making maintainability a critical consideration.
20 / 33
PR Description:
"Implemented a new feature to allow users to upload profile pictures. Initial tests seem successful, but I'm concerned about the long-term maintainability of this code. It's quite complex and relies heavily on third-party image processing libraries."The question focuses on maintaining code quality over time. Option 1 correctly identifies that concern regarding future maintainability is being raised. The incorrect options either focus solely on immediate functionality (Option 3), ignore maintainability concerns entirely (Option 2), or misinterpret the PR's content. A good PR description should acknowledge potential long-term challenges.
21 / 33
Liam: "I'm seeing some weird spikes in latency when processing large data sets through this service. It seems to be struggling under load." Chloe (another developer) replies: "Have you considered the impact on *scalability*? We need to ensure the system can handle increasing volumes without significant performance degradation."
Which of the following best describes the core meaning behind Chloe's comment, relating to a quality attribute?Chloe is focusing on
scalability, which is a crucial quality attribute concerning how well a system can handle increased load. The key misconception here is that scalability isn't just about speed; it's fundamentally about the system's ability to *grow* and adapt without breaking down or experiencing significant performance drops under pressure. The other options represent different aspects of software quality – technical debt focuses on code design, robustness deals with error handling, and insufficient simply acknowledges a problem hasn't been identified.22 / 33
Reviewer: 'This function is doing too much. It handles user authentication, data validation, and database interaction – it's a code smell! We should break this down into smaller, more focused units.'
Which of the following best describes the reviewer's concern regarding code cohesion?Code cohesion refers to the degree to which elements within a module are related. Low cohesion indicates that a function tries to do too many different things, making it harder to understand and modify without unintended consequences. The reviewer is highlighting this issue by suggesting separation of concerns.
23 / 33
Team Lead (during a daily standup): 'Okay team, I'm seeing some reports that the new payment processing service is experiencing intermittent timeouts. Users are reporting transactions failing after several minutes. Has anyone investigated?'
Which of the following best represents the Team Lead's primary concern regarding availability in this situation?Availability in a service context refers to the percentage of time it's operational and accessible. The intermittent timeouts directly translate to periods where the service isn't available for use, causing disruption and potentially impacting business outcomes. While response times are related, availability is the core problem being addressed here.
24 / 33
API Response (from a user profile update endpoint):
```json
{
"status": "502",
"message": "Bad Gateway"
}
```
What does this API response primarily indicate about the reliability of the service?A
502 Bad Gateway status code indicates that the server acting as a gateway or proxy received an invalid response from another server upstream. This strongly suggests a transient issue—the service is temporarily unreliable and needs investigation rather than being considered permanently broken.25 / 33
Developer (in a Slack channel): 'I've been profiling the image processing service, and it's consuming almost all of the CPU on my server. The algorithm is highly computationally intensive, especially when handling large images.'
What aspect of performance is this developer primarily addressing?Throughput measures how efficiently a system handles requests. The developer's statement about CPU consumption directly relates to the system's capacity to process images quickly – indicating a potential bottleneck in its performance.
26 / 33
During a code review meeting, Sarah comments to David: 'This module is incredibly tightly coupled with the UI. Changes there will almost certainly break this logic.' What does Sarah primarily mean when discussing *tight coupling* in this context?
Sarah refers to 'tight coupling' here meaning a high degree of interdependence between the module and the UI. This indicates that changes in one component are highly likely to have unintended consequences in the other due to direct access and modification. Option A discusses database connections (a separate concern), option C relates to deployment, and option D describes dependency management – all less directly relevant to Sarah's core observation.
27 / 33
A Slack message from Ben reads: 'I'm seeing a significant increase in the number of 500 errors coming from our microservice. The logs show a lot of 'NullPointerException' errors – it seems like we're not handling null values correctly.' What is Ben primarily highlighting as a potential cause for these errors?
Ben is focusing on 'NullPointerException' errors, which directly indicate a problem with how the code handles missing or null data. This suggests that input validation and error handling are inadequate, allowing invalid data to propagate through the system. Options A, C, and D represent other potential issues but don't directly address the specific symptom described in the message.
28 / 33
During a standup meeting, Maria says: 'I'm facing challenges with the performance of this new feature. The API response times are consistently high, even under low load.' What is Maria most likely concerned about regarding *response time* in this scenario?
Maria's concern about 'high response times' directly relates to the efficiency of database queries. Slow or unoptimized queries are a common cause of performance bottlenecks in APIs. While options A, C, and D represent potential architectural issues, the core problem is identified as inefficient database interactions.
29 / 33
Alex is explaining a recent issue with the new recommendation engine to the team. He says: 'The system's been throwing a lot of 'TimeoutException' errors when processing complex user profiles. It's taking an unusually long time – sometimes over 30 seconds – and we're getting reports from users that their recommendations aren't appearing.' What aspect of code quality is Alex *most* likely highlighting in this situation?
Alex is focusing on the system's responsiveness and its ability to consistently deliver results. A 'TimeoutException' directly indicates a problem with performance – specifically, the system isn't completing tasks within an acceptable timeframe. While reliability and maintainability could be impacted, the immediate concern is the slow response time.
30 / 33
During a code review, David points out: 'This class has far too many responsibilities – it manages user authentication, handles data validation, and interacts with the database. It's a clear violation of the Single Responsibility Principle.' What is David primarily referring to when he describes this situation?
David is identifying a problem with *cohesion* – the degree to which elements within a class are related. A class that handles multiple unrelated responsibilities has low cohesion, meaning it's not focused on one specific task. This leads to increased complexity and potential bugs.
31 / 33
The team is discussing the design of a new microservice. Sarah states: 'I'm concerned that this service will be difficult to test effectively due to its tight integration with several other services and its complex state management.' What quality attribute is Sarah primarily raising concerns about?
Sarah's focus on 'testability' reflects the difficulty of isolating and testing a system that is heavily coupled with other components. Tight integration makes it harder to create focused tests and can lead to flaky or unreliable results.
32 / 33
A Slack message from Mark reads: 'I'm seeing a lot of `NullPointerException` errors in the logging module. It appears we're not handling null values appropriately – it's leading to unpredictable behavior.' What type of code quality issue is Mark describing?
Mark's message highlights a problem with the code's ability to gracefully manage unexpected data. 'NullPointerException' errors directly indicate inadequate error handling – specifically, missing checks for null values before operating on variables. This is a fundamental aspect of robust and reliable code.
33 / 33
During a standup meeting, Emily says: 'We've been getting reports that the user notification service has a high error rate. The logs show many instances of the service failing to connect to our messaging provider.' What code quality attribute is Emily most concerned about?
Emily's statement directly addresses the service's ability to consistently function as intended. A high error rate when connecting to a messaging provider signifies a problem with *reliability* – the system isn't reliably delivering notifications.
Frequently Asked Questions
What does the "Software Quality Attributes" exercise practise?
Practice English vocabulary for ISO 25010 quality attributes: maintainability, reliability, portability, performance efficiency, and quality attribute trade-offs. 5 exercises.
How many questions are in this exercise?
This exercise has 33 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Code Quality & Metrics category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Software Quality Attributes" part of a larger series?
Yes — it's one exercise in the Code Quality & Metrics category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Quality & Metrics category page for related exercises, or browse the main Exercises hub for other IT English topics.