So we have 0 (free of charge) boundary weights are -> 0, 0.1, 2.0 for 10$ we have -> 2.1, 12.0 for 17$ we have -> 12.1, 27.0 then we have 5$ per extra kilo -> 27.1, 28, 28.1, 29, 29.1 .... 150.0 and no more than 150kg -> 150.1

From those values we see that answer "2.0, 12.1, 27.0, 150.1" is the only one that has some of those values.

A. generating expected outputs: Typical commercial test execution tools do not generate expected outputs automatically. Expected outputs are usually defined by testers based on requirements, specifications, or domain knowledge. The tool can then compare actual outputs to these pre-defined expected outputs.

Why the other options are correct:

B. comparison of expected outcomes with actual outcomes: Test execution tools are designed to compare the actual outcomes of test runs with the expected outcomes to determine if the tests have passed or failed.

C. replaying inputs according to a programmed script: Test execution tools can replay a series of inputs according to pre-recorded or scripted test cases, automating the testing process.

D. recording test inputs: These tools often have the capability to record the actions of testers, which can then be used to create automated test scripts for future test execution.

Example for clarification:

·     Test execution tool functionality: A tester records a test case where they log into an application, perform a series of actions, and log out. The tool can replay these steps (C), record the inputs (D), and compare the actual results against the expected results (B) during execution. However, the expected results must be defined by the tester, not generated by the tool (A).

By understanding the limitations and capabilities of test execution tools, you can effectively use them to automate and streamline your testing processes.

B. Likelihood and Impact: These are the two primary factors used to quantify risks.

·     Likelihood (or Probability): This refers to the chance that a particular risk will occur.

·     Impact: This refers to the potential consequences or severity of the risk if it does occur.

Why the other options are incorrect:

A. Probability and Likelihood:

Probability and Likelihood essentially mean the same thing, referring to the chance of the risk occurring. This pair does not cover the consequences of the risk.

C. Impact and Cost:

While cost can be an important factor in understanding the impact of a risk, it is not one of the primary factors used to quantify risk on its own. Impact includes broader consequences beyond just cost.

D. Product and Project:

These terms refer to the scope of what is being developed or managed, not factors used to quantify risk.

Example for clarification:

·     Likelihood: There is a 30% chance of a data breach occurring.

·     Impact: If the data breach occurs, it could lead to severe financial loss and damage to the company's reputation.

By combining the likelihood and impact of a risk, organizations can prioritize which risks need more immediate attention and resources to mitigate.

C. Alpha testing: This type of testing is performed at the developer's site by internal staff or a small group of users. It is typically done towards the end of the development process but before beta testing.

Why the other options are incorrect:

A. Regression Testing:

Regression testing is performed to ensure that recent code changes have not adversely affected existing functionality. It can be done at any location, not specifically at the developing organization's site.

B. Integration testing:

Integration testing focuses on verifying that different modules or components of the application work together correctly. Like regression testing, it can be performed at various stages and locations during the development cycle.

D. Unit testing:

Unit testing involves testing individual components or modules of the software in isolation. Developers typically perform unit tests, but it is not specific to the developing organization's site and can be done wherever the developers are working.

Example for clarification:

·     Alpha testing example: A software development company finishes a new application and conducts alpha testing at their office, where internal testers and a few invited users try out the software to identify any major issues before it is released for broader beta testing.

Alpha testing is crucial for catching critical issues in a controlled environment before exposing the software to a larger audience during beta testing.

Following the arrows, S1 SO S1 S2 SO can be achieved by exercising the events D, A, B, C.

1.    Business Priority: The tests with higher business priority (1) should be executed first, followed by those with lower priority.

2.    Dependencies: Tests that are dependent on others must be scheduled accordingly. For example, R requires S to be run first.

3.    Regression Testing: Regression tests (Q and T) should only be run after all other tests have completed.

Sequence Justification:

·     S (Priority 2, No dependencies): Can be run first.

·     R (Priority 1, Requires S): Must follow S due to its dependency.

·     U (Priority 3, No dependencies): Can be run after S and R since it has no dependencies.

·     P (Priority 3, No dependencies, but code delivery is late): Can be run after S, R, and U.

·     Q (Priority 1, Regression testing only): Should be run after all other tests except T due to its regression testing requirement.

·     T (Priority 2, Regression testing only): Should be run last as it's also a regression test.

Why Other Options Are Incorrect:

A. S, R, P, U, Q, T: This option runs P before Q and T, but P has a lower priority and should be run later due to the late code delivery.

B. Q, R, S, T, P, U: Runs Q first, which is incorrect as Q is a regression test and should be run after all other tests.

C. R, Q, S, T, U, P: Starts with R, which is fine for priority, but runs Q second, which is a regression test and should be at the end.

Example:

·     Running a high-priority test first ensures critical functions are validated early.

·     Running dependent tests in order (e.g., S before R) ensures dependencies are met.

·     Regression tests (Q and T) should be at the end to confirm no issues arise from previous tests.

Requirement specifications, test cases, user guides are good candidates for manual static testing (reviews).

Memory leaks, performance and perspective based are not written documents, so we can't review them.

a. It can help derive test cases based on analysis of specification documents. (wrong, this is black box techniques)

b. It can identify tests not easily captured by formal techniques. (correct)

c. It can make good use of tester's experience and available defect data. (correct)

d. It finds more defects that more formal test design techniques. (wrong, error guessing complements other techniques)

Inspections are a type of static testing technique where the software work products are examined manually by a team. They can detect various issues but have limitations.

Why Other Options Are Correct:

A. Spelling and grammar faults in the documents: Inspections can identify these errors by reviewing the documentation.

C. Requirements that have been omitted from the design documents: Inspections can detect missing requirements by comparing design documents against the requirement specifications.

D. Variables not defined in the code: Inspections can spot such issues by manually reviewing the code for undefined variables.

Example:

A: Reviewing a design document, the inspection team notices several typos and corrects them.

C: During an inspection, the team finds that a critical requirement mentioned in the requirement document is not reflected in the design document.

D: While inspecting the code, the team identifies that a variable is used but never defined.

However, inspections cannot determine how much of the code has been covered by tests, which is typically measured by dynamic analysis tools that track code execution during testing. This is why option B is the correct answer.

A root cause of a bug refers to the fundamental reason why the bug occurred. The options listed can indeed be root causes for bugs in a software product.

Why Each Option is Correct:

·     The project had incomplete procedures for configuration management: Poor configuration management can lead to inconsistencies and integration issues, causing bugs.

·     The time schedule to develop a certain component was cut: Rushed development often results in inadequate testing and poor-quality code, leading to bugs.

·     The specification was unclear: Unclear or ambiguous specifications can lead to misunderstandings and incorrect implementation, causing bugs.

·     Use of the coding standards was not followed up: Not adhering to coding standards can result in code that is difficult to maintain and prone to errors, leading to bugs.

Example:

·     (I): Without proper configuration management, different team members might work with different versions of the code, causing integration issues.

·     (II): If a development phase is shortened, developers might skip thorough testing, resulting in undetected bugs.

·     (III): If the requirement says "the system should be fast" without specifying what "fast" means, developers might not implement the feature correctly.

·     (IV): If coding standards mandate error handling but developers do not follow them, unhandled errors might lead to system crashes.

Why Option (V) is Incorrect:

·     (V) The testers were not certified: While certification may reflect a tester’s knowledge, it is not a direct cause of bugs. Bugs are caused by defects in the product, not the qualifications of the testers.

Thus, options (I) through (IV) are correct root causes of bugs, making B the correct answer.