SESSION 8/ SESSION 9

Test Management - Monitoring & Defect Management

Subtopic
 Purpose, contents, and audience for test reports
 Metrics used in testing.
 Configuration management
 Definition of risk
 Defect management
 Product and project risks
LO-2: Explain the test process and types for a software project.
LO-3: Apply the testing design plan and tools to the testing process.

• Test monitoring is 

– A test management activity that involves checking the status of testing activities, identifying any
variances from the planned or expected status and reporting status to stakeholders.
• Test control is 
– A test management task that deals with developing and applying a set of corrective actions to
get a test project on track when monitoring shows a deviation from what was planned.

• Test monitoring is concerned with gathering data and information about test activities; test control is
using that information to guide or control the remaining testing. 

• Projects do not always unfold as planned. In fact, any human endeavor more complicated than a
family picnic is likely to vary from plan. Risks become occurrences. Stakeholders need evolve.  The
world around us changes.  When plans and reality diverge, we must act to bring the project back
under control, and testing is no exception.
• In some cases, the test findings themselves are behind the divergence; for example, suppose the
quality of the test items proves unacceptably bad and delays test progress. In other cases, testing is
affected by outside events; for example, testing can be delayed when the test items show up late or
the test environment is unavailable. 
• Test control is about guiding and corrective actions to try to achieve the best possible outcome for the
project.

1. Explain what the difference between Test Monitoring and Test Control is? (LO-2)
Answer:
• Test monitoring is 
– A test management activity that involves checking the status of testing activities, identifying
any variances from the planned or expected status and reporting status to stakeholders.
• Test control is 
– A test management task that deals with developing and applying a set of corrective actions to
get a test project on track when monitoring shows a deviation from what was planned.
• Test monitoring is concerned with gathering data and information about test activities; test control is
using that information to guide or control the remaining testing. 

Jelaskan apakah perbedaan antara Test Monitoring dengan Test Control

• Uji pemantauan adalah
– Aktivitas manajemen pengujian yang melibatkan pemeriksaan status aktivitas pengujian, mengidentifikasi
setiap perbedaan dari status yang direncanakan atau yang diharapkan, dan status pelaporan kepada
pemangku kepentingan.

• Tes kontrol
– Tugas manajemen pengujian yang berhubungan dengan pengembangan dan penerapan serangkaian
tindakan korektif untuk mendapatkan proyek pengujian di jalurnya ketika pemantauan menunjukkan
penyimpangan dari apa yang direncanakan.
• Pemantauan tes berkaitan dengan pengumpulan data dan informasi tentang kegiatan tes; kontrol tes
menggunakan informasi itu untuk memandu atau mengontrol pengujian yang tersisa.

• Proyek tidak selalu berjalan sesuai rencana. Nyatanya, usaha manusia mana pun yang lebih rumit daripada
piknik keluarga cenderung berbeda dari rencana. Risiko menjadi kejadian. Pemangku kepentingan perlu
berkembang. Dunia di sekitar kita berubah. Ketika rencana dan kenyataan menyimpang, kita harus bertindak
untuk mengembalikan kendali proyek, dan pengujian tidak terkecuali.

• Dalam beberapa kasus, temuan pengujian itu sendiri berada di balik divergensi; misalnya, misalkan kualitas
item tes terbukti sangat buruk dan menunda kemajuan tes. Dalam kasus lain, pengujian dipengaruhi oleh
peristiwa luar; misalnya, pengujian dapat ditunda saat item pengujian muncul terlambat atau lingkungan
pengujian tidak tersedia.

• Test control adalah tentang membimbing dan tindakan korektif untuk mencoba mencapai hasil terbaik untuk
proyek tersebut.

SESSION 10

Bug Management
Subtopic
 Bugs and Root Causes
 Benefit of Defect Analysis
 Steps for Better Bug Reports
 Bug Life Cycle
 Managing Bug Tracking
 Levels of Importance to Bug
LO-3: Apply the testing design plan and tools to the testing process.

