ISTQB Foundation Level Exam Crash Course Part-13
This is Part 13 of 35 containing 5 Questions (Q. 61 to 65) with detailed explanation as expected in ISTQB Foundation Level Exam Latest Syllabus updated in 2011
Deep study of these 175 questions shall be of great help in getting success in ISTQB Foundation Level Exam
Q. 61: How do we take a decision of which experience based test technique to use?
It is not a simple task to decide in favor of any particular technique. However following factors are helpful
1) Type of system
2) Regulatory standards
3) Customer or contractual requirements
4) Level of risk
5) Type of risk
6)
Test objectives
7) Documentation available
8) Knowledge of the testers
9) Time and budget
10) Development life cycle
11) Use case models
12) Experience of type of defects found
One or more of the above factors may be important on any given occasion. Some factors leave no room for any selection like the following:
# Regulatory or contractual requirements leave the tester with no choice.
# Test objectives, where they relate to exit criteria such as test coverage, may also lead to mandatory techniques.
# Where documentation is not available, or where time and budget are limited, the use of experience-based techniques may be favored.
# All others provide pointers within a broad framework: level and type of risk will push the tester towards a particular approach, where high risk is a good reason for using systematic techniques;
# Knowledge of testers, especially where this is limited, may narrow down the available choices;
# The type of system and the development life cycle will encourage testers to lean in one direction or another depending on their own particular experience.
There are few clear-cut cases, and the exercise of sound judgement in selecting appropriate techniques is a mark of a good test manager or team leader.
<<<<<< =================== >>>>>>
Q. 62: What are the reasons of failure of software systems?
The people who design the systems make mistakes. People make mistakes because they are fallible, but there are also many pressures that make mistakes more likely. Pressures such as deadlines, complexity of systems and organizations, and changing technology all bear down on designers of systems and increase the likelihood of errors in specifications, in designs and in software code. These errors are where major system failures usually begin.
If a document with an error in it is used to specify a component the component will be faulty and will probably exhibit incorrect behavior. If this faulty component is built into a system the system may fail. While failure is not always guaranteed, it is likely that errors in specifications will lead to faulty components and faulty components will cause system failure.
An error (or mistake) leads to a defect, which can cause an observed failure as shown in the following figure.
There are other reasons why systems fail. Environmental conditions such as the presence of radiation, magnetism, electronic fields or pollution can affect the operation of hardware and firmware and lead to system failure.
If we want to avoid failure we must either avoid errors and faults or find them and rectify them. Testing can contribute to both avoidance and rectification, as we will see when we have looked at the testing process in a little more detail.
If we wish to influence errors with testing we need to do the following
a) Begin testing as soon as we begin making errors
b) Begin testing right at the beginning of the development process
c) Continue testing until we are confident that there will be no serious system failures
d) Continue testing right up-to the end of the development process.
<<<<<< =================== >>>>>>
Q. 63: What are the different effects or harms of an incorrect software?
1) To people: e.g. by causing an aircraft crash in which people die, or by causing a hospital life support system to fail
2) To companies: e.g. by causing incorrect billing, which results in the company losing money
3) To the environment: e.g. by releasing chemicals or radiation into the atmosphere.
Software failures can sometimes cause all three of these at once. The scenario of a train carrying nuclear waste being involved in a crash has been explored to help build public confidence in the safety of transporting nuclear waste by train. A failure of the train’s on-board systems or of the signaling system that controls the train’s movements could lead to catastrophic results. This may not be likely but it is a possibility that could be linked with software failure. Software failures, then, can lead to:
a) Loss of money
b) Loss of time
c) Loss of business reputation
d) Injury
e) Death
<<<<<< =================== >>>>>>
Q. 64: What is the relation between Testing and Risk?
Risk is inherent in all software development. The system may not work or the project to build it may not be completed on time, for example. These uncertainties become more significant as the system complexity and the implications of failure increase. Intuitively, we would expect to test an automatic flight control system more than we would test a video game system. Why? Because the risk is greater.
There is a greater probability of failure in the more complex system and the impact of failure is also greater.
What we test, and how much we test it, must be related in some way to the risk. Greater risk implies more and better testing.
<<<<<< =================== >>>>>>
Q. 65: What is the relation between Testing and Quality?
Quality is hard to define. If a system meets its users’ requirements that constitutes a good starting point.
The software development process, like any other, must balance competing demands for resources. If we need to deliver a system faster (i.e. in less time), for example, it will usually cost more. The items at the corners (or vertices) of the triangle of resources shown in the following figure are time, money and quality. These three affect one another, and also influence the features that are or are not included in the delivered software.
One role for testing is to ensure that key functional and non-functional requirements are examined before the system enters service and any defects are reported to the development team for rectification. Testing cannot directly remove defects, nor can it directly enhance quality. By reporting defects it makes their removal possible and so contributes to the enhanced quality of the system. In addition, the systematic coverage of a software product in testing allows at least some aspects of the quality of the software to be measured. Testing is one component in the overall quality assurance activity that seeks to ensure that systems enter service without defects that can lead to serious failures.
One role for testing is to ensure that key functional and non-functional requirements are examined before the system enters service and any defects are reported to the development team for rectification. Testing cannot directly remove defects, nor can it directly enhance quality. By reporting defects it makes their removal possible and so contributes to the enhanced quality of the system. In addition, the systematic coverage of a software product in testing allows at least some aspects of the quality of the software to be measured. Testing is one component in the overall quality assurance activity that seeks to ensure that systems enter service without defects that can lead to serious failures.
Part – 14 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.