XI. Implementasi Sistem
Kegiatan Implmentasi Sistem meliputi : Training Personal, Konversi Sistem, Review post-implementation, Dokumentasi, dan dukungan lain
XI.1. Training Personal
Tipe Training disesuaikan dengan keadaan lingkungan implementasi sistem:
* Eksternal Training: kursus dr vendor pelatihan
* Internal Training: On the Job Training
* Belajar Sendiri
Memilih Staf yang akan dilatih terdiri dari tiga kelompok user
* Teknisi & Administrator yang akan bertugas merawat sistem
* Application user (user pd umumnya)
* General Manager
Pelatihan untuk Administrator:
* Set-up sistem awal
* Rutinitas harian
* Diagnosis kesalahan
* Menulis sistem log
* Trouble shooting
* Penanganan Keamanan
* Melakukan perubahan, penghapusan, restore
* Melakukan Backup / Disaster Recovery
Application Training
* Set up files
* Proses transaksi
* Validasi data
* Update batch
* Prosedur akhir-hari
* Mencetak laporan
* Pemahaman pesan kesalahan
XI.2. Konversi Sistem
Proses organisasional terhadap perubahan sistem dari sistem informasi lama ke sistem baru sehingga perlu perencanaan shutdown sistem dan Sirkulasi kegiatan organisasi
XI.2.1. Instalasi Sistem
1. Konversi Sistem Secara Langsung
Disebut juga sbg Cold Turkey yaitu langsung menghentikan sistem lama dan menjalankan sistem baru;
Konversi sistem ini dilakukan apabila:
* Sistem lama sudah tidak berfungsi sama sekali
* Sistem baru bersifat kecil / sederhana
* Tidak harus menggantikan sistem lain
* Rancangan sistem baru sangat berbeda dengan sistem lama
Keuntungan adalah biaya yang relatif tidak mahal
Kelemahan: resiko kegagalan yang tinggi
Perlu segera diikuti oleh program pengujian dan pelatihan
Instalasi Langsung
2. Konversi Paralel
Sistem lama dan sistem baru beroperasi bersamaan untuk periode waktu tertentu.
Output dari masing2 sistem dibandingkan, apabila terdapat perbedaan akan direkonsiliasi
Keuntungan: resiko kegagalan rendah
Kerugian: biaya yg tinggi khususnya duplikasi dokumen
Apabila terdapat perbedaan dalam metode produksi, aturan keputusan, prosedur akunting, dan model kendali inventarisasi maka metode konversi paralel tidak dapat dilakukan
Instalasi Paralel
3. Konversi Phase- In
Sistem baru diimplementasikan secara gradual, sedikit demi sedikit -> memberikan waktu lebih utk asimilasi perubahan
Sistem harus disegmentasi, dan penginstalan sistem baru berdasarkan segmentasi tsb.
Untuk setiap segmentasi mis.:
* mekanisme sistem lama dikembangkan untuk memproses data baru,
* kemudian sistem baru yang berhubungan dg segmen tersebut diinstal setelah tidak terdapat kegagalan proses
* kemudian dievaluasi.
Keunggulan: proses asimilasi sistem dapat diminimalisasi,
Kerugian: biaya yang besar utk membuat interface temporer.
Instalasi Perfase
4. Konversi Pilot
Sistem diinstal hanya pada sebagian organisasi (mis. Kantor cabang atau pabrik) sbg pilot -> segmentasi organisasi
Keuntungan: resiko lebih sedikit dibandingkan metode langsung, dan lebih murah dibandingkan metode paralel, alokasi kesalahan, alokasi pelatihan untuk semua organisasi.
Instalasi Pilot
XI.2.2. Konversi Data
Melakukan modifikasi file yang sudah ada dalam bentuk : Format, Isi data dan Medium penyimpanan
Metode Konversi:
1. Konversi File Langsung
– Membuat program konversi data apabila sistem lama menggunakan komputer, sedangkan apabila dr model manual ke komputer butuh waktu lama utk memasukkan data,
– Membuat suatu prosedur kendali:
* File Master -> pemeriksaan terhadap field dan records
* File Transaksi -> perlu diperiksa apabila terdapat perbedaan medium / prosedur
* File Indeks -> Key yg menghubungkan master file
* File Backup -> Mengamankan database apabila terjadi kesalahan proses atau kerusakan di pusat data
2. Konversi File Gradual
File dikonversi sedikit demi sedikit
Rekord akan dikonversi hanya ketika menunjukkan aktifitas transaksi.
Rekord lama yang sudah tidak melakukan transaksi tidak dikonversi,
* Apabila terdapat transaksi, maka kemudian akan dimasukkan ke sistem,
* Program mencari di file master baru utk record yg akan diupdate dan kemudia diproses,
* Jika record tidak ditemukan dalam file master baru, file master lama diakses untuk record yg sesuai dan rekord tersebut ditambahkan ke file master baru.
XI.3. Evaluasi Sistem Baru
– Bertujuan untuk mendapatkan cara meningkatkan efisiensi dan efektifitas sistem baru, serta memberikan informasi untuk pengembangan sistem mendatang.
– Biasanya dilakukan setelah dua hingga enam bulan instalasi -> sudah terdapat periodik pelaporan serta isu sistem masih baru
– Area Penininjauan meliputi :
XI.3.1. Faktor Sistem
– Faktor kelayakan TELOS (Technical, Economical, Legality, Operation, Schedule) meliputi
* Teknologi pendukung;
* Pendanaan utk biaya teknologi, operasional, pemeliharaan;
* Operasinal sistem yg tidak melanggar hukum;kesesuain jadwal.
* Keterampilan personal dll.
– Faktor strategik PDM (Productivity, Differentiation, Management)
* Sudah tercapainya produktivitas stl implementasi sistem baru
* Kontribusi terhadap diferensiasi produk dan layanan
* Dukungan informasi utk peningkatan kualitas perencanaan, pengontrolan, dan pembuatan keputusan manajemen
Faktor rancangan MURRE (Maintenability, Usability, Reusability, Extenability)
* Dokumentasi sudah komprehensive, jelas dan up to date
* Mendukung CMS (Change Management System)
* Module untuk user sudah terpenuhi
* Terpenuhinya dukungan ke user
* Modul perangkat lunak dapat digunakan kembali
* Terbebas dari fault/error
* Adaptif dan fleksibel
XI.3.2. Komponen Rancangan Sistem
– Output
* Output harus sesuai, relevan, akurat dan dapat digunakan kembali
* Kemanan pengguna output bagi user yg tidak berhak
* Kemudahan akses
* Sesuai dengan kognitif user
* Ketepatan edit dan identifikasi laporan
Input
* Form memenuhi kaidah pedoman dan spesifikasi rancangan
* Verifikator data input
* Manual pengisian form
* Proses
* Pengujian terhadap semua proses
* Peninjauan terhadap prosedur dan dokumentasi
* Prosedure pengoperasian
* Reliability sistem
Database
* Pengujian penambahan record baru stl record terakhir
* Membuat suatu file baru
* Membaca / menulis ke file dengan label header yg salah
* Memproses data end-of-file
* Memasukkan record yg tidak lengkap
* Proses Back-up, recovery
* Kecepatan melakukan query
* Mengatasi batch proses secara efisien (proses tidak terlalu lama)
Kendali
* Penetapan standar operasional untuk mengendalikan kejadian yang bersifat luar biasa.
* Rencana pemulihan sistem sudah terujikan (disimulasikan) dan ditetapkan,
* Terdapat kendali akses terhadap serangan virus maupun perusak lainnya
Platform Teknologi
* Peripheral, workstation, processor, dan jaringan,
* Membandingkan kinerja dengan rancangan
* Membutuhkan komponen penunjang:
* Job accounting system
* Hardware monitoring
* Software monitoring
* Konfigurasi teknologi yang optimal
* Respon time yang acceptable
Keakuratan Estimasi
* Waktu: menggunakan tool spt PERT, Gant, atau lainnya.
* Biaya yg sebenarnya sesuai dg yg diestimasi
* Manfaat
Tingkat dukungan:
* Sumber daya tersedia
* Manajemen puncak
* Pelatihan (teknik pelatihan, user, tutor)
XI.4. Dokumentasi Sistem
Informasi detail tentang spesifikasi perancangan sistem, rician proses kerja internal berserta fungsionalitasnya.
XI.4.1. Bentuk Dokumentasi Sistem
Internal documentation, dokumentasi sistem yang merupakan bagian dari source code program atau yang dibuat pada saat proses kompilasi
External documentation, dokumentasi sistem tetang teknik perancangan yang berbentuk diagram terstruktur seperti Data Flow Diagram ataupun E-R Diagram
Dokumentasi Proses, merekam proses pengembangan dan perawatan, dimana isi dokumentasi proses adalah: perencanaan, jadwal, kualitas proses, standard proses.
Dokumentasi Produk, menggambarkan produk yang sedang dikembangkan dari sudut pandang engineer pengembang/perawatan yang termasuk dokumentasi produk adalah: user manual, help.
Dokumentasi Maintenance, menjelaskan tata cara perawatan dan pengelolaan sistem yang baik.
* Maintenance Manual
* Trouble shooting manual
* Tingkat kerusakan yang ditulis biasanya hanyalah sampai pada level yang ringan dan tak perlu penanganan khusus.
Dokumentasi Source Code, penamaan variable, constant, procedure. Function yang jelas dan konsisten
* Memberi keterangan pada header setiap procedure, yang berisis:
* Fungsi dari procedure
* Variable local masukan, dan keluaran
* Variable global yang digunakan dan yang dipengaruhi.
* Pada Header Program diberi:
* Nama penulis program
* Editor
* Compiler dan Library yang digunakan
* Versi dan upgrade history
* Tanggal pembuatan software
* Deskripsi singkat tentang software
XI.4.2. User Documentation,
Informasi yang tertulis ataupun melalui bentuk visual lainnya tentang aplikasi sistem, bagaimana sistem tersebut bekerja, dan cara menggunakannya.
Technical manual untuk hardware dan pengoperasian sistem dengan kualitas penulisan yang baik dan jelas
Fitur yang harus terdapat dalam user manual
* Bagian “Bagaimana Memulai”
* Indeks yang komprehensif
* Tutorial
* Contoh-contoh
* Quick reference guide
* Referensi Ringkas yg menunjukkan fitur dan routin
* Ilustrasi
* Manual yg mudah diikuti, mudah dimengerti dan terurut secara logis
XI.4.3. Isi User Manual
System Overview
* Komponen Hardware,
* Komponen Software
* Komponen Aplikasi
* Sistem Akses Kontrol
* Flow of system process
Instalasi
* Persyaratan minimal sistem yang dibutuhkan
* Menyalin dan memback-up
* Proses instalasi
* Konfigurasi/kustomisasi produk
Tutorial
* Penjelasan langkah-demi langkah dengan contoh
* Penjelasan tiap contoh
* Pengembangan dari contoh dasar
* Penggunaan on-line Help
Instruksi detail
* Keluaran dari produk
* Masukan untuk produk
* Pengoperasian produk
* Penanganan error
* Fungsi khusus
Detail Teknis
* Prinsip dari operasi
* Fitur lanjutan
* Algoritma utama yang digunakan
* Struktur data utama
* Modifikasi produk
* Cara memperoleh dukungan teknis dan informasi lanjutan
* User Manual
* Pesan Kesalahan
* Trouble Shooting
XI.5. Dukungan Suksesnya Implementasi SI
Dua syarat yang diperlukan untuk kesuksesan implementasi:
* Dukungan manajemen ketika pengembangan sistem.
* Terlibatnya user ketika proses pengembangan.
Pemahaman terhadap proses
* Resiko
* Komitmen terhadap project
* Komitmen terhadap perubahan
* Pemahaman terhadap definisi dan rencana project
* Harapan user yang realistis
Faktor kesuksesan implementasi:
* Mengetahui sistem apa yang dipakai
* Kepuasan user akan sistem
Rabu, 30 Desember 2009
TESTING 10
X. Distribusi Proyek Test
Usaha membangun tes terdistribusi melibatkan pembuatan organisasi tes tambahan, berdasarkan skill, berdasarkan proyek, pembentukan tim test, kontributor lain di perusahaan, serta orang yang bekerja di perusahaan lain.
Testing terdistribusi terdiri dari:
* Vendor (perusahaan-perusahaan yang menyediakan produk-produk yang diintegrasikan ke dalam produk)
* Organisasi tes yang independen (bebas)
* Kantor Penjualan (khususnya kantor-kantor luar negeri untuk lokalisasi tes)
* Target Customer (untuk beta testing)
Untuk mendistribusikan tes dengan sukses, perlu di lakukan 3 langkah sekuensial :
1. Pemilihan rekan test, berdasarkan spesifikasi tes yang dibutuhkan untuk distribusi dan kenapa harus melakukan hal itu
2. Merencanakan tes terdistribusi
3. Mengatur external testing seperti milik sendiri
X.1. Pemilihan Rekan
Alasan penggunaan sumber tes dari luar dibandingkan dengan tim sendiri.
* mencoba untuk menggunakan pengaruh dari pihak luar, khususnya disaat tidak dapat atau tidak mau untuk membuat ulang didalam organisasi;
* tidak dapat menanggung pekerjaan yang tidak dapat menanganinya secara cepat.
X.1.1. Vendor
Jika Anda adalah seorang tes manajer untuk DataRocket, beberapa dari peserta dalam distribusi tes Anda adalah vendor Anda. Kartu SCSI, dipesan dari vendor Taiwan, dan kartu LAN, dipesan dari vendor Amerika Serikat, harus bekerja dengan baik pada mainboard Anda, dimana satu dengan yang lain, dengan harddisk, dengan perangkat keras lain yang terpasang, dan dengan perangkat lunak – tetapi yang pertama dan yang utama mereka harus bekerja dengan sendirinya. Apa jaminan yang Anda miliki bahwa produk yang dijual vendor bekerja? Dan, jika Anda percaya bahwa produk bekerja, apakah Anda perlu mengulangi testing vendor?
Pertanyaan ini dapat dipergunakan bukan hanya untuk perangkat keras, tetapi juga untuk perangkat lunak. Dengan peningkatan tajam, perusahaan perangkat lunak memberikan pekerjaan pengembangannya pada pihak ketiga, beberapa diantaranya terpisah jauh ribuan mil dari kantor utama. Entah apakah usaha outsourcing meliputi perangkat keras, perangkat lunak, ataupun keduanya, Anda telah dapat definisi pendistribusian testing. Pertanyaan kemudian menjadi apakah Anda dapat menghasilkan testing terdistribusi untuk berjalan memiliki kekuatan dan menghindari usaha yang sia-sia.
Saya mengaudit proses tes vendor untuk menyakinkan bahwa perusahaan modem tersebut mentes secara cukup dan untuk menentukan testing apa yang dapat diabaikan oleh klien saya. Saya menemukan bahwa vendor telah melakukan sebuah pekerjaan yang baik untuk testing modem itu sendiri. Testing tersebut terfokus kedalam, dan modem tersebut dapat berkerja dengan baik.
Dari persepektif luar untuk melihat modem sebagai seluruh bagian dari sistem, bagaimanapun juga, testing belum selesai. Sebagai contoh, vendor tersebut melalukan tes suhu panas di modem, mengingat bahwa modem tersebut akan diinstall di komputer laptop. Tetapi, tes tersebut menggunakan kasus buatan yang tidak cocok dengan setting yang terdapat pada sistem klien saya sehingga tidak dapat bekerja dengan baik. Saat saya menunjuk hal ini, vendor tetap menolak secara sopan untuk mengubah spesifikasi tes. Saya menerima respon yang sama mengenai pertanyaan dari kecocokan software: vendor tidak tertarik untuk mengubah proses testingnya untuk mengunakan lingkungan operasi untuk perangkat lunak yang ingin kami sertakan di dalam harddisk. Vendor modem merasa bahwa tes integrasi dari modem ke dalam sistem dan pengaruhnya dalam bagian dari sebuah sistem secara jelas merupakan perhatian klien saya.
Dalam kasus sebuah komponen seperti sebuah modem, fokus yang terbatas mungkin dapat diterima. Karena interface modem yang terhubung dengan sistem biasanya menggunakan serial, integrasi perangkat lunak adalah melalui interface standar. Tetapi jika vendor Anda menjual kartu SCSI, integrasi merupakan isu yang besar buat Anda. Isu kompabilitas muncul antara perangkat SCSI. Anda tidak dapat dengan mudah mengangpap bahwa menghubungkan harddisk, tape drive, perangkat removable mass-storage, dan mungkin sebuah scanner ke perangkat SCSI akan berguna. Testing integrasi sangat penting dan harus dimulai lebih awal.
Demikian juga, jika Anda membeli bagian komponen yang signifikan untuk sistem Anda, dari sebuah vendor, kesuksesan proyek Anda tergantung fungsi yang tepat dari komponen; itu adalah dasar keberhasilan platform Anda. Bahkan jika beberapa bagian dari sistem tidak cukup dewasa, Anda mungkin butuh untuk mulai testing sistem lebih awal. Prototipe yang berfungsi penuh, bahkan jika prototipe tersebut kehilangan aspek “tepat dan selesai (fit and finish)”, diperlukan sebelum Anda menganggap bahwa prototipe tersebut akan bekerja.
Kebanyakan vendor mengambil pandangan sempit untuk hal yang ditargetkan dari testing mereka: mereka mungkin mengetes dengan dalam dalam area-area tertentu, tetapi mereka sepertinya tidak ingin untuk mengetesnya secara luas. Kecuali produk Anda hanya melakukan fungsi yang terbatas (mesin ATM, sebagai contohnya), Anda mungkin membutuhkan testing vendor tambahan dengan tes yang luas. Bahkan jika vendor melakukan sejumlah tes yang besar, tes tersebut tidak rinci seperti yang Anda butuhkan.
Faktor Kunci
Gambar mengilustrasikan tiga faktor kunci yang mempengaruhi perluasan dimana Anda harus mengintegrasikan testing vendor ke dalam usaha Anda sendiri.
• Irreplaceability. Jika sebuah komponen seperti kartu PCI LAN atau sebuah modem ISA adalah sebuah masalah, Anda dapat mengantikannya dengan mudah; sebuah motherboard, pada hal lain, akan membuktikan hal yang berbeda. Demikian juga, jika Anda memberikan pembuatan perangkat lunak back-end untuk aplikasi jaringan kepada pihak lain, Anda sepenuhnya tergantung untuk software tersebut bekerja secara benar.
• Coupling. Jika komponen vendor pada dasarnya berdiri sendiri – modem sebagai contohnya – dan tidak dapat berinteraksi dengan sistem dalam cara-cara yang unik (dan mungkin sangat bebas), komponen tersebut tidak terikat dengan erat (not tightly coupled). Tetapi, jika hal itu mempengaruhi kerja keseluruhan dari sistem, seperti BIOS, komponen itu sangat terikat (coupled). Keterikatan (coupling) mungkin akan lebih dari sekedar masalah teknis: marketing terkadang menentukan batasan-batasan (constraints) yang mengikat produk Anda dengan komponen-komponen tertentu.
• Capability. Anda dapat memutuskan apakah dapat percaya kepada kapabilitas (kemampuan) tes vendor dengan mengaudit operasi tes perusahaan. Jika Anda puas dengan kualitas dari testing, Anda dapat membiarkan vendor mengerjakan sebagian besar lainnya, walaupun demikian, Anda mungkin ingin memeriksanya selama pelaksanaan tes. Tetapi, jika proses tes vendor seluruhnya khusus dan staf testing tampaknya kurang memuaskan organisasi, Anda harus merencanakan untuk secara aktif mengatur pekerjaan vendor – atau mengulangnya kembali.
Didalam Gambar 10-2, semakin dekat vendor dari tempat asalnya dari ketiga panah ini, semakin sedikit Anda perlu mengintegrasikan usahanya kepada organisasi/perusahaan Anda. Semakin jauh sebuah vendor bergerak dari tempat asalnya semakin dekat Anda perlu mengatur tiap proses dari tes kepada diri Anda, atau mengundurkan diri Anda sendiri untuk menduplikasikannya seluruhnya.
X.1.2. Penguji Pihak Ketiga
Sumber tes pihak ketiga menyertakan organisasi manapun yang menawarkan pelayanan tes untuk membayar klien. Pelayanan ini dapat tersedia dalam bentuk off site atau on site atau keduanya. Saya membedakan antara antara sebuah body shop atau agensi sementara dan tes pihak ketiga berdasarkan apakah perusahaan mengatur proyek. Tes organisasi pihak ketiga harus menyediakan sejumlah perencanaan tes proyek dan manajemen. Jika perusahaan mau memberikan suatu tester untuk menunjukkan seperti yang Anda lihat cocok, adalah agensi sementara, bukan perusahaan tes pihak ketiga.
Organisasi tes pihak ketiga yang tepat membawa beberapa kunci kekuatan keatas meja. Hal yang sangat penting adalah ahli (expertise) di dalam manajemen proyek tes dan keterampilan serta pengalaman dalam teknis-teknis testing. Keterampilan perusahaan mungkin juga spesial, cukup fokus, atau unik. Sebagai contoh, beberapa konsultasi tes tidak melakukan apapun kecuali untuk pekerjaan keamanan komputer, sementara lainnya memiliki ahli yang dapat dipergunakan. Keahlian ini tidak umum dan tidak dapat dikuasai dengan cepat; jika anda membutuhkan ahli, bekerja dengan organisasi pihak ketiga yang baik mungkin hanya satu-satunya pilihan Anda.
Keuntungan lainnya adalah bahwa perusahaan tes dapat seringkali memulai menjalankan tes untuk Anda lebih cepat daripada ketika Anda melakukannya sendiri. Beberapa organisasi mempertahankan kebebasan konfederasi dari subkontraktor yang dapat melompat jauh; lainnya memiliki sebuah staff dari ahli tes dalam pengajian. Sebagai tambahan, beberapa perusahaan ini mempertahankan inventori perangkat keras yang banyak atau perpustakaan perangkat lunak yang tidak dapat Anda miliki atau tidak mau Anda gandakan. Sebagai contohnya, beberapa laboratorium tes mengkhususkan diri dalam lingkungan testing, dimana dapat melibatkan peralatan yang besar dan mahal seperti kamar panas (thermal chamber) dan meja getar (shock tables).
Telah disebutkan, pengaturan dengan tes laboratorium pihak ketiga dapat mengakibatkan jurang yang dalam. Untuk kebanyakan bagian, jurang ini sama berbahaya jika menyewa konsultan. Saat Anda mengontrak dengan sebuah organisasi tes diluar perusahaan, Anda adalah orangnya yang menanggung resiko yang harus dibuktikan oleh perusahaan yang tidak mampu dari penghentian tes terdistribusi yang dibutuhkan oleh Anda. Anda mungkin menuntut untuk malpraktik, tetapi seperti kebanyakan, lab luar perusahaan yang tidak mampu akan keluar begitu saja dengan satu proyek yang sangat berharga dan seorang klien yang tidak senang. Anda, bagaimanapun juga, dapat kehilangan pekerjaan Anda untuk memilih rekan yang salah.
Jalan untuk menghindari situasi semacam itu adalah Anda harus berlatih dengan rajin pertama kalinya Anda melakukan bisnis dengan tim tes eksternal. Saat Anda menyewa seorang pekerja atau kontraktor untuk menjadi staf Anda, Anda mewawancarai secara individual, memeriksa referensi, dan meneliti resume orang tersebut. Mencari organisasi tes dari pihak ketiga yang tepat juga tidak jauh berbeda.
Anda mulai dengan wawancara, yang sepertinya akan bertingkat. Dalam beberapa kasus, Anda akan berbicara dengan tenaga penjual terlebih dahulu. Sepertinya akan menyia-nyiakan waktu Anda tetapi sebenarnya tidak. Dalam pertemuaan ini, Anda dapat mengkualifikasikan (atau mendiskualifikasikan) perusahaan dalam isu-isu bisnis seperti harga, turnaround time, dan fasilitas-fasilitas yang disediakan. Ingat, bahwa tenaga penjual memeriksa Anda juga, mengumpulkan informasi tentang isu-isu yang keluar dari perspektif perusahaan.
Jika hasil dari interview postif untuk kedua belah pihak, Anda harus melanjukan diskusi dengan manajer proyek dan staf teknis. Jangan lewati langkah ini, dan Anda dapat langsung berbicara secara langsung kepada orang-orang yang akan bekerja dengan Anda didalam proyek. (Jika perusahaan tidak mau menyetujui individual secara spesifik dalam poin ini, itu mungkin tidak mematikan perjanjian, tetapi Anda harus mengarisbawahi dalam kontrak utama, siapapun yang akan menjadi, harus menyetujui setiap dan semua perubahan dalam personel kita) Anda sudah tahu bagaimana untuk menyewa pimpinan tes proyek yang baik, insinyur tes, dan teknisi tes yang baik, jadi Anda dapat mempergunakan standar yang sama untuk indiviu-individu yang terlibat disini. Dalam kenyataannya, dalam situasi seperti ini standar Anda haruslah lebih tinggi: orang-orang ini akan mengeluarkan biaya yang lebih banyak dari gaji pekerja Anda yang, jadi Anda mempunyai hak untuk mengharapkan level yang lebih tinggi dari seorang ahli.
Berhati-hatilah bahwa pembayaran per jam untuk layanan dari labora-torium tes eksternal relatif linear, tetapi tidak sama untuk biaya yang dibayarkan untuk tester yang Anda miliki. Jika Anda membayar $75 per jam untuk kontrak dengan insinyur tes, Anda dapat membayar dua atau tiga kali lebih besar untuk sumber yang sama melalui perusahaan tes pihak ketiga. Hal ini tampaknya tidak masuk akal, tetapi, seperti menyewa Porsche lawan dari memilikinya, menyewa profesional terampil membutuhkan pengeluaran yang lebih jika dibandingkan basis per jam. Tingkatan Anda untuk komitmen adalah kecil, dan Anda tidak membayar untuk down time, jadi laboratorium tes tidak dibayar untuk resiko tersebut. Ada perumpamaan, jangan berbisnis dengan orang bodoh, atau membayar mahal untuk hal yang memalukan. Tujuan Anda adalah untuk yakin bahwa orang-orang yang mengaku bahwa mereka dapat mengerjakan pekerjaan mereka benar-benar dapat melakukannya, bahwa harganya pantas untuk Anda, dan bahwa keuntungannya adil untuk perusahaan pengetesan.
Pertimbangan tambahan diperhitungkan jika pekerjaan dilakukan secara off site. Dalam kasus ini, Anda akan membayar tidak hanya untuk ornag-orang tetapi untuk fasilitas dan akses kepada peralatan tersebut. Jika Anda menyewa laboratorium tes untuk melakukan tes lingkungan, sebagai contohnya, Anda menyewa ruangan panas dan meja getar, bersama dengan profesional terampil yang mengoperasikannya.
Akhirnya, mengingat fasilitas itu sendiri. Saya menyarankan kunjungan on-site untuk Anda jika Anda murni bekerja pada sumber off-site. Apa yang dibutuhkan keamanan Anda? Apakah Anda membutuhkan laboratorium terpisah? (Apakah saingan kita menggunakan fasilitas yang sama?) Apakah fasilitas geografis nyaman/tidak nyaman? Apakah lokasi tersebut memberikan Anda akses kepada kolam talenta yang murah yang dapat ditemukan secara lokal? (Sebagai contoh, biaya pekerja yang murah yang sering Anda temukan di laboratorium tes luar negeri mungkin terbatas dengan geografis yang kurang dekat dan perjalanan yang mungkin akan sering Anda lakukan untuk mengkoordinasikan pekerjaan.)
X.1.3. Sales Offices
Jika Anda menjual produk secara internasional, Anda harus mempunyai kantor penjualan lokal atau sebuah rekan penjualan (seperti distributor) dalam bagian-bagian yang beragam. Alternatif yang lain, Anda mungkin memiliki kantor pemasaran “maya”, dengan dengan anggota staf di dalam kantor penjualan utama menangani penjualan luar negeri. Jalan lain, kantor penjualan harus sadar dan berkualifikasi untuk mengevaluasi resiko kualitas yang unik untuk market luar negeri.
Bab 1 daftar dari kualitas resiko memasukkan lokalisasi sebagai kategori utama dari resiko untuk produk apapun yang terjual atau digunakan secara internasional. (Lihat “Lokalisasi”, halaman 22.) Di dalam beberapa kasus, testing kualitas resiko dalam kantor rumah adalah suatu tantangan. Dengan DataRoket sebagai contoh, Anda mungkin membutuhkan tester yang menguasai bahasa Jepang, Korea, Mandarin, Thai, Kanton, Jerman, Belanda, Perancis, Rusia, Spanyol, dan Italia untuk melengkapi panduan dokumentasi dan startup.
Seperti dalam semua situasi, trade-offs muncul. Kabar baiknya adalah sebagai rekan kerja, anggota staff dalam sebuah kantor penjualan memiliki tujuan yang sama seperti yang Anda miliki – mereka memiliki sebuah keinginan untuk memastikan bahwa usaha tes berhasil. Jika rekan Anda di kantor Tokyo melakukan pekerjaan yang buruk untuk testing lokalisasi SpeedyWriter wilayah Asia, mereka akan merugi sama seperti Anda merugi.
Walaupun demikian, ada kekurangan untuk masalah ini. Anda tidak dapat mengasumsikan teknik yang canggih untuk kebanyakan tenaga penjual. Jika Anda bertanggung jawab untuk hasil dari testing dan ingin barang tertentu dijual, Anda akan butuh untuk melakukan detail-detail berikut. Setiap kasus tes apapun yang Anda berikan kepada rekan yang tidak memiliki keahlian teknis harus tepat dan tidak membingungkan.
Anda juga harus ingat bahwa tenaga penjual atau rekan penjualan mungkin tidak bekerja untuk Anda dalam satu pengertian yang sama. Walaupun Anda bertanggung jawab untuk menyakinkan kualitas dan kelengkapan dari tes yang mereka lakukan, Anda tidak dapat memberi struktur pekerjaan mereka, dan Anda tidak dapat menspesifikasikan standar dari kelakukan mereka, bagaimana cara berinteraksi tim Anda atau situasi dimana Anda akan mengakhiri hubungan. Sebagai masalah yang praktis, Anda mungkin dapat memiliki masalah untuk mendapatkan hasil dari mereka.
X.2. Perencanaan Distribusi Test Selanjutnya
Anda perlu memiliki rencana untuk distribusi testing dengan tingkatkan yang sama dari detail yang Anda gunakan untuk usaha internal. Rencana itu harus merupakan proses yang mengarah ke depan, membuktikan bahwa Anda memiliki operasi yang dalam kontrol. Poin awal adalah kelengkapan perencanaan tes dari level atas dibahas di Bab 1 dan 2. Anda harus juga memiliki perangkat tes yang sudah didefinisikan dengan baik, walaupun beberapa detail mungkin tetap untuk diselesaikan. Penelusuran tes dan bug harus bekerja, termasuk rencana untuk menyebarkan sistem penelusuran bug.
X.2.1. Menilai Kemampuan
Saat Anda cukup mempelajari tentang potensi dari rekan tes untuk memilih organisasi untuk proyek, seperti yang telah dijabarkan sebelumnya, Anda perlu untuk menaksir kemampuan tes rekan Anda yang spesifik sebagai bagian dari perencanaan keseluruhan usaha Anda. Anda harus melakukan pendekatan untuk latihan ini, seperti pendekatan Anda kepada pertemuan bisnis apapun: dengan beberapa keluaran yang diharapkan didalam pikiran. Menyusun daftar permintaan dari kontribusi dapat Anda check off jika Anda melakukan perkiraan, memfokuskan diri khususnya pada pertanyaan yang berhubungan dengan keahlian, penempatan staf, dan pengaturan fisikal.
Pada setiap tugas yang diberikan , bisakah test partner memproduksi orang yang ahli , berpengalaman , kompeten dengan kemampuan yang mencukupi, bila begitu siapa yang akan bekerja? Dalam banyak kasus , kau akan dikejutkan oleh level kemampuan dari partner testmu, bagaimanapun juga perusahaan berusaha untuk terus memproduksi orang ahli. Tapi dalam beberapa kasus aku akan menemukan bahwa orang-orang yang kau wawancarai tidak akan sesuai dengan harapanmu.
Ini bukanlah alasan untuk menyingkirkan partner kerjamu dari pemikiranmu , bagaimanapunn juga , terutama orang-orang yang memiliki kualifikasi yang cukup dibandingkan dengan kandidat lainnya..
Pengaturan karyawan sangatlah penting. Hal ini sering menguji perusahaan tentang bagaimana cara kerja eksternal perusahaan tersebut berlangsung . Tapi setiap perusahaan mempunyai pembatasan karyawan dan staff. Pastikan dirimu bahwa partner kerjamu dapat mensupport seluruh team . Sangatlah tidak wajar bagi para ahli software dan hardware untuk melakukan pekerjaan yang tidak bersumber untuk memenangkan bisnis dengan berjanji secara berlebihan kepada klien dengan tujuan untuk pembuatan sebuah projek. Lalu, setelah memenangkan bisnis, perusahaan tidak dapat melanjutkan pengeksekusian. Ini adalah kelemahan beberapa perusahaan yang sering dipertanyakan, tai dapat juga memberikan sebuah kesalahan yang sangat fatal kepadamu jika beberapa hal dalam elemen-elemen penting dalam test tidak diselesaikan secara sempurna dan dapat menyebabkan kesalahan yang fatal karena tidak memeriksa partner test secara sempurna.
X.2.2. Mengerti biaya dan resiko
Sebelum meneruskan ke hal yang lebih detil , partner testmu harus mempunyai segala perincian mengenai biaya yang dibutuhkan di dalam pembuatan proyek tersebut.Dalam perusahaan yang mandiri , tentu saja, menghasilakan uang dengan menjual test services, dengan tidak membicarakan prospek dalam test services. Atasanmu mngkin akan menyimpulkan bahwa pendiskusian adalah bagian dari persetujuanmu dengan perusahaanmu, tapi mungkin juga mereka tidak akan mencapai kesepakatan. Para pembeli asing mungkin bersedia untuk melakukan beberapa test dengan gratis namun kamu juga tidak dapat menyimpulkan bahwa semua waktu yang mereka gunakan tidak berharga sama sekali.
Dari atasan atau dari orang ketiga dalam perusahaan anda dapat melakukan penawaran , yang biaya penawaran mengenai waktu , biaya material yang diperlukan . Jika kamu menerima penawaran mengenai waktu dan bahan-bahan dasar , kamu akan memerlukan data yang mendetil mengenai penjurnalan keuangan perusahaan anda yang juga memperhitungkan mengenai budget yang dibutuhkan dan besarnya uang yang dikeluarkan. Pastikan bahwa penawaran tersebut meliputi flexibility , bukan cuma kemungkinan yang dapat terjadi tapi juga mengenai langkah-langkah yang dapat diambil ketika kamu menciptakan test program lainnya. Dalam pembuatan program uang selalu jadi masalah utama dan untuk menekan biaya dibutuhkan kerja yang ekstra dalam perancanaan test.
X.2.3. Koordinasi dan partisi dalam pembuatan test program
Langkah berikutnya dalam pendistribusian test adalah penggabungan 2 atau lebih projek menjadi satu program yang united(berhubungan dan mandiri). Pada umumnya, dalam pembuatan kue pie, bermacam-macam bahan masakan diperlukan dalam pembuatan kue tersebut , lalu ketika kue-kue pie tersebut telah siap untuk dimakan setiap kue tersebut sudah tersedia dalam piring-piring setiap orang untuk dinikmati.
Mari kita gunakan contoh Data Rocket yang lain . Dengan tidak menghiraukan lokasi pembuatan , kita simpulkan bahwa pemain mendistribusikan usaha test dalam Winged Bytes, kartu SCSI dan tempat test lab ,System Cookers.Tujuan utamanya adalah untuk memproduksi kasus test, yang diorganisasikan menjadi beberapa test suites yang di mana setiap test tersebut mempunyai 3 team.
Langkah pertama , kolasi , yang meliputi single list yang akan dijalankan dari setiap studi kasus yang akan dijalankan. Kau memerlukan untuk mengumpulkan setiap daftar dari tim tersebut dan menambahkannya dalam lembar kerjamu.Gunakan lembar kerja kolom untuk menyimpan track di mana setiap tim bertanggung jawab pada setiap test.
Langkah kedua , koordinasi , anda harus melenyapkan kasus yang tidak berguna, sebagai contoh, anda menyadari bahwa Lucky Bit merencanakan untuk menjalankan thermal test dalam kartu SCSI namun anda lebih memilih System Cookers yang menjalankan test tersebut dengan kartu SCSI yang sudah diinstall.Mungkin Lucky Bit dapat mengkalkulasi perkembangan pada setiap komponen dan spesifikasi test.System Cookers dapat memasukkan thermal sensor ke dalam komponen-komponen dan menjalankannya kemudian.
Langkah ketiga yang harus dilakukan adalah membuat partisi dan detail mengenai kerjanya, mengulas kembali test pada lembar kerja yang dibutuhkan kepada pembeli yang baru.
Ketiga tahap atau langkah dan proses ini harus diangkat ke permukaan agar tidak dianggap sebagai masalah tehnik semata melainkan masalah yang serius. Masalah modal juga mengkhawatirkan dan dapat menjadi masalah sewaktu-waktu jika sudut pandang dan wawasan diubah. Dan juga masalah politik juga dapat memerankan peranan penting.
X.2.4. Mengorganisasikan Masalah Logistik
Salah satu keuntungan dari pendistribusian testing adalah ketika di mana ketika semua test suites dikerjakan secara benar dan setiap partner mengerjakan fungsinya masing-masing secara tepat maka dalam situasi yang seperti ini dapat meminimalkan masalah logistic.
Dalam beberapa kasus , bagaimanapun juga pendistribusian testing menciptakan masalah logistic yang unik. Masalah yang paling menyulitkan adalah ketika suatu produk meliputi 1 atau lebih hardware yang berbeda.
Berbicara mengenai hardware , seseorang haruslah menkoordinasi dan mengatur pengiriman dan pengembalian barang. Pengiriman barang dengan menggunakan kapal adalah hal yang sangat sulit dilakukan karena membutuhkan perencanaan dan konsentrasi . Bila hendak mengirimkan barang dengan menggnakan kapal anda akan melewati batas-batas territorial atau batas internasional sehingga anda harus dihadapkan dengan bermacam-macam persoalan.
X.2.5. Menghadapi masalah Mapping
Jika semua pengoperasian berjalan dengan cara-cara yang sama maka merut buku pertunjuk yang ada maka pekerjaan anda akan selesai setelah program tersebut mempunai hubungan atau jaringan. , tugas-tugasnya mempunyai partisi yang jelas dan segala maslah logstik sudah terselesaikan dan sudah teratasi. Pada kenyataannya bahwa setiap team menggunakan pendekatan yang berbeda dan anda tidak bias dan tidak usah untuk melakukan pekerjaan itu dengan cara-cara yang sama , tapi yang perlu untuk dilakukan adalah mengenali dan menkoordinasi setiap perbedaan yang ada. Hal ini disebut dengan maslaah mapping karena kau hendak untuk mengidentifikasi kan dan memasukkan tugas dan pekerjaan rekan kerjamu ke dalam pekerjaan kita.
Dalam mapping yang pertama kali terkadang muncul masalah yang sering kali timbul selama koordinasi, seperti ketika mengurutkan dan membandingkan studi kasus. Beberapa kasus umumnya tidak berhubungan antara kasus yang satu dengan kasus yang lainnya, dan anda diharuskan untuk menyimpan dan mengatur mereka dalam setiap level yang seharusnya.
Contoh Beberapa Kasus Test Case
Ketika kamu menemukan parsial, anda bisa beberapa kali melewatkan beberapa kasus dan mencari kasus yang baru untuk menutupi kondisi yang tidak stabil tersebut. Besarnya waktu yang terbuang danusaha yang sia-sia umumnya sangat rendah jika dibandingkan dengan parameter keseluruhan proyek.
Ukuran test(dalam durasi waktu, usaha, dan keduanya) bias mempengaruhi dan merumitkan koordinasi dan partisi yang aa . Beberapa para ahli menuliskan kasus dengan durasi yang panjang dan beberapa ada yang menuliskan dengan durasi yang pendek.
Anda akan menemukan beberapa masalah mapping yang berlangsung selama pengeksekusian test, dan kamu harus merencanakan solusi ke depannya . Hal yang paling penting dalam pembuatan suatu proses adalah harus mendapatkan semua bug reports ke dalam suatu single bug system. Dengan DataBase, kamu dapat menggunakan tayangna replikasi untuk mendistribusikan database kepada partnermu, atau mereka dapat menghubungi dan mengakses data ke dalam server atau jaringan kita.
Karena kita mempunyai rekan kerja yang banyak tidak hanya satu maka kamu akan melihat bahwa banyak sekali nomor-nomor replica atau duplikatn dari bug report. Bahkan jika kamu melakukan pekerjaan yang bagus dalam pengkoordinasian dan partisi untuk menghindari overlap, maka akan ada virus yang menduplikasikan dirinya ke dalam test yang kita buat atau yang kita kerjakan.
Bahasa juga dapat menjadi masalah yang sangat utama ketika sedang menyelidiki masalah mengenai pencarian virus-virus dan penyelidikan test. Anda akan membutuhkan banyak sekali usaha untuk mensetting proses data secara elektronik untuk mencari tahu bagaimana cara untuk berkomunikasi. Sialnya dengan menggunakan alat penerjemah elektronik sangatlah tidak memuaskan dan tidak memadai, dan hal ini kemudian menjadi masalah teknik karena pertanyaan yang diberikan bervariasi. Bahasa dapat menjadi masalah yang utama dalam pendistribusian system oleh karena itu kamu harus terlebih dulu yakin terhadap masalah yang dihadapi ketika membuat sebuah program
X.3. Pengelolaan Disribusi Test Selanjutnya
Ketika kamu mulai terbiasa dengan masalah pendistribusian ini, mengatur test tim secara virtual tidak jauh berbeda dengan mengatur tim di dalam perusahaanmu sendiri. Kau akan menemukan bahwa ada 5 area yang memiliki beberapa kelebihan :
X.3.1. Memonitor eksekusi test
Mungkin kau akan menemukan hal ini lebih menarik dalam pendistribusian test, bahkan jika anda telah menyelesaikan pekerjaan dengan baik mengenai mapping yang baik yang seperti telah dijelaskan sebelumnya. Jarak, perjalanan waktu, dan batasan bahasa dapat menjadi sebuah halangan dalam melakukan pekerjaan.Jika kamu memperbaharui dan mengup-date terus data mengenai lembar kerja tracking , dalam sekejap, dan menemukan bahwa kamu punya beberapa pertanyaan mengenai beberapa kesalahan yang dilakukan oleh rekan sekerjamu , anda akan kehilangan beberapa jam untuk melacak tentang siapa orang yang dapat menyediakan informasi tersebut. Jika kamu butuh data yang penting dalam situasi yang sangat penting pula dalam management, hal ini dapat menjadi masalah yang sangat serius. Umumnya , kamu harus merencanakan mengenai kemungkinan hasil yang akan didapat dari rekan sekerjamu.
X.3.2. Mengkomunikasikan Status dan Merubah Arah
Tidak ada satu dari rekan sekerjamu yang dapat mengoperasikan dalam keadaan jeda atau vakum.Kamu harus tetap mensibukkan program tersebut apapun yang terjadi, dan merupakan cara untuk membiarkan mereka untuk masuk ke dalam perhatian kita.
E-mail merupakan alat komunikasi di dunia web yang tidak buruk namun e –mail ini dapat dijadikan sebagai alat untuk mengadu domba atau pemecah dalam diskusi dan komunikasi. Pembaharuan harian dalam setiap test haruslah mempunyai tampilan report status.
X.3.3. Mengatasi Pertimbangan Politik
Semenjak kamu memilih test participant dan test effort , kamu mempunyai andil dalam kesuksesan mereka , tidak hanya sukses secara tehnik(menemukan virus dan melindungi bagian –bagian yang penting) namun sukses di dalam bidang poitik. Hal ini terkadang terjadi, pandangan atau persepsi yang negative terhadap test partner terkadang benar. Dalam beberapa kasus mereka merupakan projek yang terjaring di dalam suatu jaringan.
X.3.4. Sensitif Terhadap Kebudayaan
Kapanpun organisasi manapun memgantungkan dirinya kepada rekan kerja eksternalnya, perbedaan dalam kebudayaan dapat menjadi masalah. Masa lalu saya(penulis) menyediakan sebuah contoh, aku berubah dari menjadi seorang programmer dan system administrator menjadi penguji coa ketika kuterima pekerjaan itu dengan lab bebas yang independent., semua kolega di laboratorium tersebut adalah seorang tester.Kita bekerja kepada klien yang sedagn mengembangkan software dan hardware, tapi biasanya kita berinteraksi hanya dengan satu atau dua orang klien saja.Saya dipaksa untuk eradaptasi secara instant, bagaimanapun juga , setelah beberapa tahun kemudian, ketika saya menjadi manager di sebuah toko pengembangan software, saya merasakan pengalaman bagaimana menjadi manager untuk pertama kalinya dan mempunyai banyak bawahan dan klien.
Sama seperti kau mengimplementasikan bagaimana mendistribusikan test program kau akan merasakan pengalaman yang dirasakan ketika mendistribusikannya. Perspektif, nilai dan prioritas menjadi suatu kesatuan di dalam perusahaan , tergantung terhadap setiap kepribadian yang ada pada setiap anggota tim, kempemimpinan seorang manager, hubungan teknik dan non teknik yang ada antara pemimpin dan bawahannya. Ketika berhadapan dengan organisasi di dunia luar , factor dan masalah kebudayaan ini selalu diperhitungkan karena pemimpin sering kali membeda-bedakan nilai yang ada terhadap anggota timnya ataiupun bawahannya.
Dalam istilah testing terdistribusi perbedaan semacam itu ddapta juga berarti bahwa individual yang gagal debagai seorang teknisi yang ahli, insinyur penguji, atau manager penguji dalam perusahaanmu diangap sebagai penguji yang professional yang dipasangkan dengan budaya pada organisasi perusahaanmu. Sebagai contoh, saya menempatkan nilai yang besar untuk hubungan kerjasama yang antara tester dan pengembang. Perbedaannya, bagaimanapun juga, beberapa organisasi yang berhasil menggunakan pendekatan melalui adversatorial, dengan manajer tes memberi semangat untuk “menangkap” kesalahan pada pengembang. Saya akan menemukannya secara emosional untuk bekerja di dalam organisasi dimana para pekerja saling menggagalkan kesuksesan yang lainnya, tetapi, jika saya bekerja dengan rekan tes yang menggunakan pendekatan yang demikian, adalah sangat sulit untuk saya mengubah budaya pada lingkungan saya itu. Meskipun demikian, saya mungkin akan menemukan
Lebih halus, tetapi tantangan yang sama tentang pertentangan budaya dapat muncul. Sebagai contoh, saya mempunyai klien yang (atas rekomendasi saya) menggunakan lab eksternal di Taipei untuk menangani beberapa tes kompabilitas. Vendor klien juga berlokasi di Taipei. Budaya laboratorium tes sangat dinamis tetapi untuk waktu yang lama, seperti yang telah dilakukan oleh klien saya. Vendor yang terlibat memiliki budaya “8-to-5”. Ironisnya, saat kami membutuhkan untuk mengadakan conference call secara reguler, budaya vendor dan klien saya tidak bermasalah, tetapi perbedaan waktu bermasalah dengan laboratorium tes. Kami sudah merencanakan conference call pada jam 8.30 pagi waktu Taipei, dimana tidak masalah bagi vendor tetapi merupakan masalah bagi pimpinan proyek di laboratorium tes, yang bekerja dari siang hari sampai malam hari karena pilihannya. Saya telah menyelesaikan situasi semacam ini dengan memutuskan untuk membebaskannya dari conference call, meyakinkan bahwa saya mengerti hasil dari laboratorium tes dan dapat mencari jalan keluarnya. Akomodasi semacam ini membiarkan manajer tes untuk terus bekerja pada jadwal yang dirasanya nyaman. Jika saya bersikeras bahwa dia harus mulai bekerja pada waktu yang tidak dirasanya nyaman, hubungan kami bisa menjadi rusak.
X.3.5. Membangun dan Mempertahankan Kepercayaan
Banyak pertanyaan yang lebih mendasar daripada masalah kesamaan budaya adalah apakah Anda dapat mempercayai rekan tes Anda. Kepercayaan adalah konsep yang lebih licik dari budaya, tetapi kita mengenal orang-orang yang kita percaya atau kita tidak dapat percaya. Bahkan mereka yang menghabiskan banyak waktu untuk membangun kepercayaan kita dapat dengan mudah kehilangan kepercayaan itu. Anggap saja bahwa Anda adalah seorang manajer di Winged Byte, bekerja dalam DataRocket. Rekan-rekan Anda, manajer tes vendor kartu SCSI, telah dengan cermat melaporkan masalah-masalah yang ditemukan oleh manajer tim tes, tidak hanya dalam proyek ini tetapi juga dua poyek sebelumnya. Angap saja sekarang bahwa tes manajer menunda atau menyembunyikan berita dari bug yang fatal dalam kartu BIOS. Kepercayaan yang telah dibangun tersebut selama beberapa tahun akan menderita secara serius bahkan fatal, mundur.
Semua perangkat-perangkat dan tip-tip mendiskusikan di dalam bab ini tidak dapat menyelesaikan masalah. Jika Anda membagi tes program Anda supaya rekan tes menjalankan tes kritis, Anda harus membangun hubungan untuk kepercayaan. Anda harus percaya bahwa laboratorium tes tidak akan melewatkan beberapa tes karena hal itu akan bekerja dibelakang jadwal dan ketakutan untuk kehilangan uang untuk proyek Anda. Anda harus percaya vendor Anda untuk berterus terang mengenai bug bahkan untuk yang paling memalukan sekalipun. Anda harus percaya rekan Anda yang berada di kantor penjualan di luar negeri untuk menindaklanjuti hasil tes jadi Anda tidak akan bingung pada menit-menit terakhir untuk berurusan dengan bug yang kritis.
Kepercayaan juga melibatkan keyakinan yang lebih bahwa rekan Anda tidak akan mengambil keuntungan dari Anda. Anda harus behati-hati dengan mereka juga. Sebagai contoh, saya telah membantu rekan tes di dalam proyek saya bekerja mengatasi faktur-faktur dan kontrak-kontrak. Ada juga jalan yang cukup sulit untuk permasalahan ini, saat Anda mempertaruhkan tanggung jawab Anda kepada bawahan Anda. Tetapi membantu rekan tes Anda yang terpilih untuk berurusan dengan kontrak yang samar-samar atau utang usaha yang tidak jelas menunjukkan kepercayaan yang baik dan sebuah perhatian untuk keberhasilan rekan Anda. Saat seseorang mengenal bahwa Anda memperhatikan mereka, mereka biasanya juga akan memperhatikan Anda.
Saat buku ini memberikan penggambaran yang lebih jelas, sangatlah berguna untuk memperhatikan bahwa kepercayaan bukan hanya isu untuk rekan tes eksternal Anda. Sangatlah kritis untuk semua tim proyek, entah mereka yang bekerja pada satu perusahaan atau banyak perusahaan. Anda harus mengasumsikan bahwa mereka memberikan kesuksesan untuk proyek dengan bekerja memberikan kemampuan mereka yang terbaik sesuai dengan peranan mereka masing-masing. Anda juga harus mengasumsikan bahwa mereka bekerja untuk keberhasilan kolaborasi mereka.
Klise mengenai beberapa apel yang buruk yang membuat rusak satu tong apel, khususnya untuk kepercayaan dalam organisasi. tetapi juga adalah benar bahwa pemimpin kunci dalam sebuah perusahaan dapat memberikan contoh untuk membangun standar perusahaan yang luas. Orang-orang yang secara konsisten memberikan usaha terbaik mereka menciptakan semangat dan dedikasi. Orang yang memberikan dukungan kepada rekan kerja mereka dan bekerja sama untuk kebaikkan dalam suatu tim membantu perkembangan kepercayaan diri dan niat baik. Tidak ada seorangpun bisa memberikan kontribusi kepercayaan perusahaan sebanyak seorang manajer. Manajer yang menjaga komitmen mereka; yang tidak pernah membuat seorang bawahan untuk jatuh dalam kesalahan mereka sendiri; yang mendukung dan merayakan keberhasilan pemain bintang mereka, tim mereka, dan perusahaan sebagai keseluruhan; yang menyeimbangkan kebutuhan perusahaan dengan kebutuhan personal dari bawahan dan rekan mereka; dan yang secara konsisten memberikan dan mengharapkan kejujuran dari staf mereka, kawan sekerja mereka, dan manajer mereka sendiri membuat sebuah budaya perusahaan untuk kepercayaan dan integritas. Sebagai seorang manajer tes, Anda harus berpartisipasi dalam menciptakan dan menegakkan lingkungan kepercayaan, baik dalam tim dan lintas perusahaan. Standar yang Anda pasang dalam tim Anda penting seperti hal lainnya yang Anda lakukan.
Usaha membangun tes terdistribusi melibatkan pembuatan organisasi tes tambahan, berdasarkan skill, berdasarkan proyek, pembentukan tim test, kontributor lain di perusahaan, serta orang yang bekerja di perusahaan lain.
Testing terdistribusi terdiri dari:
* Vendor (perusahaan-perusahaan yang menyediakan produk-produk yang diintegrasikan ke dalam produk)
* Organisasi tes yang independen (bebas)
* Kantor Penjualan (khususnya kantor-kantor luar negeri untuk lokalisasi tes)
* Target Customer (untuk beta testing)
Untuk mendistribusikan tes dengan sukses, perlu di lakukan 3 langkah sekuensial :
1. Pemilihan rekan test, berdasarkan spesifikasi tes yang dibutuhkan untuk distribusi dan kenapa harus melakukan hal itu
2. Merencanakan tes terdistribusi
3. Mengatur external testing seperti milik sendiri
X.1. Pemilihan Rekan
Alasan penggunaan sumber tes dari luar dibandingkan dengan tim sendiri.
* mencoba untuk menggunakan pengaruh dari pihak luar, khususnya disaat tidak dapat atau tidak mau untuk membuat ulang didalam organisasi;
* tidak dapat menanggung pekerjaan yang tidak dapat menanganinya secara cepat.
X.1.1. Vendor
Jika Anda adalah seorang tes manajer untuk DataRocket, beberapa dari peserta dalam distribusi tes Anda adalah vendor Anda. Kartu SCSI, dipesan dari vendor Taiwan, dan kartu LAN, dipesan dari vendor Amerika Serikat, harus bekerja dengan baik pada mainboard Anda, dimana satu dengan yang lain, dengan harddisk, dengan perangkat keras lain yang terpasang, dan dengan perangkat lunak – tetapi yang pertama dan yang utama mereka harus bekerja dengan sendirinya. Apa jaminan yang Anda miliki bahwa produk yang dijual vendor bekerja? Dan, jika Anda percaya bahwa produk bekerja, apakah Anda perlu mengulangi testing vendor?
Pertanyaan ini dapat dipergunakan bukan hanya untuk perangkat keras, tetapi juga untuk perangkat lunak. Dengan peningkatan tajam, perusahaan perangkat lunak memberikan pekerjaan pengembangannya pada pihak ketiga, beberapa diantaranya terpisah jauh ribuan mil dari kantor utama. Entah apakah usaha outsourcing meliputi perangkat keras, perangkat lunak, ataupun keduanya, Anda telah dapat definisi pendistribusian testing. Pertanyaan kemudian menjadi apakah Anda dapat menghasilkan testing terdistribusi untuk berjalan memiliki kekuatan dan menghindari usaha yang sia-sia.
Saya mengaudit proses tes vendor untuk menyakinkan bahwa perusahaan modem tersebut mentes secara cukup dan untuk menentukan testing apa yang dapat diabaikan oleh klien saya. Saya menemukan bahwa vendor telah melakukan sebuah pekerjaan yang baik untuk testing modem itu sendiri. Testing tersebut terfokus kedalam, dan modem tersebut dapat berkerja dengan baik.
Dari persepektif luar untuk melihat modem sebagai seluruh bagian dari sistem, bagaimanapun juga, testing belum selesai. Sebagai contoh, vendor tersebut melalukan tes suhu panas di modem, mengingat bahwa modem tersebut akan diinstall di komputer laptop. Tetapi, tes tersebut menggunakan kasus buatan yang tidak cocok dengan setting yang terdapat pada sistem klien saya sehingga tidak dapat bekerja dengan baik. Saat saya menunjuk hal ini, vendor tetap menolak secara sopan untuk mengubah spesifikasi tes. Saya menerima respon yang sama mengenai pertanyaan dari kecocokan software: vendor tidak tertarik untuk mengubah proses testingnya untuk mengunakan lingkungan operasi untuk perangkat lunak yang ingin kami sertakan di dalam harddisk. Vendor modem merasa bahwa tes integrasi dari modem ke dalam sistem dan pengaruhnya dalam bagian dari sebuah sistem secara jelas merupakan perhatian klien saya.
Dalam kasus sebuah komponen seperti sebuah modem, fokus yang terbatas mungkin dapat diterima. Karena interface modem yang terhubung dengan sistem biasanya menggunakan serial, integrasi perangkat lunak adalah melalui interface standar. Tetapi jika vendor Anda menjual kartu SCSI, integrasi merupakan isu yang besar buat Anda. Isu kompabilitas muncul antara perangkat SCSI. Anda tidak dapat dengan mudah mengangpap bahwa menghubungkan harddisk, tape drive, perangkat removable mass-storage, dan mungkin sebuah scanner ke perangkat SCSI akan berguna. Testing integrasi sangat penting dan harus dimulai lebih awal.
Demikian juga, jika Anda membeli bagian komponen yang signifikan untuk sistem Anda, dari sebuah vendor, kesuksesan proyek Anda tergantung fungsi yang tepat dari komponen; itu adalah dasar keberhasilan platform Anda. Bahkan jika beberapa bagian dari sistem tidak cukup dewasa, Anda mungkin butuh untuk mulai testing sistem lebih awal. Prototipe yang berfungsi penuh, bahkan jika prototipe tersebut kehilangan aspek “tepat dan selesai (fit and finish)”, diperlukan sebelum Anda menganggap bahwa prototipe tersebut akan bekerja.
Kebanyakan vendor mengambil pandangan sempit untuk hal yang ditargetkan dari testing mereka: mereka mungkin mengetes dengan dalam dalam area-area tertentu, tetapi mereka sepertinya tidak ingin untuk mengetesnya secara luas. Kecuali produk Anda hanya melakukan fungsi yang terbatas (mesin ATM, sebagai contohnya), Anda mungkin membutuhkan testing vendor tambahan dengan tes yang luas. Bahkan jika vendor melakukan sejumlah tes yang besar, tes tersebut tidak rinci seperti yang Anda butuhkan.
Faktor Kunci
Gambar mengilustrasikan tiga faktor kunci yang mempengaruhi perluasan dimana Anda harus mengintegrasikan testing vendor ke dalam usaha Anda sendiri.
• Irreplaceability. Jika sebuah komponen seperti kartu PCI LAN atau sebuah modem ISA adalah sebuah masalah, Anda dapat mengantikannya dengan mudah; sebuah motherboard, pada hal lain, akan membuktikan hal yang berbeda. Demikian juga, jika Anda memberikan pembuatan perangkat lunak back-end untuk aplikasi jaringan kepada pihak lain, Anda sepenuhnya tergantung untuk software tersebut bekerja secara benar.
• Coupling. Jika komponen vendor pada dasarnya berdiri sendiri – modem sebagai contohnya – dan tidak dapat berinteraksi dengan sistem dalam cara-cara yang unik (dan mungkin sangat bebas), komponen tersebut tidak terikat dengan erat (not tightly coupled). Tetapi, jika hal itu mempengaruhi kerja keseluruhan dari sistem, seperti BIOS, komponen itu sangat terikat (coupled). Keterikatan (coupling) mungkin akan lebih dari sekedar masalah teknis: marketing terkadang menentukan batasan-batasan (constraints) yang mengikat produk Anda dengan komponen-komponen tertentu.
• Capability. Anda dapat memutuskan apakah dapat percaya kepada kapabilitas (kemampuan) tes vendor dengan mengaudit operasi tes perusahaan. Jika Anda puas dengan kualitas dari testing, Anda dapat membiarkan vendor mengerjakan sebagian besar lainnya, walaupun demikian, Anda mungkin ingin memeriksanya selama pelaksanaan tes. Tetapi, jika proses tes vendor seluruhnya khusus dan staf testing tampaknya kurang memuaskan organisasi, Anda harus merencanakan untuk secara aktif mengatur pekerjaan vendor – atau mengulangnya kembali.
Didalam Gambar 10-2, semakin dekat vendor dari tempat asalnya dari ketiga panah ini, semakin sedikit Anda perlu mengintegrasikan usahanya kepada organisasi/perusahaan Anda. Semakin jauh sebuah vendor bergerak dari tempat asalnya semakin dekat Anda perlu mengatur tiap proses dari tes kepada diri Anda, atau mengundurkan diri Anda sendiri untuk menduplikasikannya seluruhnya.
X.1.2. Penguji Pihak Ketiga
Sumber tes pihak ketiga menyertakan organisasi manapun yang menawarkan pelayanan tes untuk membayar klien. Pelayanan ini dapat tersedia dalam bentuk off site atau on site atau keduanya. Saya membedakan antara antara sebuah body shop atau agensi sementara dan tes pihak ketiga berdasarkan apakah perusahaan mengatur proyek. Tes organisasi pihak ketiga harus menyediakan sejumlah perencanaan tes proyek dan manajemen. Jika perusahaan mau memberikan suatu tester untuk menunjukkan seperti yang Anda lihat cocok, adalah agensi sementara, bukan perusahaan tes pihak ketiga.
Organisasi tes pihak ketiga yang tepat membawa beberapa kunci kekuatan keatas meja. Hal yang sangat penting adalah ahli (expertise) di dalam manajemen proyek tes dan keterampilan serta pengalaman dalam teknis-teknis testing. Keterampilan perusahaan mungkin juga spesial, cukup fokus, atau unik. Sebagai contoh, beberapa konsultasi tes tidak melakukan apapun kecuali untuk pekerjaan keamanan komputer, sementara lainnya memiliki ahli yang dapat dipergunakan. Keahlian ini tidak umum dan tidak dapat dikuasai dengan cepat; jika anda membutuhkan ahli, bekerja dengan organisasi pihak ketiga yang baik mungkin hanya satu-satunya pilihan Anda.
Keuntungan lainnya adalah bahwa perusahaan tes dapat seringkali memulai menjalankan tes untuk Anda lebih cepat daripada ketika Anda melakukannya sendiri. Beberapa organisasi mempertahankan kebebasan konfederasi dari subkontraktor yang dapat melompat jauh; lainnya memiliki sebuah staff dari ahli tes dalam pengajian. Sebagai tambahan, beberapa perusahaan ini mempertahankan inventori perangkat keras yang banyak atau perpustakaan perangkat lunak yang tidak dapat Anda miliki atau tidak mau Anda gandakan. Sebagai contohnya, beberapa laboratorium tes mengkhususkan diri dalam lingkungan testing, dimana dapat melibatkan peralatan yang besar dan mahal seperti kamar panas (thermal chamber) dan meja getar (shock tables).
Telah disebutkan, pengaturan dengan tes laboratorium pihak ketiga dapat mengakibatkan jurang yang dalam. Untuk kebanyakan bagian, jurang ini sama berbahaya jika menyewa konsultan. Saat Anda mengontrak dengan sebuah organisasi tes diluar perusahaan, Anda adalah orangnya yang menanggung resiko yang harus dibuktikan oleh perusahaan yang tidak mampu dari penghentian tes terdistribusi yang dibutuhkan oleh Anda. Anda mungkin menuntut untuk malpraktik, tetapi seperti kebanyakan, lab luar perusahaan yang tidak mampu akan keluar begitu saja dengan satu proyek yang sangat berharga dan seorang klien yang tidak senang. Anda, bagaimanapun juga, dapat kehilangan pekerjaan Anda untuk memilih rekan yang salah.
Jalan untuk menghindari situasi semacam itu adalah Anda harus berlatih dengan rajin pertama kalinya Anda melakukan bisnis dengan tim tes eksternal. Saat Anda menyewa seorang pekerja atau kontraktor untuk menjadi staf Anda, Anda mewawancarai secara individual, memeriksa referensi, dan meneliti resume orang tersebut. Mencari organisasi tes dari pihak ketiga yang tepat juga tidak jauh berbeda.
Anda mulai dengan wawancara, yang sepertinya akan bertingkat. Dalam beberapa kasus, Anda akan berbicara dengan tenaga penjual terlebih dahulu. Sepertinya akan menyia-nyiakan waktu Anda tetapi sebenarnya tidak. Dalam pertemuaan ini, Anda dapat mengkualifikasikan (atau mendiskualifikasikan) perusahaan dalam isu-isu bisnis seperti harga, turnaround time, dan fasilitas-fasilitas yang disediakan. Ingat, bahwa tenaga penjual memeriksa Anda juga, mengumpulkan informasi tentang isu-isu yang keluar dari perspektif perusahaan.
Jika hasil dari interview postif untuk kedua belah pihak, Anda harus melanjukan diskusi dengan manajer proyek dan staf teknis. Jangan lewati langkah ini, dan Anda dapat langsung berbicara secara langsung kepada orang-orang yang akan bekerja dengan Anda didalam proyek. (Jika perusahaan tidak mau menyetujui individual secara spesifik dalam poin ini, itu mungkin tidak mematikan perjanjian, tetapi Anda harus mengarisbawahi dalam kontrak utama, siapapun yang akan menjadi, harus menyetujui setiap dan semua perubahan dalam personel kita) Anda sudah tahu bagaimana untuk menyewa pimpinan tes proyek yang baik, insinyur tes, dan teknisi tes yang baik, jadi Anda dapat mempergunakan standar yang sama untuk indiviu-individu yang terlibat disini. Dalam kenyataannya, dalam situasi seperti ini standar Anda haruslah lebih tinggi: orang-orang ini akan mengeluarkan biaya yang lebih banyak dari gaji pekerja Anda yang, jadi Anda mempunyai hak untuk mengharapkan level yang lebih tinggi dari seorang ahli.
Berhati-hatilah bahwa pembayaran per jam untuk layanan dari labora-torium tes eksternal relatif linear, tetapi tidak sama untuk biaya yang dibayarkan untuk tester yang Anda miliki. Jika Anda membayar $75 per jam untuk kontrak dengan insinyur tes, Anda dapat membayar dua atau tiga kali lebih besar untuk sumber yang sama melalui perusahaan tes pihak ketiga. Hal ini tampaknya tidak masuk akal, tetapi, seperti menyewa Porsche lawan dari memilikinya, menyewa profesional terampil membutuhkan pengeluaran yang lebih jika dibandingkan basis per jam. Tingkatan Anda untuk komitmen adalah kecil, dan Anda tidak membayar untuk down time, jadi laboratorium tes tidak dibayar untuk resiko tersebut. Ada perumpamaan, jangan berbisnis dengan orang bodoh, atau membayar mahal untuk hal yang memalukan. Tujuan Anda adalah untuk yakin bahwa orang-orang yang mengaku bahwa mereka dapat mengerjakan pekerjaan mereka benar-benar dapat melakukannya, bahwa harganya pantas untuk Anda, dan bahwa keuntungannya adil untuk perusahaan pengetesan.
Pertimbangan tambahan diperhitungkan jika pekerjaan dilakukan secara off site. Dalam kasus ini, Anda akan membayar tidak hanya untuk ornag-orang tetapi untuk fasilitas dan akses kepada peralatan tersebut. Jika Anda menyewa laboratorium tes untuk melakukan tes lingkungan, sebagai contohnya, Anda menyewa ruangan panas dan meja getar, bersama dengan profesional terampil yang mengoperasikannya.
Akhirnya, mengingat fasilitas itu sendiri. Saya menyarankan kunjungan on-site untuk Anda jika Anda murni bekerja pada sumber off-site. Apa yang dibutuhkan keamanan Anda? Apakah Anda membutuhkan laboratorium terpisah? (Apakah saingan kita menggunakan fasilitas yang sama?) Apakah fasilitas geografis nyaman/tidak nyaman? Apakah lokasi tersebut memberikan Anda akses kepada kolam talenta yang murah yang dapat ditemukan secara lokal? (Sebagai contoh, biaya pekerja yang murah yang sering Anda temukan di laboratorium tes luar negeri mungkin terbatas dengan geografis yang kurang dekat dan perjalanan yang mungkin akan sering Anda lakukan untuk mengkoordinasikan pekerjaan.)
X.1.3. Sales Offices
Jika Anda menjual produk secara internasional, Anda harus mempunyai kantor penjualan lokal atau sebuah rekan penjualan (seperti distributor) dalam bagian-bagian yang beragam. Alternatif yang lain, Anda mungkin memiliki kantor pemasaran “maya”, dengan dengan anggota staf di dalam kantor penjualan utama menangani penjualan luar negeri. Jalan lain, kantor penjualan harus sadar dan berkualifikasi untuk mengevaluasi resiko kualitas yang unik untuk market luar negeri.
Bab 1 daftar dari kualitas resiko memasukkan lokalisasi sebagai kategori utama dari resiko untuk produk apapun yang terjual atau digunakan secara internasional. (Lihat “Lokalisasi”, halaman 22.) Di dalam beberapa kasus, testing kualitas resiko dalam kantor rumah adalah suatu tantangan. Dengan DataRoket sebagai contoh, Anda mungkin membutuhkan tester yang menguasai bahasa Jepang, Korea, Mandarin, Thai, Kanton, Jerman, Belanda, Perancis, Rusia, Spanyol, dan Italia untuk melengkapi panduan dokumentasi dan startup.
Seperti dalam semua situasi, trade-offs muncul. Kabar baiknya adalah sebagai rekan kerja, anggota staff dalam sebuah kantor penjualan memiliki tujuan yang sama seperti yang Anda miliki – mereka memiliki sebuah keinginan untuk memastikan bahwa usaha tes berhasil. Jika rekan Anda di kantor Tokyo melakukan pekerjaan yang buruk untuk testing lokalisasi SpeedyWriter wilayah Asia, mereka akan merugi sama seperti Anda merugi.
Walaupun demikian, ada kekurangan untuk masalah ini. Anda tidak dapat mengasumsikan teknik yang canggih untuk kebanyakan tenaga penjual. Jika Anda bertanggung jawab untuk hasil dari testing dan ingin barang tertentu dijual, Anda akan butuh untuk melakukan detail-detail berikut. Setiap kasus tes apapun yang Anda berikan kepada rekan yang tidak memiliki keahlian teknis harus tepat dan tidak membingungkan.
Anda juga harus ingat bahwa tenaga penjual atau rekan penjualan mungkin tidak bekerja untuk Anda dalam satu pengertian yang sama. Walaupun Anda bertanggung jawab untuk menyakinkan kualitas dan kelengkapan dari tes yang mereka lakukan, Anda tidak dapat memberi struktur pekerjaan mereka, dan Anda tidak dapat menspesifikasikan standar dari kelakukan mereka, bagaimana cara berinteraksi tim Anda atau situasi dimana Anda akan mengakhiri hubungan. Sebagai masalah yang praktis, Anda mungkin dapat memiliki masalah untuk mendapatkan hasil dari mereka.
X.2. Perencanaan Distribusi Test Selanjutnya
Anda perlu memiliki rencana untuk distribusi testing dengan tingkatkan yang sama dari detail yang Anda gunakan untuk usaha internal. Rencana itu harus merupakan proses yang mengarah ke depan, membuktikan bahwa Anda memiliki operasi yang dalam kontrol. Poin awal adalah kelengkapan perencanaan tes dari level atas dibahas di Bab 1 dan 2. Anda harus juga memiliki perangkat tes yang sudah didefinisikan dengan baik, walaupun beberapa detail mungkin tetap untuk diselesaikan. Penelusuran tes dan bug harus bekerja, termasuk rencana untuk menyebarkan sistem penelusuran bug.
X.2.1. Menilai Kemampuan
Saat Anda cukup mempelajari tentang potensi dari rekan tes untuk memilih organisasi untuk proyek, seperti yang telah dijabarkan sebelumnya, Anda perlu untuk menaksir kemampuan tes rekan Anda yang spesifik sebagai bagian dari perencanaan keseluruhan usaha Anda. Anda harus melakukan pendekatan untuk latihan ini, seperti pendekatan Anda kepada pertemuan bisnis apapun: dengan beberapa keluaran yang diharapkan didalam pikiran. Menyusun daftar permintaan dari kontribusi dapat Anda check off jika Anda melakukan perkiraan, memfokuskan diri khususnya pada pertanyaan yang berhubungan dengan keahlian, penempatan staf, dan pengaturan fisikal.
Pada setiap tugas yang diberikan , bisakah test partner memproduksi orang yang ahli , berpengalaman , kompeten dengan kemampuan yang mencukupi, bila begitu siapa yang akan bekerja? Dalam banyak kasus , kau akan dikejutkan oleh level kemampuan dari partner testmu, bagaimanapun juga perusahaan berusaha untuk terus memproduksi orang ahli. Tapi dalam beberapa kasus aku akan menemukan bahwa orang-orang yang kau wawancarai tidak akan sesuai dengan harapanmu.
Ini bukanlah alasan untuk menyingkirkan partner kerjamu dari pemikiranmu , bagaimanapunn juga , terutama orang-orang yang memiliki kualifikasi yang cukup dibandingkan dengan kandidat lainnya..
Pengaturan karyawan sangatlah penting. Hal ini sering menguji perusahaan tentang bagaimana cara kerja eksternal perusahaan tersebut berlangsung . Tapi setiap perusahaan mempunyai pembatasan karyawan dan staff. Pastikan dirimu bahwa partner kerjamu dapat mensupport seluruh team . Sangatlah tidak wajar bagi para ahli software dan hardware untuk melakukan pekerjaan yang tidak bersumber untuk memenangkan bisnis dengan berjanji secara berlebihan kepada klien dengan tujuan untuk pembuatan sebuah projek. Lalu, setelah memenangkan bisnis, perusahaan tidak dapat melanjutkan pengeksekusian. Ini adalah kelemahan beberapa perusahaan yang sering dipertanyakan, tai dapat juga memberikan sebuah kesalahan yang sangat fatal kepadamu jika beberapa hal dalam elemen-elemen penting dalam test tidak diselesaikan secara sempurna dan dapat menyebabkan kesalahan yang fatal karena tidak memeriksa partner test secara sempurna.
X.2.2. Mengerti biaya dan resiko
Sebelum meneruskan ke hal yang lebih detil , partner testmu harus mempunyai segala perincian mengenai biaya yang dibutuhkan di dalam pembuatan proyek tersebut.Dalam perusahaan yang mandiri , tentu saja, menghasilakan uang dengan menjual test services, dengan tidak membicarakan prospek dalam test services. Atasanmu mngkin akan menyimpulkan bahwa pendiskusian adalah bagian dari persetujuanmu dengan perusahaanmu, tapi mungkin juga mereka tidak akan mencapai kesepakatan. Para pembeli asing mungkin bersedia untuk melakukan beberapa test dengan gratis namun kamu juga tidak dapat menyimpulkan bahwa semua waktu yang mereka gunakan tidak berharga sama sekali.
Dari atasan atau dari orang ketiga dalam perusahaan anda dapat melakukan penawaran , yang biaya penawaran mengenai waktu , biaya material yang diperlukan . Jika kamu menerima penawaran mengenai waktu dan bahan-bahan dasar , kamu akan memerlukan data yang mendetil mengenai penjurnalan keuangan perusahaan anda yang juga memperhitungkan mengenai budget yang dibutuhkan dan besarnya uang yang dikeluarkan. Pastikan bahwa penawaran tersebut meliputi flexibility , bukan cuma kemungkinan yang dapat terjadi tapi juga mengenai langkah-langkah yang dapat diambil ketika kamu menciptakan test program lainnya. Dalam pembuatan program uang selalu jadi masalah utama dan untuk menekan biaya dibutuhkan kerja yang ekstra dalam perancanaan test.
X.2.3. Koordinasi dan partisi dalam pembuatan test program
Langkah berikutnya dalam pendistribusian test adalah penggabungan 2 atau lebih projek menjadi satu program yang united(berhubungan dan mandiri). Pada umumnya, dalam pembuatan kue pie, bermacam-macam bahan masakan diperlukan dalam pembuatan kue tersebut , lalu ketika kue-kue pie tersebut telah siap untuk dimakan setiap kue tersebut sudah tersedia dalam piring-piring setiap orang untuk dinikmati.
Mari kita gunakan contoh Data Rocket yang lain . Dengan tidak menghiraukan lokasi pembuatan , kita simpulkan bahwa pemain mendistribusikan usaha test dalam Winged Bytes, kartu SCSI dan tempat test lab ,System Cookers.Tujuan utamanya adalah untuk memproduksi kasus test, yang diorganisasikan menjadi beberapa test suites yang di mana setiap test tersebut mempunyai 3 team.
Langkah pertama , kolasi , yang meliputi single list yang akan dijalankan dari setiap studi kasus yang akan dijalankan. Kau memerlukan untuk mengumpulkan setiap daftar dari tim tersebut dan menambahkannya dalam lembar kerjamu.Gunakan lembar kerja kolom untuk menyimpan track di mana setiap tim bertanggung jawab pada setiap test.
Langkah kedua , koordinasi , anda harus melenyapkan kasus yang tidak berguna, sebagai contoh, anda menyadari bahwa Lucky Bit merencanakan untuk menjalankan thermal test dalam kartu SCSI namun anda lebih memilih System Cookers yang menjalankan test tersebut dengan kartu SCSI yang sudah diinstall.Mungkin Lucky Bit dapat mengkalkulasi perkembangan pada setiap komponen dan spesifikasi test.System Cookers dapat memasukkan thermal sensor ke dalam komponen-komponen dan menjalankannya kemudian.
Langkah ketiga yang harus dilakukan adalah membuat partisi dan detail mengenai kerjanya, mengulas kembali test pada lembar kerja yang dibutuhkan kepada pembeli yang baru.
Ketiga tahap atau langkah dan proses ini harus diangkat ke permukaan agar tidak dianggap sebagai masalah tehnik semata melainkan masalah yang serius. Masalah modal juga mengkhawatirkan dan dapat menjadi masalah sewaktu-waktu jika sudut pandang dan wawasan diubah. Dan juga masalah politik juga dapat memerankan peranan penting.
X.2.4. Mengorganisasikan Masalah Logistik
Salah satu keuntungan dari pendistribusian testing adalah ketika di mana ketika semua test suites dikerjakan secara benar dan setiap partner mengerjakan fungsinya masing-masing secara tepat maka dalam situasi yang seperti ini dapat meminimalkan masalah logistic.
Dalam beberapa kasus , bagaimanapun juga pendistribusian testing menciptakan masalah logistic yang unik. Masalah yang paling menyulitkan adalah ketika suatu produk meliputi 1 atau lebih hardware yang berbeda.
Berbicara mengenai hardware , seseorang haruslah menkoordinasi dan mengatur pengiriman dan pengembalian barang. Pengiriman barang dengan menggunakan kapal adalah hal yang sangat sulit dilakukan karena membutuhkan perencanaan dan konsentrasi . Bila hendak mengirimkan barang dengan menggnakan kapal anda akan melewati batas-batas territorial atau batas internasional sehingga anda harus dihadapkan dengan bermacam-macam persoalan.
X.2.5. Menghadapi masalah Mapping
Jika semua pengoperasian berjalan dengan cara-cara yang sama maka merut buku pertunjuk yang ada maka pekerjaan anda akan selesai setelah program tersebut mempunai hubungan atau jaringan. , tugas-tugasnya mempunyai partisi yang jelas dan segala maslah logstik sudah terselesaikan dan sudah teratasi. Pada kenyataannya bahwa setiap team menggunakan pendekatan yang berbeda dan anda tidak bias dan tidak usah untuk melakukan pekerjaan itu dengan cara-cara yang sama , tapi yang perlu untuk dilakukan adalah mengenali dan menkoordinasi setiap perbedaan yang ada. Hal ini disebut dengan maslaah mapping karena kau hendak untuk mengidentifikasi kan dan memasukkan tugas dan pekerjaan rekan kerjamu ke dalam pekerjaan kita.
Dalam mapping yang pertama kali terkadang muncul masalah yang sering kali timbul selama koordinasi, seperti ketika mengurutkan dan membandingkan studi kasus. Beberapa kasus umumnya tidak berhubungan antara kasus yang satu dengan kasus yang lainnya, dan anda diharuskan untuk menyimpan dan mengatur mereka dalam setiap level yang seharusnya.
Contoh Beberapa Kasus Test Case
Ketika kamu menemukan parsial, anda bisa beberapa kali melewatkan beberapa kasus dan mencari kasus yang baru untuk menutupi kondisi yang tidak stabil tersebut. Besarnya waktu yang terbuang danusaha yang sia-sia umumnya sangat rendah jika dibandingkan dengan parameter keseluruhan proyek.
Ukuran test(dalam durasi waktu, usaha, dan keduanya) bias mempengaruhi dan merumitkan koordinasi dan partisi yang aa . Beberapa para ahli menuliskan kasus dengan durasi yang panjang dan beberapa ada yang menuliskan dengan durasi yang pendek.
Anda akan menemukan beberapa masalah mapping yang berlangsung selama pengeksekusian test, dan kamu harus merencanakan solusi ke depannya . Hal yang paling penting dalam pembuatan suatu proses adalah harus mendapatkan semua bug reports ke dalam suatu single bug system. Dengan DataBase, kamu dapat menggunakan tayangna replikasi untuk mendistribusikan database kepada partnermu, atau mereka dapat menghubungi dan mengakses data ke dalam server atau jaringan kita.
Karena kita mempunyai rekan kerja yang banyak tidak hanya satu maka kamu akan melihat bahwa banyak sekali nomor-nomor replica atau duplikatn dari bug report. Bahkan jika kamu melakukan pekerjaan yang bagus dalam pengkoordinasian dan partisi untuk menghindari overlap, maka akan ada virus yang menduplikasikan dirinya ke dalam test yang kita buat atau yang kita kerjakan.
Bahasa juga dapat menjadi masalah yang sangat utama ketika sedang menyelidiki masalah mengenai pencarian virus-virus dan penyelidikan test. Anda akan membutuhkan banyak sekali usaha untuk mensetting proses data secara elektronik untuk mencari tahu bagaimana cara untuk berkomunikasi. Sialnya dengan menggunakan alat penerjemah elektronik sangatlah tidak memuaskan dan tidak memadai, dan hal ini kemudian menjadi masalah teknik karena pertanyaan yang diberikan bervariasi. Bahasa dapat menjadi masalah yang utama dalam pendistribusian system oleh karena itu kamu harus terlebih dulu yakin terhadap masalah yang dihadapi ketika membuat sebuah program
X.3. Pengelolaan Disribusi Test Selanjutnya
Ketika kamu mulai terbiasa dengan masalah pendistribusian ini, mengatur test tim secara virtual tidak jauh berbeda dengan mengatur tim di dalam perusahaanmu sendiri. Kau akan menemukan bahwa ada 5 area yang memiliki beberapa kelebihan :
X.3.1. Memonitor eksekusi test
Mungkin kau akan menemukan hal ini lebih menarik dalam pendistribusian test, bahkan jika anda telah menyelesaikan pekerjaan dengan baik mengenai mapping yang baik yang seperti telah dijelaskan sebelumnya. Jarak, perjalanan waktu, dan batasan bahasa dapat menjadi sebuah halangan dalam melakukan pekerjaan.Jika kamu memperbaharui dan mengup-date terus data mengenai lembar kerja tracking , dalam sekejap, dan menemukan bahwa kamu punya beberapa pertanyaan mengenai beberapa kesalahan yang dilakukan oleh rekan sekerjamu , anda akan kehilangan beberapa jam untuk melacak tentang siapa orang yang dapat menyediakan informasi tersebut. Jika kamu butuh data yang penting dalam situasi yang sangat penting pula dalam management, hal ini dapat menjadi masalah yang sangat serius. Umumnya , kamu harus merencanakan mengenai kemungkinan hasil yang akan didapat dari rekan sekerjamu.
X.3.2. Mengkomunikasikan Status dan Merubah Arah
Tidak ada satu dari rekan sekerjamu yang dapat mengoperasikan dalam keadaan jeda atau vakum.Kamu harus tetap mensibukkan program tersebut apapun yang terjadi, dan merupakan cara untuk membiarkan mereka untuk masuk ke dalam perhatian kita.
E-mail merupakan alat komunikasi di dunia web yang tidak buruk namun e –mail ini dapat dijadikan sebagai alat untuk mengadu domba atau pemecah dalam diskusi dan komunikasi. Pembaharuan harian dalam setiap test haruslah mempunyai tampilan report status.
X.3.3. Mengatasi Pertimbangan Politik
Semenjak kamu memilih test participant dan test effort , kamu mempunyai andil dalam kesuksesan mereka , tidak hanya sukses secara tehnik(menemukan virus dan melindungi bagian –bagian yang penting) namun sukses di dalam bidang poitik. Hal ini terkadang terjadi, pandangan atau persepsi yang negative terhadap test partner terkadang benar. Dalam beberapa kasus mereka merupakan projek yang terjaring di dalam suatu jaringan.
X.3.4. Sensitif Terhadap Kebudayaan
Kapanpun organisasi manapun memgantungkan dirinya kepada rekan kerja eksternalnya, perbedaan dalam kebudayaan dapat menjadi masalah. Masa lalu saya(penulis) menyediakan sebuah contoh, aku berubah dari menjadi seorang programmer dan system administrator menjadi penguji coa ketika kuterima pekerjaan itu dengan lab bebas yang independent., semua kolega di laboratorium tersebut adalah seorang tester.Kita bekerja kepada klien yang sedagn mengembangkan software dan hardware, tapi biasanya kita berinteraksi hanya dengan satu atau dua orang klien saja.Saya dipaksa untuk eradaptasi secara instant, bagaimanapun juga , setelah beberapa tahun kemudian, ketika saya menjadi manager di sebuah toko pengembangan software, saya merasakan pengalaman bagaimana menjadi manager untuk pertama kalinya dan mempunyai banyak bawahan dan klien.
Sama seperti kau mengimplementasikan bagaimana mendistribusikan test program kau akan merasakan pengalaman yang dirasakan ketika mendistribusikannya. Perspektif, nilai dan prioritas menjadi suatu kesatuan di dalam perusahaan , tergantung terhadap setiap kepribadian yang ada pada setiap anggota tim, kempemimpinan seorang manager, hubungan teknik dan non teknik yang ada antara pemimpin dan bawahannya. Ketika berhadapan dengan organisasi di dunia luar , factor dan masalah kebudayaan ini selalu diperhitungkan karena pemimpin sering kali membeda-bedakan nilai yang ada terhadap anggota timnya ataiupun bawahannya.
Dalam istilah testing terdistribusi perbedaan semacam itu ddapta juga berarti bahwa individual yang gagal debagai seorang teknisi yang ahli, insinyur penguji, atau manager penguji dalam perusahaanmu diangap sebagai penguji yang professional yang dipasangkan dengan budaya pada organisasi perusahaanmu. Sebagai contoh, saya menempatkan nilai yang besar untuk hubungan kerjasama yang antara tester dan pengembang. Perbedaannya, bagaimanapun juga, beberapa organisasi yang berhasil menggunakan pendekatan melalui adversatorial, dengan manajer tes memberi semangat untuk “menangkap” kesalahan pada pengembang. Saya akan menemukannya secara emosional untuk bekerja di dalam organisasi dimana para pekerja saling menggagalkan kesuksesan yang lainnya, tetapi, jika saya bekerja dengan rekan tes yang menggunakan pendekatan yang demikian, adalah sangat sulit untuk saya mengubah budaya pada lingkungan saya itu. Meskipun demikian, saya mungkin akan menemukan
Lebih halus, tetapi tantangan yang sama tentang pertentangan budaya dapat muncul. Sebagai contoh, saya mempunyai klien yang (atas rekomendasi saya) menggunakan lab eksternal di Taipei untuk menangani beberapa tes kompabilitas. Vendor klien juga berlokasi di Taipei. Budaya laboratorium tes sangat dinamis tetapi untuk waktu yang lama, seperti yang telah dilakukan oleh klien saya. Vendor yang terlibat memiliki budaya “8-to-5”. Ironisnya, saat kami membutuhkan untuk mengadakan conference call secara reguler, budaya vendor dan klien saya tidak bermasalah, tetapi perbedaan waktu bermasalah dengan laboratorium tes. Kami sudah merencanakan conference call pada jam 8.30 pagi waktu Taipei, dimana tidak masalah bagi vendor tetapi merupakan masalah bagi pimpinan proyek di laboratorium tes, yang bekerja dari siang hari sampai malam hari karena pilihannya. Saya telah menyelesaikan situasi semacam ini dengan memutuskan untuk membebaskannya dari conference call, meyakinkan bahwa saya mengerti hasil dari laboratorium tes dan dapat mencari jalan keluarnya. Akomodasi semacam ini membiarkan manajer tes untuk terus bekerja pada jadwal yang dirasanya nyaman. Jika saya bersikeras bahwa dia harus mulai bekerja pada waktu yang tidak dirasanya nyaman, hubungan kami bisa menjadi rusak.
X.3.5. Membangun dan Mempertahankan Kepercayaan
Banyak pertanyaan yang lebih mendasar daripada masalah kesamaan budaya adalah apakah Anda dapat mempercayai rekan tes Anda. Kepercayaan adalah konsep yang lebih licik dari budaya, tetapi kita mengenal orang-orang yang kita percaya atau kita tidak dapat percaya. Bahkan mereka yang menghabiskan banyak waktu untuk membangun kepercayaan kita dapat dengan mudah kehilangan kepercayaan itu. Anggap saja bahwa Anda adalah seorang manajer di Winged Byte, bekerja dalam DataRocket. Rekan-rekan Anda, manajer tes vendor kartu SCSI, telah dengan cermat melaporkan masalah-masalah yang ditemukan oleh manajer tim tes, tidak hanya dalam proyek ini tetapi juga dua poyek sebelumnya. Angap saja sekarang bahwa tes manajer menunda atau menyembunyikan berita dari bug yang fatal dalam kartu BIOS. Kepercayaan yang telah dibangun tersebut selama beberapa tahun akan menderita secara serius bahkan fatal, mundur.
Semua perangkat-perangkat dan tip-tip mendiskusikan di dalam bab ini tidak dapat menyelesaikan masalah. Jika Anda membagi tes program Anda supaya rekan tes menjalankan tes kritis, Anda harus membangun hubungan untuk kepercayaan. Anda harus percaya bahwa laboratorium tes tidak akan melewatkan beberapa tes karena hal itu akan bekerja dibelakang jadwal dan ketakutan untuk kehilangan uang untuk proyek Anda. Anda harus percaya vendor Anda untuk berterus terang mengenai bug bahkan untuk yang paling memalukan sekalipun. Anda harus percaya rekan Anda yang berada di kantor penjualan di luar negeri untuk menindaklanjuti hasil tes jadi Anda tidak akan bingung pada menit-menit terakhir untuk berurusan dengan bug yang kritis.
Kepercayaan juga melibatkan keyakinan yang lebih bahwa rekan Anda tidak akan mengambil keuntungan dari Anda. Anda harus behati-hati dengan mereka juga. Sebagai contoh, saya telah membantu rekan tes di dalam proyek saya bekerja mengatasi faktur-faktur dan kontrak-kontrak. Ada juga jalan yang cukup sulit untuk permasalahan ini, saat Anda mempertaruhkan tanggung jawab Anda kepada bawahan Anda. Tetapi membantu rekan tes Anda yang terpilih untuk berurusan dengan kontrak yang samar-samar atau utang usaha yang tidak jelas menunjukkan kepercayaan yang baik dan sebuah perhatian untuk keberhasilan rekan Anda. Saat seseorang mengenal bahwa Anda memperhatikan mereka, mereka biasanya juga akan memperhatikan Anda.
Saat buku ini memberikan penggambaran yang lebih jelas, sangatlah berguna untuk memperhatikan bahwa kepercayaan bukan hanya isu untuk rekan tes eksternal Anda. Sangatlah kritis untuk semua tim proyek, entah mereka yang bekerja pada satu perusahaan atau banyak perusahaan. Anda harus mengasumsikan bahwa mereka memberikan kesuksesan untuk proyek dengan bekerja memberikan kemampuan mereka yang terbaik sesuai dengan peranan mereka masing-masing. Anda juga harus mengasumsikan bahwa mereka bekerja untuk keberhasilan kolaborasi mereka.
Klise mengenai beberapa apel yang buruk yang membuat rusak satu tong apel, khususnya untuk kepercayaan dalam organisasi. tetapi juga adalah benar bahwa pemimpin kunci dalam sebuah perusahaan dapat memberikan contoh untuk membangun standar perusahaan yang luas. Orang-orang yang secara konsisten memberikan usaha terbaik mereka menciptakan semangat dan dedikasi. Orang yang memberikan dukungan kepada rekan kerja mereka dan bekerja sama untuk kebaikkan dalam suatu tim membantu perkembangan kepercayaan diri dan niat baik. Tidak ada seorangpun bisa memberikan kontribusi kepercayaan perusahaan sebanyak seorang manajer. Manajer yang menjaga komitmen mereka; yang tidak pernah membuat seorang bawahan untuk jatuh dalam kesalahan mereka sendiri; yang mendukung dan merayakan keberhasilan pemain bintang mereka, tim mereka, dan perusahaan sebagai keseluruhan; yang menyeimbangkan kebutuhan perusahaan dengan kebutuhan personal dari bawahan dan rekan mereka; dan yang secara konsisten memberikan dan mengharapkan kejujuran dari staf mereka, kawan sekerja mereka, dan manajer mereka sendiri membuat sebuah budaya perusahaan untuk kepercayaan dan integritas. Sebagai seorang manajer tes, Anda harus berpartisipasi dalam menciptakan dan menegakkan lingkungan kepercayaan, baik dalam tim dan lintas perusahaan. Standar yang Anda pasang dalam tim Anda penting seperti hal lainnya yang Anda lakukan.
TESTING 9
IX. Pengelolaan Organisasi Tim Test
Pertanyaan yang muncul
* Berapa orang yang dibutuhkan ?
* Skill apa yang harus dipunyai ?
* Posisi apa yang harus diisi ?
* Pengorganisasiannya berdasarkan proyek atau area test ?
* Apa yang menjadi motivasi tim ?
* Bagaimana memanfaatkan pekerja tak tetap untuk membantu tim dalam keadaan mendesak ?
IX.1. Definisi Tim:
Size,
* Dapat ditentukan melalui fokus pekerjaan atau perbandingan antara penguji dan pengembang
* Pendekatan dapat dilakukan untuk menentukan size dari tim
* Dalam penugasan menggunakan Gant Chart
Usulan Tim Test berdasarkan perintah kehadiran
Skills
* Pada kasus tertentu dibutuhkan skill khusus
* Penentuan skill dapat dilihat dari CV dan kriteria yang diperlukan
Posisi dan penempatan
* Mana yang dilakukan oleh manajer
* Mana yang dilakukan otomatis
IX.2. Model Organisasi
Model organisasi pada test tim ada dua yaitu :
* Skill Based test organization
* Project Based test organization
Skills Based Test Organization
Project Based Test Organization
IX.3. Kualifikasi Test Engineers
Pada kulitas suatu tim testing terdapat
* Test specialist, seseorang yang karirnya terfokus pada hal-hal khusus mengenai testing
* Content Specialist, adalah staf yang harus mengerjakakan tugas-tugas khusus untuk testing, misalnya staf yang mengerti produk dan teknologi suatu perusahaan.
Pekerjaan testing untuk melihat dari kualifikasi tim tesebut dalam mengerjakan test.
IX.4. Kelompok Test di Organisasi
IX.5. Penambahan Fungsi Test
IX.6. Aspek Manajemen Testing
IX.7. Test Tanpa Dokumentasi
IX.8. Pengaruh Eksternal dari Produktifitas Penguji
IX.9. Layoffs & Likuidasi
IX 10. Target Report dari Hasil Testing
IX.11. Pengaruh Awal Pengadopsian pada Test
Pertanyaan yang muncul
* Berapa orang yang dibutuhkan ?
* Skill apa yang harus dipunyai ?
* Posisi apa yang harus diisi ?
* Pengorganisasiannya berdasarkan proyek atau area test ?
* Apa yang menjadi motivasi tim ?
* Bagaimana memanfaatkan pekerja tak tetap untuk membantu tim dalam keadaan mendesak ?
IX.1. Definisi Tim:
Size,
* Dapat ditentukan melalui fokus pekerjaan atau perbandingan antara penguji dan pengembang
* Pendekatan dapat dilakukan untuk menentukan size dari tim
* Dalam penugasan menggunakan Gant Chart
Usulan Tim Test berdasarkan perintah kehadiran
Skills
* Pada kasus tertentu dibutuhkan skill khusus
* Penentuan skill dapat dilihat dari CV dan kriteria yang diperlukan
Posisi dan penempatan
* Mana yang dilakukan oleh manajer
* Mana yang dilakukan otomatis
IX.2. Model Organisasi
Model organisasi pada test tim ada dua yaitu :
* Skill Based test organization
* Project Based test organization
Skills Based Test Organization
Project Based Test Organization
IX.3. Kualifikasi Test Engineers
Pada kulitas suatu tim testing terdapat
* Test specialist, seseorang yang karirnya terfokus pada hal-hal khusus mengenai testing
* Content Specialist, adalah staf yang harus mengerjakakan tugas-tugas khusus untuk testing, misalnya staf yang mengerti produk dan teknologi suatu perusahaan.
Pekerjaan testing untuk melihat dari kualifikasi tim tesebut dalam mengerjakan test.
IX.4. Kelompok Test di Organisasi
IX.5. Penambahan Fungsi Test
IX.6. Aspek Manajemen Testing
IX.7. Test Tanpa Dokumentasi
IX.8. Pengaruh Eksternal dari Produktifitas Penguji
IX.9. Layoffs & Likuidasi
IX 10. Target Report dari Hasil Testing
IX.11. Pengaruh Awal Pengadopsian pada Test
TESTING 8
VIII. Pengelolaan Test Lab
Pada Materi ini akan dibahas mengenai :
* Process Planning
* Establishing a test lab
* Running
Hal-hal yang perlu diperhatikan dalam pembahasan ini :
* Pembahasan testing dilakukan dan dikondisikan pada test lab
* Pembahasan difokuskan pada lingkungan lab (laboratorium), dimana akan dipengaruhi oleh faktor-faktor lingkungan hw, elektromagnetik, suara, kompabilitas sw & hw, performace, dan kelakuan sistem.
* Test Platform pada lingkungan lab
Perlunya suatu Test Lab, kebutuhan akan test lab dapat dilihat dari hal-hal berikut :
* Kebutuhan peralatan test yang banyak.
* Kebutuhan suatu lingkungan yang khusus
* Kebutuhan terhadap keamanan
* Kebutuhan pengaksesan fasilitas test pada waktu tertentu.
* Kebutuhan privatisasi hasil test.
VIII.1. Pemilihan dan Perencanaan Area Lab
Size, ukuran dari luas lab akan mempengaruhi kelancaran dari test dalam kenyamanan test jika membutuhkan harware yang banyak.
Lighting, pencahayaan akan mempengaruhi, bila test dilakukanpada siang hari lentak jendela harus sesuai dan bila testing dilakukan siangdan malam ketersediaan lampu perlu diperhitungkan
Layout, kebutuhan akan meja dan rak yang mencukupi akan mempengaruhi berapa banyak peralatan yang diinstal untuk testing
Climate Control, pengaturan suhu ruangan akan berpengaruh sebab testing akan menjadi baik pada suhu yang stabil.
Fire Safety & Preventation, setiap pekerjaan akan mempunyai peluang terjadinya kebakaran oleh sebab itu pemasangan deteksi asam (smoke detektor) sangat diperlukan.
Power, sumber tegangan yang berbeda harus tersedia pada saat testin, karena testing akan dilakukan dengan berbagai variasi perubahan tegangan.
Static, ketersediaan karpet pada lab akan membatu dalam mengurangi tegangan statik dari listrik.
Facilities, fasilitas bagi penguji sangat diperlukan karena testing mungkin akan membutuhkan waktu yang lama.
VIII.2. Inventarisasi Test Lab
Software.
* Operating Systems
* Applications
* Test Tools & Utilities
Hardware
* PC Cards
* Monitors/Video Cards
* Printers/Scanners
* Modem/Network Cards
* Data Storage
* Surge Protectors/UPS Units
* Reference Platform
* Cables & Networking
Consumables, barang-barang habis pakai seperti :
* Computer Media
* Desk Necessities
* Printer Suplies
Furnishings
* Copiers & Printers
* Shredder
* Meja & Kursi
* Mouse Pads & Static Pads
Tools
* Specialized Hardware
* Test Management Software
* Computer Toolkit
Reference Material
* Classics (umum)
* Standards
* Phone Books
VIII.3. Security
Fisik, keamanan dari kerusakan dalam bentuk fisik seperti :
* Kebakaran
* Kebanjiran
* Jatuh dan lain sebagainya.
Non Fisik
* Masuknya virus
* Diakses oleh yang bukan haknya
* Pengupdate-an tanpa sengaja dan lain sebagainya
VIII.4. Pengelolaan Peralatan dan Konfigurasinya
ERD Pengelolaan Logistik dan Aset LAB
Selanjutnya pengelolaan peralatan dan konfigurasinya menggunakan database logistik
Perubahan Data akan terjadi sesuai dengan konfigurasi yang ada
Suatu konfigurasi hardware digabung dengan konfigurasi software tertentu hasil setupnya akan berbeda bila konfigurasinya dirubah kemudian disetup lagi.
Tabel Relationship dan Aset Lab
VIII.5. Human Factors
Keamanan merupakan produktifitas dari suatu LAB
Kerusakan pada peralatan LAB
Produktifitas di dalam LAB
Pada Materi ini akan dibahas mengenai :
* Process Planning
* Establishing a test lab
* Running
Hal-hal yang perlu diperhatikan dalam pembahasan ini :
* Pembahasan testing dilakukan dan dikondisikan pada test lab
* Pembahasan difokuskan pada lingkungan lab (laboratorium), dimana akan dipengaruhi oleh faktor-faktor lingkungan hw, elektromagnetik, suara, kompabilitas sw & hw, performace, dan kelakuan sistem.
* Test Platform pada lingkungan lab
Perlunya suatu Test Lab, kebutuhan akan test lab dapat dilihat dari hal-hal berikut :
* Kebutuhan peralatan test yang banyak.
* Kebutuhan suatu lingkungan yang khusus
* Kebutuhan terhadap keamanan
* Kebutuhan pengaksesan fasilitas test pada waktu tertentu.
* Kebutuhan privatisasi hasil test.
VIII.1. Pemilihan dan Perencanaan Area Lab
Size, ukuran dari luas lab akan mempengaruhi kelancaran dari test dalam kenyamanan test jika membutuhkan harware yang banyak.
Lighting, pencahayaan akan mempengaruhi, bila test dilakukanpada siang hari lentak jendela harus sesuai dan bila testing dilakukan siangdan malam ketersediaan lampu perlu diperhitungkan
Layout, kebutuhan akan meja dan rak yang mencukupi akan mempengaruhi berapa banyak peralatan yang diinstal untuk testing
Climate Control, pengaturan suhu ruangan akan berpengaruh sebab testing akan menjadi baik pada suhu yang stabil.
Fire Safety & Preventation, setiap pekerjaan akan mempunyai peluang terjadinya kebakaran oleh sebab itu pemasangan deteksi asam (smoke detektor) sangat diperlukan.
Power, sumber tegangan yang berbeda harus tersedia pada saat testin, karena testing akan dilakukan dengan berbagai variasi perubahan tegangan.
Static, ketersediaan karpet pada lab akan membatu dalam mengurangi tegangan statik dari listrik.
Facilities, fasilitas bagi penguji sangat diperlukan karena testing mungkin akan membutuhkan waktu yang lama.
VIII.2. Inventarisasi Test Lab
Software.
* Operating Systems
* Applications
* Test Tools & Utilities
Hardware
* PC Cards
* Monitors/Video Cards
* Printers/Scanners
* Modem/Network Cards
* Data Storage
* Surge Protectors/UPS Units
* Reference Platform
* Cables & Networking
Consumables, barang-barang habis pakai seperti :
* Computer Media
* Desk Necessities
* Printer Suplies
Furnishings
* Copiers & Printers
* Shredder
* Meja & Kursi
* Mouse Pads & Static Pads
Tools
* Specialized Hardware
* Test Management Software
* Computer Toolkit
Reference Material
* Classics (umum)
* Standards
* Phone Books
VIII.3. Security
Fisik, keamanan dari kerusakan dalam bentuk fisik seperti :
* Kebakaran
* Kebanjiran
* Jatuh dan lain sebagainya.
Non Fisik
* Masuknya virus
* Diakses oleh yang bukan haknya
* Pengupdate-an tanpa sengaja dan lain sebagainya
VIII.4. Pengelolaan Peralatan dan Konfigurasinya
ERD Pengelolaan Logistik dan Aset LAB
Selanjutnya pengelolaan peralatan dan konfigurasinya menggunakan database logistik
Perubahan Data akan terjadi sesuai dengan konfigurasi yang ada
Suatu konfigurasi hardware digabung dengan konfigurasi software tertentu hasil setupnya akan berbeda bila konfigurasinya dirubah kemudian disetup lagi.
Tabel Relationship dan Aset Lab
VIII.5. Human Factors
Keamanan merupakan produktifitas dari suatu LAB
Kerusakan pada peralatan LAB
Produktifitas di dalam LAB
TESTING 7
VII. Object Oriented Testing
Komponen yang diuji adalah class-object.
Lebih besar dibandingkan pengujian suatu function sehingga pendekatan white-box testing perlu diperluas.
Tidak jelasnya ‘top’ suatu system untuk top-down integration dan testing.
VII.1. Testing levels
Testing operations pada objects
Object Form
Testing object classes, menguji terhadap semua operation yg ada dan perubahan atribut-atributnya.
Testing clusters cooperating objects
* Cluster testing digunakan untuk test integrasi terhadap kooperatif object.
* Identifikasi clusters menggunakan knowledge operation objects dan system features yang diimplementasikan oleh cluster tersebut.
Cluster Testing
Testing OO system secara lengkap
Object-Interaction Testing
VII.2. Pengujian Aplikasi Server
Volume Testing
* Menemukan kelemahan sistem selama melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat.
* Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data antar batasan fisik dan batasan logik.
* Contoh: Mengujikan proses antar server dan antar partisi hardisik pd satu server.
Stress Testing
* Tujuan: mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses. Contoh periode puncak: ketika penolakan proses login on-line setelah sistem down atau pada kasus batch, pengiriman batch proses dalam jumlah yg besar dilakukan setelah sistem down.
* Contoh: Melakukan login ke server ketika sejumlah besar workstation melakukan proses menjalankan perintah sql database
Performance Testing
* Dilakukan secara paralel dengan Volume dan Stress testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi.
* Dilakukan pada semua konfigurasi sistem perangkat keras dan lunak.
• Mis.: pd aplikasi Client-Server diujikan pd kondisi korporate ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop)
• Menguji sistem dengan hubungannya sistem ke lain pada server yg sama.
* Load Balancing Monitor
* Network Monitor
Data Recovery Testing
* Investigasi dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses.
* Penting dilakukan karena data yg disimpan di server dapat dikonfigurasi dengan berbagai cara.
* Kehilangan Data terjadi akibat kegagalan sistem, hardisk rusak, peghapusan yg tidak sengaja, kecelakaan, virus dan pencuri.
Data Backup and Restore Testing
* Dilakukan untuk melihat prosedur back-up dan recovery.
* Diakukan dengan mensimulasikan beberapa kesalahan untuk menguji proses backup dan recovery.
* Pengujian dilakukan terhadap strategi backup: frekuensi , medium, waktu, mekanisme backup (manual/ otomatis), personal, ? Berapa lama backup akan disimpan.
* Switching antara live dan backup server ketika terjadi kerusakan (load log transaction pada back-up kemudian melaku recovery).
Data Security Testing
* Privilege access terhadap database diujikan pada beberapa user yang tidak memiliki privilege access ke database.
* Shutdown database engine melalui operating system (dengan beberapa perintah OS) yg dapat mematikan aplikasi database.
VII.3. Test Case
Untuk White-box testing
* Pengujian struktur logik internal
* Perintah spesifik yang diujikan:
• SELECT,
• OPEN/CLOSE,
• COPY-REPLACE
• IF statement
• REPEAT UNTIL – DO-WHILE LOOP
• CALL
Untuk Blac-box testing
* Pengujian fungsional sistem berdasarkan input – output
* Membagi input – output ke dalam beberapa kelas (kelas ekuivalensi pada boundary input).
* Menggunakan input yang tidak sesuai spesifikasi (negatif, di luar range)
VII.4. Tools Testing
ApTest
Segue (Silk product) -> functional software
Citrix -> Server Performance
Test Case ID: CUST.01
Function: Menambah satu pelanggan baru
Data Assumptions: Customer database sudah di-restore
Deskripsi: Menambah satu pelanggan, melalui Form Tambah Pelanggan, dan menampilkan validasi pelanggan baru tersebut pada Tampilan Pelanggan
Aksi
State Awal atau Tampilan
Data
Hasil yg diharapkan
(Response)
1. Aplikasi Penjualan dijalankan melalui Icon di windows
Program Manager
Tidak Ada
Menu utama Aplikasi Penjualan.
2. Pilih Pelanggan pada Menu Tampilan. Tampilan Utama Penjualan
Tidak Ada Pelanggan menampilkan Tampilan.
3. Click pilihan All Customers
Tampilan Pelanggan Tidak Ada Window Pelanggan ditampilkan dengan judul “Pelanggan”.
4. Click pada Button Tambah
Customer-All Customer Tidak Ada Tampilan Tambah Pelanggan ditampilkan
5. Masukkan data utk menambah satu pelanggan baru dan click satu kali button tambah. Tambah Pelanggan Nama: Foo
Alamat: Jl. XxxxKota: Jakarta
Data ditampilkan pd field-field yg sesuai (atau seperti yg ditampilkan oleh data sheet).
Contoh Test Case
Hasil yang diharapkan
Tujuan Test
Penolakan
Pesan Kesalah yg ditampilkan
Rancangan Test Case
Hasil yang sebenarnya
Menguji perhitungan digit input X
X
Input nomor rekening (yang sudah diubah urutannya)
Pesan kesalahan penolakan dan ditampilkan
Menentukan nomor-nomor departemen dicek X
X Input nomor departemen yang salah Pesan kesalahan penolakan dan ditampilkan
Keakuratan perhitungan Pembayaran lembur untuk pekerja jam-jaman selama 15 jam Pembayaran lembur sebesar 1.5 kali pembayaran normal
Matriks Test Case
Faktor Usabilitas
Contoh Laporan Hasil Test
Testing Workbach
Komponen yang diuji adalah class-object.
Lebih besar dibandingkan pengujian suatu function sehingga pendekatan white-box testing perlu diperluas.
Tidak jelasnya ‘top’ suatu system untuk top-down integration dan testing.
VII.1. Testing levels
Testing operations pada objects
Object Form
Testing object classes, menguji terhadap semua operation yg ada dan perubahan atribut-atributnya.
Testing clusters cooperating objects
* Cluster testing digunakan untuk test integrasi terhadap kooperatif object.
* Identifikasi clusters menggunakan knowledge operation objects dan system features yang diimplementasikan oleh cluster tersebut.
Cluster Testing
Testing OO system secara lengkap
Object-Interaction Testing
VII.2. Pengujian Aplikasi Server
Volume Testing
* Menemukan kelemahan sistem selama melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat.
* Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data antar batasan fisik dan batasan logik.
* Contoh: Mengujikan proses antar server dan antar partisi hardisik pd satu server.
Stress Testing
* Tujuan: mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses. Contoh periode puncak: ketika penolakan proses login on-line setelah sistem down atau pada kasus batch, pengiriman batch proses dalam jumlah yg besar dilakukan setelah sistem down.
* Contoh: Melakukan login ke server ketika sejumlah besar workstation melakukan proses menjalankan perintah sql database
Performance Testing
* Dilakukan secara paralel dengan Volume dan Stress testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi.
* Dilakukan pada semua konfigurasi sistem perangkat keras dan lunak.
• Mis.: pd aplikasi Client-Server diujikan pd kondisi korporate ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop)
• Menguji sistem dengan hubungannya sistem ke lain pada server yg sama.
* Load Balancing Monitor
* Network Monitor
Data Recovery Testing
* Investigasi dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses.
* Penting dilakukan karena data yg disimpan di server dapat dikonfigurasi dengan berbagai cara.
* Kehilangan Data terjadi akibat kegagalan sistem, hardisk rusak, peghapusan yg tidak sengaja, kecelakaan, virus dan pencuri.
Data Backup and Restore Testing
* Dilakukan untuk melihat prosedur back-up dan recovery.
* Diakukan dengan mensimulasikan beberapa kesalahan untuk menguji proses backup dan recovery.
* Pengujian dilakukan terhadap strategi backup: frekuensi , medium, waktu, mekanisme backup (manual/ otomatis), personal, ? Berapa lama backup akan disimpan.
* Switching antara live dan backup server ketika terjadi kerusakan (load log transaction pada back-up kemudian melaku recovery).
Data Security Testing
* Privilege access terhadap database diujikan pada beberapa user yang tidak memiliki privilege access ke database.
* Shutdown database engine melalui operating system (dengan beberapa perintah OS) yg dapat mematikan aplikasi database.
VII.3. Test Case
Untuk White-box testing
* Pengujian struktur logik internal
* Perintah spesifik yang diujikan:
• SELECT,
• OPEN/CLOSE,
• COPY-REPLACE
• IF statement
• REPEAT UNTIL – DO-WHILE LOOP
• CALL
Untuk Blac-box testing
* Pengujian fungsional sistem berdasarkan input – output
* Membagi input – output ke dalam beberapa kelas (kelas ekuivalensi pada boundary input).
* Menggunakan input yang tidak sesuai spesifikasi (negatif, di luar range)
VII.4. Tools Testing
ApTest
Segue (Silk product) -> functional software
Citrix -> Server Performance
Test Case ID: CUST.01
Function: Menambah satu pelanggan baru
Data Assumptions: Customer database sudah di-restore
Deskripsi: Menambah satu pelanggan, melalui Form Tambah Pelanggan, dan menampilkan validasi pelanggan baru tersebut pada Tampilan Pelanggan
Aksi
State Awal atau Tampilan
Data
Hasil yg diharapkan
(Response)
1. Aplikasi Penjualan dijalankan melalui Icon di windows
Program Manager
Tidak Ada
Menu utama Aplikasi Penjualan.
2. Pilih Pelanggan pada Menu Tampilan. Tampilan Utama Penjualan
Tidak Ada Pelanggan menampilkan Tampilan.
3. Click pilihan All Customers
Tampilan Pelanggan Tidak Ada Window Pelanggan ditampilkan dengan judul “Pelanggan”.
4. Click pada Button Tambah
Customer-All Customer Tidak Ada Tampilan Tambah Pelanggan ditampilkan
5. Masukkan data utk menambah satu pelanggan baru dan click satu kali button tambah. Tambah Pelanggan Nama: Foo
Alamat: Jl. XxxxKota: Jakarta
Data ditampilkan pd field-field yg sesuai (atau seperti yg ditampilkan oleh data sheet).
Contoh Test Case
Hasil yang diharapkan
Tujuan Test
Penolakan
Pesan Kesalah yg ditampilkan
Rancangan Test Case
Hasil yang sebenarnya
Menguji perhitungan digit input X
X
Input nomor rekening (yang sudah diubah urutannya)
Pesan kesalahan penolakan dan ditampilkan
Menentukan nomor-nomor departemen dicek X
X Input nomor departemen yang salah Pesan kesalahan penolakan dan ditampilkan
Keakuratan perhitungan Pembayaran lembur untuk pekerja jam-jaman selama 15 jam Pembayaran lembur sebesar 1.5 kali pembayaran normal
Matriks Test Case
Faktor Usabilitas
Contoh Laporan Hasil Test
Testing Workbach
TESTING 6
VI. Managing Dynamic
Beberapa Bug Sulit untuk di temukan, hanya beberapa menampakkan Kinerja, stress, volume, data quality, dan reliability testing
Beberapa bug dapat membuat masalah besar spt server crashes, kinerja mendadak hilang, dan database corruption
Tests untuk bug ini sangat efektif dibentuk seperti lingkungan sendiri, dimana hasil test dalam bentuk kurang lengkap jarang di extrapolasi, shg software tidak linear
VI.1. Kekomplekan Konfigurasi Test
Lingkungan produksi sering komplek spt banyak interkoneksi servers, ratusan clients, dan koneksi LAN/WAN/PSTN
Menggunakan database untuk konfigurasi model
* Perencanaan, konfigurasi, dan perawatan lingkungan test melalui test project
* Access database didesain menggunakan teknik Entity-Relationship
VI.2. Kapabilitas Logistics Database
Perencanaan, Jalur (track), pengelolaan, dan laporan spt :
Intalasi Hw, lokasi, dan relokasi
Keadaan saat ini, kemarin, dan perencaan konfigurasi hw
Interkoneksi Hw dan networking
Lokasi Test dan Infrastruktur Test
Tugas Test engineer dan lokasinya
Pengembangan sumber daya manusia
VI.3. Proses perancangan Database
Pertimbangan untuk dikelola dan bagaimana relasinya
Entities
* Hardware, software, penguji, tests, dan lokasi
* Entities mempunyai properties
* Properties yang unik dapat menjadi primari key
Relationships
* One-to-one, one-to-many, many-to-many
* Relationships dapat mempunyai properties
Logistics database Entity-Relationship diagram
VI.4. Implementasi Logistics Database
Dari diagram logik ke diagram fisik (tabel raltionship)
Setiap entitas menjadi tabel
Setiap properti dari entiti menjadi field di tabel
Propertie key diidentifikasikan menjadi key field
Penambahan deskripsi field jika diperlukan
Hubungan many to many relationshipnya menjadi tabel, dimana menggabungkan dua key dan ditambah field tertentu dari relationship tersebut.
Dalam kasus ini digunakan microsoft acces, tetapi dapat juga digunakan program database yang lain, mis Mysql, oracle, SQL server dan lain sebagainya
Tabel relationships dari Logistic Database
VI.5. Penggunaan Logistic Database untuk Budget dan Planning
VI.5.1. Test, Penguji dan Lokasi
Data untuk masing-masing field dientry dan ditentukan primary key dalam bentuk pengkodean jika diperlukan.
Testers and tests
* Diset dari test suites dan estimasi waktu
* Tugas testers melaksasakan specific tests
Hardware and infrastructure
Lokasi dan lab
* Lokasi testers bekerja
* Hardware diinstal pada lokasi yang sama atau dapat diakses pada tempat yang lain ketika test
Dibuat query lalu berdasarkan query laporan untuk mengetahui informasi yang dinginkan.
Jadwal Awal dan Akhir Test Suite
Penguji
Tugas-tugas dari Penguji
Laporan Tugas-tugas Penguji
Laporan Jadwal Test
Lokasi Test
Lokasi Penguji
Test berdasarkan Lokasi dan Pengujinya
Lokasi Berdasarkan Test dan Pengujinya
Query memilih Lokasi Test berdasarkan Tanggal
VI.5.2. Perencanaan Hardware dan Infrastruktur
Logistics database dapat juga digunakan pada testing mengunakan konfigurasi software dan hardware yang komplek, mis dalam berbagi sistem operasi yang ada pada jaringan
Client Test Platforms
Lingkungan Test
Bentuk testing ini dapat dibuat laporan, sehingga diketahui dimana lokasi hardware serta spesifikasi, konfigurasi software, sistem operasi untuk masing-masing tahapan testingnya.
Laporan tugas-tugas Hardware
Laporan Test Hardware
VI.5.3. Jalur Konfigurasi Software
Jalur untuk semua relevansi konfigurasi software seperti
* BIOS,
* Versi Sistem Operasi
* Applikasi,
* Mesin virtual dan Interpreter,
* Utilities,
* Test tools and scripts
Perencanaan Release pada Target Platform
Konfigurasi software yang di test dibuat laporan berdasarkan tabel software.
Tabel Release Software
Laporan Konfigurasi yang di lakukan test
VI.6. Kesimpulan
Logistics database merupakan basic tool untuk pengelolaan logistik testing yang komplek
Keuntungan dari pengelolaan logistiknya :
* Pencegahan kesalahan material
* Testing dapat mengetahui keadaan dari pengaruh user pada kondisi yang hampir sama dengan sebenarnya
Menangani lingkungan test yang tersebar dan human logistik.
Perencanaan dan jalur software releases ke lingkungan test untuk bug tracking dan regression testing
Beberapa Bug Sulit untuk di temukan, hanya beberapa menampakkan Kinerja, stress, volume, data quality, dan reliability testing
Beberapa bug dapat membuat masalah besar spt server crashes, kinerja mendadak hilang, dan database corruption
Tests untuk bug ini sangat efektif dibentuk seperti lingkungan sendiri, dimana hasil test dalam bentuk kurang lengkap jarang di extrapolasi, shg software tidak linear
VI.1. Kekomplekan Konfigurasi Test
Lingkungan produksi sering komplek spt banyak interkoneksi servers, ratusan clients, dan koneksi LAN/WAN/PSTN
Menggunakan database untuk konfigurasi model
* Perencanaan, konfigurasi, dan perawatan lingkungan test melalui test project
* Access database didesain menggunakan teknik Entity-Relationship
VI.2. Kapabilitas Logistics Database
Perencanaan, Jalur (track), pengelolaan, dan laporan spt :
Intalasi Hw, lokasi, dan relokasi
Keadaan saat ini, kemarin, dan perencaan konfigurasi hw
Interkoneksi Hw dan networking
Lokasi Test dan Infrastruktur Test
Tugas Test engineer dan lokasinya
Pengembangan sumber daya manusia
VI.3. Proses perancangan Database
Pertimbangan untuk dikelola dan bagaimana relasinya
Entities
* Hardware, software, penguji, tests, dan lokasi
* Entities mempunyai properties
* Properties yang unik dapat menjadi primari key
Relationships
* One-to-one, one-to-many, many-to-many
* Relationships dapat mempunyai properties
Logistics database Entity-Relationship diagram
VI.4. Implementasi Logistics Database
Dari diagram logik ke diagram fisik (tabel raltionship)
Setiap entitas menjadi tabel
Setiap properti dari entiti menjadi field di tabel
Propertie key diidentifikasikan menjadi key field
Penambahan deskripsi field jika diperlukan
Hubungan many to many relationshipnya menjadi tabel, dimana menggabungkan dua key dan ditambah field tertentu dari relationship tersebut.
Dalam kasus ini digunakan microsoft acces, tetapi dapat juga digunakan program database yang lain, mis Mysql, oracle, SQL server dan lain sebagainya
Tabel relationships dari Logistic Database
VI.5. Penggunaan Logistic Database untuk Budget dan Planning
VI.5.1. Test, Penguji dan Lokasi
Data untuk masing-masing field dientry dan ditentukan primary key dalam bentuk pengkodean jika diperlukan.
Testers and tests
* Diset dari test suites dan estimasi waktu
* Tugas testers melaksasakan specific tests
Hardware and infrastructure
Lokasi dan lab
* Lokasi testers bekerja
* Hardware diinstal pada lokasi yang sama atau dapat diakses pada tempat yang lain ketika test
Dibuat query lalu berdasarkan query laporan untuk mengetahui informasi yang dinginkan.
Jadwal Awal dan Akhir Test Suite
Penguji
Tugas-tugas dari Penguji
Laporan Tugas-tugas Penguji
Laporan Jadwal Test
Lokasi Test
Lokasi Penguji
Test berdasarkan Lokasi dan Pengujinya
Lokasi Berdasarkan Test dan Pengujinya
Query memilih Lokasi Test berdasarkan Tanggal
VI.5.2. Perencanaan Hardware dan Infrastruktur
Logistics database dapat juga digunakan pada testing mengunakan konfigurasi software dan hardware yang komplek, mis dalam berbagi sistem operasi yang ada pada jaringan
Client Test Platforms
Lingkungan Test
Bentuk testing ini dapat dibuat laporan, sehingga diketahui dimana lokasi hardware serta spesifikasi, konfigurasi software, sistem operasi untuk masing-masing tahapan testingnya.
Laporan tugas-tugas Hardware
Laporan Test Hardware
VI.5.3. Jalur Konfigurasi Software
Jalur untuk semua relevansi konfigurasi software seperti
* BIOS,
* Versi Sistem Operasi
* Applikasi,
* Mesin virtual dan Interpreter,
* Utilities,
* Test tools and scripts
Perencanaan Release pada Target Platform
Konfigurasi software yang di test dibuat laporan berdasarkan tabel software.
Tabel Release Software
Laporan Konfigurasi yang di lakukan test
VI.6. Kesimpulan
Logistics database merupakan basic tool untuk pengelolaan logistik testing yang komplek
Keuntungan dari pengelolaan logistiknya :
* Pencegahan kesalahan material
* Testing dapat mengetahui keadaan dari pengaruh user pada kondisi yang hampir sama dengan sebenarnya
Menangani lingkungan test yang tersebar dan human logistik.
Perencanaan dan jalur software releases ke lingkungan test untuk bug tracking dan regression testing
TESTING 5
V. Managing Test Case : Test Tracking Spreadsheets (TTS)
Sebelum melakukan pengetesan diperlukan adanya persiapan untuk membuat kasus test.
Sehingga di akhir pengetesan dapat mengetahui secara pasti berapa banyak test yang dilakukan, berapa banyak test yang terlewati, dan berapa banyak bug yang ditemukan dalam kasus test tersebut.
V.1. Building Minimalist TTS
Kasus test dikelompokan kedalam test suite yang terdiri dari :
* Lingkungan
* Load, kapasitas dan volume
* Fungsi dasar
* Standarisasi
Setiap kasus test ada status, system configuration, bug id, tester, keterangan, Kasus test, Fail, Pass
Bila kolom kasus test, fail, dan pass dijumlahkan akan didapat total kasus test , total fail, dan total pass di dalam satu kelompok
Test Case SummaryWorksheet
System Configuration Worksheet
Test Suite Summary Worksheet
V.2. Peningkatan Selanjutnya
Identifikasi Test Suites dan Test Cases
* Dengan menggunakan dewey number
* Test suite angka dibelakang nol seperti 1.000, 2.000, sedangkan test case angka dibelakang sesuai dengan urutan dan sub kelompok seperti 1.101, 1.102, 2.101, 2.102
Penambahan Tanggal dan Jam informasi, penamabahan waktu (jam dan tanggal ) dimaksudkan untuk memudahkan dalam waktu penyelesaian proyek test, sehingga upah tim dapat dihitung
Pengumpulan data untuk kebenaran perhitungan, digunakan untuk menjaga dan mengetahui MTBF pada hardware.
Peningkatan ketepatan Status Test Case
* In Queue state , diindikasikan dengan kekurangan masukan pada kolom status dari test case summary
* In Progress (IP), mengidikasikan bahwa test menjalankan dan akan mungkin diteruskan.
* Block mereflesikan kenyataan bahwa beberapa kondisi eksternal seperti kehilangan bagian kecil dari fungsi
* Skip, dimaksudkan dengan terdapat keputusan yang harus dimunculkan karena me-skip (melompat) dari test (dijelaskan pada kolom komentar).
* Closed, tim test mengkonfirmasikan bahwa semua bug yang sebelumnya diidentifikasikan mengganggu test case sudah diperbaiki.
* Warn, mengidikasikan keberadaan problem, walaupun tidak serius cukup untuk menandakan bahwa test case dalam status gagal (fail).
Kemungkinan yang ada dari Test Case States
Perhitungan Bobot Kegagalan
Penyimpanan nama pemilik (Ownership)
Pelakasanaan apa yang penting
Penambahan Summary lain
Pengelompokan data
V.3. Detail test case
Penambahan test case detail dapat dilakukan pada program aplikasi spreadsheets
Terdapat tiga kelompok yang ada yaitu :
* Kelompok baris pertama menyediakan informasi pendahuluan dari test case
* Bagian tengah menyediakan daftar langkah-langkah yang meng-create kondisi test
* Bagian akhir merupakan sumarry dari hasil
Detail Test Case Tempelate
Sebelum melakukan pengetesan diperlukan adanya persiapan untuk membuat kasus test.
Sehingga di akhir pengetesan dapat mengetahui secara pasti berapa banyak test yang dilakukan, berapa banyak test yang terlewati, dan berapa banyak bug yang ditemukan dalam kasus test tersebut.
V.1. Building Minimalist TTS
Kasus test dikelompokan kedalam test suite yang terdiri dari :
* Lingkungan
* Load, kapasitas dan volume
* Fungsi dasar
* Standarisasi
Setiap kasus test ada status, system configuration, bug id, tester, keterangan, Kasus test, Fail, Pass
Bila kolom kasus test, fail, dan pass dijumlahkan akan didapat total kasus test , total fail, dan total pass di dalam satu kelompok
Test Case SummaryWorksheet
System Configuration Worksheet
Test Suite Summary Worksheet
V.2. Peningkatan Selanjutnya
Identifikasi Test Suites dan Test Cases
* Dengan menggunakan dewey number
* Test suite angka dibelakang nol seperti 1.000, 2.000, sedangkan test case angka dibelakang sesuai dengan urutan dan sub kelompok seperti 1.101, 1.102, 2.101, 2.102
Penambahan Tanggal dan Jam informasi, penamabahan waktu (jam dan tanggal ) dimaksudkan untuk memudahkan dalam waktu penyelesaian proyek test, sehingga upah tim dapat dihitung
Pengumpulan data untuk kebenaran perhitungan, digunakan untuk menjaga dan mengetahui MTBF pada hardware.
Peningkatan ketepatan Status Test Case
* In Queue state , diindikasikan dengan kekurangan masukan pada kolom status dari test case summary
* In Progress (IP), mengidikasikan bahwa test menjalankan dan akan mungkin diteruskan.
* Block mereflesikan kenyataan bahwa beberapa kondisi eksternal seperti kehilangan bagian kecil dari fungsi
* Skip, dimaksudkan dengan terdapat keputusan yang harus dimunculkan karena me-skip (melompat) dari test (dijelaskan pada kolom komentar).
* Closed, tim test mengkonfirmasikan bahwa semua bug yang sebelumnya diidentifikasikan mengganggu test case sudah diperbaiki.
* Warn, mengidikasikan keberadaan problem, walaupun tidak serius cukup untuk menandakan bahwa test case dalam status gagal (fail).
Kemungkinan yang ada dari Test Case States
Perhitungan Bobot Kegagalan
Penyimpanan nama pemilik (Ownership)
Pelakasanaan apa yang penting
Penambahan Summary lain
Pengelompokan data
V.3. Detail test case
Penambahan test case detail dapat dilakukan pada program aplikasi spreadsheets
Terdapat tiga kelompok yang ada yaitu :
* Kelompok baris pertama menyediakan informasi pendahuluan dari test case
* Bagian tengah menyediakan daftar langkah-langkah yang meng-create kondisi test
* Bagian akhir merupakan sumarry dari hasil
Detail Test Case Tempelate
TESTING 4
IV. Bug Tracking Database
IV.1. Formal Bug Tracking System
Bug tracking database dapat mengkomunikasikan bug dengan jelas.
Dengan memberikan standard penulisan bug dapat menjelaskan lebih baik dibandingkan dengan email form biasa
Dengan database dapat diberikan nomor urut secara otomatis, sehingga pada saat kita akan merujuk ke bug tertentu dapat menggunakan nomor urut tersebut.
Dapat diberikan prioritas urutan dengan mudah untuk memperbaiki bug.
Dapat mengelola pelacakan bug melalui sklus hidupnya dari laporan awal hingga resolusi akhir.
Sebagai bug progress sklus hidupnya memudahkan bagi developers, testers dan manajer dalam dalam mempelajari informasi baru.
IV.2. Failure Description
Keterangan tentang failure dari suatu program, failure description ini merupakan alat untuk mengkomunikasikan bug dari tester pada programmer
Penulisan Failure Description
* Jelaskan tahapan bagaimana caranya untuk mendapatkan bug tersebut
* Penulisan harus singkat dan jelas, tidak bertele-tele dan tidak terlalu singkat sehingga sulit di mengerti
Contoh Laporan Bug yang Baik
Contoh Laporan Bug yang Terlampau Singkat
IV.3. Konstruksi Awal Database
Minimal suatu bug tracking database harus menyimpan diskripsi failure, summary, langkah-langkah reproduksi dan isolasinya.
Dengan identifikasi informasinya menggunakan sequential nomor Id, nama proyek pembuat laporan dan tanggal laporan yang dimasukan.
Tabel Dasar untuk Bug Tracking Database
Tampilan pada bug tracking database menggunakan bug entry form
Laporan Detail Bug
Laporan Summary Bug
IV.4. Pengelompokan Bug
Severity adalah akibat dari kesalahan didalam sistem yang sedang dilakukan pengetesan, dapat ditandakan berdasarkan nomor yang ada dibawah ini :
1. Data hilang, kerusakan hardware
2. Fungsi yang tidak dapat berjalan dengan baik, dan tidak ada cara lain
3. Fungsi yang tidak dapat berjalan dengan baik, dan mempunyai cara lain untuk menjalankanya
4. Fungsi atau fitur yang hilang sebagian
5. Kesalahan kosmetik
Prioritas perlu diberikan dalam memperbaiki suatu error, dan prioritas ini tidak selalu sama dengan severity. Pemberian prioritas adalah sebagai berikut :
1. Highest priority. The system is practically unusable with this bug
2. High priority. The bug will have a serious impact on the company’s ability to sell and maintain this system
3. Medium priority. The company will lose some money if this bug is in the system, but it might be more important to meet the schedule. Fix after release if it is not fixed before
4. Low priority. Don’t delay the release, but do fix this problem afterward
5. Lowest priority. Fix as time and resources allow
IV.5. Penambahan Informasi Dinamik
IV.5.1. Pengelolaan Bug Life Cycles
Bug State dan Transisi
Review, setelah tester melakukan pengetesan bug report di review oleh test manager
Rejected, bila bug report tidak jelas atau kurang informasi maka bug report tersebut ditolak untuk di perbaiki oleh si tester
Open, jika bug report sudah di review dan diterima maka bug report tersebut open untuk di lihat oleh developer
Assigned, jika developer menerima bug report tersebut, kemudian menunjuk developer untuk memperbaiki bug tersebut
Test, setelah diperbaiki oleh developer maka di test kembali dan dilakukan regression testing.
Reopened, jika perbaikannya masih ada yang salah maka bug di buka kembali agar dapat diperbaiki oleh developer
Closed, jika bug sudah selesai di perbaiki status bug sudah selesai maka di tutup
Deffered, bila bug tersebut dianggap tidak perlu diperbaiki sekarang karena mempunyai prioritas yang rendah, atau digunakan untuk versi yang akan datang
IV.5.2. Pelacakan Perubahan Status
Setiap bug melewati perubahan status, direkam didalam status log sehingga tester, developers dan para manager dapat melacak bug yang ada.
Penulisan untuk bug dilakukan untuk kejadian yang mengubah status bug saja, bukan setiap kejadian seperti pada buku harian
IV.6. Informasi tentang bug
Agar dapat menyelesaikan masalah bug dengan baik diperlukan adanya suatu pengukuran yang baik.
Didalam pelacakan database, perlu ditambahkan beberapa informasi seperti close date, resolution, dan root cause.
Perlu juga adanya pengelompokan dari sistem, agar kita dapat mengetahui di modul yang mana yang masih banyak mengandung bug.
Lokasi Bug dan Skedul test untuk SpeedyWriter
Opened/closed chart untuk SpeedyWriter
Endless Bug Discovery
Closure period for SpeedyWriter
SpeedyWriter root cause breakdown
SpeedyWriter subsystem breakdown
IV.1. Formal Bug Tracking System
Bug tracking database dapat mengkomunikasikan bug dengan jelas.
Dengan memberikan standard penulisan bug dapat menjelaskan lebih baik dibandingkan dengan email form biasa
Dengan database dapat diberikan nomor urut secara otomatis, sehingga pada saat kita akan merujuk ke bug tertentu dapat menggunakan nomor urut tersebut.
Dapat diberikan prioritas urutan dengan mudah untuk memperbaiki bug.
Dapat mengelola pelacakan bug melalui sklus hidupnya dari laporan awal hingga resolusi akhir.
Sebagai bug progress sklus hidupnya memudahkan bagi developers, testers dan manajer dalam dalam mempelajari informasi baru.
IV.2. Failure Description
Keterangan tentang failure dari suatu program, failure description ini merupakan alat untuk mengkomunikasikan bug dari tester pada programmer
Penulisan Failure Description
* Jelaskan tahapan bagaimana caranya untuk mendapatkan bug tersebut
* Penulisan harus singkat dan jelas, tidak bertele-tele dan tidak terlalu singkat sehingga sulit di mengerti
Contoh Laporan Bug yang Baik
Contoh Laporan Bug yang Terlampau Singkat
IV.3. Konstruksi Awal Database
Minimal suatu bug tracking database harus menyimpan diskripsi failure, summary, langkah-langkah reproduksi dan isolasinya.
Dengan identifikasi informasinya menggunakan sequential nomor Id, nama proyek pembuat laporan dan tanggal laporan yang dimasukan.
Tabel Dasar untuk Bug Tracking Database
Tampilan pada bug tracking database menggunakan bug entry form
Laporan Detail Bug
Laporan Summary Bug
IV.4. Pengelompokan Bug
Severity adalah akibat dari kesalahan didalam sistem yang sedang dilakukan pengetesan, dapat ditandakan berdasarkan nomor yang ada dibawah ini :
1. Data hilang, kerusakan hardware
2. Fungsi yang tidak dapat berjalan dengan baik, dan tidak ada cara lain
3. Fungsi yang tidak dapat berjalan dengan baik, dan mempunyai cara lain untuk menjalankanya
4. Fungsi atau fitur yang hilang sebagian
5. Kesalahan kosmetik
Prioritas perlu diberikan dalam memperbaiki suatu error, dan prioritas ini tidak selalu sama dengan severity. Pemberian prioritas adalah sebagai berikut :
1. Highest priority. The system is practically unusable with this bug
2. High priority. The bug will have a serious impact on the company’s ability to sell and maintain this system
3. Medium priority. The company will lose some money if this bug is in the system, but it might be more important to meet the schedule. Fix after release if it is not fixed before
4. Low priority. Don’t delay the release, but do fix this problem afterward
5. Lowest priority. Fix as time and resources allow
IV.5. Penambahan Informasi Dinamik
IV.5.1. Pengelolaan Bug Life Cycles
Bug State dan Transisi
Review, setelah tester melakukan pengetesan bug report di review oleh test manager
Rejected, bila bug report tidak jelas atau kurang informasi maka bug report tersebut ditolak untuk di perbaiki oleh si tester
Open, jika bug report sudah di review dan diterima maka bug report tersebut open untuk di lihat oleh developer
Assigned, jika developer menerima bug report tersebut, kemudian menunjuk developer untuk memperbaiki bug tersebut
Test, setelah diperbaiki oleh developer maka di test kembali dan dilakukan regression testing.
Reopened, jika perbaikannya masih ada yang salah maka bug di buka kembali agar dapat diperbaiki oleh developer
Closed, jika bug sudah selesai di perbaiki status bug sudah selesai maka di tutup
Deffered, bila bug tersebut dianggap tidak perlu diperbaiki sekarang karena mempunyai prioritas yang rendah, atau digunakan untuk versi yang akan datang
IV.5.2. Pelacakan Perubahan Status
Setiap bug melewati perubahan status, direkam didalam status log sehingga tester, developers dan para manager dapat melacak bug yang ada.
Penulisan untuk bug dilakukan untuk kejadian yang mengubah status bug saja, bukan setiap kejadian seperti pada buku harian
IV.6. Informasi tentang bug
Agar dapat menyelesaikan masalah bug dengan baik diperlukan adanya suatu pengukuran yang baik.
Didalam pelacakan database, perlu ditambahkan beberapa informasi seperti close date, resolution, dan root cause.
Perlu juga adanya pengelompokan dari sistem, agar kita dapat mengetahui di modul yang mana yang masih banyak mengandung bug.
Lokasi Bug dan Skedul test untuk SpeedyWriter
Opened/closed chart untuk SpeedyWriter
Endless Bug Discovery
Closure period for SpeedyWriter
SpeedyWriter root cause breakdown
SpeedyWriter subsystem breakdown
TESTING 3
III. Arsitektur Test sistem, Kasus Test dan Ruang Lingkupnya
III.1. Arsitektur & Rekayasa Test Sistem
Test Sistem biasanya melibatkan satu atau banyak test tools, misal Sistem operasi, Scripting languages, GUI otomatisasi test dan oscilloscopes.
Penggunaan tools tersebut menghasilkan suatu log (catatan) yang dapat dibuat secara otomatis maupun manual oleh penguji.
Tim test akan menggunakan alat untuk melaksanakan kasus test, dimana tools mendukung test case library.
Hubungan antar dua elemen tersebut banyak ke banyak, yaitu tiap tool dapat digunakan untuk banyak kasus test dan setiap kasus test dapat melibatkan banyak penggunaan tools.
Test case library dan hasil logs (catatan) dimasukan ke report tool.
Test engineers merakit test suites dari test case library., diamana hubungan kasus test dan test suites juga bayak ke bayak.
Berdasarkan test suites dan report tool dibuat report test.
Pada level tertinggi arsitektur test mendefinisikan prinsip desain, struktur dan tool sebagai inter relasi antara bagian unsur dengan proyek yang independen tetapi merefleksikan sistem dalam keaadaan test.
Representasi visual dari test sistem
III.2. Susunan Kasus Test
Test case setup, menentukan konfigurasi sistem untuk melakukan test
Test Condition, kondisi seperti apa yang akan dilakukan pada saat pengetesan, seperti pada performance test, yaitu test yang dilakukan untuk menentukan unjuk kerja software, perlu suatu kondisi dimana software diberi beban pengolahan data yang cukup besar
Test case teardown, menentukan tahapan untuk memulai pengetesan ulang, setelah dilakukan pengetesan sehingga akan terjadi keadaan seperti awal sebelum dimulainya pengetesan
Hubungan antara test tools, test case library dan test suites
III.3. Mendisain Kasus Test
Kasus untuk test adalah suatu test yang dibuat untuk mengukur karakteristik kwalitas sistem.
Kasus untuk test yang paling umum adalah untuk mentest fungsional dari sistem .
Dapat dirancang setelah setiap kebutuhan dapat diidentifikan dan setiap kebutuhan memerlukan paling tidak satu kasus untuk test.
Use Case Diagram
Test Case
Multiple Test Use Case
Test Case Matrix Coverage
III.4. Menentukan Kasus Test
Untuk menentukan kasus test dilihat dari :
Level of test detail, menentukan seberapa detil test akan dilakukan
Test coverage, seberapa luas pengetesan akan dilakukan
Test Case Tempelate
III.5. Test Escape
Test escape terjadi karena beberapa masalah seperti
A low fidelity test system, test system yang mencakup hampir semua fitur tetapi fitur yang sangat penting tidak tercover. Biasanya terjadi karena engineering yang kurang baik
A regression test gap, test case tidak mencakup dimana bug ditemukan. Biasanya terjadi karena terbatasnya waktu atau terbatasnya sumber daya
A type II error, terjadi bila tester tidak dapat mendeteksi incorrect system behaviour. Biasanya terjadi karena tester, atau test manager
Low- fidelity test system
Regression test gap
III.6. Tipe-tipe Kesalahan
Input/Output Error
* Rutin untuk membuka dan menutup file secara benar
* Definisi dari field, record, dan file secara benar
* Penggunaan key secara benar pada saat membaca dan menulis ke file
* Penanganan kondisi end-of-file secara benar
* Penanganan input/output error secara benar
Interface Error
Function tun_pph(gapok, status)
selisih = 1
PTKP = tarip(status)
tunjangan = fPajak(gapok - PTKP)
Do While selisih > 0.0001
biaya = jabat(gapok + tunjangan)
PKP = gapok + tunjangan - (PTKP + biaya)
pajak = fPajak(PKP)
selisih = Abs(tunjangan - pajak)
If pajak > tunjangan Then
tunjangan = pajak - selisih / 3
Else
tunjangan = pajak + selisih / 3
End If
Loop
End Function
Data Structure Error
* Pendefinisian dan penggunaan subscrip dan index secara benar
* Penggunaan nama data secara konsisten
* Inisialisasi konstanta dengan benar
* Inisialisasi kounter dan akumulator dengan benar
Arithmatic Error
* Tipe dan besarnya variabel untuk hasil perhitungan yang cukup
* Tipe data yang benar yang digunakan dalam perhitungan
* Urutan pengoperasian aritmatik secara benar
* Mampu untuk menangani pembagian nol
Comparison Error
* Atribut data yang akan dibandingkan atau di test harus sama
* Urutan yang benar dalam pembandingan untuk perbandingan yang menggunakan “or” dan “and”
Control Logic Error
* Persyaratan untuk keluar dari loop
* Inisialisasi dan penambahan subscript pada loop
* Persyaratan pada setiap cabang untuk semua kemungkinan kondisi
* Satu exit point pada satu modul
III.7. Test Data
Range of Value
Jumlah digit yang dapat menampung hasil perhitungan
* Diatas batas atas
* Dibatas atas
* Dibatas bawah
* Dibawah batas bawah
Batas Atas dan Batas Bawah dari nilai
Categories of Value
Jenis data yang dimasukan apakah benar
* Hanya numeric saja, seperti nomor telepon
* Hanya alphabet saja seperti nama orang
* Apakah tanggal yang dimasukan sesuai dengan bulannya
Ordered Value
* Urutan data di dalam suatu tabel
* Indeks dari suatu file
* Pilih elemen pertama didalam satu set urutan
* Pilih elemen terakhir didalam satu set urutan
* Pilih elemen yang diketahui tidak ada
* Perlu diperiksa batas atas dan batas bawah, untuk file perlu dicari data pertama dan data terakhir dari suatu file
Discrete Value
* Data yang berupa diskrit
* Status pajak, K/0, K/1, K/2
* Jenis Kelamin P/W, L/P
* Jabatan, pemula, madya, mahir
* Perlu diperiksa apakah data yang tidak masuk dalam kategori tersebut dapat diterima atau tidak
III.1. Arsitektur & Rekayasa Test Sistem
Test Sistem biasanya melibatkan satu atau banyak test tools, misal Sistem operasi, Scripting languages, GUI otomatisasi test dan oscilloscopes.
Penggunaan tools tersebut menghasilkan suatu log (catatan) yang dapat dibuat secara otomatis maupun manual oleh penguji.
Tim test akan menggunakan alat untuk melaksanakan kasus test, dimana tools mendukung test case library.
Hubungan antar dua elemen tersebut banyak ke banyak, yaitu tiap tool dapat digunakan untuk banyak kasus test dan setiap kasus test dapat melibatkan banyak penggunaan tools.
Test case library dan hasil logs (catatan) dimasukan ke report tool.
Test engineers merakit test suites dari test case library., diamana hubungan kasus test dan test suites juga bayak ke bayak.
Berdasarkan test suites dan report tool dibuat report test.
Pada level tertinggi arsitektur test mendefinisikan prinsip desain, struktur dan tool sebagai inter relasi antara bagian unsur dengan proyek yang independen tetapi merefleksikan sistem dalam keaadaan test.
Representasi visual dari test sistem
III.2. Susunan Kasus Test
Test case setup, menentukan konfigurasi sistem untuk melakukan test
Test Condition, kondisi seperti apa yang akan dilakukan pada saat pengetesan, seperti pada performance test, yaitu test yang dilakukan untuk menentukan unjuk kerja software, perlu suatu kondisi dimana software diberi beban pengolahan data yang cukup besar
Test case teardown, menentukan tahapan untuk memulai pengetesan ulang, setelah dilakukan pengetesan sehingga akan terjadi keadaan seperti awal sebelum dimulainya pengetesan
Hubungan antara test tools, test case library dan test suites
III.3. Mendisain Kasus Test
Kasus untuk test adalah suatu test yang dibuat untuk mengukur karakteristik kwalitas sistem.
Kasus untuk test yang paling umum adalah untuk mentest fungsional dari sistem .
Dapat dirancang setelah setiap kebutuhan dapat diidentifikan dan setiap kebutuhan memerlukan paling tidak satu kasus untuk test.
Use Case Diagram
Test Case
Multiple Test Use Case
Test Case Matrix Coverage
III.4. Menentukan Kasus Test
Untuk menentukan kasus test dilihat dari :
Level of test detail, menentukan seberapa detil test akan dilakukan
Test coverage, seberapa luas pengetesan akan dilakukan
Test Case Tempelate
III.5. Test Escape
Test escape terjadi karena beberapa masalah seperti
A low fidelity test system, test system yang mencakup hampir semua fitur tetapi fitur yang sangat penting tidak tercover. Biasanya terjadi karena engineering yang kurang baik
A regression test gap, test case tidak mencakup dimana bug ditemukan. Biasanya terjadi karena terbatasnya waktu atau terbatasnya sumber daya
A type II error, terjadi bila tester tidak dapat mendeteksi incorrect system behaviour. Biasanya terjadi karena tester, atau test manager
Low- fidelity test system
Regression test gap
III.6. Tipe-tipe Kesalahan
Input/Output Error
* Rutin untuk membuka dan menutup file secara benar
* Definisi dari field, record, dan file secara benar
* Penggunaan key secara benar pada saat membaca dan menulis ke file
* Penanganan kondisi end-of-file secara benar
* Penanganan input/output error secara benar
Interface Error
Function tun_pph(gapok, status)
selisih = 1
PTKP = tarip(status)
tunjangan = fPajak(gapok - PTKP)
Do While selisih > 0.0001
biaya = jabat(gapok + tunjangan)
PKP = gapok + tunjangan - (PTKP + biaya)
pajak = fPajak(PKP)
selisih = Abs(tunjangan - pajak)
If pajak > tunjangan Then
tunjangan = pajak - selisih / 3
Else
tunjangan = pajak + selisih / 3
End If
Loop
End Function
Data Structure Error
* Pendefinisian dan penggunaan subscrip dan index secara benar
* Penggunaan nama data secara konsisten
* Inisialisasi konstanta dengan benar
* Inisialisasi kounter dan akumulator dengan benar
Arithmatic Error
* Tipe dan besarnya variabel untuk hasil perhitungan yang cukup
* Tipe data yang benar yang digunakan dalam perhitungan
* Urutan pengoperasian aritmatik secara benar
* Mampu untuk menangani pembagian nol
Comparison Error
* Atribut data yang akan dibandingkan atau di test harus sama
* Urutan yang benar dalam pembandingan untuk perbandingan yang menggunakan “or” dan “and”
Control Logic Error
* Persyaratan untuk keluar dari loop
* Inisialisasi dan penambahan subscript pada loop
* Persyaratan pada setiap cabang untuk semua kemungkinan kondisi
* Satu exit point pada satu modul
III.7. Test Data
Range of Value
Jumlah digit yang dapat menampung hasil perhitungan
* Diatas batas atas
* Dibatas atas
* Dibatas bawah
* Dibawah batas bawah
Batas Atas dan Batas Bawah dari nilai
Categories of Value
Jenis data yang dimasukan apakah benar
* Hanya numeric saja, seperti nomor telepon
* Hanya alphabet saja seperti nama orang
* Apakah tanggal yang dimasukan sesuai dengan bulannya
Ordered Value
* Urutan data di dalam suatu tabel
* Indeks dari suatu file
* Pilih elemen pertama didalam satu set urutan
* Pilih elemen terakhir didalam satu set urutan
* Pilih elemen yang diketahui tidak ada
* Perlu diperiksa batas atas dan batas bawah, untuk file perlu dicari data pertama dan data terakhir dari suatu file
Discrete Value
* Data yang berupa diskrit
* Status pajak, K/0, K/1, K/2
* Jenis Kelamin P/W, L/P
* Jabatan, pemula, madya, mahir
* Perlu diperiksa apakah data yang tidak masuk dalam kategori tersebut dapat diterima atau tidak
TESTING 2
II. Test Plan
II. 1. Alasan menulis test plan yaitu :
Usaha yang dibutuhkan dalam test proyek
Memberikan budget
Sebagai sumber komitmen dan jadwal
Penjelasan dalam mengatur test proyek
Perbedaan antara test plan dan test suite adalah pada soal perbedaan strategi dengan taktik.
Strategi terdiri dari seluruh rencana untuk mencari dan mengidentifikasikan sebanyak mungkin bug-bug yang ada
Taktik merupakan langkah spesifik yang bisa kita ambil untuk melakukan test pengujian.
II.2. Macam/Jenis Test Plan
Different time periods.
* Jika perkembangan test dan eksekusi test untuk subproject awal dan akhir pada perbedaan tanggal
* Informasi dibutuhkan pada rencana subproject yang lebih awal sebelum informasi pada subproject berikutnya.
Different Methodologis.
* Diskusi yang rinci dari pengubahan kode rata-rata
* Platform yang bebas diotomatiskan dengan alat tes GUI yang tidak bekerja bersamaan.
Different Objectives
* Menyelesaikan 3 tujuan yang berbeda
* Tujuan tersebut yaitu
• Mencari bug-bug dalam unit fungsi
• Mengetes integrasi dari unit fungsi dan
• Mengecek fungsi bisnis dari integrasi keseluruhan.
Different Audiences
* Test plan tidak hanya memberitahukan pada teman, penguji dan manajer dari visi, itu hanya kesempatan untuk menemukan kesempurnaan.
* Input ini khususnya berguna untuk memberikan ide bagaimana fokus pada test.
II.3. Penggunaan draft untuk menstimulasi diskusi
Menggunakan penyangga pada perencanaan untuk mengindikasi pertanyaan dan membuka persoalan.
Menggunakan “Copping Out”, identifikasi dan dokumentasi untuk membuka persoalan, lebih digunakan pada aspek perencanaan latihan.
Menggunakan beberapa perkiraan waktu tentang masalah yang timbul.
Test plan terdiri dari notasi yang luas dengan masalah yang dapat diputuskan atau persoalan yang menunggu resolusi.
II.4. Test Plan Tempelete
Model yang digunakan bagi pengembangan test plan.
Model ini bukan merupakan alat pemotongan dan penyalinan suatu test plan dalam waktu yang singkat.
Suatu kumpulan rancangan logis dari topik-topik yang perlu dipertimbangkan dengan hati-hati dalam pengujian.
II.4.1. Overview
Bagian keseluruhan dari sebuah test plan memungkinkan untuk memperkenalkan rencana pendekatan test.
Menampilkan sebuah penjelasan yang jelas dari sasaran-sasaran, metodologi, dan tujuan-tujuan .
II.4.2. Bound, (mengatur batasan-batasan perencanaan test )
Mendiskusikan apa yang akan atau tidak akan diujikan.
Mendefinisikan istilah-istilah dan akronim (lawan kata) yang penting yang berhubungan dengan ujian.
Menentukan dimana usaha-usaha tes yang berhubungan dengan pelaksanaan proyek pendukung test ini.
II.4.3. Scope
Bila ingin menjelaskan secara terperinci ruang lingkup dari proyek, maka harus menggambar batasan yang memisahkan antara apa saja yang akan diperhatikan selama pelaksanaan proyek.
Contoh Test Plan Tempelete
Menggunakan tabel “Ya/Tidak” untuk mendefinisikan ruang lingkup pengetesan.
II.4.4. Definisi
Tabel dapat membantu memperjelas istilah/terminologi bagi yang tidak berpengalaman dalam bidang testing.
Membantu memastikan bahwa setiap orang dalam kelompok penguji bekerja dengan menggunakan kumpulan definisi yang sama.
II.4.5. Setting
Bagian rencana test menjelaskan keinginan untuk melakukan testing, dan penjelasan tersebut sangat sederhana.
Adanya pertimbangan untuk menampilkan tabel yang menunjukkan bagaimana pekerjaan yang akan dialokasikan.
Misalnya : laboratorium test.
II.4.6. Quality Risk
Menyimpan hasil proses test plan dalam bentuk referensi.
Bila user ingin membaca outline kualitas resiko proses test plan atau diagram FMEA.
II.4.7. Proposed Schedule of Miliestones
Rencana harus terdiri dari jadwal kegiatan yang akan dilakukan pada test proyek.
Difokuskan pada kegiatan yang mempunyai level tinggi dan pengiriman yang visible pada manajemen.
Misalnya : jadwal untuk Speedy Writer.
Milestone/effort Date
Test Deveolopment and Configurations
Test Plan Complete 8/9/2003
Test Lab Defined 8/12/2003
Test Lab Configured 8/26/2003
FMEA Complete 8/16/2003
Test Suite Complete 9/5/2003
Test Execution
System test entry 9/2/2003
Cycle 1 9/2/2003 - 9/16/2003
Cycle 2 9/19/2003 - 10/3/2003
Cycle 3 10/6/2003 - 10/13/2003
System test exit 10/13/2003
Skedul Test Sistem milestones
II.4.8. Transitions
Untuk tiap fase, system dibawah test harus memenuhi minimal 1 set kualifikasi sebelum test organisasi mendapat keuntungan dalam test execution.
Bagian test plan harus menunjukkan criteria yang esensial untuk permulaan dan kelengkapan fase test yang berbeda.
Ada 3 set criteria yang biasa digunakan yaitu : Entry, Exit, Stopping criteria.
* Entry Criteria, Kriteria masukan memungkinkan system untuk pindah kedalam fase test khusus. Ada beberapa alamat pertanyaan dalam criteria ini yaitu :
• Apakah perlu ada dokumentasi, spesifikasi, dan syarat yang memungkinkan tester mengoperasikan system dan menilai kebenaran reaksi?
• Apakah system siap untuk pengiriman dan bentuk apa saja yang cocok untuk pertanyaan fase test?
• Apa ada kegunaan dukungan, aksesoris, dan prasyarat dalam bentuk tester yang digunakan?
• Apa system pada mutu level cocok? Tiap pertanyaan biasanya mengimplementasi beberapa atau semua fase test yang telah diselesaikan dengan sukses.
• Apa test environment_lab, hardware,software, dan system pendukung administrasi siap?
* Stopping criteria
• Kriteria penundaan memberikan kondisi atau event yang menunda test execution.
• Contohnya : test environment menjadi tidak siap, system mempunyai banyak bug, tidak bisa melanjutkan testing.
* Exit criteria, alamat criteria keluaran menunjukkan bagaimana menentukan kapan testing telah selesai dan lengkap.
II.4.9. Test Configurations & Environments
Dokumen dimana hardware, software dan jaringan dan ruang lab akan menggunakan pekerjaan testing.
Untuk aplikasi PC atau kegunaannya, task ini dapat menyederhanakan hardware maupun software dari waktu ke waktu.
Sistem testing dengan element hardware yang signifikan (laptop baru atau server), 1 dengan banyak elemen hardware (jaringan system operasi atau jaringan aplikasi), atau 1 dengan elemen hardware yang mahal (mainframe, server cluster).
Membentuk skema untuk alokasi hardware dalam sebagian lokasi, bagian test plan, atau pemisahan dokumen.
II.4.10. Test Execution
Alamat test plan merupakan factor yang penting untuk mempengaruhi test execution.
Menjalankan test cycle yang berbeda dalam tiap fase test.
Dalam menjalankan test, kita dapat mengumpulkan data dan melacak dengan cara memperlihatkan pada team dan manajer.
Test Usage System Network When Where Other
Product Test
Component Interfaces/ Signal Quality Engr Proto [2] Novell, NFS, NT 9/15-10/15 Engr. Lab MS Mouse, MS Kbd, VGA Mon, USB Mouse, USB Mon, USB Kbd, 3COM LAN, USR Mdm, Epson Prn, Quantum HD, Oscilloscope
Mechanical Life Engr Proto [2] None 8/1-10/1 Engr. Lab None
Stress, Capacity, Volume Engr Proto [1] Novell, NFS, NT 9/15-10/15 Test Lab MS Mouse, VGA Mon
Performance Engr Proto [1] Novell, NFS, NT 9/15-10/15 Test Lab MS Mouse, MS Kbd, VGA Mon, Quantum HD, IBM HD
System Test
MTBF Demonstration Vld Proto [4] Novell 10/17-1/17 Engr. Lab MS Mouse, MS Kbd, VGA Mon, MUX
Functionality Vld Proto [2] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, MS Kbd, VGA Mon, USB Mouse, USB Mon, USB Kbd, USR Mdm, Epson Prn, ISDN T. Adptr
Stress, Capacity, Volume Vld Proto [1] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, VGA Mon
Performance Vld Proto [1] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, MS Kbd, VGA Mon, Quantum HD, IBM HD
Compatibility Vld Proto [3] N/A 10/24-12/1 System Cookers MS Mouse [3], MS Kbd [3], VGA Mon [3]
Environmental Vld Proto [2] N/A 10/24-12/1 System Cookers MS Mouse [2], MS Kbd [2], VGA Mon [2]
Contoh Alokasi dari Hardware
Resources/Key Participans
* Mengganti alat, system, software, hardware, jaringan dan sumber lain yang dibutuhkan.
* Menemukan beberapa overlap dengan bagian rencana yang mencakup test organisasi.
Tracking and management of Test and Bugs
* System membantu melacak dan menangani test execution dan bug yang ditemukan sebelum proses.
* Test tracking mengacu pada daftar yang digunakan untuk menangani semua test case dalam test dan cara meningkatkan dokumen pada pendaftaran (listing).
Bug Isolation and Classification
* Test plan harus menjelaskan tingkatan perencanaan isolasi bug dan metode yang digunakan pada klasifikasi bug report.
* Isolasi bug report berarti percobaan dengan system undertest dengan upaya menemukan variable yang dihubungkan, causal dan hal lainnya.
* Klasifikasi bug report yaitu :
• Requirement Failure, bug report tentang kesalahan system pada persyaratan.
• Nonrequirement Failure, bug report tidak dipenuhi oleh system requirement, tetapi mencegah kegunaan system.
• Waiver Requested, bug report memang memberikan kesalahan, tetapi developer meminta waiver karena mereka percaya bahwa masalah tidak akan mencegah kegunaan system.
• External Failure, alamat bug report salah dibangun dari factor atau factor eksternal atau dibawah control system penanganan test.
• Internal Failure, developer percaya bahwa test dikembalikan dalam keadaan invalid error.
Release Management
* Komponen software atau hardware baru harus mempunyai nomor revisi atau melampirkan identifikasi.
* Harus ada perhitungan pada penerimaan release baru dalam format yang pasti.
* Menunjukkan tiap fase test, proses khusus dan format pengiriman release baru.
* Software dan hardware akan menerima revisi baru dari pertengahan siklus test.
Test Cycles
* Test cycle biasanya berhubungan dengan release dari system undertest, misalnya membangun sebuah software atau motherboard.
* Tiap-tiap bagian dari siklus biasanya melibatkan release baru dari satu atau lebih komponen dalam system.
* Bagian dari perencanaan test sebaiknya dikeluarkan dengan asumsi yang khusus.
II.4. 11. Risk And Contingencies
Adanya penambahan perkembangan pendukung untuk debugging jika nomor yang diterima dari bug ditemukan.
Memasukkan suatu informasi ketika mendiskusikan penundaan criteria.
II.4.12. Change History
Bagian perubahan dokumen record dan revisi dibuat untuk perencanaan test.
Menandai nomor revisi dan record dari pembuat perubahan, apa yang telah diubah dan kapan revisi telah direlease.
II.4.13. Referenced Docoment
Sebagai suatu aturan, perencanaan dari test yang ditunjukkan pada dokumen lain seperti spesifikasi, persyaratan, susunan test, beberapa dokumen analisis, dan kegunaan informasi lainnya.
II.5. Selling The Plan
Menggunakan pendekatan pengambilan sebuah formal sign_off sheet pada perencanaan atau pendekatan yang memiliki rapat ulang dengan semua manajer yang terlibat.
Menyediakan extra hard copy dari perencanaan untuk audience yang pelupa.
Setelah review, membuat permintaan perubahan pada dokumen dan mensirkulasikannya lagi yang ditandai dengan “Release Execution” atau “Release 1.0”.
II. 1. Alasan menulis test plan yaitu :
Usaha yang dibutuhkan dalam test proyek
Memberikan budget
Sebagai sumber komitmen dan jadwal
Penjelasan dalam mengatur test proyek
Perbedaan antara test plan dan test suite adalah pada soal perbedaan strategi dengan taktik.
Strategi terdiri dari seluruh rencana untuk mencari dan mengidentifikasikan sebanyak mungkin bug-bug yang ada
Taktik merupakan langkah spesifik yang bisa kita ambil untuk melakukan test pengujian.
II.2. Macam/Jenis Test Plan
Different time periods.
* Jika perkembangan test dan eksekusi test untuk subproject awal dan akhir pada perbedaan tanggal
* Informasi dibutuhkan pada rencana subproject yang lebih awal sebelum informasi pada subproject berikutnya.
Different Methodologis.
* Diskusi yang rinci dari pengubahan kode rata-rata
* Platform yang bebas diotomatiskan dengan alat tes GUI yang tidak bekerja bersamaan.
Different Objectives
* Menyelesaikan 3 tujuan yang berbeda
* Tujuan tersebut yaitu
• Mencari bug-bug dalam unit fungsi
• Mengetes integrasi dari unit fungsi dan
• Mengecek fungsi bisnis dari integrasi keseluruhan.
Different Audiences
* Test plan tidak hanya memberitahukan pada teman, penguji dan manajer dari visi, itu hanya kesempatan untuk menemukan kesempurnaan.
* Input ini khususnya berguna untuk memberikan ide bagaimana fokus pada test.
II.3. Penggunaan draft untuk menstimulasi diskusi
Menggunakan penyangga pada perencanaan untuk mengindikasi pertanyaan dan membuka persoalan.
Menggunakan “Copping Out”, identifikasi dan dokumentasi untuk membuka persoalan, lebih digunakan pada aspek perencanaan latihan.
Menggunakan beberapa perkiraan waktu tentang masalah yang timbul.
Test plan terdiri dari notasi yang luas dengan masalah yang dapat diputuskan atau persoalan yang menunggu resolusi.
II.4. Test Plan Tempelete
Model yang digunakan bagi pengembangan test plan.
Model ini bukan merupakan alat pemotongan dan penyalinan suatu test plan dalam waktu yang singkat.
Suatu kumpulan rancangan logis dari topik-topik yang perlu dipertimbangkan dengan hati-hati dalam pengujian.
II.4.1. Overview
Bagian keseluruhan dari sebuah test plan memungkinkan untuk memperkenalkan rencana pendekatan test.
Menampilkan sebuah penjelasan yang jelas dari sasaran-sasaran, metodologi, dan tujuan-tujuan .
II.4.2. Bound, (mengatur batasan-batasan perencanaan test )
Mendiskusikan apa yang akan atau tidak akan diujikan.
Mendefinisikan istilah-istilah dan akronim (lawan kata) yang penting yang berhubungan dengan ujian.
Menentukan dimana usaha-usaha tes yang berhubungan dengan pelaksanaan proyek pendukung test ini.
II.4.3. Scope
Bila ingin menjelaskan secara terperinci ruang lingkup dari proyek, maka harus menggambar batasan yang memisahkan antara apa saja yang akan diperhatikan selama pelaksanaan proyek.
Contoh Test Plan Tempelete
Menggunakan tabel “Ya/Tidak” untuk mendefinisikan ruang lingkup pengetesan.
II.4.4. Definisi
Tabel dapat membantu memperjelas istilah/terminologi bagi yang tidak berpengalaman dalam bidang testing.
Membantu memastikan bahwa setiap orang dalam kelompok penguji bekerja dengan menggunakan kumpulan definisi yang sama.
II.4.5. Setting
Bagian rencana test menjelaskan keinginan untuk melakukan testing, dan penjelasan tersebut sangat sederhana.
Adanya pertimbangan untuk menampilkan tabel yang menunjukkan bagaimana pekerjaan yang akan dialokasikan.
Misalnya : laboratorium test.
II.4.6. Quality Risk
Menyimpan hasil proses test plan dalam bentuk referensi.
Bila user ingin membaca outline kualitas resiko proses test plan atau diagram FMEA.
II.4.7. Proposed Schedule of Miliestones
Rencana harus terdiri dari jadwal kegiatan yang akan dilakukan pada test proyek.
Difokuskan pada kegiatan yang mempunyai level tinggi dan pengiriman yang visible pada manajemen.
Misalnya : jadwal untuk Speedy Writer.
Milestone/effort Date
Test Deveolopment and Configurations
Test Plan Complete 8/9/2003
Test Lab Defined 8/12/2003
Test Lab Configured 8/26/2003
FMEA Complete 8/16/2003
Test Suite Complete 9/5/2003
Test Execution
System test entry 9/2/2003
Cycle 1 9/2/2003 - 9/16/2003
Cycle 2 9/19/2003 - 10/3/2003
Cycle 3 10/6/2003 - 10/13/2003
System test exit 10/13/2003
Skedul Test Sistem milestones
II.4.8. Transitions
Untuk tiap fase, system dibawah test harus memenuhi minimal 1 set kualifikasi sebelum test organisasi mendapat keuntungan dalam test execution.
Bagian test plan harus menunjukkan criteria yang esensial untuk permulaan dan kelengkapan fase test yang berbeda.
Ada 3 set criteria yang biasa digunakan yaitu : Entry, Exit, Stopping criteria.
* Entry Criteria, Kriteria masukan memungkinkan system untuk pindah kedalam fase test khusus. Ada beberapa alamat pertanyaan dalam criteria ini yaitu :
• Apakah perlu ada dokumentasi, spesifikasi, dan syarat yang memungkinkan tester mengoperasikan system dan menilai kebenaran reaksi?
• Apakah system siap untuk pengiriman dan bentuk apa saja yang cocok untuk pertanyaan fase test?
• Apa ada kegunaan dukungan, aksesoris, dan prasyarat dalam bentuk tester yang digunakan?
• Apa system pada mutu level cocok? Tiap pertanyaan biasanya mengimplementasi beberapa atau semua fase test yang telah diselesaikan dengan sukses.
• Apa test environment_lab, hardware,software, dan system pendukung administrasi siap?
* Stopping criteria
• Kriteria penundaan memberikan kondisi atau event yang menunda test execution.
• Contohnya : test environment menjadi tidak siap, system mempunyai banyak bug, tidak bisa melanjutkan testing.
* Exit criteria, alamat criteria keluaran menunjukkan bagaimana menentukan kapan testing telah selesai dan lengkap.
II.4.9. Test Configurations & Environments
Dokumen dimana hardware, software dan jaringan dan ruang lab akan menggunakan pekerjaan testing.
Untuk aplikasi PC atau kegunaannya, task ini dapat menyederhanakan hardware maupun software dari waktu ke waktu.
Sistem testing dengan element hardware yang signifikan (laptop baru atau server), 1 dengan banyak elemen hardware (jaringan system operasi atau jaringan aplikasi), atau 1 dengan elemen hardware yang mahal (mainframe, server cluster).
Membentuk skema untuk alokasi hardware dalam sebagian lokasi, bagian test plan, atau pemisahan dokumen.
II.4.10. Test Execution
Alamat test plan merupakan factor yang penting untuk mempengaruhi test execution.
Menjalankan test cycle yang berbeda dalam tiap fase test.
Dalam menjalankan test, kita dapat mengumpulkan data dan melacak dengan cara memperlihatkan pada team dan manajer.
Test Usage System Network When Where Other
Product Test
Component Interfaces/ Signal Quality Engr Proto [2] Novell, NFS, NT 9/15-10/15 Engr. Lab MS Mouse, MS Kbd, VGA Mon, USB Mouse, USB Mon, USB Kbd, 3COM LAN, USR Mdm, Epson Prn, Quantum HD, Oscilloscope
Mechanical Life Engr Proto [2] None 8/1-10/1 Engr. Lab None
Stress, Capacity, Volume Engr Proto [1] Novell, NFS, NT 9/15-10/15 Test Lab MS Mouse, VGA Mon
Performance Engr Proto [1] Novell, NFS, NT 9/15-10/15 Test Lab MS Mouse, MS Kbd, VGA Mon, Quantum HD, IBM HD
System Test
MTBF Demonstration Vld Proto [4] Novell 10/17-1/17 Engr. Lab MS Mouse, MS Kbd, VGA Mon, MUX
Functionality Vld Proto [2] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, MS Kbd, VGA Mon, USB Mouse, USB Mon, USB Kbd, USR Mdm, Epson Prn, ISDN T. Adptr
Stress, Capacity, Volume Vld Proto [1] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, VGA Mon
Performance Vld Proto [1] Novell, NFS, NT 10/17-12/1 Test Lab MS Mouse, MS Kbd, VGA Mon, Quantum HD, IBM HD
Compatibility Vld Proto [3] N/A 10/24-12/1 System Cookers MS Mouse [3], MS Kbd [3], VGA Mon [3]
Environmental Vld Proto [2] N/A 10/24-12/1 System Cookers MS Mouse [2], MS Kbd [2], VGA Mon [2]
Contoh Alokasi dari Hardware
Resources/Key Participans
* Mengganti alat, system, software, hardware, jaringan dan sumber lain yang dibutuhkan.
* Menemukan beberapa overlap dengan bagian rencana yang mencakup test organisasi.
Tracking and management of Test and Bugs
* System membantu melacak dan menangani test execution dan bug yang ditemukan sebelum proses.
* Test tracking mengacu pada daftar yang digunakan untuk menangani semua test case dalam test dan cara meningkatkan dokumen pada pendaftaran (listing).
Bug Isolation and Classification
* Test plan harus menjelaskan tingkatan perencanaan isolasi bug dan metode yang digunakan pada klasifikasi bug report.
* Isolasi bug report berarti percobaan dengan system undertest dengan upaya menemukan variable yang dihubungkan, causal dan hal lainnya.
* Klasifikasi bug report yaitu :
• Requirement Failure, bug report tentang kesalahan system pada persyaratan.
• Nonrequirement Failure, bug report tidak dipenuhi oleh system requirement, tetapi mencegah kegunaan system.
• Waiver Requested, bug report memang memberikan kesalahan, tetapi developer meminta waiver karena mereka percaya bahwa masalah tidak akan mencegah kegunaan system.
• External Failure, alamat bug report salah dibangun dari factor atau factor eksternal atau dibawah control system penanganan test.
• Internal Failure, developer percaya bahwa test dikembalikan dalam keadaan invalid error.
Release Management
* Komponen software atau hardware baru harus mempunyai nomor revisi atau melampirkan identifikasi.
* Harus ada perhitungan pada penerimaan release baru dalam format yang pasti.
* Menunjukkan tiap fase test, proses khusus dan format pengiriman release baru.
* Software dan hardware akan menerima revisi baru dari pertengahan siklus test.
Test Cycles
* Test cycle biasanya berhubungan dengan release dari system undertest, misalnya membangun sebuah software atau motherboard.
* Tiap-tiap bagian dari siklus biasanya melibatkan release baru dari satu atau lebih komponen dalam system.
* Bagian dari perencanaan test sebaiknya dikeluarkan dengan asumsi yang khusus.
II.4. 11. Risk And Contingencies
Adanya penambahan perkembangan pendukung untuk debugging jika nomor yang diterima dari bug ditemukan.
Memasukkan suatu informasi ketika mendiskusikan penundaan criteria.
II.4.12. Change History
Bagian perubahan dokumen record dan revisi dibuat untuk perencanaan test.
Menandai nomor revisi dan record dari pembuat perubahan, apa yang telah diubah dan kapan revisi telah direlease.
II.4.13. Referenced Docoment
Sebagai suatu aturan, perencanaan dari test yang ditunjukkan pada dokumen lain seperti spesifikasi, persyaratan, susunan test, beberapa dokumen analisis, dan kegunaan informasi lainnya.
II.5. Selling The Plan
Menggunakan pendekatan pengambilan sebuah formal sign_off sheet pada perencanaan atau pendekatan yang memiliki rapat ulang dengan semua manajer yang terlibat.
Menyediakan extra hard copy dari perencanaan untuk audience yang pelupa.
Setelah review, membuat permintaan perubahan pada dokumen dan mensirkulasikannya lagi yang ditandai dengan “Release Execution” atau “Release 1.0”.
TESTING
I. Dasar-Dasar Testing Sistem
I.1. Extended Test Effort
I.1.1.Test Granularity
Test Granularity
a. White Box (Structural) Testing
Disebut juga structural test, glass box test, code based test, dan design based test.
Menemukan bug dalam low level operations, Chips, subassemblies dan interfaces
Didasarkan pada bagaimana suatu sistem beroperasi dan cenderung mengenali dengan sederhana bug yang terisolasi.
Software, test ini dikembangkan dengan melihat kode dan struktrur datanya.
Hardware, membandingkan spesifikasi chip pada pembacaan di oscilloscope atau Volt Meter.
b. Black Box (Behavioral) Testing
Disebut juga behavioral test, sering digunakan untuk menemukan bug dalam high level operations, profil operasional dan customer scenarios.
Didasarkan pada apa yang sistem harus lakukan.
Fokusnya adalah keadaan external dari sistim ketika ditest.
c. Live Test
Meliputi customer ketika suatu software atau hardware diperkenalkan dengan harapan akan menemukan kesalahan bila digunakan oleh user, contohnya Beta testing.
Test ini merupakan perilaku yang lengkap dari sistem, karena user hanya mememperhatikan tentang apa yang sistim lakukan bukan bagaimana sistim program melakukannya.
Fokusnya kesalahan yang diperoleh dari pengalaman.
Test ini bentuk yang semprna untuk technical support, marketing, dan sales peusahaan, dimana orang-orang tersebut tidak mengetahui teknik test tetapi mengetahui produk dengan baik sekali.
I.1.2. Test Execution Phases
Unit Testing, meliputi pengetesan bagian dari kode yang ukurannya tidak ditentukan batasnya dalam praktek tetapi umumnya fungsi atau subroutine.
Integration Testing, pengetasan yang menemukan bug dalam hubungannya dan interface antara komponen dan grup komponen dari sistim ketika ditest.
Fuction Testing, pengetesan dari fungsi spesifikasi software atau hardware ketika dieksekusi
System Testing, Pengetesan mengunakan keseluruhan sistem untuk menemukan bug dalam variasi operasi sistem.
Acceptance Testing, Pengetesan yang menemukan kebutuhan dari sistem ketika ditest.
I.1.2.1. Tahapan Pengetesan
Tahap-Tahap Pengetesan
I.1.2.2. Alasan Phases Test Approach
Structural testing membangun produk menjadi stabil.
Structural testing memulai dengan membagi-bagi menjadi bagian-bagian sehingga memudahkan test.
Dapat mendeteksi bug lebih efisien
Dapat membandingkan metrik dari proyek dengan standar industri.
Menambah kepercayaan dan keyakinan terhadap produk secara psikologis
I.2. Kualitas Sistem
Biasanya menentukan kualitas sistem dilihat dari bug yang dapat ditemukan dalam suatu program, tetapi untuk menemukan bug juga tidak mudah.
Bisa saja suatu program pada saat dilakukan pengetesan tidak ditemukan bug, dan ternyata setelah digunakan banyak bug yang keluar.
Hal ini dapat terjadi bila cara pengetesan sistem kurang baik.
Sehingga dapat disimpulkan bahwa belum tentu pada saat dilakukan test bug tidak ditemukan berarti sistem tersebut sudah baik, ini tergantung juga pada cara pengetesan, maka cara pengetesan merupakan faktor yang sangat penting dalam melakukan sistem testing
High-fidelity test system
Low-fidelity test system
I.2.1 Karakteristik Kualitas software pada ISO 9126
a. Functionality, Kemampuan Software untuk memenuhi ketetapan dari kebutuhan tidak langsung user
Suitability, kemampuan Software untuk menyediakan sekumpulan fungsi dimana ketepatan tugas (task) tertentu dibuat oleh User
Accuracy, kemampuan Software untuk menyediakan kebenaran atau kesepakatan hasil atau efeknya
Interoperability, kemampuan Software untuk berinteraksi dengan sistem tertentu yang lain
Compliance, kemampuan Software untuk mengikuti standar yang berhubungan, perjanjian, regulasi, hukum dan aturan yang hampir sama
Security, kemampuan Software untuk melindungi akses yang tidak sah, walau sengaja atau tidak sengaja pada program dan data
b. Reliability, Kemampuan Software untuk memaintain tingkatan kinerjanya untuk waktu tertentu
Maturity, atribut Software yang dihubungkan pada frekuensi kegagalan dari kelemahan software
Fault Tolerance, kemampuan Software memaintain tingkatan kinerja tertentu pada kasus kelemahan software atau kesalahan pengunaan dari interface tertentu
Recoverability, kapabilitas Software untuk kembali pada tingkatan kinerjanya dan memperbaiki data secara langsung akibat kasus kerusakan tersebut
c. Usability, Atribut Software yang berhubungan dengan jumlah kebutuhan penggunaannya
Understanability, atribut Software yang berhubungan dengan kebutuhan user untuk mengerti dasar logika konsep software
Learnability, atribut Software yang berhubungan dengan kebutuhan user untuk untuk belajar aplikasi software
Operability, atribut Software yang berhubungan dengan kebutuhan user untuk operasi dan kontrol software
d. Efficiency, Hubungan antara tingkatan kinerja software dangan jumlah sumber daya yang digunakan
Time Behaviour, atribut Software yang berhubungan dengan respon software, waktu proses, dan throughput ketika kinerja fungsinya berjalan
Resource Behaviour, atribut Software yang berhubungan dengan jumlah sumber daya yang digunakan software dan durasi penggunaan kinerja fungsinya berjalan
e. Maintainability, Kemampuan Software untuk dibuat modifikasi tertentu
Analysability, atribut Software yang berhubungan dengan kebutuhan kurangnya diagnosa, menyebabkan kegagalan identifikasi bagian yang dimodifikasi
Changeabilty, atribut Software yang berhubungan dengan kebutuhan modifikasi, penghilanag kerusakan atau perubahan lingkungan software
Stability, atribut Software yang berhubungan resiko yang tidak diduga dari efek modifikasi
Testability, atribut Software yang mempengaruhi untuk testing setelah modifikasi
f. Portability, Kemampuan Software ditranfer dari satu lingkungan kelainnya
Adaptability, kemampuan Software beradaptasi pada lingkungan tertentu yang berbeda
Installability, atribut Software yang berhubungan jumlah kebutuhan install software pada lingkungan tertentu
Conformance, kemampuan Software mengikuti standar atau perjanjian yang berhubungan dengan portability
Replaceability, kemampuan Software diganti dengan potongan/bagian software yang lain
Software Quality Level
I.2.2. Metoda Dalam Kualitas Resiko
I.2.2.1. Metoda Informal Penilaian Kualitas Resiko
Penilaian ini berdasakan pada prioritas user, sehingga metoda yang digunakan menjadi informal
Untuk mengembangkan kategori utama, maka tahapan test di bagi manjadi Component Testing, Integration Testing, System Testing dan Acceptance Testing
a. Component Testing
a1. State
Pada beberapa kompter khususnya sitem Telephony, komponen atau sekumpulan computer melaksanakan sesuatu yang disebut oleh ilmu computer sebg state machine.
Secara informal state machine adalah suatu sistem yang menggerakkan/memindahkan suatu kondisi menjadi kondisi lain bila respon (diasosiasikan sbg output dan state berikutnya) pd suatu input bergantung pada state saat ini dan input.
State machines menyajikan suatu variasi dari kualitas resiko yang dihubungkan dengan State machines kesemua dan atau individu states.
* Apakah transisi dari suatu ke yang lainnya terjadi pada kondisi yang lebih baik ?
* Apakah output yang dihasilkan memiliki kebenaran ?
* Apakah input yang diterima utuk setiap atate memiliki kebenaran ?
a.2. Transactions
Komponen mempunyai transaksi dengan user atau dengan komponen lainnya memiliki/menghadirkan variasi resiko mis : Dalam mengcreate file baru ? ; Apakah ada file tempelete ?; Bagaimana produk merespon file ilegal ?
a.3. Code Coverage
Struktur pola dasar resiko sangat memperhatikan keberadaan untested code componen.
Area ini sering menghandel/ menyebabkan kondisi yang tidak dinamis mis pada over temp critical condition, seharusnya test tersebut merusak konfigurasi test, tetapi bagaimana jika sistem mati pada saat kejadian berlangsung.
a.4. Data Flow Coverage
Merupakan transfer data melalui parameter lingkungan data global atau penyimpanan DB dari suatu komponen kelainnya.
Pertambahan program untuk import, export, link data dari lain program mengcreate Data Flow yang komplek.
User kadang-kadang menganggap hal ini aneh.
a.5. Functionality
Setiap komponen melaksanakan beberapa fungsi untuk operasi internal spt kalkulasi, formating.
Kualitas resiko secara fungsional pada umumnya mempunyai 2 tipe :
* Fungsi yang dilaksanakan tidak benar
* Terdapat bagian fungsi yang bekerja tidak benar/ kuang benar.
a.6. User interface
Kualitas resiko untuk area ini hampir sama dengan functionality, tetapi area ini juga memasukan pertanyaan yang meliputi pemakaian promps dan massage yang dimengerti, aliran kontrol, ketepatan warna skema dan grafik.
Selama phase componen test, user interface testing meliputi prototipe interface atau penggunaan perbagian. Pengujian tidak harus menguji keseluruhan interface tetapi tiap screen dibuat maket/contoh.
a.7. Mechanical live
Setiap objek yang dapat difleksibelkan atau digerakan oleh keterbatasan pada sejumlah gerakan yang dikerjakan/ditanggung, misalnya : Keyboard break, contacks fail, pemasangan cracks dan lain sebagainya.
a.8. Signal Quality
Setiap sirkuit yang memproses data apakah itu digital ataupun analog akan dibatasi oleh kualitas input signal mis adanya noise.
b. Integration Testing
b.1. Component atau Subsystem Interfaces
Setiap fungsi, bus, konektor memungkinkan terjadinya kesalahfahaman antara dua atau lebih komponen untuk teknik pengembangannya, kesalahaman ini terjadi dengan sendirinya bila dua komponen membenarkan suatu kesalahan bersama.
b.2. Functionality
Fokusnya pada fungsional yang membutuhkan kebenaran operasi pada dua atau lebih komponen dari aliran data antara komponen.
b.3. Kapasitas dan volume
Kapasitas (statik ) dan volume (dinamik) dari pipa harus matching dengan kebutuhan aplikasi dan harapan user, dimana makin besar lingkungan (jaringannya) makin banyak variasi resikonya.
b.4. Penanganan Kesalahan dan Recover
Tidak aada yang meramalkan dengan pasti kesalahan yang akan terjadi, tetapi dengan menggunakan integration test kesalahan yang umum terjadi dapat ditangani lebih awal.
b.5. Data Quality
Jika suatu produk stores, retrives dan shared significant amount of data, khususnya yang memiliki link yang sulit, relationshipnya dan integritas data, seharusnya dipertimbangkan untuk ditest walaupun produk penanganan datanya dapat dipercaya. Misalnya pada penggunaan spreedsheet.
b.6. Performance/kinereja
Seperti pada kapasitas dan volume, performance perhatiannya berlaku pada banyaknya subsistem dan komponen dalan suatu produk
b.7. User Interface
Bila functionality diintegrasikan ke sistem seharusnya test melalui user interface, jika menggunakan prototipe ini merupakan suatu option.
c. System Testing & Acceptance Testing
c.1. Functionality
Selama test system seharusnya mempertimbangkan functionality dalam bentuk semua urutan
c.2. User Interface
Testing dapat difokuskan pada penghilangan prilaku menggangu yang muncul setiapkali dikoneksi dengan interface.
Penggunaan prototipe adalah langkah terbaik.
Pada system test pertama kali akan terlihat kelengkapan user interface dengan semua perintah dan aksi yang didapat
c.3. States
State machines dapat eksis pada tingkatan sistem sebagaimana tingkatan komponen, misalnya pada voice mail system.
c.4. Transaction
Transaksi akan terjadi untuk print file, pengiriman file dan lain-lain.
c.5. Data Quality
Selama tahapan test system resiko kualitas data yang awalnya di kover oleh test integration harus direvisi ulang, karena kekomplesitasan dari data sering meningkat setiap kali produk diintegrasikan
c.6. Operations
Sistem yang komplek spt database dan server sering membutuhkan administrator. Operasi ini membuat pekerjaan maintenance penting kadang-kadang mejadi pekerjaan off line mis backup file dan restore file atau juga migrasi dari satu sistem operasi ke sistem operasi yang lain.
c.7. Capacity & Volume
Seharusnya kapasitas dan volume direvisi ulang walaupun telah telah dikover oleh integrations test, tetapi pendekatan yang digunakan adalah black box test.
c.8. Reliability & Stability
Resiko kualitas pada area ini termasuk dapat menerima failure rates (mean time between failures atau MTBF), tidak dapat menerima recovery time (mean time to repair atau MTTR), dan ketidak mamapuan sistem untuk berfungsi pada kondisi yang legiminate tanpa kesalahan.
c.9. Error/Disaster handling & Recovery
Seperti juga untuk kapasitas dan volume perlu direvisi ulang terutama untuk external failure.
c.10. Stress
Gabungan dari tiga diatas (Capacity &Volume; Reliability & Stability; Error/Disaster handling & Recovery)
c.11. Performance
Revisi ulang dari Integration Test, tetapi lebih difokuskan pada pendekatan prilaku.
c.12. Date & Time Handling
Penggunaan waktu yang berbeda dari beberapa zone, pengukuran atau aturan tanpa menggunaan waktu standard akan mempengaruhi kualitas resiko.
c.13. Localization
Masalah lokasi diasosiasikan dalam penggunaan huruf/bahasa misal untuk keyboard, dilain hal untuk hardware masalah voltage, dialtone telepon.
c.14. Networked & Distribution Enviroments
Bila produk dipakai pada lingkungan yang berbeda akan menimbul;kan resiko kualitas misal untuk standard waktu apakh waktu internasional atau bukan ? sebab jika berkomunikasi secara international akan mempengaruhi standard telephone.
c.15. Configuration Options & Compatibility
Variasi sw, hw dan jaringan yang membingungkan dapat mengcreate problem pada sitem, mis apakh driver cocok atau tidak ?
c.16. Standards Complaince
Bug yang tidak berbahaya dihubungkan pada standard tidak menimbulkan reaksi sehingga produk secara legal dan efektif tidak terhalang dipasaran
c.17. Security
Merupakan pengetesan dalam penulisan pasword, pengupdatean, pengcopian dll
Bilamana implementasi keamanan merupakan ciri-ciri utama dari suatu dan hal tersebut tidak hanya untuk semua produk perlu ada pengetesan
c.18. Enviroment
Setiap produk memiliki resiko terhadap lingkungan, mis temperatur, kelembaban, debu, jamur dll.
c.19. Power Input, Consumption & Output.
Semua komputer membutuhkan atau berada dalam lingkungan gelombang elektrik, perubahan dalam hal tersebut menyebabkan panas atau radiasi elektro magnetik dan mempengaruhi baik langsung maupun tidak langsung terhadap kerusakan device (komponen).
c.20. Shock, Vibration & Drop
Pada saat ini banyak komputer yang moveable, yakni dapat dipindah-pindahkan, akibatnya komputer tersebut akan mengalami, goncangan, vibrasi dan jatuh (kadang-kadang)
Test sistem pada phase ini akan menemukan apakh sistem berubah setelah mengalami hukum grafitasi.
c.21. Instalation, Cut Over, SETUP & Initial Configuration
Setiap produk akan mengalami pemakaian awal
Apakah proses instalasi bekerja ?
Dapatkah data bermigrasi dari sistem lama ?
Pada multiuser situasi, konfigurasi termasuk juga membuat kreasi user account dan Bagaimana jika user ingin mengunistall program ?
c.22. Documentation & Packaging
Kesalahan tidak perlu terjadi mungkin dapat terjadi misalnya memasng 100v pada 220 V, termasuk vibrasi, shock dan drop.
c.23. Maintainability
Setiap sistem yang terlampau sederhana untuk kebutuhan operatornya akan memungkinkan terjadinya resiko kesalahan pada perwatannya, mis : dapatkah mengupgrade software atau menambah memory ?
c.24. Beta
Setiap produk secara umum baik sw atau hw tidak ada yang sebaik untuk penggunaan dan lingkungan user sendiri, untuk itu perlu mempertimbangkan dalam bentuk beta testing atau release program dalam bentuk pertama, kedua dan seterusnya.
Pengecekan dan Kelengkapan Metoda Informal
* Membuat daftar :
• Resiko tidak penting dan user tidak perhatian
• Resiko tidak kritis tapi user sangat memperhatikan
* Membuat Pembanding dengan team
* Masukan dari Internal Experts
* Masukan dari Sumber External
* Usulan dari Kualitas Resiko (Lihat Contoh pada buku referensi)
Contoh Analisis Kualitas Resiko Informal untuk Hypothetical Word Processor
I.2.2.3. Metoda Formal Untuk Pengertian Kualitas Resiko
Pengujian dengan menggunakan teknik lebih formal untuk mendefinisikan kualitas risk
Pendekatan ini dapat memetakan kebutuhan, spesifikasi, dan asumsi team proyek yang diinputkan kedalam kualitas resiko spesifik dan efeknya
Pendekatan dapat merangking resiko menurut prioritasnya dan memperbaikinya dalam perintah selanjutnya
Pendekatan ini menggunakan Failure Mode and Effect Analysis (FMEA), yaitu merupakan pendekatan formal untuk pemetaan kebutuhan, spesifikasi dan asumsi tim proyek kedalam spesifik quality risk.
Contoh FMEA untuk Hypothetical File Server
System Function or Feature
Analisis fungsi sistem dimulai dari sini, dalam melakukan breakdown deskripsi dari fungsi sistem yang akan dianalisis bila terlampau detil akan sulit dibaca sedangkan bila terlampau sedikit akan sulit mengetahui failure ada pada fungsi yang mana
Potential Failure Mode(s) – Quality Risk(s)
* Pada kolom ini terdapat fungsi yang spesifik atau ciri-cirinya tetapi bukan kategorinya.
* Pada kolom ini entrynya seharusnya sudah menemukan suatu failure.
* Quality risk diasosiasikan dengan kehilangan fungsi sistem yang spesifik.
* Tiap spesifik fungsi atau ciri-cirinya dapat mempunyai banyak mode failure.
Potential effect of failure
Tiap failure mode dapat memberikan efek pada user dari berbagai hal, oleh sebab itu sebaiknya input dalam bentuk umum lebih baik daripada dalam bentuk antisipasi terhadap kemungkinannya.
Critical
Pada kolom ini diisi ya atau tidak, dimana potential effect akan memberikan/mempunyai konsekuensi yang kritis bagi user.
Severity (kerumitan)
* Kolom ini merupakan kerumitan yang absolut dari mode failure dalam pertanyaan, mengabaikan segala kemungkinan.
* Digunakan suatu skala dari 1 s/d 5, yaitu :
1. Kehilangan data atau problem keamanan.
2. Kehilangan fungsi tanpa workaround
3. Kehilangan fungsi dengan workaround
4. Kehilangan sebagian fungsi
5. Hal-hal yang kecil.
* Workaround, suatu langkah untuk menghindari bug tanpa memperbaikinya.
Potential Cause(s) of failure
Kolom ini merupakan daftar dari triger failure mis: OS error, dll.
Priority
* Priotitas menilai bagaimana keburukan dari mode failure akan mempengaruhi kemampuan suatu perusahaan untuk memasarkan produk tersebut selama siklus hidup pengembangan (SDLC), dengan asumsi bahwa akan dikeluarkan versi release terbaru.
* Skala yang digunakan 1 s/d 5
* Input yang diterima dari umumnya dari Sales Marketing atau Technical Support.
Dectections Method(s)
* Kolom ini merupakan metoda yang ada atau prosedur untuk mendeteksi seperti aktifitas pengembangan atau vendor testing.
* Deteksi ini diharapkan dapat menemukan problem sebelum mempengaruhi use, diluar setiap test yang dilakukan.
Dectections
* Angka pada kolom ini mempresentasikan kemungkinan dari metode deteksi yang ada pada kolom sebelumnya.
* Bila metoda deteksi yang digunakan yakin (atau memiliki keyakinan) untuk memperoleh failure model, maka kolom mengidentifikasikan resiko rendah, begitu juga sebaliknya.
* Digunakan skala 1 s/d 5
RPN (Risk Priority Number)
* Kolom ini akan menunjukan bagaimana pentingnya untuk mentest failure mode secara khusus.
* RPN dihasilkan dari perkalian antara severity, priority value dan detecttion value, oleh sebab itu hasil perkaliannya antara 1 s/d 125.
Recommended Action
* Kolom ini mengandung satu atau lebih tindakan yang sederhana untuk menaikan resiko prioritas (dalam artian membuat lebih sederhana).
* Untuk mentest, kebanyakan recommended action melibatkan suatu test case yang mempengaruhi pengamanan deteksi.
Who/When ?
Kolom ini mengindikasikan siapa yang bertanggung jawab untuk setiap recommeded action dan kapan (phase test) dia bertanggung jawab.
References
Kolom ini menampilkan referensi untuk informasi yang lebih dalam tentang quality risk, biasanya hal ini meliputi spesifikasi produk, dokumen kebutuhan dll.
Action Result
Merupakan record pengaruh dari aksi yang diambilpada priority, severity, detection dan RPN, kolom ini digunakan setelah implementasi test bukan pada FMEA awal.
I.4. Schedule, Resources, & Budget
I.4.1. Cost, Schedule & Quality, ilustrasi gambar sebagai berikut :
Arah jarum jam menunjukkan perbaikan selama langkah planning.
Perbaikan ini merupakan balancing schedule, cost dan kualitas.
Ketika implmentasi dari test dimulai maka akan sulit untuk mengubah jadwal yang sudah ditetapkan, budget akan meningkat seperti diatas.
Dengan membatasi pada kotak (batas yang diinginkan) hubungan kualitas akan tampak pada garis ketiganya.
Cost, Schedule and Quality
I.4.2. Mencocokan Schedule test kedalam proyek
Pendekatan yang terbaik adalah pendekatan top down :
* Planning
* Configuration memperoleh hw dan sumber daya yang penting dan mentest lab
* Development, membangun test tools; mengcreate urutan test dan test case library; menempatkan laporan test tools pada tempatnya; dokumentasi bagaimana sistem bekerja.
* Test execution, running test; recording status test dan melaporkan hasilnya.
Kendala yang dihadapi terhadap pendekatan ini antara lain :
* Mahalnya sumber daya
* Lamanya waktu/operasional penggunaan, untuk perangkat yang harus disewa.
* Kehilangan SDM
* Dll.
Sehingga harus dibuat draft jadwal sebagai berikut : miliestone (lihat gambar).
Contoh Milesstone Testing
I.4.3. Penentuan Sumber daya dan Pembuatan Budget
Staf
* Karyawan tetap
* Kontraktor
* Konsultan
Test tools
* Software, meliputi code coverage analyzers, low level diagnostics programs dll.
* Hardware, meliputi oscilloscopes, table goncangan dan getaran, dan peralatan lainnya.
Facilities & Overhead
* Biaya sewa
* Biaya transportasi
* Workstations
* dll.
Test systems
* Melputi hw & sw
* Prototipe
* dll.
External labs
* Penggunaan laboratorium eksternal
* Performance dari lokasi.
* dll
I.1. Extended Test Effort
I.1.1.Test Granularity
Test Granularity
a. White Box (Structural) Testing
Disebut juga structural test, glass box test, code based test, dan design based test.
Menemukan bug dalam low level operations, Chips, subassemblies dan interfaces
Didasarkan pada bagaimana suatu sistem beroperasi dan cenderung mengenali dengan sederhana bug yang terisolasi.
Software, test ini dikembangkan dengan melihat kode dan struktrur datanya.
Hardware, membandingkan spesifikasi chip pada pembacaan di oscilloscope atau Volt Meter.
b. Black Box (Behavioral) Testing
Disebut juga behavioral test, sering digunakan untuk menemukan bug dalam high level operations, profil operasional dan customer scenarios.
Didasarkan pada apa yang sistem harus lakukan.
Fokusnya adalah keadaan external dari sistim ketika ditest.
c. Live Test
Meliputi customer ketika suatu software atau hardware diperkenalkan dengan harapan akan menemukan kesalahan bila digunakan oleh user, contohnya Beta testing.
Test ini merupakan perilaku yang lengkap dari sistem, karena user hanya mememperhatikan tentang apa yang sistim lakukan bukan bagaimana sistim program melakukannya.
Fokusnya kesalahan yang diperoleh dari pengalaman.
Test ini bentuk yang semprna untuk technical support, marketing, dan sales peusahaan, dimana orang-orang tersebut tidak mengetahui teknik test tetapi mengetahui produk dengan baik sekali.
I.1.2. Test Execution Phases
Unit Testing, meliputi pengetesan bagian dari kode yang ukurannya tidak ditentukan batasnya dalam praktek tetapi umumnya fungsi atau subroutine.
Integration Testing, pengetasan yang menemukan bug dalam hubungannya dan interface antara komponen dan grup komponen dari sistim ketika ditest.
Fuction Testing, pengetesan dari fungsi spesifikasi software atau hardware ketika dieksekusi
System Testing, Pengetesan mengunakan keseluruhan sistem untuk menemukan bug dalam variasi operasi sistem.
Acceptance Testing, Pengetesan yang menemukan kebutuhan dari sistem ketika ditest.
I.1.2.1. Tahapan Pengetesan
Tahap-Tahap Pengetesan
I.1.2.2. Alasan Phases Test Approach
Structural testing membangun produk menjadi stabil.
Structural testing memulai dengan membagi-bagi menjadi bagian-bagian sehingga memudahkan test.
Dapat mendeteksi bug lebih efisien
Dapat membandingkan metrik dari proyek dengan standar industri.
Menambah kepercayaan dan keyakinan terhadap produk secara psikologis
I.2. Kualitas Sistem
Biasanya menentukan kualitas sistem dilihat dari bug yang dapat ditemukan dalam suatu program, tetapi untuk menemukan bug juga tidak mudah.
Bisa saja suatu program pada saat dilakukan pengetesan tidak ditemukan bug, dan ternyata setelah digunakan banyak bug yang keluar.
Hal ini dapat terjadi bila cara pengetesan sistem kurang baik.
Sehingga dapat disimpulkan bahwa belum tentu pada saat dilakukan test bug tidak ditemukan berarti sistem tersebut sudah baik, ini tergantung juga pada cara pengetesan, maka cara pengetesan merupakan faktor yang sangat penting dalam melakukan sistem testing
High-fidelity test system
Low-fidelity test system
I.2.1 Karakteristik Kualitas software pada ISO 9126
a. Functionality, Kemampuan Software untuk memenuhi ketetapan dari kebutuhan tidak langsung user
Suitability, kemampuan Software untuk menyediakan sekumpulan fungsi dimana ketepatan tugas (task) tertentu dibuat oleh User
Accuracy, kemampuan Software untuk menyediakan kebenaran atau kesepakatan hasil atau efeknya
Interoperability, kemampuan Software untuk berinteraksi dengan sistem tertentu yang lain
Compliance, kemampuan Software untuk mengikuti standar yang berhubungan, perjanjian, regulasi, hukum dan aturan yang hampir sama
Security, kemampuan Software untuk melindungi akses yang tidak sah, walau sengaja atau tidak sengaja pada program dan data
b. Reliability, Kemampuan Software untuk memaintain tingkatan kinerjanya untuk waktu tertentu
Maturity, atribut Software yang dihubungkan pada frekuensi kegagalan dari kelemahan software
Fault Tolerance, kemampuan Software memaintain tingkatan kinerja tertentu pada kasus kelemahan software atau kesalahan pengunaan dari interface tertentu
Recoverability, kapabilitas Software untuk kembali pada tingkatan kinerjanya dan memperbaiki data secara langsung akibat kasus kerusakan tersebut
c. Usability, Atribut Software yang berhubungan dengan jumlah kebutuhan penggunaannya
Understanability, atribut Software yang berhubungan dengan kebutuhan user untuk mengerti dasar logika konsep software
Learnability, atribut Software yang berhubungan dengan kebutuhan user untuk untuk belajar aplikasi software
Operability, atribut Software yang berhubungan dengan kebutuhan user untuk operasi dan kontrol software
d. Efficiency, Hubungan antara tingkatan kinerja software dangan jumlah sumber daya yang digunakan
Time Behaviour, atribut Software yang berhubungan dengan respon software, waktu proses, dan throughput ketika kinerja fungsinya berjalan
Resource Behaviour, atribut Software yang berhubungan dengan jumlah sumber daya yang digunakan software dan durasi penggunaan kinerja fungsinya berjalan
e. Maintainability, Kemampuan Software untuk dibuat modifikasi tertentu
Analysability, atribut Software yang berhubungan dengan kebutuhan kurangnya diagnosa, menyebabkan kegagalan identifikasi bagian yang dimodifikasi
Changeabilty, atribut Software yang berhubungan dengan kebutuhan modifikasi, penghilanag kerusakan atau perubahan lingkungan software
Stability, atribut Software yang berhubungan resiko yang tidak diduga dari efek modifikasi
Testability, atribut Software yang mempengaruhi untuk testing setelah modifikasi
f. Portability, Kemampuan Software ditranfer dari satu lingkungan kelainnya
Adaptability, kemampuan Software beradaptasi pada lingkungan tertentu yang berbeda
Installability, atribut Software yang berhubungan jumlah kebutuhan install software pada lingkungan tertentu
Conformance, kemampuan Software mengikuti standar atau perjanjian yang berhubungan dengan portability
Replaceability, kemampuan Software diganti dengan potongan/bagian software yang lain
Software Quality Level
I.2.2. Metoda Dalam Kualitas Resiko
I.2.2.1. Metoda Informal Penilaian Kualitas Resiko
Penilaian ini berdasakan pada prioritas user, sehingga metoda yang digunakan menjadi informal
Untuk mengembangkan kategori utama, maka tahapan test di bagi manjadi Component Testing, Integration Testing, System Testing dan Acceptance Testing
a. Component Testing
a1. State
Pada beberapa kompter khususnya sitem Telephony, komponen atau sekumpulan computer melaksanakan sesuatu yang disebut oleh ilmu computer sebg state machine.
Secara informal state machine adalah suatu sistem yang menggerakkan/memindahkan suatu kondisi menjadi kondisi lain bila respon (diasosiasikan sbg output dan state berikutnya) pd suatu input bergantung pada state saat ini dan input.
State machines menyajikan suatu variasi dari kualitas resiko yang dihubungkan dengan State machines kesemua dan atau individu states.
* Apakah transisi dari suatu ke yang lainnya terjadi pada kondisi yang lebih baik ?
* Apakah output yang dihasilkan memiliki kebenaran ?
* Apakah input yang diterima utuk setiap atate memiliki kebenaran ?
a.2. Transactions
Komponen mempunyai transaksi dengan user atau dengan komponen lainnya memiliki/menghadirkan variasi resiko mis : Dalam mengcreate file baru ? ; Apakah ada file tempelete ?; Bagaimana produk merespon file ilegal ?
a.3. Code Coverage
Struktur pola dasar resiko sangat memperhatikan keberadaan untested code componen.
Area ini sering menghandel/ menyebabkan kondisi yang tidak dinamis mis pada over temp critical condition, seharusnya test tersebut merusak konfigurasi test, tetapi bagaimana jika sistem mati pada saat kejadian berlangsung.
a.4. Data Flow Coverage
Merupakan transfer data melalui parameter lingkungan data global atau penyimpanan DB dari suatu komponen kelainnya.
Pertambahan program untuk import, export, link data dari lain program mengcreate Data Flow yang komplek.
User kadang-kadang menganggap hal ini aneh.
a.5. Functionality
Setiap komponen melaksanakan beberapa fungsi untuk operasi internal spt kalkulasi, formating.
Kualitas resiko secara fungsional pada umumnya mempunyai 2 tipe :
* Fungsi yang dilaksanakan tidak benar
* Terdapat bagian fungsi yang bekerja tidak benar/ kuang benar.
a.6. User interface
Kualitas resiko untuk area ini hampir sama dengan functionality, tetapi area ini juga memasukan pertanyaan yang meliputi pemakaian promps dan massage yang dimengerti, aliran kontrol, ketepatan warna skema dan grafik.
Selama phase componen test, user interface testing meliputi prototipe interface atau penggunaan perbagian. Pengujian tidak harus menguji keseluruhan interface tetapi tiap screen dibuat maket/contoh.
a.7. Mechanical live
Setiap objek yang dapat difleksibelkan atau digerakan oleh keterbatasan pada sejumlah gerakan yang dikerjakan/ditanggung, misalnya : Keyboard break, contacks fail, pemasangan cracks dan lain sebagainya.
a.8. Signal Quality
Setiap sirkuit yang memproses data apakah itu digital ataupun analog akan dibatasi oleh kualitas input signal mis adanya noise.
b. Integration Testing
b.1. Component atau Subsystem Interfaces
Setiap fungsi, bus, konektor memungkinkan terjadinya kesalahfahaman antara dua atau lebih komponen untuk teknik pengembangannya, kesalahaman ini terjadi dengan sendirinya bila dua komponen membenarkan suatu kesalahan bersama.
b.2. Functionality
Fokusnya pada fungsional yang membutuhkan kebenaran operasi pada dua atau lebih komponen dari aliran data antara komponen.
b.3. Kapasitas dan volume
Kapasitas (statik ) dan volume (dinamik) dari pipa harus matching dengan kebutuhan aplikasi dan harapan user, dimana makin besar lingkungan (jaringannya) makin banyak variasi resikonya.
b.4. Penanganan Kesalahan dan Recover
Tidak aada yang meramalkan dengan pasti kesalahan yang akan terjadi, tetapi dengan menggunakan integration test kesalahan yang umum terjadi dapat ditangani lebih awal.
b.5. Data Quality
Jika suatu produk stores, retrives dan shared significant amount of data, khususnya yang memiliki link yang sulit, relationshipnya dan integritas data, seharusnya dipertimbangkan untuk ditest walaupun produk penanganan datanya dapat dipercaya. Misalnya pada penggunaan spreedsheet.
b.6. Performance/kinereja
Seperti pada kapasitas dan volume, performance perhatiannya berlaku pada banyaknya subsistem dan komponen dalan suatu produk
b.7. User Interface
Bila functionality diintegrasikan ke sistem seharusnya test melalui user interface, jika menggunakan prototipe ini merupakan suatu option.
c. System Testing & Acceptance Testing
c.1. Functionality
Selama test system seharusnya mempertimbangkan functionality dalam bentuk semua urutan
c.2. User Interface
Testing dapat difokuskan pada penghilangan prilaku menggangu yang muncul setiapkali dikoneksi dengan interface.
Penggunaan prototipe adalah langkah terbaik.
Pada system test pertama kali akan terlihat kelengkapan user interface dengan semua perintah dan aksi yang didapat
c.3. States
State machines dapat eksis pada tingkatan sistem sebagaimana tingkatan komponen, misalnya pada voice mail system.
c.4. Transaction
Transaksi akan terjadi untuk print file, pengiriman file dan lain-lain.
c.5. Data Quality
Selama tahapan test system resiko kualitas data yang awalnya di kover oleh test integration harus direvisi ulang, karena kekomplesitasan dari data sering meningkat setiap kali produk diintegrasikan
c.6. Operations
Sistem yang komplek spt database dan server sering membutuhkan administrator. Operasi ini membuat pekerjaan maintenance penting kadang-kadang mejadi pekerjaan off line mis backup file dan restore file atau juga migrasi dari satu sistem operasi ke sistem operasi yang lain.
c.7. Capacity & Volume
Seharusnya kapasitas dan volume direvisi ulang walaupun telah telah dikover oleh integrations test, tetapi pendekatan yang digunakan adalah black box test.
c.8. Reliability & Stability
Resiko kualitas pada area ini termasuk dapat menerima failure rates (mean time between failures atau MTBF), tidak dapat menerima recovery time (mean time to repair atau MTTR), dan ketidak mamapuan sistem untuk berfungsi pada kondisi yang legiminate tanpa kesalahan.
c.9. Error/Disaster handling & Recovery
Seperti juga untuk kapasitas dan volume perlu direvisi ulang terutama untuk external failure.
c.10. Stress
Gabungan dari tiga diatas (Capacity &Volume; Reliability & Stability; Error/Disaster handling & Recovery)
c.11. Performance
Revisi ulang dari Integration Test, tetapi lebih difokuskan pada pendekatan prilaku.
c.12. Date & Time Handling
Penggunaan waktu yang berbeda dari beberapa zone, pengukuran atau aturan tanpa menggunaan waktu standard akan mempengaruhi kualitas resiko.
c.13. Localization
Masalah lokasi diasosiasikan dalam penggunaan huruf/bahasa misal untuk keyboard, dilain hal untuk hardware masalah voltage, dialtone telepon.
c.14. Networked & Distribution Enviroments
Bila produk dipakai pada lingkungan yang berbeda akan menimbul;kan resiko kualitas misal untuk standard waktu apakh waktu internasional atau bukan ? sebab jika berkomunikasi secara international akan mempengaruhi standard telephone.
c.15. Configuration Options & Compatibility
Variasi sw, hw dan jaringan yang membingungkan dapat mengcreate problem pada sitem, mis apakh driver cocok atau tidak ?
c.16. Standards Complaince
Bug yang tidak berbahaya dihubungkan pada standard tidak menimbulkan reaksi sehingga produk secara legal dan efektif tidak terhalang dipasaran
c.17. Security
Merupakan pengetesan dalam penulisan pasword, pengupdatean, pengcopian dll
Bilamana implementasi keamanan merupakan ciri-ciri utama dari suatu dan hal tersebut tidak hanya untuk semua produk perlu ada pengetesan
c.18. Enviroment
Setiap produk memiliki resiko terhadap lingkungan, mis temperatur, kelembaban, debu, jamur dll.
c.19. Power Input, Consumption & Output.
Semua komputer membutuhkan atau berada dalam lingkungan gelombang elektrik, perubahan dalam hal tersebut menyebabkan panas atau radiasi elektro magnetik dan mempengaruhi baik langsung maupun tidak langsung terhadap kerusakan device (komponen).
c.20. Shock, Vibration & Drop
Pada saat ini banyak komputer yang moveable, yakni dapat dipindah-pindahkan, akibatnya komputer tersebut akan mengalami, goncangan, vibrasi dan jatuh (kadang-kadang)
Test sistem pada phase ini akan menemukan apakh sistem berubah setelah mengalami hukum grafitasi.
c.21. Instalation, Cut Over, SETUP & Initial Configuration
Setiap produk akan mengalami pemakaian awal
Apakah proses instalasi bekerja ?
Dapatkah data bermigrasi dari sistem lama ?
Pada multiuser situasi, konfigurasi termasuk juga membuat kreasi user account dan Bagaimana jika user ingin mengunistall program ?
c.22. Documentation & Packaging
Kesalahan tidak perlu terjadi mungkin dapat terjadi misalnya memasng 100v pada 220 V, termasuk vibrasi, shock dan drop.
c.23. Maintainability
Setiap sistem yang terlampau sederhana untuk kebutuhan operatornya akan memungkinkan terjadinya resiko kesalahan pada perwatannya, mis : dapatkah mengupgrade software atau menambah memory ?
c.24. Beta
Setiap produk secara umum baik sw atau hw tidak ada yang sebaik untuk penggunaan dan lingkungan user sendiri, untuk itu perlu mempertimbangkan dalam bentuk beta testing atau release program dalam bentuk pertama, kedua dan seterusnya.
Pengecekan dan Kelengkapan Metoda Informal
* Membuat daftar :
• Resiko tidak penting dan user tidak perhatian
• Resiko tidak kritis tapi user sangat memperhatikan
* Membuat Pembanding dengan team
* Masukan dari Internal Experts
* Masukan dari Sumber External
* Usulan dari Kualitas Resiko (Lihat Contoh pada buku referensi)
Contoh Analisis Kualitas Resiko Informal untuk Hypothetical Word Processor
I.2.2.3. Metoda Formal Untuk Pengertian Kualitas Resiko
Pengujian dengan menggunakan teknik lebih formal untuk mendefinisikan kualitas risk
Pendekatan ini dapat memetakan kebutuhan, spesifikasi, dan asumsi team proyek yang diinputkan kedalam kualitas resiko spesifik dan efeknya
Pendekatan dapat merangking resiko menurut prioritasnya dan memperbaikinya dalam perintah selanjutnya
Pendekatan ini menggunakan Failure Mode and Effect Analysis (FMEA), yaitu merupakan pendekatan formal untuk pemetaan kebutuhan, spesifikasi dan asumsi tim proyek kedalam spesifik quality risk.
Contoh FMEA untuk Hypothetical File Server
System Function or Feature
Analisis fungsi sistem dimulai dari sini, dalam melakukan breakdown deskripsi dari fungsi sistem yang akan dianalisis bila terlampau detil akan sulit dibaca sedangkan bila terlampau sedikit akan sulit mengetahui failure ada pada fungsi yang mana
Potential Failure Mode(s) – Quality Risk(s)
* Pada kolom ini terdapat fungsi yang spesifik atau ciri-cirinya tetapi bukan kategorinya.
* Pada kolom ini entrynya seharusnya sudah menemukan suatu failure.
* Quality risk diasosiasikan dengan kehilangan fungsi sistem yang spesifik.
* Tiap spesifik fungsi atau ciri-cirinya dapat mempunyai banyak mode failure.
Potential effect of failure
Tiap failure mode dapat memberikan efek pada user dari berbagai hal, oleh sebab itu sebaiknya input dalam bentuk umum lebih baik daripada dalam bentuk antisipasi terhadap kemungkinannya.
Critical
Pada kolom ini diisi ya atau tidak, dimana potential effect akan memberikan/mempunyai konsekuensi yang kritis bagi user.
Severity (kerumitan)
* Kolom ini merupakan kerumitan yang absolut dari mode failure dalam pertanyaan, mengabaikan segala kemungkinan.
* Digunakan suatu skala dari 1 s/d 5, yaitu :
1. Kehilangan data atau problem keamanan.
2. Kehilangan fungsi tanpa workaround
3. Kehilangan fungsi dengan workaround
4. Kehilangan sebagian fungsi
5. Hal-hal yang kecil.
* Workaround, suatu langkah untuk menghindari bug tanpa memperbaikinya.
Potential Cause(s) of failure
Kolom ini merupakan daftar dari triger failure mis: OS error, dll.
Priority
* Priotitas menilai bagaimana keburukan dari mode failure akan mempengaruhi kemampuan suatu perusahaan untuk memasarkan produk tersebut selama siklus hidup pengembangan (SDLC), dengan asumsi bahwa akan dikeluarkan versi release terbaru.
* Skala yang digunakan 1 s/d 5
* Input yang diterima dari umumnya dari Sales Marketing atau Technical Support.
Dectections Method(s)
* Kolom ini merupakan metoda yang ada atau prosedur untuk mendeteksi seperti aktifitas pengembangan atau vendor testing.
* Deteksi ini diharapkan dapat menemukan problem sebelum mempengaruhi use, diluar setiap test yang dilakukan.
Dectections
* Angka pada kolom ini mempresentasikan kemungkinan dari metode deteksi yang ada pada kolom sebelumnya.
* Bila metoda deteksi yang digunakan yakin (atau memiliki keyakinan) untuk memperoleh failure model, maka kolom mengidentifikasikan resiko rendah, begitu juga sebaliknya.
* Digunakan skala 1 s/d 5
RPN (Risk Priority Number)
* Kolom ini akan menunjukan bagaimana pentingnya untuk mentest failure mode secara khusus.
* RPN dihasilkan dari perkalian antara severity, priority value dan detecttion value, oleh sebab itu hasil perkaliannya antara 1 s/d 125.
Recommended Action
* Kolom ini mengandung satu atau lebih tindakan yang sederhana untuk menaikan resiko prioritas (dalam artian membuat lebih sederhana).
* Untuk mentest, kebanyakan recommended action melibatkan suatu test case yang mempengaruhi pengamanan deteksi.
Who/When ?
Kolom ini mengindikasikan siapa yang bertanggung jawab untuk setiap recommeded action dan kapan (phase test) dia bertanggung jawab.
References
Kolom ini menampilkan referensi untuk informasi yang lebih dalam tentang quality risk, biasanya hal ini meliputi spesifikasi produk, dokumen kebutuhan dll.
Action Result
Merupakan record pengaruh dari aksi yang diambilpada priority, severity, detection dan RPN, kolom ini digunakan setelah implementasi test bukan pada FMEA awal.
I.4. Schedule, Resources, & Budget
I.4.1. Cost, Schedule & Quality, ilustrasi gambar sebagai berikut :
Arah jarum jam menunjukkan perbaikan selama langkah planning.
Perbaikan ini merupakan balancing schedule, cost dan kualitas.
Ketika implmentasi dari test dimulai maka akan sulit untuk mengubah jadwal yang sudah ditetapkan, budget akan meningkat seperti diatas.
Dengan membatasi pada kotak (batas yang diinginkan) hubungan kualitas akan tampak pada garis ketiganya.
Cost, Schedule and Quality
I.4.2. Mencocokan Schedule test kedalam proyek
Pendekatan yang terbaik adalah pendekatan top down :
* Planning
* Configuration memperoleh hw dan sumber daya yang penting dan mentest lab
* Development, membangun test tools; mengcreate urutan test dan test case library; menempatkan laporan test tools pada tempatnya; dokumentasi bagaimana sistem bekerja.
* Test execution, running test; recording status test dan melaporkan hasilnya.
Kendala yang dihadapi terhadap pendekatan ini antara lain :
* Mahalnya sumber daya
* Lamanya waktu/operasional penggunaan, untuk perangkat yang harus disewa.
* Kehilangan SDM
* Dll.
Sehingga harus dibuat draft jadwal sebagai berikut : miliestone (lihat gambar).
Contoh Milesstone Testing
I.4.3. Penentuan Sumber daya dan Pembuatan Budget
Staf
* Karyawan tetap
* Kontraktor
* Konsultan
Test tools
* Software, meliputi code coverage analyzers, low level diagnostics programs dll.
* Hardware, meliputi oscilloscopes, table goncangan dan getaran, dan peralatan lainnya.
Facilities & Overhead
* Biaya sewa
* Biaya transportasi
* Workstations
* dll.
Test systems
* Melputi hw & sw
* Prototipe
* dll.
External labs
* Penggunaan laboratorium eksternal
* Performance dari lokasi.
* dll
Langganan:
Postingan (Atom)