Benefit of Defect Analysis

Argumentation about Defect Analysis

• Defect analysis/prevention processes help to reduce the costs of developing and maintaining software by
reducing the number of defects that require our attention in both review and execution-based testing activities.
• Defect analysis/prevention processes help to improve software quality. If we identity the cause of a class of
defects and change our process so that it does not reoccur, our software should be less defective with respect
to that class of defects and more able to meet the customer’s requirements.
• If our software contains fewer defects, this reduces the total number of problems we must look for; the sheer
volume of problems we need to address may be significantly smaller.
• Defect analysis/prevention processes provide a framework for overall process improvement activities. When
we know the cause of a defect, we identify a specific area of our process that needs work. Improvements made
in this area usually produce readily visible benefits. 
• Defect analysis/ prevention activities not only help to fine-tune an organizations’ current process and practices,
but also support the identification and implementation of new methods and tools so that current process
continues to evolve and comes closer to being optimized.
• Defect analysis/prevention activities encourage interaction between a diverse number of staff members, the
close interrelationships between specialized group activities and the quality of internal and external
deliverables becomes more apparent.
 4. Please describe Mechanism to Assign Levels of Importance to Bugs 15% (LO-3)
Mechanism to Assign Levels of Importance to Bugs

Severity Priority
Risk
Priority
Number
(RPN)

Severity, means the impact, immediate or delayed, of a bug on the system under test, regardless of the likelihood of
occurrence under end-user conditions or the effect such a bug would have on users. You can use the same scale used
for failure mode and effect analysis (FMEA):
 Loss of data, hardware damage, or a safety issue
 Loss of functionality with no workaround
 Loss of functionality with a workaround
 Partial loss of functionality
 Cosmetic or trivial

Priority
You use priority to capture the elements of importance not considered in severity, such as the likelihood of occurrence
in actual customer use and the subsequent impact on the target customer. 
• When determining priority, you can also consider whether this kind of bug is prohibited by regulation or
agreement, what kinds of customers are affected, and the cost to the company if the affected customers take
their business elsewhere because of the bug. 
• Again, you can use a scale like the priority scale used in the FMEA:
1. Complete loss of system value
2. Unacceptable loss of system value
3. Possibly acceptable reduction in system value
4. Acceptable reduction in system value
5. Negligible reduction in system value
Risk Priority Number (RPN) for the Bug
• You can multiply severity by priority to calculate a risk priority number (RPN) for the bug. 
• Using this approach, the RPN can range from 
– 1 (an extremely dangerous bug) to 25 (a completely trivial bug).

Argumentasi tentang Manfaat Defect Analysis

• Proses analisis/pencegahan kecacatan membantu mengurangi biaya pengembangan dan

pemeliharaan perangkat lunak dengan mengurangi jumlah kecacatan yang memerlukan perhatian
kami dalam aktivitas pengujian berbasis peninjauan dan eksekusi.
• Proses analisis/pencegahan cacat membantu meningkatkan kualitas perangkat lunak. Jika kami
mengidentifikasi penyebab kelas cacat dan mengubah proses kami sehingga tidak terulang kembali,
perangkat lunak kami seharusnya kurang cacat sehubungan dengan kelas cacat tersebut dan lebih
mampu memenuhi kebutuhan pelanggan.

• Jika perangkat lunak kami mengandung lebih sedikit cacat, ini mengurangi jumlah total masalah
yang harus kami cari; banyaknya masalah yang perlu kita atasi mungkin jauh lebih kecil.

• Proses analisis/pencegahan cacat menyediakan kerangka kerja untuk aktivitas peningkatan proses
secara keseluruhan. Saat kami mengetahui penyebab cacat, kami mengidentifikasi area spesifik dari
proses kami yang perlu diperbaiki. Perbaikan yang dilakukan di bidang ini biasanya menghasilkan
manfaat yang mudah terlihat.

