hello guys.. My Name is Suci Maisaroh Welcome My Presentation

1. Test
management
Nama : Suci Maisaroh
Prodi : Sistem Informasi (S1)
Fakultas : Sains dan Teknologi
UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/

2. PRESENTATION
Independent and integrated testing
Defining the skills test staff need
 TEST PLANS , ESTIMATES AND
STRATEGIES
 The purpose and substance of test plans
STANDARD TEST PLAN TEMPLATE
Estimating what testing will involve and what it
will cost
Estimation techniques
Working as a test leader

3.  Independent and integrated testing
we talked about independent testing from the perspective of indi-
vidual tester psychology. In this chapter, we'll look at the organizational
and managerial implications of independence.
The approaches to organizing a test team vary, as do the places in the
organ- ization 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 inde- pendent, objective assessment of quality.
When thinking about how independent the test team is, recognize
that inde- pendence 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 independ- ent and outside the development team, but reporting
to project management.

4.  Working as a
test leader
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.

5.  Defining the
skills test staff
need
People involved in testing need
basic professional and social qualifications
such as literacy, the ability to prepare and
deliver written and verbal reports, the
ability to communicate effectively, and so
on. Going beyond that, when we think of
the skills that testers need, three main
areas come to mind:
 Application or business domain: A tester
must understand the intended behavior,
the problem the system will solve, the
process it will automate and so forth, in
order to spot improper behavior while
testing and recognize the 'must work'
functions and features.
 Technology: A tester must be aware of
issues, limitations and capabilities of the
chosen implementation technology, in
order to effectively and effi ciently locate
problems and recognize the 'likely to
fail' functions and features.
 Testing: A tester must know the testing
topics discussed in this book - and often
more advanced testing topics - in order
to effectively and efficiently carry out the
test tasks assigned.

6.  TEST PLANS , ESTIMATES AND
STRATEGIES
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.

7.  The
purpose
and
substance
of test
plans
While people tend to have different definitions of what goes
in a test plan, for us a test plan is the project plan for the testing
work to be done. It is not a test design specification, a collection of
test cases or a set of test procedures; in fact, most of our test
plans do not address that level of detail.
Why do we write test plans? We have three main reasons.
First, writing a test plan guides our thinking. We find that if we can
explain something in words, we understand it. If not, there's a good
chance we don't.
Writing a test plan forces us to confront the challenges that await us
and focus our thinking on important topics. In Chapter 2 of Fred
Brooks' brilliant and essential book on software engineering
management, The Mythical Man-Month, he explains the importance
of careful estimation and planning for testing as follows:

8. Test plan identifier Test deliverables Introduction Test tasks
Test items Environmental needs
Features to be tested Responsibilities
Features not to be tested Staffing and training needs
Approach Schedule
Item pass/fail criteria Risks and contingencies Suspension and
resumption criteria Approvals
 STANDARD TEST PLAN
TEMPLATE

9.  Estimating what testing will involve and
what it will cost
The testing work to be done can often be seen as a subproject
within the larger project. So, we can adapt fundamental techniques of
estimation for testing. We could start with a work-breakdown
structure that identifies the stages, activities and tasks.
Starting at the highest level, we can break down a testing project into
phases using the fundamental test process identified in the ISTQB
Syllabus: planning and control; analysis and design; implementation
and execution; evaluating exit criteria and reporting; and test
closure. Within each phase we identify activities and within each
activity we identify tasks and perhaps subtasks. To identify the
activities and tasks, we work both forward and backward. When we
say we work forward, we mean that we start with the planning
activities and then move forward in time step by step, asking, 'Now,
what comes next?'

10.  Estimation
techniques
There are two techniques for estimation covered by
the ISTQB Foundation Syllabus. One involves consulting
the people who will do the work and other people with
expertise on the tasks to be done. The other involves
analyzing metrics from past projects and from industry
data. Let's look at each in turn.
Asking the individual contributors and experts involves
working with experi- enced staff members to develop a
work-breakdown structure for the project. With that done,
you work together to understand, for each task, the effort,
duration, dependencies, and resource requirements. The
idea is to draw on the collective wisdom of the team to
create your test estimate. Using a tool such as Microsoft
Project or a whiteboard and sticky-notes, you and the team
can then predict the testing end-date and major
milestones. This technique is often called 'bottom up'
estimation because you start at the lowest level of the hier-
archical breakdown in the work-breakdown structure - the
task - and let the duration, effort, dependencies and
resources for each task add up across all the tasks.

11. THANK YOU FOR WATCHING!
