ISTQB Foundation Level Exam Crash Course Part-18
This is Part 18 of 35 containing 5 Questions (Q. 86 to 90) 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. 86: What is the purpose of using Configuration Management Tools?
Configuration management tools are designed primarily for managing: the versions of different software and hardware components that comprise a complete build of the system; and various complete builds of systems that exist for various software platforms over a period of time.
<<<<<< =================== >>>>>>
Q. 87: What are the factors on which benefits from Configuration Management Tools depend?
The amount of benefit to be obtained from using configuration management tools is largely dependent upon:
1) The complexity of system architechture;
2) The number and frequency of builds of the integrated system;
3) How much choice is available to customers – whether internal or external.
For example, a software house selling different versions of a product to many customers who run on a variety of operating systems is likely to find configuration management tools more useful than an internal development department working on a single operating system for a single customer.
<<<<<< =================== >>>>>>
Q. 88: What is the importance of traceability between testware and builds?
The use of configuration management tools allows traceability between testware and builds of an integrated system and versions of subsystems and modules. Traceability is useful for:
1) Identifying the correct version of test procedures to be used;
2) Determining which test procedures and other testware can be reused or need to be updated/maintained;
3) Assisting the debugging process so that a failure found when running a test procedure can be traced back to the appropriate version of a subsystem.
when running a test procedure can be traced back to the appropriate version of a subsystem.
<<<<<< =================== >>>>>>
Q. 89: What is the purpose of using review tools in static testing?
Review tools (also known as review process support tools) provide a framework for reviews or inspections. This can include:
1) Maintaining information about the review process, such as rules and checklists.
2) The ability to record, communicate and retain review comments and defects.
3) The ability to amend and reissue the deliverable under review whilst retaining a history or log of the changes made.
4) Traceability functions to enable changes to deliverables under review to highlight other deliverables that may be affected by the change.
5) The use of web technology to provide access from any geographical location to this information.
Review tools can interface with configuration management tools to control the version numbers of a document under review.
If reviews and inspections are already performed effectively then a review tool can be implemented fairly quickly and relatively cheaply. However, if such a tool is used as a means for imposing the use of reviews then the training and implementation costs will be fairly high (as would be the case for implementing a review process without such tools). These tools support the review process, but management buy-in to reviews is necessary if benefits from them are to be obtained in the long run.
Review tools tend to be more beneficial for peer (or technical) reviews and inspections rather than walkthroughs and informal reviews.
<<<<<< =================== >>>>>>
Q. 90: What is the purpose of using Static Analysis Tools?
Static analysis tools analyze code before it is executed in order to identify defects as early as possible. Hence they are used mainly by developers prior to unit testing. A static analysis tool generates lots of error and warning messages about the code.
Training may be required in order to interpret these messages and it may also be necessary to configure the tool to filter out particular types of warning messages that are not relevant. The use of static analysis tools on existing or amended code is likely to result in lots of messages concerning programming standards. A way of dealing with this situation should be considered during the selection and implementation process. For instance, it may be agreed that small changes to existing code should not use the static analysis tool whereas medium to large changes to existing code should use the static analysis tool. A rewrite should be considered if the existing code is significantly non-compliant.
Static analysis tools can find defects that are hard to find during dynamic testing. They can also be used to enforce programming standards (including secure coding), improve the understanding of the code and to calculate complexity and other metrics.
Some static analysis tools are integrated with dynamic analysis tools and coverage measurement tools. They are usually language specific, so to test code written in C++ you would need to have a version of a static analysis tool that was specific to C++.
Other static analysis tools come as part of programming languages or only work with particular development platforms. Note that debugging tools and compilers provide some basic functions of a static analysis tool, but they are generally not considered to be test tools.
The types of defect that can be found using a static analysis tool can include:
1) Syntax errors (e.g. spelling or missing punctuation).
2) Variance from programming standards (e.g. too difficult to maintain).
3) Invalid code structures (missing ENDIF statements).
4) The structure of the code means that some modules or sections of code may not be executed. Such unreachable code or invalid code dependencies may point to errors in code structure.
5) Portability (e.g. code compiles on Windows but not on UNIX).
6) Security vulnerabilities.
7) Inconsistent interfaces between components (e.g. XML messages produced by component A are not of the correct format to be read by component B).
8) References to variables that have a null value or variables declared but never used.
Part – 19 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.