ISTQB Foundation Level Exam Crash Course Part-5
This is Part 5 of 35 containing 5 Questions (Q. 21 to 25) 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. 21: What is the use of static testing techniques?
Static testing techniques are those techniques that test software without executing the code. This includes both the testing of work-products other than code, typically requirements or specification documents, and the testing of code without actually executing it.
There are two types of static testing techniques.
1) Review: It is typically used to find and remove errors and ambiguities in documents before they are used in the development process, thus reducing one source of defects in the code.
Reviews are normally completed manually;
2) Static analysis: It enables code to be analyzed for structural defects or systematic programming weaknesses that may lead to defects.
Static analysis is normally completed automatically using tools.
<<<<<< =================== >>>>>>
Q. 22: What do we do in reviews � one of static testing techniques?
A review is a systematic examination of a document by one or more people with the main aim of finding and removing errors. Giving a draft document to a colleague to read is the simplest example of a review, and one which can usually yield a larger crop of errors than we would have anticipated.
Reviews can be used to test anything that is written or typed; this can include documents such as requirement specifications, system designs, code, test plans and test cases.
Reviews represent the first form of testing that can take place during a software development life cycle, since the documents reviewed are normally ready long before the code has been written.
<<<<<< =================== >>>>>>
Q. 23: What are the key benefits of Reviews?
The practice of testing specification documents by reviewing them early on in the life cycle helps to identify defects before they become part of the executable code, and so makes those defects cheaper and easier to remove. The same defect, if found during dynamic test execution, would incur the extra cost of initially creating and testing the defective code, diagnosing the source of the defect, correcting the problem and rewriting the code to eliminate the defect.
Reviewing code against development standards can also prevent defects from appearing in test execution, though in this case, as the code has already been written, not all the additional costs and delays are avoided.
Important as cost and time saving are, though, there are also other important benefits of finding defects early in the life cycle, among them the following:
1) Development productivity can be improved and time-scales reduced because the correction of defects in early work-products will help to ensure that those work-products are clear and unambiguous. This should enable a developer to move more quickly through the process of writing code. Also, if defects are removed before they become executable code there will be fewer errors to find and fix during test execution.
2) Testing costs and time can be reduced by removing the main delays in test execution, which arise when defects are found after they have become failures and the tester has to wait for a fix to be delivered. By reviewing the code and removing defects before they become failures the tester can move more swiftly through test execution.
3) Reductions in lifetime costs can be achieved because fewer defects in the final software ensure that ongoing support costs will be lower.
4) Improved communication results as authors and their peers discuss and refine any ambiguous content discovered during review to ensure that all involved understand exactly what is being delivered.
<<<<<< =================== >>>>>>
Q. 24: What types of defects are generally found by Reviews?
The types of defects most typically found by reviews are:
1) Deviations from standards either internally defined and managed or regulatory / legally defined by Parliament or perhaps a trade organization.
2) Requirements defects – for example, the requirements are ambiguous, or there are missing elements.
3) Design defects – for example, the design does not match the requirements.
4) Insufficient maintainability – for example, the code is too complex to maintain.
5) Incorrect interface specifications – for example, the interface specification does not match the design or the receiving or sending interface.
6) All reviews aim to find defects, but some types of review find certain types of defects more effectively and efficiently than others.
<<<<<< =================== >>>>>>
Q. 25: What are the different types of review processes?
Review processes can vary widely in their level of formality, where formality relates to the level of structure and documentation associated with the activity. Some types of review are completely informal, while others are very formal.
The decision on the appropriate level of formality for a review is usually based on combinations of the following factors:
1) The maturity of the development process: The more mature the process is, the more formal reviews tend to be.
2) Legal or regulatory requirements: These are used to govern the software development activities in certain industries, notably in safety-critical areas such as railway signaling, and determine what kinds of review should take place.
3) The need for an audit trail: Formal review processes ensure that it is possible to trace backwards throughout the software development life cycle. The level of formality in the types of review used can help to raise the level of audit trail.
Part – 6 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.