ASTQB Practice Questions

Testing the interaction between a mobile application and the device is critical. The physical device is the primary medium through which the user interacts with the application (via touchscreen, buttons, etc.) and how the application connects to external services, such as the internet for a banking app. This interaction testing validates that the application functions correctly with the device's hardware (e.g., network radios, GPS, camera), operating system, and can handle interruptions (e.g., incoming calls, notifications). For a high-risk application like mobile banking, ensuring this interaction is seamless and reliable is essential for functionality, security, and user trust.

A. This is incorrect because functional testing for mobile applications must include device interactions to cover real-world usage scenarios and hardware dependencies.

C. This is incorrect. Native applications are specifically designed to leverage device hardware and OS features, making interaction testing more critical, not less. Device fragmentation requires testing across various hardware.

D. This is incorrect because it suggests an impractical and inefficient scope. Testing should be risk-based, focusing on device features the application actually uses, not every single feature the device possesses.

---

1. ISTQB® Certified Tester Foundation Level - Mobile Application Testing Syllabus, Version 2019.

Section 1.3.1, "Mobile Device and Platform Fragmentation": This section explains the challenges posed by diverse hardware, screen sizes, and OS versions, stating, "This fragmentation is a major challenge for testing." This directly supports the need to test software-device interaction.

Section 3.2.2, "Real Devices": This section highlights the necessity of using physical devices for testing, noting they are essential for "performance testing, interoperability testing, and any testing that requires specific hardware components." This validates the reasoning in option B.

Section 4.2, "Mobile Application Test Types": This section lists specific tests like "Interruption Testing" and "Testing of Hardware-related Features," which are entirely focused on the interaction between the application and the device, refuting option A. The targeted nature of these tests also contradicts the exhaustive approach suggested in option D.

Boundary Value Analysis (BVA) is a test design technique that focuses on the values at the edges or boundaries of equivalence partitions. The problem defines six valid partitions for scores (1-49, 50-59, etc.) and two invalid partitions (scores 100). This creates seven distinct boundaries where the system's behavior changes: at the minimum/maximum valid scores (1 and 100) and between each adjacent grade range (e.g., between 49 and 50).

Standard two-point BVA requires testing the value on each side of every boundary. The seven boundaries are 0/1, 49/50, 59/60, 69/70, 79/80, 89/90, and 100/101. Each boundary requires two test cases, resulting in a total of 7 2 = 14 test cases.

A. 8: This count likely represents testing only one value from each of the eight partitions (six valid, two invalid), which is equivalence partitioning, not BVA.

C. 10: This number does not correspond to a standard application of BVA for the given ranges and would result in incomplete boundary coverage.

D. 12: This may represent testing only the six boundaries between the valid partitions (6 2 = 12), incorrectly omitting the tests for the outer boundaries (0/1 and 100/101).

1. International Software Testing Qualifications Board (ISTQB). (2018). Certified Tester Foundation Level Syllabus 2018 V3.1.1. Section 4.2.2, "Boundary Value Analysis," describes BVA as a technique for testing at the boundaries of equivalence partitions.

2. Black, R., van Veenendaal, E., & Graham, D. (2019). Foundations of Software Testing: ISTQB Certification (4th ed.). Cengage Learning. In Chapter 4, Section 4.3.3, the authors explain that for each boundary, two tests are typically created: one on the boundary and one just off the boundary in the adjacent partition.

3. Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing (3rd ed.). John Wiley & Sons. Chapter 4, "Test-Case Design Strategies," pp. 56-61, details BVA, emphasizing that errors tend to cluster around boundaries, justifying the selection of test cases on and around these boundary values.

Portability testing evaluates an application's ability to function effectively in different environments. For the future of a mobile application, this requires a forward-looking strategy. Testers and stakeholders must analyze market trends to anticipate which devices, operating systems, and form factors will become popular. This foresight is crucial for defining the scope of future portability tests, ensuring the application remains compatible and provides a good user experience as the mobile ecosystem evolves. This strategic anticipation guides the selection of devices and environments for testing, whether real or emulated, to proactively address future compatibility challenges.

A. Knowing how the application works today with today’s devices is regression or compatibility testing for the current state, not a requirement for future portability.

C. Predicting how personas will change relates primarily to future usability and user experience testing, not the technical environments central to portability testing.

D. Creating and using emulators is a method for testing. The fundamental requirement is first knowing which future device configurations to create or test on.

1. ISTQB® Certified Tester Foundation Level - Mobile Application Testing Syllabus (Version 2019). Section 3.3.2, "Portability Testing," discusses the challenge of device fragmentation. It states, "A test strategy must be created to determine which of the many devices should be tested," and suggests using "market share" and "trends" as key factors for device selection. This directly supports the need to anticipate future popular devices.

