TEST TOOL

Segun el glosaio del istqb, A software product that supports one or more test activities, such as
planning and control, specification, building initial files and data, test execution and test analysis.

A piece of software that is used to make the testing process more effective or efficient. In other
words, anything that makes testing easier, quicker, more accurate

WHY WE USE IT
Test tools can have one or more of the following purposes depending on the context:
 Improve the efficiency of test activities by automating repetitive tasks or tasks that require
significant resources when done manually (e.g., test execution, regression testing)
 Improve the efficiency of test activities by supporting manual test activities throughout the test
process (see section 1.4)
 Improve the quality of test activities by allowing for more consistent testing and a higher level of
defect reproducibility
 Automate activities that cannot be executed manually (e.g., large scale performance testing)
 Increase reliability of testing (e.g., by automating large data comparisons or simulating behavior)

TESTING TOOLS GENERAL INFORMATION

Simply acquiring a tool does not guarantee success. Each new tool introduced into an organization
will
require effort to achieve real and lasting benefits. There are potential benefits and opportunities with
the
use of tools in testing, but there are also risks. This is particularly true of test execution tools (which
is
often referred to as test automation).
Potential benefits of using tools to support test execution include:
 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)
Potential risks of using tools to support testing include:
 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 assets generated by the tool may be under-estimated
 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 assets 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

TESTING TOOLS CLASSIFICATION – 1

Tools can be classified based on several criteria such as purpose, pricing, licensing model (e.g.,
commercial or open source), and technology used. Tools are classified in this syllabus according to
the
test activities that they support.
Some tools clearly support only or mainly one activity; others may support more than one activity,
but are
classified under the activity with which they are most closely associated. Tools from a single
provider,
especially those that have been designed to work together, may be provided as an integrated suite.
Some types of test tools can be intrusive, which means that they may affect the actual outcome of
the
test. For example, the actual response times for an application may be different due to the extra
instructions that are executed by a performance testing tool, or the amount of code coverage
achieved
may be distorted due to the use of a coverage tool. The consequence of using intrusive tools is
called the
probe effect.

TESTING TOOLS CLASSIFICATION – 2

Tool support for test execution and logging
Many tools exist to support and enhance test execution and logging activities. Examples of these
tools
include:
 Test execution tools (e.g., to run regression tests)
 Coverage tools (e.g., requirements coverage, code coverage (D))
 Test harnesses (D)
 Unit test framework tools (D)

Tool support for performance measurement and dynamic analysis

Performance measurement and dynamic analysis tools are essential in supporting performance and
load
testing activities, as these activities cannot effectively be done manually. Examples of these tools
include:
 Performance testing tools
 Monitoring tools
 Dynamic analysis tools (D)

Tool support for specialized testing needs

In addition to tools that support the general test process, there are many other tools that support
more
specific testing issues. Examples of these include tools that focus on:
 Data quality assessment
 Data conversion and migration
 Usability testing
 Accessibility testing
 Localization testing
 Security testing
 Portability testing (e.g., testing software across multiple supported platforms)

TESTING TOOLS CLASSIFICATION – 3

Tool support for management of testing and testware
Management tools may apply to any test activities over the entire software development lifecycle.
Examples of tools that support management of testing and testware include:
 Test management tools and application lifecycle management tools (ALM)
 Requirements management tools (e.g., traceability to test objects)
 Defect management tools

Configuration management tools

 Continuous integration tools (D)
Tool support for static testing
Static testing tools are associated with the activities and benefits described in chapter 3. Examples
of
such tools include:
 Tools that support reviews
 Static analysis tools (D)

Tool support for test design and implementation

Test design tools aid in the creation of maintainable work products in test design and
implementation,
including test cases, test procedures and test data. Examples of such tools include:
 Test design tools
 Model-Based testing tools
 Test data preparation tools
 Acceptance test driven development (ATDD) and behavior driven development (BDD) tools
 Test driven development (TDD) tools (D)
In some cases, tools that support test design and implementation may also support test execution
and
logging, or provide their outputs directly to other tools that support test execution and logging.

KEY CONCEPTS OF THE F.O.T MAINTENANCE – 1

Once deployed to production environments, software and systems need to be maintained. Changes
of various sorts are almost inevitable in delivered software and systems, either to fix defects
discovered in operational use, to add new functionality, or to delete or alter already-delivered
functionality. Maintenance is also needed to preserve or improve non-functional quality
characteristics of the component or system over its lifetime, especially performance efficiency,
compatibility, reliability, security, compatibility, and portability.

When any changes are made as part of maintenance, maintenance testing should be performed,
both to evaluate the success with which the changes were made and to check for possible side-
effects (e.g., regressions) in parts of the system that remain unchanged (which is usually most of
the system).
Maintenance testing focuses on testing the changes to the system, as well as testing unchanged
parts that might have been affected by the changes. Maintenance can involve planned releases and
unplanned releases (hot fixes).

