Free ISTQB CT-UT Practice Exam with Questions & Answers

A usability test session is a controlled period during which a test participant performs tasks using the system under test while being observed by a moderator and sometimes additional stakeholders or observers. The goal is to understand how users interact with the interface and identify usability problems. Option A describes an individual task, not the whole session. Option C refers to a test plan or test script, and Option D describes a test technique rather than a usability session. Thus, option B provides the most accurate and comprehensive definition.

Usability reviews evaluate a system or interface against established usability principles or standards to identify potential issues before user testing. A recognized criterion for such reviews includes adherence to usability standards such as ISO 9241 or the Web Content Accessibility Guidelines (WCAG). These standards are derived from years of research and user-centered design principles. Options A and C do not directly relate to usability. Functional requirements (option B) refer to what the system should do, not how usable it is. Hence, option D is correct as usability standards provide a consistent, objective basis for evaluating usability.

A usability test task is a clearly defined activity that a participant is asked to perform during a usability test session. These tasks are typically created by the test designer or moderator and are designed to reflect realistic user goals (e.g., “Find and buy a product”). The purpose is to observe the participant’s interaction with the system and identify usability issues. Option A describes a usability test script, not a task. Option C defines usability evaluation in general, and D refers to a session, not a specific task. Therefore, B is correct.

Accessibility refers to designing products so that people with disabilities or limitations (permanent or temporary) can use them effectively. According to the Web Content Accessibility Guidelines (WCAG) and ISO standards, accessibility focuses on ensuring that users with vision, hearing, cognitive, or mobility impairments can access digital interfaces. Option D captures this intent accurately. The other options relate to general usability or responsiveness (e.g., device adaptability or user experience in noisy environments) but do not address the inclusive nature of accessibility as defined by official guidelines.

A usability evaluation is specifically designed to assess how real users interact with a software product. It focuses on effectiveness, efficiency, and user satisfaction in completing tasks. This may involve usability testing, expert reviews, or heuristic evaluations. The goal is to identify any usability problems and understand user behavior during real use.

Option A (Accessibility evaluation) targets inclusivity for users with disabilities, not general user interaction. Option B (Usability maturity assessment) evaluates the organization’s usability practices, and Option C (Risk assessment) evaluates potential project or system risks. Only option D directly involves observing and measuring user interaction.

In usability evaluations, a distinction is made between actual usability problems (where a user struggles to complete a task or is confused by the interface) and suggestions or ideas that users provide based on their preferences or perceived improvements. When a participant offers a new feature idea (such as a quick search box), this is classified as a “good idea” or “feature suggestion,” not necessarily a usability problem. It may inform future design enhancements but does not indicate a failure in usability for existing functionality.

A usability requirement specifies how usable a product or component must be, often in terms of effectiveness, efficiency, and user satisfaction, as defined in ISO 9241-11. These requirements ensure that the product meets specific human-centered design goals, such as allowing users to complete tasks accurately and quickly. Options A and C describe procedural or test setup elements, not actual usability requirements. Option B refers to personnel qualifications, which are not the same as usability requirements related to system behavior or performance.

The System Usability Scale (SUS) is a standardized, reliable tool used to measure perceived usability. It consists of 10 items with five response options (from strongly agree to strongly disagree). It is widely used due to its simplicity and effectiveness in providing a single score to reflect a user’s overall satisfaction with a system. Option A refers to ISO's definition of usability testing, B describes a task in usability testing, and D refers to a usability requirement, not SUS. Therefore, the correct description of SUS is option C.

The human-centered design process emphasizes iterative development—testing and refining designs through multiple cycles. In the scenario, the project manager interviewed users and evaluated a prototype but did not iterate based on feedback. Skipping iteration likely resulted in unmet user needs. Human-centered design, per ISO 9241-210, includes: understanding context of use, specifying requirements, producing design solutions, and evaluating—repeated iteratively. Hence, option D (“iterate”) is correct.

Moderating the usability test is a core activity during the actual usability test session. The moderator guides participants through tasks, ensures the session stays on track, and avoids introducing bias. Option A (testing the setup) happens before the session, during preparation. Option C (extracting findings) occurs during analysis, after the test. Option D (talking during task execution) should be minimized unless necessary, to avoid influencing user behavior. Therefore, option B is the only correct answer aligned with best practices in usability testing.