2. ISTQB® Certified Tester Advanced Level Test Analyst Syllabus (Version 3.1.2, 2021). Section 4.5, "Portability Testing," defines portability as testing the ease of transfer between environments. The syllabus emphasizes testing on "all specified target platforms," which for future planning, necessitates anticipating what those future platforms will be.

3. Gao, J., et al. (2015). Mobile Application Testing: A Tutorial. IEEE Computer, 48(2), 46-55. This academic tutorial on mobile testing highlights the importance of a device selection strategy. It notes that "factors such as a device’s market share, OS version, and screen resolution" are critical. For future-proofing, these factors must be projected forward based on market analysis and trends. (DOI: https://doi.org/10.1109/MC.2015.53, Page 51).

From a user's perspective, the immediate experience of using a mobile application is paramount. Usability testing ensures the application is intuitive, easy to navigate on various screen sizes, and provides a positive user experience. Performance testing addresses critical user expectations regarding speed, responsiveness, and efficient use of device resources like battery and data. Mobile users have low tolerance for slow, confusing, or resource-intensive applications, making these two non-functional test types particularly important for app adoption and retention. They directly reflect the "how well" an application works in the user's hands.

A. Suitability and Accuracy: These are fundamental functional requirements for any application, not characteristics uniquely critical to the mobile user's experience.

C. Portability and Usability: While users expect an app to work on their device (a facet of portability), performance is a more direct and constantly evaluated user concern than technical portability.

D. Performance and Security: Security is a critical attribute, but users often assume it is present. They are more likely to actively notice and be frustrated by poor usability on a moment-to-moment basis.

1. ISTQB® Certified Tester Foundation Level - Mobile Application Testing Syllabus, Version 2019.

Section 4.3, Usability Testing: "Mobile users have high expectations for usability. They expect applications to be intuitive, easy to learn, and efficient to use... Poor usability is a common reason for users to stop using an application." (p. 26)

Section 4.4, Performance Testing: "Performance is a key factor for the success of a mobile application. Users expect applications to be responsive and to have a minimal impact on device resources such as battery life and data consumption." (p. 27)

2. ISTQB® Certified Tester Advanced Level - Technical Test Analyst Syllabus, Version 3.1.1 (2021).

Section 4.2.1, Introduction to Performance Testing: This section emphasizes that performance testing evaluates system behavior under various load conditions, which directly relates to the user's expectation of responsiveness. (p. 31)

Section 4.4.1, Introduction to Usability Testing: This section defines usability as "The degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use," directly aligning with user expectations for a mobile app. (p. 40)

A native device simulator is a software tool designed to mimic the software environment and configurations of a specific mobile device. It allows developers and testers to run and test an application in an environment that behaves like a particular target device (e.g., a specific model of an iPhone or Android phone) without needing the physical hardware. This type of simulator replicates the device's operating system, screen resolution, and standard application programming interfaces (APIs), providing a representation of how the application will respond on that native platform.

A. A hybrid simulator is not a standard industry term; it could ambiguously refer to a tool for testing hybrid apps, not the specific function of simulating a device's native environment.

C. A web-based application simulator focuses on simulating different web browsers and screen sizes for testing web applications, not the underlying native device operating system and hardware characteristics.

D. A browsed-based application simulator is a less common term for a web-based simulator and is incorrect for the same reason; its focus is on the browser, not the specific device.

---

1. ISTQB® Certified Tester Foundation Level Mobile Application Testing Syllabus (CTFL-MAT), Version 2019.

Section 3.3.1, Simulators and Emulators: "A simulator creates an environment that mimics the behavior and configurations of a real device. For example, an iOS simulator can be used to simulate an iPhone or an iPad on a Mac computer." This directly supports the concept of a tool simulating a specific device's native environment.

2. Apple Developer Documentation.

About Simulator: "Simulator is an app on your Mac that you use to prototype and test your apps during the development process. Simulator lets you test your apps on a simulated iOS, iPadOS, watchOS, or tvOS device..." This documentation describes a tool that simulates specific, native Apple devices, which is the definition of a native device simulator.

3. Android Studio User Guide.

Run apps on the Android Emulator: "The Android Emulator simulates Android devices on your computer so that you can test your application on a variety of devices and Android API levels without needing to have each physical device." This describes a tool that simulates various specific Android devices, fitting the description in the question.

The primary role of testing within any software development lifecycle is to act as a risk management activity. It aims to provide stakeholders with sufficient information to make informed decisions about product release. This involves a pragmatic balance between ensuring quality and meeting business objectives, such as time-to-market. The goal is not to find every possible defect, which is impossible, but to focus test efforts on areas of highest risk. This approach helps prevent catastrophic failures in the live environment while ensuring that the testing process itself does not become an unreasonable bottleneck to the product's release schedule.

A. Testing is an integral activity that directly impacts project timelines; its duration and findings are critical inputs to any release schedule.

B. Intentionally ignoring all non-critical bugs is irresponsible, as it can lead to poor product quality, user dissatisfaction, and increased long-term maintenance costs.

C. According to the fundamental principles of testing, exhaustive testing (finding all failures) is impossible for any non-trivial software due to the vast number of input combinations and paths.

1. ISTQB® Certified Tester Foundation Level Syllabus, Version 2018 v3.1.1.

Section 1.3, Seven Testing Principles, Principle 2: "Exhaustive testing is impossible. Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases." This directly refutes option C.

Section 5.5.1, Test Management in Context: This section discusses how the test manager must consider the context of the project, including "project constraints, such as time, budget, and resources." This supports the idea that testing must not substantially slow progress (option D).

Section 5.2.1, Risk-Based Testing and Product Risk: "Product risk analysis... provides information for... determining the extent of testing to be carried out." This highlights the core concept of reducing the risk of failure, as stated in option D.

2. Ammann, P., & Offutt, J. (2016). Introduction to Software Testing (2nd ed.). Cambridge University Press.

Chapter 1, Section 1.2, Economics of Testing: The text explains that "the tester’s job is to find an acceptable tradeoff" between the cost of preventing failures and the cost of failures occurring in the field. This economic balance is central to the principle described in option D.

3. Jorgensen, P. C. (2013). Software Testing: A Craftsman's Approach (4th ed.). CRC Press.

Chapter 1, A Perspective on Testing, Section 1.1, The Tester's Role in a Software Development Organization: The author emphasizes that testing provides a "service to the developers" and management by providing information about the quality of the product. This information service is crucial for balancing release speed with risk, as described in option D.

A comprehensive test strategy for an application dependent on a peripheral must validate two key scenarios. First, testing with the peripheral ensures the application correctly utilizes the hardware for its intended features (interoperability). Second, testing without the peripheral is crucial for robustness testing. This verifies that the application handles the absence of the hardware gracefully, for instance, by displaying an informative message or disabling the relevant feature, rather than crashing or behaving unpredictably. This approach covers both positive and negative test cases for the dependency.

A. Testing the peripheral in isolation is hardware component testing, not the responsibility of the application tester, whose focus is on the integrated system.

B. This approach is incomplete. It only covers the "happy path" and fails to test the application's robustness and error handling when the peripheral is unavailable.

D. This suggests an unstructured, incidental approach. Effective testing requires a deliberate strategy to cover specific conditions, not assuming they will be tested "anyway."

1. ISTQB® Certified Tester Foundation Level Mobile Application Testing Syllabus 2019: Section 3.2.3, "Interoperability Testing," states that testing should focus on the "interaction with peripherals (e.g., headsets, chargers, external keyboards...)." This supports the requirement to test with the peripheral.

2. ISTQB® Certified Tester Advanced Level Technical Test Analyst Syllabus Version 4.0 (2021): Section 4.3.2, "Robustness," defines robustness testing as determining "the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions." The absence of a required peripheral is a stressful condition that must be tested, supporting the need to test without it.

3. Koomen, T., van der Aalst, L., Broekman, B., & Vroon, M. (2006). TMap Next: For result-driven testing. UTN Publishers. (A foundational text in software testing methodology often referenced in academic settings). Chapter 14, "Specification techniques," discusses cause-effect graphing and decision table testing, which encourage testing all combinations of conditions. In this context, the presence or absence of the peripheral are two distinct causes whose effects on the application must be explicitly tested.

A major differentiator between mobile and traditional software is user context and expectations. Users of traditional software, particularly in enterprise or professional environments, are often a "captive audience." They may be required to use a specific application for their job and have fewer alternatives, leading to a higher tolerance for performance issues like slowness. In contrast, the mobile application market is characterized by intense competition and low user switching costs. Mobile users have extremely low patience for performance problems and are very likely to uninstall a slow or unresponsive application in favor of a competitor. This difference in user commitment is a critical consideration for mobile development and testing strategies.

A. Mobile applications are not inherently easier to develop; they present unique challenges like device fragmentation, network variability, and resource constraints.

C. This is the opposite of observed behavior; mobile users are known for their low tolerance for slow performance and will quickly abandon such apps.

D. Traditional applications, especially large-scale enterprise systems, can be significantly more complex to develop than many mobile applications.

1. ISTQB® Certified Tester Foundation Level - Mobile Application Testing Syllabus, Version 2019.

Section 1.2.2, User Expectations: "Mobile users are often less tolerant of problems than desktop users. For example, a desktop user may be willing to wait for a slow application to load, but a mobile user is more likely to delete a slow application." This directly supports the rationale that traditional users are more committed or tolerant of slowness compared to mobile users.

2. Kaner, C., Falk, J., & Nguyen, H. Q. (1999). Testing Computer Software. John Wiley & Sons.

While not an ASTQB-specific document, this foundational text is often referenced in testing curricula. It discusses user context extensively. In Chapter 2, "The testing process," the concept of the user environment and expectations is highlighted as a key driver for testing. The context of a traditional desktop user (often at a desk, with a stable connection) is fundamentally different from a mobile user (on the go, with variable connectivity), which shapes their tolerance and commitment.

3. Gao, J., Bai, X., Tsai, W. T., & Uehara, T. (2014). Mobile Application Testing: A Tutorial. IEEE Computer, 47(4), 46-55. https://doi.org/10.1109/MC.2014.96

Section: "Challenges in Mobile Application Testing," p. 48: This peer-reviewed article, relevant to the academic underpinnings of testing, notes: "Users have high expectations for mobile applications... Poor performance, high battery consumption, or a clumsy user interface can lead to user frustration and application abandonment." This reinforces the low commitment of mobile users when faced with issues like slowness.

Equivalence Partitioning is a black-box test design technique where test cases are designed to exercise representative values from partitions. The tax rules create five distinct valid partitions for income:

1. Up to 5,000 EUR

2. 5,001 to 10,000 EUR

3. 10,001 to 15,000 EUR

4. 15,001 to 20,000 EUR

5. Above 20,000 EUR

The principle is to select one test value from within each partition. Option B (3000, 6000, 12000, 19000, 30000) is the only choice that provides a single, representative value from each of these five valid partitions, thus achieving 100% coverage for this technique.

A: Includes -1000, which belongs to an invalid equivalence partition (negative income), whereas the question specifically asks for valid partitions.

C: This set is incomplete as it fails to select any test values for the partitions covering incomes from 5,001-10,000 and 10,001-15,000 EUR.

D: This set is incomplete as it fails to select a test value for the partition covering incomes from 10,001-15,000 EUR.

1. ISTQB® Certified Tester Foundation Level Syllabus (CTFL) 2018 V3.1.1. Section 4.2.1, "Equivalence Partitioning," states: "Test cases are designed to cover each partition at least once... Coverage is measured as the number of equivalence partitions tested... divided by the total number of identified equivalence partitions." This principle directly supports selecting option B, which covers all five identified partitions.

2. Jorgensen, P. C. (2013). Software Testing: A Craftsman's Approach, Fourth Edition. CRC Press. In Chapter 7, "Domain Testing," the methodology for equivalence class testing is detailed. It specifies identifying partitions (classes) and selecting one representative value from each class as the minimum requirement for test cases, which validates the approach of choosing one value per identified tax bracket.

3. MIT OpenCourseWare. (2010). 6.170 Software Studio, Lecture 2: Testing. Massachusetts Institute of Technology. The lecture notes on black-box testing explain the strategy of partitioning the input space into equivalence classes where the program is expected to behave similarly. The testing strategy is to "pick one input from each class," which is precisely what option B accomplishes for the given problem. (Available at: ocw.mit.edu)

The scenario describes users abandoning the application immediately after the initial download and before any meaningful interaction ("never use it"). This points to a failure at the very first step of the user experience. Application launch time is the first performance characteristic a user encounters. An excessively long launch time creates a poor first impression and is a direct and plausible reason for immediate abandonment, thus aligning perfectly with the observed user behavior and the hypothesis that poor performance is the cause. Testing this specific metric is the most targeted way to validate the hypothesis.

A. User interface delays: These are experienced during interaction with the application's features, which the problem states is not occurring.

B. Irregular performance: This is a characteristic observed over a period of use, but users are abandoning the app before they can experience such variations.

C. Resource usage: High resource usage is a valid performance concern, but its negative effects are typically noticed during or after a session, not usually causing abandonment before the app even opens.

1. ISTQB® Certified Tester Performance Tester Syllabus (Version 2018): Section 2.2.2, "Performance Objectives," discusses key performance indicators, including "Response time: The time it takes for the system to respond to a user’s request." Application launch is the system's response to the user's first request (opening the app). A failure to meet user expectations for this initial response time is a critical performance risk.

2. ISTQB® Certified Tester Advanced Level Syllabus - Technical Test Analyst (Version 3.1.2, 2021): Section 4.2.1, "Introduction," highlights that performance testing addresses quality risks such as the "failure to meet user expectations regarding response times." The scenario presents a classic example where the initial response time (launch time) fails to meet user expectations, leading to abandonment.

3. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. Chapter 19, "Software Testing Strategies," discusses performance testing as a type of non-functional testing. It emphasizes evaluating system response time under various conditions. The initial launch is the first and most critical response time measurement from a new user's perspective.