KEY CONCEPTS OF THE F.O.T MAINTENANCE – 2

There are several reasons why software maintenance, and thus maintenance testing, takes place,
both
for planned and unplanned changes.
We can classify the triggers for maintenance as follows:
 Modification, such as planned enhancements (e.g., release-based), corrective and emergency
changes, changes of the operational environment (such as planned operating system or
database upgrades), upgrades of COTS software, and patches for defects and vulnerabilities
 Migration, such as from one platform to another, which can require operational tests of the new
environment as well as of the changed software, or tests of data conversion when data from
another application will be migrated into the system being maintained
 Retirement, such as when an application reaches the end of its life
When an application or system is retired, this can require testing of data migration or archiving if
long
data-retention periods are required. Testing restore/retrieve procedures after archiving for long
retention
periods may also be needed. In addition regression testing may be needed to ensure that any
functionality that remains in service still works.
TESTER ROLE
Typical tester tasks may include:
 Review and contribute to test plans
 Analyze, review, and assess requirements, user stories and acceptance criteria, specifications,
and models for testability (i.e., the test basis)
 Identify and document test conditions, and capture traceability between test cases, test
conditions, and the test basis
 Design, set up, and verify test environment(s), often coordinating with system administration and
network management
 Design and implement test cases and test procedures
 Prepare and acquire test data
 Create the detailed test execution schedule
 Execute tests, evaluate the results, and document deviations from expected results
 Use appropriate tools to facilitate the test process
 Automate tests as needed (may be supported by a developer or a test automation expert)
 Evaluate non-functional characteristics such as performance efficiency, reliability, usability,
security, compatibility, and portability
 Review tests developed by others

NORMATIVITY AND STANDARDS

ISO9126: International Standard about the software quality evaluation based in the features:
Functionality, Fiability, Usability, efficiency, maintainability, portability and quality use.

IEEE829: Software standard to the software and documentation for the system test.

IEEE610: It refers to the software engineering terminology, identifies terms used actually in the
software engineering field.

TEST MANAGEMENT
Typical test manager tasks may include:
 Develop or review a test policy and test strategy for the organization
 Plan the test activities by considering the context, and understanding the test objectives and
risks. This may include selecting test approaches, estimating test time, effort and cost, acquiring
resources, defining test levels and test cycles, and planning defect management
 Write and update the test plan(s)
 Coordinate the test plan(s) with project managers, product owners, and others
 Share testing perspectives with other project activities, such as integration planning
 Initiate the analysis, design, implementation, and execution of tests, monitor test progress and
results, and check the status of exit criteria (or definition of done)
 Prepare and deliver test progress reports and test summary reports based on the information
gathered
 Adapt planning based on test results and progress (sometimes documented in test progress
reports, and/or in test summary reports for other testing already completed on the project) and
take any actions necessary for test control
 Support setting up the defect management system and adequate configuration management of
testware
 Introduce suitable metrics for measuring test progress and evaluating the quality of the testing
and the product
 Support the selection and implementation of tools to support the test process, including
recommending the budget for tool selection (and possibly purchase and/or support), allocating
time and effort for pilot projects, and providing continuing support in the use of the tool(s)
 Decide about the implementation of test environment(s)
 Promote and advocate the testers, the test team, and the test profession within the organization
 Develop the skills and careers of testers (e.g., through training plans, performance evaluations,
coaching, etc.)

MONITORING
The purpose of test monitoring is to gather information and provide feedback and visibility about test
activities. Information to be monitored may be collected manually or automatically and should be
used to
assess test progress and to measure whether the test exit criteria, or the testing tasks associated
with an
Agile project's definition of done, are satisfied, such as meeting the targets for coverage of product
risks,
requirements, or acceptance criteria.
Test control describes any guiding or corrective actions taken as a result of information and metrics
gathered and (possibly) reported. Actions may cover any test activity and may affect any other
software
lifecycle activity.

• Provide feedback to the team and stakeholders about the progress.

• Broadcasting the results to the associated members.

Finding and tracking the test metrics

Metric

Percentage of planned work done in test case preparation (or percentage of planned test cases
implemented)
 Percentage of planned work done in test environment preparation
 Test case execution (e.g., number of test cases run/not run, test cases passed/failed, and/or test
conditions passed/failed)
 Defect information (e.g., defect density, defects found and fixed, failure rate, and confirmation test
results)
 Test coverage of requirements, user stories, acceptance criteria, risks, or code
 Task completion, resource allocation and usage, and effort
 Cost of testing, including the cost compared to the benefit of finding the next defect or the cost
compared to the benefit of running the next test

ESTIMATION – 1
Test effort estimation involves predicting the amount of test-related work that will be needed in order
to
meet the objectives of the testing for a particular project, release, or iteration. Factors influencing
the test
effort may include characteristics of the product, characteristics of the development process,
characteristics of the people, and the test results,

poker

ESTIMATION – 2