• Aktivitas analisis/pencegahan cacat tidak hanya membantu menyempurnakan proses dan praktik
organisasi saat ini, tetapi juga mendukung identifikasi dan penerapan metode dan alat baru
sehingga proses saat ini terus berkembang dan semakin dekat untuk dioptimalkan.

• Kegiatan analisis/pencegahan cacat mendorong interaksi antara sejumlah anggota staf yang
beragam, hubungan yang erat antara kegiatan kelompok khusus dan kualitas hasil kerja internal
dan eksternal menjadi lebih jelas.

Bugs and Root Causes

• An anomaly occurs when a tester observes an unexpected behavior. If the test

environment and the tester’s actions were correct, this anomaly indicates either a
system failure or a test failure. 
• The failure arises from a bug in either the system or the test. The bug comes from an error committed by a
software or hardware engineer (while creating the system under test) or a test engineer (while creating the test
system).
• That error is the root cause.
• Usually, the aim of performing a root cause analysis isn’t to determine the exact error and how it happened.
Other than flogging some hapless engineer, you can’t do much with such information.
• Instead, root cause analysis categorizes bugs into a taxonomy.
Bug dan Akar Penyebab
• Anomali terjadi saat penguji mengamati perilaku yang tidak diharapkan. Jika lingkungan pengujian dan tindakan
penguji benar, anomali ini menunjukkan kegagalan sistem atau kegagalan pengujian.
• Kegagalan muncul dari bug baik di sistem maupun pengujian. Bug berasal dari kesalahan yang dilakukan oleh insinyur
perangkat lunak atau perangkat keras (saat membuat sistem yang diuji) atau insinyur uji (saat membuat sistem
pengujian).
• Kesalahan itu adalah akar penyebabnya.
• Biasanya, tujuan melakukan analisis akar masalah bukanlah untuk menentukan kesalahan yang sebenarnya dan
bagaimana hal itu terjadi. Selain mencambuk beberapa insinyur yang malang, Anda tidak dapat berbuat banyak dengan
informasi semacam itu.
• Sebaliknya, analisis akar penyebab mengkategorikan bug ke dalam taksonomi.

• Defect analysis/prevention processes provide a framework for overall process improvement activities. When
we know the cause of a defect, we identify a specific area of our process that needs work. Improvements made
in this area usually produce readily visible benefits. 
• Defect analysis/ prevention activities not only help to fine-tune an organizations’ current process and practices,
but also support the identification and implementation of new methods and tools so that current process
continues to evolve and comes closer to being optimized.
Defect analysis/prevention activities encourage interaction between a diverse number of staff members, the close
interrelationships between specialized group activities and the quality of internal and external deliverables becomes
more apparent.

• Proses analisis/pencegahan cacat menyediakan kerangka kerja untuk aktivitas peningkatan proses secara
keseluruhan. Saat kami mengetahui penyebab cacat, kami mengidentifikasi area spesifik dari proses kami yang
perlu diperbaiki. Perbaikan yang dilakukan di bidang ini biasanya menghasilkan manfaat yang mudah terlihat.
 • Aktivitas analisis/pencegahan cacat tidak hanya membantu menyempurnakan proses dan praktik organisasi
saat ini, tetapi juga mendukung identifikasi dan penerapan metode dan alat baru sehingga proses saat ini terus
berkembang dan semakin dekat untuk dioptimalkan.
• Kegiatan analisis/pencegahan cacat mendorong interaksi antara sejumlah anggota staf yang beragam,
hubungan timbal balik yang erat antara kegiatan kelompok khusus dan kualitas hasil kerja internal dan
eksternal menjadi lebih jelas

SESSION 11

Tool Support for Testing

Subtopic
 Benefits and risks of test automation
 Test tool classification
 Pilot project
 Test management tools
 Test execution tools
 Effective use of tools
 Success factors for tools

LO-3: Apply the testing design plan and tools to the testing process.
LO-3: Terapkan rencana dan alat desain pengujian ke proses pengujian

