ISTQB Foundation Level Exam Crash Course Part-23

Posted in: ISTQB Foundation Level Exam Crash Course

1) Supplier issues:

a) Failure of a third party to deliver on time or at all.

b) Contractual

issues, such as meeting acceptance criteria.c) Organizational factors:

d) Skills, training and staff shortages.

2) Personal issues.

a) Political issues, such as problems that stop testers communicating their needs and test results.

b) Failure by the team to follow up on information found in testing and reviews (e.g. not improving development and testing practices).

c) Improper attitude toward or expectations of testing (e.g. not appreciating the value of finding defects during testing).

3) Technical issues:

a) Problems in defining the right requirements.

b) The extent that requirements can be met given existing project constraints.

c) Test environment not ready on time.

d) Late data conversion, migration planning and development and testing data conversion/migration tools.

e) Low quality of the design, code, configuration data, test data and tests.

For each risk identified a probability (chance of the risk being realized) and impact (what will happen if the risk is realized) should be identified as well as the identification and management of any mitigating actions (actions aimed at reducing the probability of a risk occurring, or reducing the impact of the risk if it did occur).

When analyzing, managing and mitigating these risks the test manager is following well-established project management principles provided within project management methods and approaches. The project risks recognized during test planning should be documented in the IEEE 829 test plan for the ongoing management and control of existing and new project risks a risk register should be maintained by the test leader.

<<<<<< =================== >>>>>>

Q. 112: What are the different types of Product Risks?

When planning and defining tests a test leader or tester using a risk-based testing approach will be managing product risks.

Potential failure areas (adverse future events or hazards) in software are known as product risks, as they are a risk to the quality of the product. In other words, the potential of a defect occurring in the live environment is a product risk. Examples of product risks are:

1) Failure-prone software delivered.

2) The potential that a defect in the software/hardware could cause harm to an individual or company.

3) Poor software characteristics (e.g. functionality, security, reliability, usability, performance).

4) Poor data integrity and quality (e.g. data migration issues, data conversion problems, data transport problems, violation of data standards).

5) Software that does not perform its intended functions.

Risks are used to decide where to start testing in the software development life cycle, e.g. the risk of poor requirements could be mitigated by the use of formal reviews as soon as the requirements have been documented at the start of a project. Product risks also provide information enabling decisions regarding how much testing should be carried out on specific components or systems, e.g. the more risk there is, the more detailed and comprehensive the testing may be. In these ways testing is used to reduce the risk of an adverse effect (defect) occurring or being missed.

Mitigating product risks may also involve non-test activities. For example, in the poor requirements situation, a better and more efficient solution may be simply to replace the analyst who is writing the poor requirements in the first place.

<<<<<< =================== >>>>>>

Q. 113: What are the benefits of using a risk-based approach to testing?

Risk-based approach to testing provides proactive opportunities to reduce the levels of product risk starting in the initial stages of a project. It involves the identification of product risks and how they are used to guide the test planning, specification and execution.

In a risk-based approach the risks identified:

a) Will determine the test techniques to be employed, and/or the extent of testing to be carried out, e.g. some companies define which test techniques should be used for each level of risk: the higher the risk, the higher the coverage required from test techniques;

b) Prioritize testing in an attempt to find the critical defects as early as possible, e.g. by identifying the areas most likely to have defects (the most complex) the testing can be focused on these areas;

c) Will determine any non-test activities that could be employed to reduce risk, e.g. to provide training to inexperienced designers.

<<<<<< =================== >>>>>>

Q. 114: What are the after effects of using risk management approach in testing?

Risk-based testing draws on the collective knowledge and insights of the project stakeholders, testers, designers, technical architects, business reps and anyone with knowledge of the solution to determine the risks and the levels of testing to address those risks.

To ensure that the chance of a product failure is minimized, risk management activities provide a disciplined approach:

1) To assess continuously what can go wrong (risks). Regular reviews of the existing and looking for any new product risks should occur periodically throughout the life cycle.

2) To determine what risks are important to deal with (probability � impact). As the project progresses, owing to the mitigation activities risks may reduce in importance, or disappear altogether.

3) To implement actions to deal with those risks (mitigating actions).

Testing supports the identification of new risks by continually reviewing risks of the project deliverables throughout the life cycle; it may also help to determine what risks are important to reduce by setting priorities; it may lower uncertainty about risks by, for example, testing a component and verifying that it does not contain any defects; and lastly by running specific tests it may verify other strategies that deal with risks, such as contingency plans.

Testing is a risk control activity that provides feedback about the residual risk in the product by measuring the effectiveness of critical defect removal and by reviewing the effectiveness of contingency plans.

<<<<<< =================== >>>>>>

Q. 115: What are different levels of independence of testing in an organization?

Independent testing is testing carried out by someone other than the creator (developer) of the code being tested. By remaining independent it is possible to improve the effectiveness of testing if implemented correctly.

As humans we are all capable of making mistakes, from the simplest misspelling or wrong use of syntax to fundamental errors at the core of any documents we write. The problem is that as authors we are less able to see our own errors than someone else, who is less directly associated with the document, would be. This is a problem that is made worse, in the world of software development, by the differing �world view� of testers and developers. A developer, as the creator and owner of documents and code related to development, perceives these deliverables as being correct when they are delivered. The general awareness that we all make mistakes is, at this stage, overridden by the belief that what has been produced is what is required. A tester, by contrast, will take the view that anything delivered for testing is likely to contain errors and will search diligently to identify and locate those errors.

This is where independent testing is important, as it is genuinely hard for authors to identify their own errors, but it is easier for others to see them. There are many options for many levels of independence. In general, the more remote a tester is from the production of the document, the greater is the level of independence. Following figure indicates the most common roles and the levels of independence they bring.

The most common roles and the levels of independence

Levels of independent testing

Of course independence comes at a price. The greater the level of independence, the greater the likelihood of errors in testing arising from unfamiliarity. Levels of independence will also depend on the size of the organization. In smaller organizations where everybody contributes to every activity it is harder to differentiate the role of the tester from any other role, and therefore testers may not be very independent at all. The key in these circumstances is for the testers to have independence of mind, not necessarily to be in an independent (separate) team. In organizations where there are clearly defined roles it is a lot easier for a tester to remain independent.

It is also possible to mix and match the levels of independence, e.g. a test team made up of permanent resources, business unit resources and contractors. For large, complex or safety-critical projects, it is usually best to have multiple levels of testing, with some or all of the levels done by independent testers.

The �agile� approach to development challenges the traditional approach to independence. In this approach everybody takes on multiple roles and so maintaining total independence is not always possible. A tester in this situation has to be able to switch to an independent view, at the relevant points in the project. Testers achieve this independence of view by not assuming anything and by not starting to own the software like a developer would, e.g. the view that was how it was developed to work.

Part – 24 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification

0 0 votes

Article Rating