Test Management

Suci Ayu Mawarni
Nim: 11453201908
Sistem Informasi
Sains dan Teknologi
Universitas Islam Negri Sultan Syarif Kasim Riau
TEST MANAGEMENT

In this section, let's talk about organizing a test
effort within a project. We'll look at the value of
independent testing, and discuss the potential benefits
and risks associated with independent testing. We will
examine the various types of different test team members
we might want on a test team. And we'll familiarize
ourselves with the typical tasks performed by test leaders
and testers.
As we go through this section, keep your eyes open
for the glossary terms tester, test leader and test manager.
1. TEST MANAGEMENT

The approaches to organizing a test team vary, as do the
places in the organization structure where the test team fits. Since
testing is an assessment of quality, and since that assessment is not
always positive, many organizations strive to create an
organizational climate where testers can deliver an independent,
objective assessment of quality.
When thinking about how independent the test team is,
recognize that independence is not an either/or condition, but a
continuum. At one end of the continuum lies the absence of
independence, where the programmer performs testing within the
programming team.
Moving toward independence, you find an integrated tester
or group of testers working alongside the programmers, but still
within and reporting to the development manager. You might find a
team of testers who are independent and outside the development
team, but reporting to project management.
INDEPENDENT AND INTEGRATED TESTING

We have seen that the location of a test team within a project
organization can vary widely. Similarly there is wide variation in the
roles that people within the test team play. Some of these roles occur
frequently, some infrequently. Two roles that are found within many test
teams are those of the test leader and the tester, though the same people
may play both roles at various points during the project. Let's take a look
at the work done in these roles, starting with the test leader.
Test leaders tend to be involved in the planning, monitoring, and
control of the testing activities and tasks. At the outset of the project, test
leaders, in collaboration with the other stakeholders, devise the test
objectives, organizational test policies (if not already in place), test
strategies and test plans. They estimate the testing to be done and
negotiate with management to acquire the necessary resources. They
recognize when test automation is appropriate and, if it is, they plan the
effort, select the tools, and ensure training of the team. They may consult
with other groups - e.g., programmers - to help them with their testing.
They lead, guide and monitor the analysis, design, implementation and
execution of the test cases, test procedures and test suites. They ensure
proper configuration management of the testware produced and
traceability of the tests to the test basis.
WORKING AS A TEST LEADER

As with test leaders, projects should include testers at the outset, though
it is often the case that project doesn't need a full complement of testers until the
test execution period. In the planning and preparation phases of the testing,
testers should review and contribute to test plans, as well as analyzing, review-
ing and assessing requirements and design specifications. They may be involved
in or even be the primary people identifying test conditions and cre- ating test
designs, test cases, test procedure specifications and test data, and may automate
or help to automate the tests. They often set up the test envi- ronments or assist
system administration and network management staff in doing so.
As test execution begins, the number of testers often increases, starting
with the work required to implement tests in the test environment. (They may
play such a role on all test levels, even those not under the direct control of the
test group; e.g., they might implement unit tests which were designed by
programmers.) Testers execute and log the tests, evaluate the results and
document problems found. They monitor the testing and the test environment,
often using tools for this task, and often gather performance metrics. Throughout
the testing life cycle, they review each other's work, including test specifica-
tions, defect reports and test results.
Working as a tester

In this section, let's talk about a complicated trio of test topics:
plans, estimates and strategies. Plans, estimates and strategies depend on
a number of factors, including the level, targets and objectives of the
testing we're setting out to do. Writing a plan, preparing an estimate and
selecting test strategies tend to happen concurrently and ideally during
the planning period for the overall project, though we must ready to
revise them as the project proceeds and we gain more information.
Let's look closely at how to prepare a test plan, examining issues related
to planning for a project, for a test level or phase, for a specific test type
and for test execution. We'll examine typical factors that influence the
effort related to testing, and see two different estimation approaches:
metrics-based and expert- based. We'll discuss selecting test strategies
and ways to establish adequate exit criteria for testing. In addition, we'll
look at various tasks related to test preparation and execution that need
planning.
As you read, keep your eyes open for the glossary terms entry
criteria, exit criteria, exploratory testing, test approach, test level, test
plan, test procedure and test strategy.

2. TEST PLANS, ESTIMATES AND
STRATEGIES

Monitoring the progress of test activities
Having developed our plans, defined our test strategies and
approaches and estimated the work to be done, we must now track
our testing work as we carry it out. Test monitoring can serve
various purposes during the project, including the following:
• Give the test team and the test manager feedback on how the
testing work is going, allowing opportunities to guide and improve
the testing and the project.
• Provide the project team with visibility about the test results.
• Measure the status of the testing, test coverage and test items
against the exit criteria to determine whether the test work is done.
• Gather data for use in estimating future test efforts.
3. TEST PROGRESS MONITORING AND CONTROL

Configuration management is a topic that often perplexes new
practitioners, but, if you ever have the bad luck to work as a tester on a
project where this critical activity is handled poorly, you'll never forget
how important it is. Briefly put, configuration management is in part
about determining clearly what the items are that make up the software or
system. These items include source code, test scripts, third-party
software, hardware, data and both development and test documentation.
Configuration management is also about making sure that these items are
managed carefully, thoroughly and attentively throughout the entire
project and product life cycle.
For another thing, configuration management supports the build
process, which is essential for delivery of a test release into the test
environment. Simply sending Zip archives by e-mail will not suffice,
because there are too many opportunities for such archives to become
polluted with undesirable contents or to harbor left-over previous
versions of items. Especially in later phases of testing, it is critical to
have a solid, reliable way of delivering test items that work and are the
proper version.
4. 4 CONFIGURATION MANAGEMENT

Risks and levels of risk
Risk is a word we all use loosely, but what exactly is risk? Simply put,
it's the possibility of a negative or undesirable outcome. In the future, a risk has
some likelihood between 0% and 100%; it is a possibility, not a certainty. In the
past, however, either the risk has materialized and become an outcome or issue
or it has not; the likelihood of a risk in the past is either 0% or 100%.
The likelihood of a risk becoming an outcome is one factor to consider
when thinking about the level of risk associated with its possible negative conse-
quences. The more likely the outcome is, the worse the risk. However, likeli-
hood is not the only consideration.
For example, most people are likely to catch a cold in the course of
their lives, usually more than once. The typical healthy individual suffers no
serious consequences. Therefore, the overall level of risk associated with colds
is low for this person. But the risk of a cold for an elderly person with breathing
diffi- culties would be high. The potential consequences or impact is an
important consideration affecting the level of risk, too.
5. 5 RISK AND TESTING

What are incident reports for and how do I write good ones?
When running a test, you might observe actual results that vary from
expected results. This is not a bad thing - one of the major goals of testing is to
find problems. Different organizations have different names to describe such
situations. Commonly, they're called incidents, bugs, defects, problems or issues.
To be precise, we sometimes draw a distinction between incidents on the one
hand and defects or bugs on the other. An incident is any situation where the
system exhibits questionable behavior, but often we refer to an incident as a
defect only when the root cause is some problem in the item we're testing.
Other causes of incidents include misconfiguration or failure of the test
environment, corrupted test data, bad tests, invalid expected results and tester
mistakes. (However, in some cases the policy is to classify as a defect any inci-
dent that arises from a test design, the test environment or anything else which is
under formal configuration management.) We talk about incidents to indicate the
possibility that a questionable behavior is not necessarily a true defect. We log
these incidents so that we have a record of what we observed and can follow up
the incident and track what is done to correct it.
6 INCIDENT MANAGEMENT

Test Management

More Related Content

What's hot

Similar to Test Management

Recently uploaded

Test Management