LECTURE NOTES
ISYS6507
Testing dan Implementation System
Week 4
Distributing Test Project
LEARNING OUTCOMES
LO2: Design the testing management plans for software
OUTLINE MATERI (Sub-Topic):
1. Choosing your partners
2. Planning a distributed test effort 3. Managing a distributed test effort
ISI MATERI
Menyusun upaya pengujian terdistribusi melibatkan pembuatan proyek tes matriks / keterampilan-matriks proyek hybrid, yang terdiri dari tim pengujian, kontributor lain dalam perusahaan, dan orang-orang yang bekerja di perusahaan lain. Dalam beberapa kasus, pengujian terdistribusi terjadi di luar ruang lingkup organisasi pengujian. Tim pemasaran sering menjalankan program uji beta di perangkat lunak pasar dan organisasi sistem. Pengujian terdistribusi hadir dalam empat rasa dasar:
1. Vendor Anda
2. Organisasi uji independen
3. Kantor penjualan atau pemasaran Anda
4. Analis bisnis Anda, help desk atau dukungan teknis, target pelanggan atau pengguna.
Mendistribusikan pengujian dalam situasi seperti itu berarti Anda telah memperpanjang operasi pengujian Anda, dengan semua manfaat dan tantangan yang tersirat. Untuk mendistribusikan pengujian dengan sukses, Anda perlu melakukan tiga urutan langkah berikut ini:
1. Pilih mitra pengujian Anda, berdasarkan pengujian khusus yang Anda butuhkan untuk didistribusikan dan alsan mengapa Anda perlu melakukannya.
2. Rencanakan upaya pengujian yang didistribusikan.
3. Kelola pengujian eksternal seolah-olah itu milik Anda.
Choosing Your Partner
Mari kita mulai dengan pertanyaan tentang alasan mengapa ingin menggunakan sumber daya pengujian di luar tim Anda sendiri secara eksklusif. Anda mungkin ingin melibatkan analis bisnis, help desk atau dukungan teknis, target pelanggan atau pengguna, atau staf penjualan dan pemasaran yang terlibat dalam pengujian untuk membangun kepercayaan mereka pada kualitas sistem yang akan dirilis — atau pengujian yang dilakukan tim Anda atau beberapa tim lain dalam sistem tersebut. Dalam beberapa kasus, motivasinya bersifat politis, untuk menebus defisit kredibilitas di tim pengembangan atau tim penguji Anda sendiri. Dalam kasus-kasus lain — terutama keterlibatan pelanggan dalam pengujian penerimaan —
motivasinya bersifat kontrak, karena banyak upaya pengembangan outsourcing mencakup periode pengujian penerimaan oleh pelanggan sebelum pembayaran akhir.
Namun, yang lebih khas, penggunaan pengujian terdistribusi, terutama selama pengujian sistem, muncul dari satu (atau keduanya) dari dua motivasi manajerial: entah karena sedang berusaha meningkatkan kekuatan pihak eksternal, terutama yang tidak bisa atau tidak ingin membuat ulang pengujian inhouse; atau saya sedang menangani pekerjaan yang tidak bisa saya tangani dengan cukup cepat.
Dalam hal lokalisasi, kompatibilitas, dan pengujian use case yang tidak biasa, Anda meningkatkan kekuatan sumber daya eksternal. Mitra penjualan Anda di luar negeri memiliki akses ke orang-orang yang dapat membantu Anda dengan lokalisasi. Seperti kebanyakan lab uji eksternal, STC memiliki akses ke lebih banyak perangkat keras daripada yang Anda inginkan — atau mungkin bahkan mampu — untuk dipertahankan di lab internal Anda. Use Case unik dari pelanggan terdiri dari dokumen khusus yang mereka miliki dan alur kerja yang biasa mereka lakukan. Dalam hal ini, masuk akal untuk menggunakan kantor penjualan asing, laboratorium eksternal, dan pengguna untuk tugas-tugas ini, bahkan jika Anda bisa menangani pekerjaan ini di perusahaan.
Dalam hal tugas-tugas pengujian sistem lainnya yang termasuk dalam tiga siklus pengujian, sebaiknya Anda melepas pekerjaan berlebih ke STC. Adalah hal yang benar bahwa uji kapasitas / volume dan jaringan mungkin cocok untuk laboratorium eksternal, mengingat banyaknya perangkat keras yang umumnya dimiliki oleh laboratorium ini. Namun, motivasi utama Anda adalah menyelesaikan pekerjaan Anda untuk menghindari pekerjaan yang berlebihan pada staf Anda.
Seperti yang ditunjukkan contoh ini, Anda dapat memilih untuk mendistribusikan pengujian berdasarkan faktor kekuatan dan kebutuhan, dengan setiap keputusan melibatkan jumlah yang berbeda dari setiap faktor. Namun, dalam beberapa kasus, keharusan dapat menggoda Anda untuk membuat keputusan alih daya yang merusak keberhasilan upaya pengujian Anda. Untuk menghindari hal ini, Anda harus memahami kekuatan dan kelemahan berbagai calon mitra tes, seperti yang dibahas di bagian berikut.
1. Vendor Anda
Ada tren yang telah berkembang selama beberapa tahun terakhir dalam rekayasa perangkat lunak dan sistem perangkat keras untuk melakukan outsourcing pengembangan satu atau lebih komponen kunci dalam sistem. Ketika vendor memproduksi komponen utama untuk
sistem Anda, penilaian yang jelas tentang kualitas komponen dan strategi pengujian yang cerdas adalah kunci untuk mengurangi risiko-risiko yang ada.
Hal ini tidak hanya terjadi pada komponen perangkat keras saja tetapi kini juga telah mencakup komponen-komponen perangkat lunak. Semakin banyak perusahaan perangkat lunak yang melakukan outsourcing pekerjaan pengembangan ke pihak ketiga, beberapa di antaranya dipisahkan dari kantor utama oleh ribuan mil. Apakah upaya outsourcing ini termasuk perangkat keras, perangkat lunak, ataupun keduanya, anda secara definisi mendistribusikan pengujian. Pertanyaannya kemudian menjadi apakah Anda dapat memanfaatkan pengujian terdistribusi sebagai kekuatan dan menghindari usaha yang sia- sia.
Sebagian besar vendor mengambil pandangan sempit dan terarah dari pengujian mereka:
mereka mungkin menguji sangat dalam di area-area tertentu, tetapi mereka cenderung tidak menguji secara luas. Bagaimana risiko kualitas sistem Anda terkait dengan komponen vendor? Selain pertimbangan normal risiko terhadap kualitas sistem ada empat faktor tambahan, yang ditunjukkan pada Gambar 4.1.
Gambar 4.1. Key Factors Influencing Component Risk to System Quality (Black, 2009)
Komponen kunci yang mempengaruhi kualitas sistem adalah sebagai berikut:
a. Component irreplaceability / Komponen tidak tergantikan.
Ada beberapa komponen yang mudah untuk digantikan seperti PCI LAN card atau modem, tetapi ada juga yang terbukti sulit untuk digantikan didalam sistem seperti motherboard. Dari segi komponen perangkat lunak, jika Anda membutuhkan database di perangkat lunak Anda, Anda seharusnya tidak kesulitan menemukan berbagai opsi database yang dapat Anda gunakan.
b. Component essentiality
Beberapa sistem memiliki komponen tambahan yang merupakan fitur tambahan yang menarik, yang bagus jika bekerja, tetapi bukan fitur utama bagi pelanggan.
c. Component/ system coupling
Jika komponen vendor pada dasarnya berdiri sendiri — modem, misalnya — dan tidak berinteraksi dengan sistem dengan cara yang unik (dan mungkin berjauhan), komponen itu tidak dipasangkan dengan erat. Namun, jika hal itu memengaruhi perilaku keseluruhan sistem, seperti yang dilakukan oleh BIOS, maka sistem tersebut akan digabungkan dengan erat. Perangkat lunak yang berinteraksi dengan tabel dan catatan umum dalam shared system database digabungkan sangat erat. Penggabungan mungkin lebih dari sisi teknis: bagian pemasaran kadang-kadang memaksakan untuk memasangkan produk Anda ke komponen tertentu.
d. Vendor quality problems
Smart outsourcing mencakup penilaian yang cermat atas kemampuan, kekuatan, dan kelemahan vendor dan yang harus mencakup masalah kualitas seperti praktik dan proses pengembangan dan pemeliharaan, tim dan teknologi, termasuk pengujian.
2. Third-Party Testing Organization / Organisasi pengujian pihak ketiga
Sumber daya pengujian pihak ketiga mencakup organisasi apa pun yang menawarkan layanan pengujian kepada klien yang membayar. Layanan ini dapat disediakan di luar lokasi, di lokasi, atau keduanya. Organisasi pengujian pihak ketiga yang sesungguhnya menghadirkan beberapa kekuatan utama. Yang paling penting adalah keahlian dalam manajemen proyek uji dan keterampilan berpengalaman dalam pengujian teknis.
Keahlian perusahaan mungkin juga terspesialisasi, terfokus dengan ketat, atau unik.
Keuntungan lain adalah perusahaan uji sering dapat mulai menjalankan tes untuk Anda lebih cepat daripada yang Anda bisa lakukan sendiri. Perusahaan pengujian pihak ketiga, apakah lab atau konsultan atau apa pun, mungkin juga dapat menawarkan layanan konsultasi dan pelatihan ahli.
Selain keuntungan di atas, pengaturan dengan lab pengujian pihak ketiga dapat mengandung jebakan yang signifikan. Cara untuk menghindari situasi seperti ini adalah dengan melakukan uji kelayakan yang tuntas ketika pertama kali Anda berbisnis dengan tim uji eksternal. Ketika Anda merekrut karyawan atau kontraktor untuk staf Anda
sendiri, Anda mewawancarai orang tersebut, memeriksa referensi, dan meneliti riwayat hidup orang tersebut. Mempertahankan organisasi pengujian pihak ketiga yang tepat tidak jauh berbeda.
3. Sales Office
Jika Anda menjual produk secara internasional, Anda mungkin memiliki kantor penjualan lokal atau mitra penjualan (seperti distributor) di berbagai wilayah. Atau, Anda mungkin memiliki kantor penjualan "virtual", dengan anggota staf di kantor penjualan utama yang menangani penjualan asing. Bagaimanapun, kantor penjualan secara sadar dan memenuhi syarat bertujuan untuk mengevaluasi risiko kualitas unik dari pasar luar negeri.
Sayangnya, orang-orang penjualan dan pemasaran ini mungkin tidak memiliki kecakapan teknis atau keterampilan khusus dalam pengujian. Jika Anda bertanggung jawab atas hasil pengujian dan ingin barang tertentu diuji, Anda perlu menjabarkan detail ini. Semua kasus uji yang Anda berikan kepada kolega nonteknis harus tepat dan tidak ambigu.
4. User and User Surogate
Dalam kategori ini, saya menyertakan analis bisnis, help desk, dukungan pelanggan, dan personel dukungan teknis bersama dengan pelanggan dan pengguna yang merupakan target aktual. Paling umum, orang-orang ini berpartisipasi dalam upaya pengujian alfa, beta, pilot (uji coba), atau penerimaan.
Contoh paling umum dari jenis pengujian ini adalah penerimaan dan uji coba. Pengujian penerimaan harus menunjukkan kesesuaian dengan persyaratan dan kesesuaian untuk digunakan. Uji coba percontohan menunjukkan kesiapan untuk produksi, baik dalam hal jalur perakitan atau mulai menggunakan sistem untuk melakukan pekerjaan nyata.
Jika Anda perlu memperluas cakupan pengujian, maka fokus umumnya adalah menemukan bug lagi.
Sebagian besar program alfa dan beta ada dalam kategori ini. Jenis pengujian ini dapat memberikan cakupan alur kerja, kumpulan data, konfigurasi, dan kondisi lapangan yang digunakan yang mungkin sulit untuk ditiru di lab uji.
Planning a Distributed Test Effort
Anda perlu merencanakan pengujian terdistribusi dengan tingkat detail yang sama dengan yang Anda gunakan untuk merencanakan upaya internal Anda. Titik awal adalah penyelesaian perencanaan tes tingkat tinggi. Anda juga harus memiliki suite tes sendiri yang didefinisikan dengan cukup baik, meskipun beberapa detail mungkin masih harus diselesaikan.
Proses pelacakan pengujian dan pelacakan bug Anda harus dikerjakan, termasuk rencana untuk menggunakan sistem pelacakan bug.
1. Assessing Capabilities / Penilaian Kemampuan
Setelah cukup mempelajari tentang calon mitra pengujian untuk memilih organisasi untuk proyek tersebut, Anda selanjutnya perlu menilai kemampuan pengujian khusus mitra tersebut sebagai bagian dari perencanaan keseluruhan upaya pengujian Anda. Ini sangat penting ketika berbicara dengan vendor Anda atau organisasi pengujian pihak ketiga yang potensial.
Dengan orang-orang penjualan dan pemasaran, pengguna, pengganti pengguna, atau rekan kerja atau kolega lainnya tanpa tanggung jawab langsung untuk menjalankan tes, penilaian harus tidak hanya melihat kemampuan, tetapi juga komitmen.
Staf yang memadai sangat penting. Sering tergoda untuk melihat vendor dan perusahaan pengujian sebagai sumur tak berdasar dari para ahli tes yang terampil, terutama jika itu yang Anda butuhkan. Namun, setiap perusahaan memiliki batasan kepegawaian.
Penilaian Anda terhadap pengaturan fisik pasangan Anda harus mencakup peralatan, fasilitas, dan lokasi. Jika pekerjaan pengujian akan terjadi di luar lokasi, penilaian Anda harus dilakukan di fasilitas mitra pengujian.
2. Understanding the cost / memahami biaya
Sebelum Anda melanjutkan lebih jauh dengan perencanaan terperinci, vendor atau organisasi pengujian pihak ketiga mungkin mengharuskan Anda mulai membayar untuk proyek tersebut.
Dari vendor atau perusahaan pengujian pihak ketiga, Anda dapat meminta penawaran, yang bisa berupa tawaran biaya tetap atau tawaran waktu dan bahan. Jika Anda menerima tawaran waktu dan bahan, Anda perlu memperkirakan biaya mingguan atau bulanan untuk keperluan penganggaran Anda sendiri. Pastikan bahwa penawaran menyertakan beberapa fleksibilitas atau dana darurat, tidak hanya untuk perubahan yang tak terhindarkan yang
akan terjadi, tetapi juga untuk memungkinkan perubahan yang akan Anda buat pada langkah berikutnya ketika Anda membuat program pengujian terpadu.
Selain biaya yang mungkin ditagih oleh mitra pengujian, biaya tertentu juga harus dikaitkan dengan pengujian yang didistribusikan itu sendiri. Selain pengeluaran ini, Anda akan memiliki overhead lainnya seperti komunikasi dan perjalanan. Kumpulkan semua biaya terkait ini dan masukkan ke dalam anggaran Anda.
Pekerjaan anggaran ini mungkin membosankan dan dapat memperlambat proses, tetapi penting untuk mengurusnya pada tahap awal untuk menghindari terjebak dengan program yang Anda tidak mampu. Uang selalu penting, dan itu sangat berarti dalam upaya pengujian terdistribusi.
3. Collating, Coordinating , and Partitioning Test Program / menyusun, mengkoordinasi dan memartisi test uji
Tugas Anda berikutnya dalam pengujian terdistribusi adalah untuk menggabungkan dua atau lebih proyek pengujian menjadi satu program pengujian tunggal. Langkah- langkahnya yaitu:
a) Langkah pertama, collation, melibatkan pembuatan daftar tunggal dari semua kasus uji yang akan dijalankan.
b) Pada langkah kedua, koordinasi, Anda menghilangkan kasus uji yang berlebihan.
c) Langkah ketiga Anda adalah mempartisi pekerjaan, meninjau spreadsheet pelacakan pengujian dan menugaskan kembali kasus pengujian ke pemilik baru. Sebagian besar pekerjaan ini dilakukan secara default saat Anda mengoordinasikan pengujian, karena kasus uji yang dilewati dihapus dari beban kerja tim dan dihilangkan dari daftar.
Gambaran keiga langkah ini dapat dilihat pada gambar 4.2. berikut ini.
Gambar 4.2. Integrating 3 Distinct Step Program into One (Black, 2009)
4. Organizing Logistic / pengorganisasian logistik
Salah satu keuntungan dari pengujian terdistribusi, ketika suite tes dipartisi dengan benar, adalah bahwa masing-masing pasangan bermain dengan kekuatannya. Situasi ini cenderung meminimalkan masalah logistik.
Namun, dalam beberapa kasus, pengujian terdistribusi menciptakan masalah logistik yang unik. Hambatan paling sulit muncul ketika suatu proyek mencakup satu atau beberapa perangkat keras khusus, sampel teknik, atau peralatan terbatas lainnya.
Namun, aspek perangkat lunak pun bukannya tanpa jebakan. Masalah di bidang ini umumnya berkaitan dengan konfigurasi dan manajemen rilis. Salah satu aspek dari tantangan manajemen rilis ini melibatkan keamanan. Jika Anda menemukan metode pengiriman rilis perangkat lunak Anda melalui Internet, Anda mungkin khawatir tentang seseorang yang mencegat perangkat lunak itu. Untuk menangani masalah itu, Anda mungkin memutuskan untuk mengenkripsi perangkat lunak.
Anda dapat menggunakan database logistik untuk membantu mengelola dan melacak logistik pengujian terdistribusi. Tetapi ketika Anda memiliki mitra jarak jauh, Anda tidak perlu menggunakan database ini. Mengorganisir lab mereka sendiri adalah bagian dari apa yang Anda bayar untuk mitra pengujian Anda.
5. Dealing with mapping issues / mengatasi masalah pemetaan
Jika setiap operasi pengujian bekerja dengan cara yang persis sama dengan perencanaan Anda, pekerjaan akan selesai setelah program uji disatukan, pekerjaan dipartisi dengan tepat, dan masalah logistik ditangani. Namun kenyataannya, setiap tim uji menggunakan pendekatan yang berbeda. Anda tidak dapat (dan tidak perlu) membuat setiap mitra pengujian bekerja dengan cara yang sama, tetapi Anda memang perlu mengenali dan mengelola perbedaan. Inilah yang disebut dengan istilah “mapping issues”, karena kita coba memetakan upaya pengujian yang dilakukan oleh mitra kita kedalam upaya pengujian kita sendiri.
Masalah pemetaan pertama biasanya muncul selama koordinasi, karena Anda membandingkan dan menyortir kasus uji. Gambar 4.3 mengilustrasikan beberapa kemungkinan yang mungkin Anda temui. Beberapa test case sama sekali tidak berhubungan satu sama lain, dan Anda harus menyimpan semuanya untuk mempertahankan tingkat coverage yang diinginkan. Dalam kasus lain, ada kasus uji yang benar-benar redundan: ada dua kasus uji yang memiliki tujuan yang sama persis, atau satu
kasus uji sepenuhnya mencakup kondisi orang lain (bersama dengan kondisi tambahan).
Masih ada test case lain yang tumpang tindih satu sama lain: case test A mencakup beberapa tetapi tidak semua kondisi case test B, dan sebaliknya, tetapi Anda tidak dapat menjatuhkan salah satu tanpa mengorbankan coverage.
Ketika Anda menemukan sebagian tumpang tindih, Anda kadang-kadang dapat menjatuhkan satu test case dan kemudian mendesain ulang yang lain untuk menutupi kondisi yang hilang. Namun, sering kali, Anda harus mengundurkan diri ke beberapa redundansi cakupan pada tingkat test case. Jumlah waktu dan usaha yang terbuang biasanya sangat rendah dibandingkan dengan parameter dari keseluruhan proyek.
Gambar 4.3. Examples of test case independence, redundancy, and partial overlap. (Black, 2009)
Ukuran tes, dalam hal durasi, upaya, atau keduanya, juga dapat menyulitkan koordinasi dan partisi. Beberapa insinyur uji menulis kasus uji panjang; yang lain menulis yang lebih pendek. Beberapa kasus uji pada dasarnya membutuhkan durasi yang lama atau lebih banyak upaya.
Anda akan menemukan masalah pemetaan lainnya selama pelaksanaan pengujian, dan Anda harus merencanakan solusi sebelumnya. Yang paling penting adalah menciptakan proses untuk memasukkan semua laporan bug ke dalam sistem pelacakan bug tunggal.
Atau, Anda atau asisten administrasi dapat menerima laporan bug dari mitra dan memasukkannya ke dalam basis data. Kedua pendekatan akan bekerja, asalkan Anda memastikan waktu penyelesaian minimal.
Karena banyak mitra menguji, Anda akan melihat lebih dari jumlah laporan bug duplikat yang biasa. Bahkan jika Anda melakukan pekerjaan yang baik dalam mengoordinasi dan
mempartisi kasus uji untuk menghindari tumpang tindih, bug tertentu akan muncul dengan sendirinya pada beberapa pengujian.
Bahasa juga bisa menjadi masalah utama dalam hal pelacakan bug dan pelacakan tes. Anda dapat menghabiskan banyak upaya untuk menyiapkan proses berbagi data secara elektronik, hanya untuk mengetahui bahwa tim tidak dapat berkomunikasi dalam bahasa yang sama. Sayangnya, menggunakan penerjemah nonteknis atau asisten administrasi tidak akan cukup, karena banyak dari pertanyaan yang muncul mungkin bersifat teknis.
Bahasa dapat menjadi penghalang yang tidak dapat diatasi dalam beberapa upaya uji terdistribusi; Anda harus yakin untuk menyelidiki masalah ini sebelum membuat program semacam itu.
Masalah pemetaan lainnya dapat berasal dari perbedaan antar perusahaan dalam jam kerja, panggilan konferensi, kebijakan telecommuting, dan sejenisnya. Tantangan teknis seperti ketidaksesuaian sistem email dapat membuat kesulitan. Bahkan hambatan hukum dan perdagangan yang tidak terduga terkadang menghadirkan tantangan.
Tidak mungkin untuk membuat daftar setiap masalah pemetaan yang mungkin. Poin mendasarnya adalah bahwa selama tahap perencanaan program uji terdistribusi, Anda harus mengantisipasi perbedaan, baik formal maupun informal, antara proses yang Anda dan mitra tes Anda ikuti dan mencoba untuk menempatkan rencana untuk meminimalkan kesulitan.
Managing a Distributed Test Effort
Setelah Anda terbiasa dengan hal itu, mengelola tim uji virtual Anda saat hasil pekerjaan tidak jauh berbeda dengan mengelola tim perusahaan Anda sendiri. Namun, Anda akan menemukan bahwa kelima bidang ini memerlukan perhatian khusus: melacak proyek uji dan temuannya; mengkomunikasikan status tes dan perubahan arah; menangani realitas politik;
peka terhadap budaya yang berbeda; dan membangun dan mempertahankan kepercayaan.
1. Monitoring execution test / memantau eksekusi tes
Anda mungkin akan menemukan ini lebih menantang dalam upaya uji terdistribusi, bahkan jika Anda telah melakukan pekerjaan dengan baik untuk menangani masalah pemetaan yang dibahas sebelumnya. Jarak, zona waktu, dan hambatan bahasa semua bisa menghalangi.
Secara umum, Anda harus merencanakan kelambatan tertentu dalam menerima hasil dari mitra tes eksternal, dari beberapa menit hingga beberapa hari, tergantung pada lokasi.
2. Communicating Status and Changing Direction / Mengkomunikasikan Status dan Mengubah Arah
Tidak ada mitra pengujian Anda yang dapat beroperasi dalam ruang hampa. Anda perlu cara untuk membuat mereka tahu tentang apa yang sedang terjadi, cara untuk memungkinkan mereka membawa masalah untuk anda perhatikan, dan cara untuk menyesuaikan kursus berdasarkan keadaan yang berubah dan temuan pengujian.
Email bukanlah saluran komunikasi yang buruk untuk tujuan ini, tetapi dapat dengan mudah berubah menjadi "perang api" dan diskusi tangensial. Jika Anda menggunakan email untuk mengkomunikaikan status, ada baiknya memformat pesan sebagai laporan status atau daftar item tindakan. Pembaruan harian dari dokumen pendek (satu atau dua halaman) dari masing-masing tes partners harus cukup sebagai laporan status. Atau, Anda dapat menyimpan daftar item tindakan bernomor tertentu, masing-masing dengan pemilik dan tanggal tenggat.
Daftar item tindakan paling efektif bila dikombinasikan dengan panggilan konferensi reguler setidaknya sekali seminggu. elama mode krisis, Anda mungkin akan menemukan bahwa panggilan semacam itu diperlukan setiap hari. Panggilan konferensi harus selalu memiliki agenda terstruktur, dengan masing-masing mitra melaporkan status dan masalah pada kelompok pada gilirannya, diikuti dengan peninjauan item tindakan. Pada akhir setiap panggilan konferensi, semua peserta harus menyetujui status proyek uji saat ini dan apa yang akan terjadi selanjutnya.
Panggilan konferensi ini juga merupakan tempat yang tepat untuk mengkomunikasikan perubahan arah yang memengaruhi banyak mitra. Perubahan yang memengaruhi hanya satu mitra dapat dikomunikasikan baik melalui telepon atau email, tergantung pada urgensi. Pastikan untuk melacak setiap perubahan dalam rencana dalam database manajemen perubahan Anda. Perubahan yang memengaruhi mitra pengujian Anda sama pentingnya dengan yang memengaruhi tim Anda sendiri.
3. Handling Political Consideration / Menangani Pertimbangan Politik
Meskipun mitra pengujian di luar lokasi Anda mungkin terisolasi dari kekacauan dan intrik proyek pengembangan Anda, Anda akan mewarisi masalah politik mereka. Setiap orang dalam proyek pengembangan harus dilihat sebagai peserta yang aktif dan positif. Namun,
karena perusahaan dan vendor pengujian pihak ketiga berada di luar lokasi, citra mereka sebagai non-kontributor yang hanya mengejar uang dapat meningkat. Selain itu, pertanyaan tentang kompetensi dan ketekunan dapat muncul ketika kesalahan yang tak terhindarkan dibuat.
Karena Anda memilih peserta tes dan merencanakan upaya pengujian, Anda memiliki andil dalam keberhasilan mereka — tidak hanya keberhasilan teknis mereka (menemukan bug dan meliput poin uji penting), tetapi juga keberhasilan politik mereka (dipersepsikan oleh anggota tim pengembang lainnya) efektif, berkomitmen, dan pekerja keras). Terserah Anda untuk memperjuangkan mitra uji eksternal di antara rekan-rekan internal Anda di tim pengembangan.
4. Being Sensitive to Culture Clashes / peka terhadap benturan budaya
Kapan pun organisasi pengujian Anda mengandalkan mitra eksternal, masalah budaya akan menjadi relevan, baik yang berbasis pada budaya lokal atau dalam budaya perusahaan. Ini dijamin oleh fakta bahwa penguji harus memiliki perspektif yang berbeda dari kontributor teknis lainnya.
Ketika Anda menerapkan program uji terdistribusi, Anda akan mengalami masalah budaya ini secara besar-besaran. Perspektif, prioritas, dan nilai-nilai berbeda dari satu tim ke tim lainnya bahkan dalam suatu perusahaan, tergantung pada kepribadian anggota tim, keterampilan kepemimpinan manajer, integritas para pemimpin teknis dan moral yang dirasakan tim (bukan hanya manajer), dan, paling tidak, misi yang dilayani tim. Ketika Anda berurusan dengan organisasi eksternal, masalah budaya ini diperkuat oleh fakta bahwa para pemimpin perusahaan mitra dapat menanamkan nilai-nilai yang berbeda.
Dalam hal pengujian terdistribusi, perbedaan tersebut dapat berarti bahwa beberapa individu yang akan gagal sebagai teknisi pengujian, insinyur pengujian, atau manajer pengujian di perusahaan Anda dipandang sebagai penguji profesional yang sempurna yang selaras dengan budaya perusahaan di organisasi mitra pengujian Anda.
5. Building and Maintaining Trust / membangun dan merawat kepercayaan
Lebih mendasar daripada budaya yang kongruen adalah pertanyaan apakah Anda bisa mempercayai mitra pengujian Anda. Kepercayaan adalah konsep yang bahkan lebih licin daripada budaya, tetapi kita semua mengenali orang yang kita percayai atau tidak percaya.
Semua alat dan tips yang dibahas dalam bab ini tidak dapat menyelesaikan masalah ini.
Jika Anda mempartisi program pengujian Anda agar mitra tes menjalankan tes kritis, Anda
harus membangun hubungan saling percaya. Anda harus percaya bahwa lab tes tidak akan melewatkan beberapa tes karena itu berjalan di bawah jadwal dan khawatir bahwa itu akan kehilangan uang pada proyek Anda. Anda harus percaya vendor Anda jujur tentang bug yang paling memalukan sekalipun. Anda harus memercayai kolega Anda di kantor penjualan asing untuk menindaklanjuti dengan hasil tes sehingga Anda tidak berebut pada menit terakhir untuk berurusan dengan bug kritis. Anda harus memercayai pengguna dan pengganti pengguna untuk tidak menggunakan hasil pengujian untuk membanting tim Anda — atau proyek.
Kepercayaan melibatkan lebih dari sekedar memastikan bahwa mitra Anda tidak akan mengambil keuntungan dari Anda. Anda harus memperhatikan mereka juga.
Tentu saja ada jalan sempit untuk melangkah dalam hal-hal seperti itu, karena Anda memiliki tanggung jawab fidusia kepada majikan Anda. Namun, membantu mitra pengujian yang Anda pilih dalam menangani masalah hutang yang samar-samar atau lamban menunjukkan niat baik dan kepedulian terhadap keberhasilan mitra Anda. Saat orang tahu Anda menjaga mereka, biasanya mereka akan memperhatikan Anda.
SIMPULAN
Kesimpulan yang dapat diambil dari materi ini adalah:
1. Menyusun upaya pengujian terdistribusi melibatkan pembuatan proyek tes matriks / keterampilan-matriks proyek hybrid, yang terdiri dari tim pengujian, kontributor lain dalam perusahaan, dan orang-orang yang bekerja di perusahaan lain.
2. Mendistribusikan pengujian dengan langkah berikut dengan memilih mitra pengujian Anda, merencanakan upaya pengujian yang didistribusikan, mengelola pengujian eksternal seolah-olah itu milik Anda.
3. Memilih partner dimulai dari vendor, organisasi uji independent, kantor penjualan atau pemasaran, analis bisnis anda, help desk atau dukungan teknis, target pelanggan atau pengguna.
4. Merencanakan pendistribusian pengetesan sistem terdiri dari memantau eksekusi test, mengkomunikasikan status dan mengubah arah testing, menangani pertimbangan politik, peka terhadap benturan budaya, merawat dan membangun kepercayaan.
DAFTAR PUSTAKA
Black, Rex. (2009). Managing the testing process: practical tools and techniques for managing hardware and software testing. 03. Wiley. Indianapolis. ISBN: 9780470404157
