Chapter 6 Testing tool considerations Flashcards
What activity does this type of tool sit under?
‘Configuration management tools’
Tools to surppot management of testing a testware
What activity does this type of tool sit under?
‘Model-Based testing tools ‘
Tools to support test design and implementation
What activity does this type of tool sit under?
‘Dynamic analysis tools’
Tools to support performance measurement and dynamic analysis Performance
(D)
What activity does this type of tool sit under?
‘Test execution tools (e.g., to run regression tests) ‘
Tools to support test execution and logging
What activity does this type of tool sit under?
‘Performance testing tools’
Tools to support performance measurement and dynamic test analysis performance
What activity does this type of tool sit under?
‘Test harnesses’
Tool support for test execution and logging (D)
What activity does this type of tool sit under?
‘Requirements management tools (e.g., traceability to test objects)’
Tool to support test management of tesinting and testware
What activity does this type of tool sit under?
‘Static analysis tools’
Tool to support static testing (D)
What activity does this type of tool sit under?
‘Defect management tools’
Tool to support management of testing and testware (D)
What activity does this type of tool sit under?
‘Test data preparation tools’
Tools to support test design and test implementation
What activity does this type of tool sit under?
‘Coverage tools (e.g., requirements coverage, code coverage ‘
Tool support for test execution and logging
(D)
What activity does this type of tool sit under?
‘Continuous integration tools’
Tool to support management of testing and testware (D)
(D)
‘In addition to tools that support the general test process, there are many other tools that support more specific testing for non-functional characteristics. ‘ - what is this tool called?
Tool support for specialized testing needs
What are some of the benefits of test tools?
- Reduction in repetitive manual work (e.g., running regression tests, environment set up/tear down tasks, re-entering the same test data, and checking against coding standards), thus saving time
- Greater consistency and repeatability (e.g., test data is created in a coherent manner, tests are executed by a tool in the same order with the same frequency, and tests are consistently derived from requirements)
- More objective assessment (e.g., static measures, coverage)
- Easier access to information about testing (e.g., statistics and graphs about test progress, defect rates and performance)
What is the capturing test approach?
Capturing tests by recording the actions of a manual testers. A captured script is a linear representation with specific data and actions as part of each script.
What are the disadvantages of the capturing test approach?
- Does not scale to large numbers of test scripts
- This type of script may be unstable when unexpected events occur
- require ongoing maintenance as the system’s user interface evolves over time.
What is the data driven approach?
This test approach separates out the test inputs and expected results, usually into a spreadsheet, and uses a more generic test script that can read the input data and execute the same test script with different data.
What is the key word appraoch
This test approach, a generic script processes keywords describing the actions to be taken (also called action words), which then calls keyword scripts to process the associated test data.
What is the model based testing?
Tools enable a functional specification to be captured in the form of a model, such as an activity diagram. This task is generally performed by a system designer. The MBT tool interprets the model in order to create test case specifications which can then be saved in a test management tool and/or executed by a test execution tool (see ISTQB-CTFL-MBT).
What are the potential risks of using tools to support testing?
- Expectations for the tool may be unrealistic (including functionality and ease of use)
- The time, cost and effort for the initial introduction of a tool may be under-estimated (including training and external expertise)
- The time and effort needed to achieve significant and continuing benefits from the tool may be under-estimated (including the need for changes in the test process and continuous improvement in the way the tool is used)
- The effort required to maintain the test work products generated by the tool may be underestimated
- The tool may be relied on too much (seen as a replacement for test design or execution, or the use of automated testing where manual testing would be better)
- Version control of test work products may be neglected
- Relationships and interoperability issues between critical tools may be neglected, such as requirements management tools, configuration management tools, defect management tools and tools from multiple vendors
- The tool vendor may go out of business, retire the tool, or sell the tool to a different vendor
- The vendor may provide a poor response for support, upgrades, and defect fixes An open source project may be suspended
- A new platform or technology may not be supported by the tool
- There may be no clear ownership of the tool (e.g., for mentoring, updates, etc.)