OVERVIEW
• In this section, we will describe the various tool types in terms of their general functionality, rather than
going into lots of detail.
• The reason for this is that, in general, the types of tools will be fairly stable over a longer period, even
though there will be new vendors in the market, new and improved tools, and even new types of tool in
the coming years.
• We will also discuss both the benefits and the risks of using tools to run or execute tests.
• We will outline special considerations for test execution tools and for test management tools, the most
popular types of test tools.
• There are several ways in which tools can be used to support testing activities: 

2. Describe what tools can be used to support testing activities. (LO-3)

a. To start with the most visible use, we can use tools directly in testing. This includes test execution
tools and test data preparation tools. 
b. We can use tools to help us manage the testing process. This includes tools that manage
requirements, test cases, test procedures, automate test scripts, test results, test data and defects,
as well as tools that assist with reporting and monitoring test execution progress. 
c. We can use tools as part of exploration, investigation, and evaluation. For example, we can use
tools to monitor file activity for an application. 
d. We can use tools in several other ways, in the form of any tool that aids in testing. This would
include spreadsheets when used to manage test assets or progress, or to document manual or
automated tests.
e.
• Pada bagian ini, kami akan menjelaskan berbagai jenis alat dalam kaitannya dengan fungsi umumnya, daripada
menjelaskannya secara mendetail.
• Alasannya adalah, secara umum, jenis alat akan cukup stabil dalam jangka waktu yang lebih lama, meskipun
akan ada vendor baru di pasar, alat baru dan lebih baik, dan bahkan jenis alat baru di tahun-tahun mendatang .
• Kami juga akan membahas manfaat dan risiko menggunakan alat untuk menjalankan atau menjalankan
pengujian.
• Kami akan menguraikan pertimbangan khusus untuk alat pelaksanaan pengujian dan untuk alat manajemen
pengujian, jenis alat pengujian yang paling populer.

Ada beberapa cara alat dapat digunakan untuk mendukung kegiatan pengujian:
How some tools that can be used to support testing activities:
• Untuk memulai dengan penggunaan yang paling terlihat, kita dapat menggunakan alat secara langsung dalam
pengujian. Ini termasuk alat eksekusi uji dan alat persiapan data uji.
• Kita dapat menggunakan alat untuk membantu kita mengelola proses pengujian. Ini termasuk alat yang
mengelola persyaratan, kasus pengujian, prosedur pengujian, mengotomatiskan skrip pengujian, hasil pengujian,
data pengujian dan cacat, serta alat yang membantu pelaporan dan pemantauan kemajuan pelaksanaan
pengujian.
• Kita dapat menggunakan alat sebagai bagian dari eksplorasi, investigasi, dan evaluasi. Misalnya, kita dapat
menggunakan alat untuk memantau aktivitas file untuk suatu aplikasi.
• Kita dapat menggunakan alat dalam beberapa cara lain, dalam bentuk alat apa pun yang membantu pengujian.
Ini akan mencakup spreadsheet saat digunakan untuk mengelola aset atau progres pengujian, atau untuk
mendokumentasikan pengujian manual atau otomatis.

1. Please explain and describe about what is test management tools

