ISTQB Foundation Level Exam Crash Course Part-2
This is Part 2 of 35 containing 5 Questions (Q. 6 to 10) 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. 6: How would you explain the different branches of a typical V-model for software development?
Refer following figure explaining a typical V-model
A) Left Side Branch: As for the waterfall model, the left-hand side of the model focuses on elaborating the initial requirements, providing successively more technical detail as the development progresses.
In the model shown, these are:
1) Requirement specification – capturing of user needs.
2) Functional specification – definition of functions required to meet user needs.
3) Technical specification – technical design of functions identified in the functional specification.
4) Program specification – detailed design of each module or unit to be built to meet required functionality.
These specifications can be reviewed to check for the following:
a) Conformance to the previous work-product (so in the case of the functional specification, verification would include a check against the requirement specification).
b) That there is sufficient detail for the subsequent work-product to be built correctly (again, for the functional specification, this would include a check that there is sufficient information in order to create the technical specification).
c) That it is testable – is the detail provided sufficient for testing the work-product?
B) Middle Branch: The middle of the V-model shows that planning for testing should start with each work-product. Thus, using the requirement specification as an example, acceptance testing would be planned for, right at the start of the development.
C) Right Side Branch: The right-hand side focuses on the testing activities. For each work-product, a testing activity is identified. These are shown in figure above
1) Testing against the requirement specification takes place at the acceptance testing stage.
2) Testing against the functional specification takes place at the system testing stage.
3) Testing against the technical specification takes place at the integration testing stage.
4) Testing against the program specification takes place at the unit testing stage.
This allows testing to be concentrated on the detail provided in each work-product, so that defect can be identified as early as possible in the life cycle, when the work-product has been created.
Remembering that each stage must be completed before the next one can be started, this approach to software development pushes validation of the system by the user representatives right to the end of the life cycle. If the customer needs were not captured accurately in the requirement specification, or if they change, then these issues may not be uncovered until the user testing is carried out. Fixing problems at this stage could be very costly; in addition, it is possible that the project could be cancelled altogether.
<<<<<< =================== >>>>>>
Q. 7: How would you explain the iterative development model for software development?
This is one where the requirements do not need to be fully defined before coding can start. Instead, a working version of the product is built, in a series of stages, or iterations – hence the name iterative or incremental development. Each stage encompasses requirements definition, design, code and test.
Refer following figure explaining typical Iterative Development Model
An Iterative model for development has fewer steps, but involves user from the beginning. These steps are typically:
1) Define Iteration Requirements
2) Buid Iteration
3) Test Iteration
This type of development is often referred to as cyclical – we go �round the development cycle a number of times�, within the project. The project will have a defined time-scale and cost. Within this, the cycles will be defined. Each cycle will also have a defined time-scale and cost. The cycles are commonly referred to as time-boxes. For each time-box, a requirement is defined and a version of the code is produced, which will allow testing by the user representatives. At the end of each time-box, a decision is made on what extra functionality needs to be created for the next iteration. This process is then repeated until a fully working system has been produced.A key feature of this type of development is the involvement of user representatives in the testing. Having the users represented throughout minimizes the risk of developing an unsatisfactory product. The user representatives are empowered to request changes to the software, to meet their needs.
This approach to software development can pose problems, however.
The lack of formal documentation makes it difficult to test. To counter this, developers may use test-driven development. This is where functional tests are written first, and code is then created and tested. It is reworked until it passes the tests.
In addition, the working environment may be such that developers make any changes required, without formally recording them. This approach could mean that changes cannot be traced back to the requirements or to the parts of the software that have changed. Thus, traceability as the project progresses is reduced. To mitigate this, a robust process must be put in place at the start of the project to manage these changes (often part of a configuration management process
Another issue associated with changes is the amount of testing required to ensure that implementation of the changes does not cause unintended changes to other parts of the software (this is called regression testing.
Forms of iterative development include prototyping, rapid application development (RAD) and agile software development. A proprietary methodology is the Rational Unified Process (RUP).
<<<<<< =================== >>>>>>
Q. 8: What are the significant benefits of an iterative model for software development?
1) The involvement of user representatives in the testing.
2) Minimized risk of developing an unsatisfactory product due to the availability of users representative throughout.
3) The user representatives are empowered to request changes to the software, to meet their needs.
<<<<<< =================== >>>>>>
Q. 9: What are the attributes of good testing across the development life cycle?
Some of the characteristics of good testing effort across the development life cycle are:
1) Early test design: In the V-model, the test planning begins with the specification documents. This activity is part of the fundamental test process. After test planning, the documents would be analyzed and test cases designed. This approach would ensure that testing starts with the development of the requirements, i.e. a proactive approach to testing is undertaken. As we saw in iterative development, test-driven development may be adopted, pushing testing to the front of the development activity.
2) Each work-product is tested: In the V-model, each document on the left is tested by an activity on the right. Each specification document is called the test basis, i.e. it is the basis on which tests are created. In iterative development, each release is tested before moving on to the next.
3) Testers are involved in reviewing requirements before they are released: In the V-model, testers would be invited to review all documents from a testing perspective.
<<<<<< =================== >>>>>>
Q. 10: What are the different levels of testing?
The typical levels of testing are:
1) Unit (Component) testing
2) Integration testing
3) System testing
4) Acceptance testing
Each of these test levels will include tests designed to uncover problems specifically at that stage of development. These levels of testing can be applied to iterative development also. In addition, the levels may change depending on the system. For instance, if the system includes some software developed by external parties, or bought off the shelf, acceptance testing on these may be conducted before testing the system as a whole.
Part – 3 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.
Thanks for providing the materials. Very useful for me. Cleared ISTQB.
Let mew know how to down load ISTQB exam paper.
I could not found.
@ Ramoji,
HI.. can u pls let me know your approach for preparing ISTQB exam and the books you read.. pls let me know at roopa.yabaluri@gmail.com
Great work!!!!
Very useful Thanks.