ISTQB Foundation Level Exam Crash Course Part-25
This is Part 25 of 35 containing 5 Questions (Q. 121 to 125) 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. 121: What is a test approach & what is the right time to formulate the test approach?
A test approach is the implementation of a test strategy on a particular project. The test approach defines how testing will be implemented. A test approach can reflect testing for a whole organization, a program of work or an individual project.
Test approach can be:
1) Developed early in the life
cycle, which is known as preventative – in this approach the test design process is initiated as early as possible in the life cycle to stop defects being built into the final solution;2) Deferred until just before the start of test execution, which is known as reactive – this is where testing is the last development stage and is not started until after design and coding has been completed (sometimes it is identified as the waterfall approach, i.e. all development stages are sequential, the next not starting until the previous one has nearly finished).
A test approach includes all of the decisions made on how testing should be implemented, based upon the (test) project goals and objectives, as well as the risk assessment. It forms the starting point for test planning, selecting the test design techniques and test types to be employed. It should also define the software and test entry and exit criteria.
<<<<<< =================== >>>>>>
Q. 122: What are the different approaches or strategies that can be deployed in Testing projects?
There are many approaches or strategies that can be employed. All will depend on the context within which the test team is working, and may consider risks, hazards and safety, available resources and skills, the technology, the nature of the system (e.g. custom built vs COTS), test objectives and regulations, and may include:
1) Analytical approaches: Such as risk-based testing where testing is directed to areas of greatest risk (see later in this section for an overview of risk-based testing).
2) Model-based approaches: Such as stochastic testing using statistical information about failure rates (such as reliability growth models) or usage (such as operational profiles).
3) Methodical approaches: Such as failure-based (including error guessing and fault attacks), checklist based and quality-characteristic based.
4) Standard-compliant approaches: As specified by industry-specific standards such as The Railway Signaling standards (which define the levels of testing required) or the MISRA (which defines how to design, build and test reliable software for the motor industry).
5) Process-compliant approaches: These adhere to the processes developed for use with the various agile methodologies or traditional waterfall approaches.
6) Dynamic and heuristic approaches: Such as exploratory testing where testing is more reactive to events than pre-planned, and where execution and evaluation are concurrent tasks.
7) Consultative approaches: Such as those where test coverage is driven primarily by the advice and guidance of technology and/or business domain experts outside or within the test team.
8) Regression-averse approaches: Such as those that include reuse of existing test material, extensive automation of functional regression tests, and standard test suites.
Different approaches may be combined if required. The decision as to how and why they will be combined will depend on the circumstances prevalent in a project at the time. For example, an organization may as a standard use an agile method, but in a particular situation the structure of the test effort could use a risk-based approach to ensure the testing is correctly focused.
<<<<<< =================== >>>>>>
Q. 123: What are the factors that need to be considered when defining the strategy or approach for testing?
Deciding on which approach to take may be dictated by standards, e.g. those used in the motor industry that is set by MISRA, or at the discretion of those developing the approach or strategy. Where discretion is allowed, the context or scenario needs to be taken into account.
Following factors are considered when defining the strategy or approach:
1) Risk of failure of the project, hazards to the product and risks of product failure to humans, the environment and the company, e.g. the cost of failure would be too high (safety-critical environments).
2) Skills and experience of the people in the proposed techniques, tools and methods. There is no point in implementing a sophisticated component-level, technique-driven approach or strategy when the only resources available are business users with no technical grounding.
3) The objective of the testing endeavor and the mission of the testing team, e.g. if the objective is to find only the most serious defects.
4) Regulatory aspects, such as external and internal regulations for the development process, e.g. The Railway Signaling standards that enforce a given level of test quality.
5) The nature of the product and the business, e.g. a different approach is required for testing mobile phone coverage than for testing an online banking operation.
<<<<<< =================== >>>>>>
Q. 124: What do we mean by Test Planning?
Test planning is the most important activity undertaken by a test leader in any test project. It ensures that there is initially a list of tasks and milestones in a baseline plan to track progress against, as well as defining the shape and size of the test effort. Test planning is used in development and implementation projects as well as maintenance activities involving changes and fixes.
The main document produced in test planning is often called a master test plan or a project test plan. This document defines the high level of the test activities being planned. It is normally produced during the early phases of the project (e.g. initiation) and will provide sufficient information to enable a test project to be established (bearing in mind that at this point in a project little more than requirements may be available from which to plan).
<<<<<< =================== >>>>>>
Q. 125: What are the different sections of a Test plan?
The details of the test-level activities are documented within test-level plans, e.g. the system test plan.
These documents will contain the detailed activities and estimates for the relevant test level.
The IEEE 829 standard identifies that there should be a minimum of 16 sections present in a test plan, as described in the following table.
Section No. | Heading | Details |
1 | Test plan identifier | A unique identifying reference such as Doc ref XYZ v2? |
2 | Introduction | A brief introduction to the document and the project for which it has been produced |
3 | Test items | # A test item is a software item that is the object of testing
# A software item is one or more items of source code, object code, job control code, or control data # This section should contain any documentation references, e.g. design documents |
4 | Features to be tested | # A feature is a distinguishing characteristic of a software item (e.g. performance, portability, or functionality)
# Identify all software features and combinations of features and the associated test design specification |
5 | Features not to be tested | Identify all software features and significant combinations and state the reasons for not including them |
6 | Approach | Details the overall approach to testing; this could include a detailed process definition, or could refer to other documentation where the detail is documented, i.e. a test strategy |
7 | Item pass / fail criteria | Used to determine whether a software item has passed or failed its test |
8 | Suspension and resumption requirements | Suspension requirements define criteria for stopping part or all of the testing activity Resumption requirements specify the requirements to resume testing |
9 | Test deliverables | The documents that testing will deliver, e.g. from IEEE 829 documents such as:
# Test plans (for each test level) # Test specifications (design, case and procedure) # Test summary reports |
10 | Testing tasks | All tasks for planning and executing the testing, including the inter-task dependencies |
11 | Environmental needs | Definition of all environmental requirements such as hardware, software, PCs, desks, stationery, etc. |
12 | Responsibilities | Identifies the roles and tasks to be used in the test project and who will own them |
13 | Staffing and training needs | Identifies any actual staffing requirements and any specific skills and training requirements, e.g. automation |
14 | Schedule | Document delivery dates and key milestones |
15 | Risks and contingencies | High-level project risks and assumptions and a contingency plan for each risk |
16 | Approvals | Identifies all approvers of the document, their titles and the date of signature |
Part – 26 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.