• Test management tool is
– A tool that provides support to the test management and control part of a test process. It often has
several capabilities, such as test ware management, scheduling of tests, the logging of results,
progress tracking, incident management and test reporting. (Note that the Glossary definition
mentions incident management, but the Syllabus covers defect management.
2. Describe what tools can provide support for test testing and control of part
of the test process.
• Test management tools provide features that cover both the management of testing, such as progress
reports and keeping track of testing activities, and the management of test ware, such as logging of test
results and keeping track of test environments needed for tests. 
• There are some tools that provide support for only one activity (for example defect management tools);
other tools or tool suites may provide support for all test management activities. 
• Application lifecycle management (ALM) tools manage not only testing but also development and
deployment. With a focus on communication, collaboration, and task tracking, they are popular in Agile
development.

• Alat manajemen tes adalah

– Alat yang memberikan dukungan untuk manajemen pengujian dan kontrol bagian dari proses pengujian.
Ini sering memiliki beberapa kemampuan, seperti manajemen perangkat pengujian, penjadwalan pengujian,
pencatatan hasil, pelacakan kemajuan, manajemen insiden, dan pelaporan pengujian

• Alat manajemen pengujian menyediakan fitur yang mencakup pengelolaan pengujian, seperti laporan kemajuan
dan pelacakan aktivitas pengujian, serta pengelolaan perangkat pengujian, seperti pencatatan hasil pengujian dan
pemantauan lingkungan pengujian yang diperlukan untuk pengujian.

• Ada beberapa alat yang menyediakan dukungan hanya untuk satu aktivitas (misalnya alat manajemen
kerusakan); alat atau suite alat lain dapat memberikan dukungan untuk semua aktivitas manajemen pengujian.

• Alat manajemen siklus hidup aplikasi (ALM) tidak hanya mengelola pengujian tetapi juga pengembangan dan
penerapan. Dengan fokus pada komunikasi, kolaborasi, dan pelacakan tugas, mereka populer dalam
pengembangan Agile.

Requirements Management Tools

• Are requirements management tools really testing tools? Some people may say they are not, but they do
provide some features that are very helpful to testing. 
• Because tests are based on requirements, the better the quality of the requirements, the easier it will be
to write tests from them.
• It is also important to be able to trace tests to requirements and requirements to tests, as we saw in
Chapter 2. 
• Note that requirements mean any source of what the system should do, such as user stories.
Defect Management Tools
• This type of tool is also known as a defect tracking tool, an incident management tool, a bug tracking tool
or a bug management tool. 
• However not all the things tracked are actually defects or bugs. There may also be perceived problems,
anomalies (that aren’t necessarily defects) or enhancement requests; this is why they are sometimes
referred to as incidents and incident management tools. 
• Also, what is normally recorded is information about the failure (not the defect) that was generated
during testing; information about the defect that caused that failure would come to light when someone
(for example a developer) begins to investigate the failure.
• Defect management tools make it much easier to keep track of the defects and their status over time.

Configuration Management Tools

• An example: A test group began testing the software. But to their surprise, very few defects were found.
Before they celebrated the great quality of this release, they just found out that they were testing the
version from two months earlier (which had been debugged) with the tests for that earlier version. 
• Configuration management tools are not strictly testing tools either, but good configuration management
is critical for  controlled  testing. 
• It is possible to perform configuration management activities without the use of tools, but the tools make
life a lot easier, especially in complex environments. 
• Test ware also has different versions and is changed over time.
• It is important to run the correct version of the tests as well, as our example shows.

Continuous Integration Tools (D)

• Incremental and iterative development life cycles require frequent builds, and continuous integration tools
are an essential part of the Agile toolkit. 
• Continuous integration is the practice of integrating new or changed code with the existing code repository
very frequently, at least daily but sometimes dozens of times a day or more. 
• Unit tests are most often automatically run when a new build is made (when a developer commits his or
her change), so any defects found can be corrected immediately. 
• The result of the integration is a system that is tested and could in principle be deployed to users at any
time.
• If the deployment is automated, then it is called continuous delivery, but there might still be some final
human approval before it is released.
•

Tool Support for Test Design and Specification/ Dukungan Alat untuk Desain dan Spesifikasi Pengujian

• Test design tools

– Test design tools help to construct test cases, or at least test inputs (part of a test case). If an
automated oracle is available, then the tool can also construct the expected result, so it can actually
generate test cases, rather than just test inputs.
• Model-based testing tools
– Tools that generate test inputs or test cases from stored information that represents some kind of
model of the system or software are called model-based testing tools. Such tools may be based on a
state diagram, to implement state transition testing, for example.
• Test data preparation tools
– Setting up test data can be a significant effort, especially if an extensive range or volume of data is
needed for testing. Test data preparation tools help in this area. 
• Test-driven development (TDD) tools (D)
– Test-driven development (TDD) is a software development approach started as part of Extreme
Programming, which had a great influence on Agile development. 
• Acceptance test-driven development (ATDD) and behavior-driven development (BDD) tools
 – Tools to develop system-level tests before developing the system itself are becoming increasingly
popular. ATDD is a way of capturing requirements by writing acceptance tests
in conjunction with users.

Test Management Tools

Test management tools can provide a lot of useful information, but the information as produced by the
tool may not be in the form that will be most effective within your own context. 

• Some additional work may be needed to produce interfaces to other tools or a spreadsheet to ensure that
the information is communicated in the most effective way.
• Test management tools need to interface with other tools (including spreadsheets for example) for various
reasons, including: 
• To produce useful information in a format that fits the needs of the organization. 
• To maintain consistent traceability to requirements in a requirements management tool. 
• To link with test object version information in the configuration management tool.
• Tools such as application lifecycle management (ALM) tools may have aspects that are used by different
people within the organization. For example, a high-level manager wants to see trends and graphs about
test progress, application quality schedules and budgets, but a developer wants to see detailed information
about how a defect occurred.

Alat Manajemen Tes

Alat manajemen pengujian dapat memberikan banyak informasi berguna, tetapi informasi yang
dihasilkan oleh alat tersebut mungkin tidak dalam bentuk yang paling efektif dalam konteks Anda
sendiri.

• Beberapa pekerjaan tambahan mungkin diperlukan untuk membuat antarmuka ke alat lain atau
spreadsheet untuk memastikan bahwa informasi dikomunikasikan dengan cara yang paling efektif.

• Alat manajemen pengujian perlu berinteraksi dengan alat lain (termasuk spreadsheet misalnya)
karena berbagai alasan, termasuk:

• Menghasilkan informasi yang berguna dalam format yang sesuai dengan kebutuhan organisasi.

• Untuk mempertahankan ketertelusuran yang konsisten terhadap persyaratan dalam alat manajemen
persyaratan.

• Untuk menautkan dengan informasi versi objek uji di alat manajemen konfigurasi.

• Alat seperti alat manajemen siklus hidup aplikasi (ALM) mungkin memiliki aspek yang digunakan oleh
orang yang berbeda dalam organisasi. Misalnya, manajer tingkat tinggi ingin melihat tren dan grafik
tentang kemajuan pengujian, jadwal dan anggaran kualitas aplikasi, tetapi pengembang ingin melihat
informasi mendetail tentang bagaimana kerusakan terjadi.

Effective Use of Tools

Main Principles for Tool Selection

• The place to start when introducing a tool into an organization is not with the tool: it is with the
organization. 
• For a tool to provide benefit, it must match a need within the organization, and solve that need in a way
that is both effective and efficient. 
• The tool should help to build on the strengths of the organization and address its weaknesses. 
 • The following factors are important in selecting a tool: 
– Assessment of the organization’s maturity (for example strengths and weaknesses, readiness for
change). 
– Identification of the areas within the organization where tool support will help to improve testing
processes. 
– Understanding the technologies used by the test object(s), so that a tool will be selected that is
compatible with those technologies.
– Knowledge of any build and continuous integration tools already being used within the
organization, to make sure that the new tool(s) will integrate with them and be compatible. 
– Evaluation of tools against clear requirements and objective criteria. 
– Consideration of any free trial period for the tool (for commercial tools) to ensure that this gives
adequate time to evaluate the tool. 
– Evaluation of the vendor (including training, support and other commercial aspects) or support for
non-commercial tools (open source). 
– Identification of internal requirements for coaching and mentoring in the use of the tool. 
– Evaluation of training needs for those who will use the tools directly and indirectly (for example
without technical detail), considering testing skills and test automation skills (for those working
directly with the tools). 
– Consideration of pros and cons of different licensing models (for example commercial or open
source).
– Estimation of a cost-benefit ratio based on a concrete and realistic business case (if required).

Prinsip Utama apa saja yang dapat digunakan Pemilihan Alat mendukung test

3. What are the main principles that can be used in the selection of tools to support the
test.(LO-3)

Prinsip Utama Pemilihan Alat

• Tempat untuk memulai saat memperkenalkan alat ke dalam organisasi bukanlah dengan alatnya: melainkan
dengan organisasi.

• Agar alat dapat memberikan manfaat, alat tersebut harus sesuai dengan kebutuhan dalam organisasi, dan
menyelesaikan kebutuhan tersebut dengan cara yang efektif dan efisien.

• Alat tersebut harus membantu membangun kekuatan organisasi dan mengatasi kelemahannya.

Faktor-faktor berikut penting dalam memilih alat:

– Penilaian kematangan organisasi (misalnya kekuatan dan kelemahan, kesiapan untuk berubah).

– Identifikasi area dalam organisasi di mana dukungan alat akan membantu meningkatkan proses pengujian.

– Memahami teknologi yang digunakan oleh benda uji, sehingga akan dipilih alat yang kompatibel dengan
teknologi tersebut.

– Pengetahuan tentang alat build dan continuous integration yang sudah digunakan dalam organisasi, untuk
memastikan bahwa alat(-alat) baru akan terintegrasi dengannya dan kompatibel.

– Evaluasi alat terhadap persyaratan yang jelas dan kriteria objektif.

– Mempertimbangkan setiap periode uji coba gratis untuk alat (untuk alat komersial) untuk memastikan bahwa ini
memberikan waktu yang cukup untuk mengevaluasi alat tersebut.

– Evaluasi vendor (termasuk pelatihan, dukungan dan aspek komersial lainnya) atau dukungan untuk alat non-
komersial (sumber terbuka).

– Identifikasi persyaratan internal untuk pembinaan dan pendampingan dalam penggunaan alat ini.

– Evaluasi kebutuhan pelatihan bagi mereka yang akan menggunakan alat secara langsung dan tidak langsung
(misalnya tanpa detail teknis), dengan mempertimbangkan keterampilan pengujian dan keterampilan otomasi
pengujian (bagi mereka yang bekerja langsung dengan alat).

– Pertimbangan pro dan kontra dari model lisensi yang berbeda (misalnya komersial atau open source).

– Estimasi rasio biaya-manfaat berdasarkan kasus bisnis yang konkret dan realistis (jika diperlukan).

5.What is the important factor in the selection of tools to support

testing
Success Factors for Tools

• Success is not guaranteed or automatic when acquiring a testing tool, but many organizations have
succeeded. 
• After a successful selection process and a pilot project, two other things are also important to get the
greatest benefit from the tools: 
– the way in which the tool(s) is deployed within the wider organization, the way in which ongoing
support is organized.
– Here are some of the factors that contribute to success: 
– Rolling out the tool incrementally (after the pilot) to the rest of the organization (a gradual uptake
of the tool, not trying to get the whole organization to use it at once immediately). 
– Adapting and improving processes, testware and tool artefacts to get the best fit and balance
between them and the use of the tool. 
– Providing adequate support, training (for example for those using the tool directly), coaching (for
example from external specialist automation consultants) and mentoring for tool users.
– Defining and communicating guidelines for the use of the tool, based on what was learned in the
pilot (for example internal standards for automation). 
– Implementing a way to gather information about the use of the tool, to enable continuous
improvement as tool use spreads through more of the organization. 
– Monitoring the use of the tool and the benefits achieved, and adapting the use of the tool to take
account of what is learned. 
– Providing continuing support for anyone using test tools, such as the test team (for example,
technical expertise is needed to help non-programmer testers who use keyword-driven testing). 
– Gathering lessons learned, based on information gathered from all teams who are using test tools.
SESSION 12

Other Players in Testing Project

Subtopic
 Outsourcing in Testing Project
 Partners in Testing Project

LO-3: Apply the testing design plan and tools to the testing process.

Needs for Partners

• You might want to get business analysts, help desk or technical support, target customers or
users, or sales and marketing staff involved in testing to build their confidence in the quality of
the system that’s about to be released— or the testing that your team or some other team
performed on that system. 

• In some cases, the motivation is political, to make up for credibility deficits in the development
team or your own team of testers.

• In other cases— especially customer involvement in acceptance testing— the motivation is

contractual, since many outsource development efforts include a period of acceptance testing by
the customers prior to final payment.

Kebutuhan Mitra

• Anda mungkin ingin melibatkan analis bisnis, pusat bantuan atau dukungan teknis, pelanggan atau pengguna target,
atau staf penjualan dan pemasaran yang terlibat dalam pengujian untuk membangun kepercayaan mereka terhadap
kualitas sistem yang akan dirilis— atau pengujian yang dilakukan tim Anda atau beberapa tim lain tampil di sistem itu.
• Dalam beberapa kasus, motivasinya bersifat politis, untuk menutupi kekurangan kredibilitas dalam tim pengembangan
atau tim penguji Anda sendiri.
• Dalam kasus lain—khususnya keterlibatan pelanggan dalam pengujian penerimaan—motivasinya bersifat kontraktual,
karena banyak upaya pengembangan pihak luar mencakup periode pengujian penerimaan oleh pelanggan sebelum
pembayaran akhir.

Partners in Testing Project (Mitra dalam Proyek Pengujian)

Dalam pengujian untuk membangun kepercayaan mereka terhadap kualitas sistem diburuhkan adanya mitra dalam
proyek. Jelaskan dengan gambar siapa saja mitra yang terlibat dalam melakukan proyek pengujian.

6. In testing to build their confidence in the quality of the system, partners in the
project are required. Explain with pictures which partners are involved in
conducting the test project. (LO-3)

Vendors
  When vendors are producing key components for your systems, clear-headed assessments of component quality
and smart testing strategies are key to mitigating those risks.
 Most vendors take a narrow, targeted view of their testing: they might test very deeply in certain areas, but they
aren’t likely to test broadly.
 What is the risk to your system’s quality related to your vendors’ components?
- Component irreplaceability.
- Component essentiality.
- Component/system coupling.
- Vendor quality problems.

Testing Service Providers

• Testing service providers include any organization that offers test services to clients. Most of
the time these services come at a fee, but some organizations provide some specialized
services at no charge to the client. 

• The provider can offer these services on-site (insourcing), off-site (outsourcing), or both.

• A testing service provider brings several key strengths to the table. The most important is
expertise in test project management and test engineering.

• Another advantage is that testing service providers can often begin running tests for you more
quickly than you could do it yourself.

• A testing service provider, whether lab or consultancy or whatever, might also offer expert
consulting and training services.

Sales Office

• If you sell a product internationally, you might have a local sales office or a sales partner (such as a distributor)
in various regions.
• As fellow employees, the staff members in a sales office have the same goals and objectives you do —they
have a stake in ensuring that the test effort is successful.
• Unfortunately, these sales and marketing people might not have technical sophistication or a particular skill
with testing. 
• If you are responsible for the results of the testing and want specific items tested, you will need to spell out
these details. Any test cases you give to nontechnical colleagues must be precise and unambiguous.

Users & User-Surrogates

• This category includes business analysts, help desk, customer support, and technical support personnel along
with actual target customers and users. 
• Most commonly, these folks participate in alpha, beta, pilot, or acceptance testing efforts. (One of our clients,
though, invites its customers’ most-expert users of its system to participate in system test, using their own
unique data and workflows). 
• As mentioned previously, testing by users and user-surrogates can result from considerations of credibility,
contractual obligation, or from a need to broaden test coverage.

SESSION 13
Software Implementation
Subtopic
 Project Closure
 Infrastructure Management
 Network Configuration
 Implementation Approaches
 Project Evaluation
 Database Implementation
  Virtualization and cloud

LO-3: Apply the testing design plan and tools to the testing process.
LO-4: Describe the software implementation strategies.