Ringkuman bab 19-22 buku Software Engineering A Practitioners Approach mengenai tiga hal utama: 1. Pengujian perangkat lunak pada level komponen perlu strategi dan taktik yang tepat seperti unit testing dan integration testing untuk memastikan komponen berfungsi dengan benar. 2. Perencanaan pengujian yang baik diperlukan termasuk mendefinisikan tujuan, lingkup, dan jadwal pengujian. Scaffolding penting untuk memfasilitasi pengujian terisolasi setiap komponen.

1. Ringkasan Bab 19 – 22 Buku Software
Engineering A Practitioners Approach
Oleh : Ebenezer Hutahaean (09011282126080)

2. Chapter 19 : Software Testing— Component
Level

3. 19.1 A Strategic Approach to Software
Testing
 Strategi pengujian perangkat lunak mencakup sekelompok taktik yang
memfasilitasi pengujian pada level rendah yang diperlukan untuk memverifikasi
bahwa segmen kode sumber kecil telah diimplementasikan dengan benar serta
pengujian level tinggi yang memvalidasi fungsi sistem utama terhadap
kebutuhan pelanggan. Strategi tersebut harus memberikan panduan bagi
praktisi dan seperangkat tonggak waktu bagi manajer. Karena langkah-langkah
strategi pengujian terjadi pada saat tekanan tenggat waktu mulai meningkat,
kemajuan harus terukur dan masalah harus muncul secepat mungkin.

4. 19.1.1 Verification and Validation
 Verifikasi dan validasi mencakup berbagai macam aktivitas SQA: ulasan teknis,
audit kualitas dan konfigurasi, pemantauan kinerja, simulasi, studi kelayakan,
peninjauan dokumen, peninjauan basis data, analisis algoritma, pengujian
pengembangan, pengujian kegunaan, pengujian kualifikasi, pengujian
penerimaan, dan pengujian instalasi. Meskipun pengujian memainkan peran
yang sangat penting dalam V&V, banyak aktivitas lainnya juga diperlukan.
19.1.2 Organizing for Software Testing
 Pengujian yang efektif memerlukan strategi dan taktik yang tepat serta
pelibatan kelompok pengujian independen (ITG) untuk menemukan kesalahan
yang mungkin terlewatkan oleh pembangun. Namun, pembangun tetap harus
tersedia untuk memperbaiki kesalahan yang ditemukan oleh ITG. Terdapat pula
perdebatan psikologis tentang pengujian perangkat lunak, dimana pembangun
cenderung melihat pengujian sebagai tindakan merusak yang berpotensi
menghancurkan karya mereka, sehingga dibutuhkan upaya yang hati-hati untuk
melakukannya. Meskipun pengujian adalah elemen penting dari V&V (verifikasi
dan validasi), ada banyak aktivitas lain yang diperlukan dalam SQA (asuransi
kualitas perangkat lunak) seperti tinjauan teknis, pengawasan kinerja, studi
kelayakan, dan lain sebagainya.

5. 19.1.3 The Big Picture
 The big picture pada software testing komponen level mengacu pada
pandangan menyeluruh tentang pengujian yang diterapkan pada unit-unit
terkecil dari perangkat lunak, yaitu pada tingkat kode atau modul. Untuk
memastikan pengujian dilakukan secara efisien dan efektif, diperlukan strategi
dan taktik pengujian yang tepat, seperti unit testing dan integration testing.
Penting untuk memiliki pandangan yang jelas dan terorganisir dari seluruh
proses pengujian pada level komponen. Dengan memahami the big picture dari
pengujian perangkat lunak pada level komponen, pengembang perangkat lunak
dapat membuat rencana yang terstruktur dan terorganisir untuk pengujian
komponen mereka, yang dapat membantu meningkatkan kualitas perangkat
lunak yang dihasilkan.

6. 19.1.4 Criteria for “Done”
 Pertanyaan yang sering muncul dalam diskusi tentang pengujian perangkat
lunak adalah "Kapan kita selesai melakukan pengujian - bagaimana kita tahu
bahwa kita sudah cukup melakukan pengujian?" Jawabannya tidak pasti, tetapi
ada beberapa respons pragmatis dan upaya awal untuk panduan empiris.
Salah satu respons adalah "Anda tidak pernah selesai melakukan pengujian;
beban itu hanya bergeser dari Anda (insinyur perangkat lunak) ke pengguna
akhir." Fakta yang menyedihkan ini menekankan pentingnya aktivitas
penjaminan kualitas perangkat lunak lainnya. Respons lain yang sedikit sinis
tetapi tetap akurat adalah "Anda selesai melakukan pengujian ketika waktu
atau uang Anda habis." Meskipun sedikit praktisi yang akan membantah
respons ini, Anda memerlukan kriteria yang lebih ketat untuk menentukan
kapan pengujian yang cukup telah dilakukan.

7. 19.2 Planning and Recordkeeping
 Perencanaan dan pencatatan (recordkeeping) merupakan kegiatan penting
dalam pengujian perangkat lunak pada level komponen. Perencanaan
melibatkan definisi tujuan pengujian, cakupan pengujian, lingkungan pengujian,
dan jadwal pengujian.

8. 19.2.1 Role of Scaffolding
 Dalam konteks pengujian perangkat lunak, istilah "scaffolding" mengacu pada
kerangka kerja atau struktur yang digunakan untuk menunjang dan
memfasilitasi pengujian. Scaffolding dapat digunakan untuk mengatur data uji,
mengatur pengujian, memfasilitasi interaksi dengan sistem atau lingkungan
pengujian, dan banyak lagi.
 Dalam pengujian perangkat lunak pada level komponen, scaffolding biasanya
digunakan untuk membuat objek tes, mengorganisasi objek tes, dan
memberikan lingkungan yang terisolasi untuk pengujian. Scaffolding dapat
membantu mengisolasi komponen yang diuji dari komponen lain dalam sistem,
sehingga memungkinkan pengujian yang lebih terfokus dan efektif. Selain itu,
scaffolding juga dapat membantu dalam memudahkan pembuatan dan
pemeliharaan pengujian serta meningkatkan efisiensi pengujian secara
keseluruhan.
 Peran scaffolding dalam pengujian perangkat lunak level komponen sangat
penting untuk memastikan bahwa pengujian yang dilakukan efektif dan efisien
dalam menguji komponen perangkat lunak secara terisolasi.

9. 19.2.2 Cost-Effective Testing
 Pengujian secara menyeluruh (exhaustive testing) memerlukan semua
kombinasi kemungkinan dari nilai masukan dan urutan kasus uji diproses oleh
komponen yang diuji (misalnya, pertimbangkan generator gerakan dalam
permainan catur komputer). Dalam beberapa kasus, hal ini akan memerlukan
pembuatan jumlah dataset yang hampir tak terbatas. Hasil dari pengujian
secara menyeluruh seringkali tidak sebanding dengan usaha yang dikeluarkan,
karena pengujian saja tidak dapat digunakan untuk membuktikan bahwa
komponen telah diimplementasikan dengan benar. Terdapat beberapa situasi di
mana Anda tidak memiliki sumber daya untuk melakukan pengujian unit yang
komprehensif. Dalam hal ini, pengujian unit sebaiknya difokuskan pada modul
yang sangat penting untuk kesuksesan proyek dan yang diduga rentan
terhadap kesalahan karena kompleksitasnya

10. 19.3 Test-Case Design
 Pada tahap Test-Case Design, tim pengujian harus melakukan analisis terhadap
spesifikasi kebutuhan fungsional dan non-fungsional untuk menentukan jenis dan
jumlah test case yang perlu dibuat. Setelah itu, tim harus merancang test case
dengan menggunakan teknik desain kasus uji yang tepat, seperti equivalence
partitioning, boundary value analysis, decision table, atau state transition diagram.
Teknik-teknik tersebut bertujuan untuk memastikan bahwa semua kondisi yang
mungkin terjadi pada komponen perangkat lunak akan diuji dengan baik.
 Selain itu, dalam Test-Case Design, tim pengujian juga harus memperhatikan aspek
lain seperti penggunaan data dummy atau mock data, pengaturan kondisi awal dan
pengaturan lingkungan pengujian yang sesuai. Hal ini bertujuan untuk memastikan
bahwa hasil pengujian yang diperoleh akurat dan dapat diandalkan.
 Setelah test case dirancang, tim pengujian harus melakukan review terhadap test
case tersebut untuk memastikan bahwa semua kondisi yang mungkin terjadi sudah
tercakup dan juga memastikan bahwa test case sudah siap digunakan dalam
proses pengujian.

11. 19.3.1 Requirements and Use Cases
 tentang pengujian perangkat lunak. Tahapan pengumpulan kebutuhan dimulai
dengan bekerja sama dengan pelanggan untuk menghasilkan user stories yang
kemudian bisa digunakan oleh developer untuk menghasilkan formal use cases
dan analysis models. Use cases dan model ini dapat digunakan untuk
mengarahkan pembuatan test case secara sistematis yang mampu melakukan
pengujian fungsional dari setiap komponen perangkat lunak dan memberikan
cakupan tes yang baik secara keseluruhan.

12. 19.3.2 Traceability
 Untuk memastikan bahwa proses pengujian dapat diaudit, setiap kasus uji
harus dapat dilacak kembali ke persyaratan fungsional atau nonfungsional atau
anti- persyaratan tertentu. Seringkali persyaratan nonfungsional harus dapat
dilacak kembali ke persyaratan bisnis atau arsitektural tertentu. Beberapa
pengembang agile menolak konsep pelacakan karena dianggap sebagai beban
yang tidak perlu bagi pengembang. Namun, kegagalan dalam proses pengujian
seringkali dapat dilacak ke jalur pelacakan yang hilang, data uji yang tidak
konsisten, atau cakupan pengujian yang tidak lengkap. Regression testing,
memastikan bahwa kasus uji dapat dilacak kembali ke persyaratan merupakan
langkah penting yang perlu dilakukan selama pengujian komponen.

13. 19.4 White-Box Testing
 White-box testing, juga disebut sebagai glass-box testing atau structural
testing, adalah suatu filosofi desain test-case yang menggunakan struktur
kontrol yang dijelaskan sebagai bagian dari desain level komponen untuk
mendapatkan test case. Dengan menggunakan metode white-box testing,
kamu dapat mendapatkan test case yang (1) menjamin bahwa semua jalur
independen dalam suatu modul telah diuji minimal satu kali, (2) menguji semua
keputusan logis pada sisi benar dan salahnya, (3) mengeksekusi semua
perulangan pada batasnya dan dalam batasan operasionalnya, dan (4) menguji
struktur data internal untuk memastikan validitasnya.

14. 19.4.1 Basis Path Testing
 Basis path testing merupakan teknik pengujian white-box yang pertama kali
diperkenalkan oleh Tom McCabe. Metode basis path memungkinkan
perancang pengujian untuk menentukan ukuran kompleksitas logis dari desain
prosedural dan menggunakannya sebagai panduan untuk mendefinisikan
himpunan basis dari jalur eksekusi. Tes yang dihasilkan untuk menguji
himpunan basis dijamin akan mengeksekusi setiap pernyataan dalam program
minimal satu kali selama pengujian.

15. 19.4.2 Control Structure Testing
 pengujian struktur kontrol dibahas. Ini memperluas cakupan pengujian dan
meningkatkan kualitas pengujian kotak putih. Pengujian kondisi adalah metode
perancangan kasus uji yang melibatkan kondisi logis yang terdapat dalam
sebuah modul program. Pengujian aliran data memilih jalur pengujian program
sesuai dengan lokasi definisi dan penggunaan variabel dalam program.

16. 19.5 Black-Box Testing
 Black-box testing atau disebut juga dengan behavioral testing atau functional
testing, fokus pada persyaratan fungsional perangkat lunak. Artinya, teknik-
teknik black-box testing memungkinkan Anda untuk menentukan kumpulan
kondisi input yang akan sepenuhnya menguji semua persyaratan fungsional
dari sebuah program. Black-box testing bukan alternatif untuk teknik white-box.
Sebaliknya, ini adalah pendekatan yang melengkapi dan mungkin menemukan
kelas kesalahan yang berbeda dengan metode white-box.
 Black-box testing berusaha untuk menemukan kesalahan dalam kategori
berikut: (1) fungsi yang salah atau hilang, (2) kesalahan antarmuka, (3)
kesalahan pada struktur data atau akses basis data eksternal, (4) kesalahan
perilaku atau kinerja, dan (5) kesalahan inisialisasi dan terminasi.

17. 19.5.1 Interface Testing
 Pengujian antarmuka digunakan untuk memeriksa bahwa komponen program
menerima informasi yang diteruskan padanya dalam urutan dan jenis data yang
tepat, serta mengembalikan informasi dalam urutan dan format data yang benar.
Pengujian antarmuka sering dianggap sebagai bagian dari pengujian integrasi.
Karena sebagian besar komponen bukan program mandiri, penting untuk
memastikan bahwa saat komponen diintegrasikan ke dalam program yang sedang
berkembang, itu tidak akan memecahkan build. Inilah tempat di mana penggunaan
stub dan driver menjadi penting bagi pengujian komponen.
 Stubs dan driver terkadang menggabungkan kasus uji yang akan diteruskan ke
komponen atau diakses oleh komponen. Dalam kasus lain, kode debugging
mungkin perlu dimasukkan ke dalam komponen untuk memeriksa bahwa data yang
diteruskan diterima dengan benar Dalam kasus lain, kerangka pengujian harus
berisi kode untuk memeriksa bahwa data yang dikembalikan dari komponen
diterima dengan benar. Beberapa pengembang yang cakap dalam metode agile
lebih memilih untuk melakukan pengujian antarmuka menggunakan salinan versi
produksi program yang sedang berkembang dengan beberapa kode debugging
yang ditambahkan.

18. 19.5.2 Equivalence Partitioning
 Equivalence partitioning adalah teknik pengujian yang membagi domain input
dari sebuah program menjadi kelas-kelas data tertentu. Teknik ini bertujuan
untuk mengidentifikasi sejumlah kecil test case yang paling efektif dan efisien
dalam mengungkap kesalahan yang mungkin terjadi pada input data.
 Untuk mendesain test case menggunakan equivalence partitioning, langkah
pertama adalah mengevaluasi kelas-kelas ekuivalensi untuk kondisi input.
Kelas ekuivalensi adalah himpunan objek yang terhubung oleh hubungan
simetris, transitif, dan refleksif. Kelas ekuivalensi merepresentasikan himpunan
state valid atau invalid untuk kondisi input, yang dapat didefinisikan
berdasarkan panduan tertentu.
 Panduan untuk mendefinisikan kelas ekuivalensi adalah sebagai berikut:
1. Kondisi Input Range: Jika sebuah kondisi input menentukan suatu rentang,
maka satu kelas ekuivalensi valid dan dua kelas ekuivalensi invalid didefinisikan.
Kelas ekuivalensi valid mencakup nilai di dalam rentang, sedangkan kelas
ekuivalensi invalid mencakup nilai di bawah rentang dan nilai di atas rentang.

19. 2. Kondisi Input Nilai Spesifik: Jika sebuah kondisi input memerlukan suatu nilai
spesifik, maka satu kelas ekuivalensi valid dan dua kelas ekuivalensi invalid
didefinisikan. Kelas ekuivalensi valid mencakup nilai yang tepat, sedangkan kelas
ekuivalensi invalid mencakup nilai di luar nilai yang diminta.
3. Kondisi Input Set: Jika sebuah kondisi input menentukan sebuah himpunan nilai,
maka satu kelas ekuivalensi valid dan satu kelas ekuivalensi invalid didefinisikan.
Kelas ekuivalensi valid mencakup nilai dari himpunan tersebut, sedangkan kelas
ekuivalensi invalid mencakup nilai di luar himpunan tersebut.
4. Kondisi Input Boolean: Jika sebuah kondisi input merupakan sebuah kondisi
Boolean, maka satu kelas ekuivalensi valid dan satu kelas ekuivalensi invalid
didefinisikan. Kelas ekuivalensi valid mencakup kondisi yang benar (true),
sedangkan kelas ekuivalensi invalid mencakup kondisi yang salah (false).
Dengan menerapkan panduan-panduan tersebut, test case untuk setiap item data
dalam domain input dapat dikembangkan dan dieksekusi. Test case dipilih
sedemikian rupa sehingga jumlah atribut dari sebuah kelas ekuivalensi yang teruji
sekaligus semaksimal mungkin.
Lanjutan….

20. 19.5.3 Boundary Value Analysis
 Boundary value analysis (BVA) adalah teknik pengujian perangkat lunak yang
melengkapi pengelompokan ekuivalen. BVA memilih kasus pengujian di
"pinggiran" kelas ekuivalen, di mana kesalahan lebih mungkin terjadi. BVA
juga menggunakan domain keluaran untuk menghasilkan kasus pengujian.
Pedoman untuk BVA mirip dengan pengelompokan ekuivalen, yang
mempertimbangkan batas nilai. Contohnya, jika kondisi masukan menentukan
rentang nilai, kasus uji harus dirancang dengan nilai batas, sedikit di atas dan
di bawah nilai batas. Demikian pula, untuk kondisi keluaran, kasus pengujian
harus dirancang untuk menciptakan laporan keluaran yang menghasilkan
jumlah entri tabel yang diizinkan maksimum (dan minimum). Teknik ini
membantu memastikan pengujian pinggiran lebih lengkap, sehingga memiliki
kemungkinan yang lebih tinggi dalam mendeteksi kesalahan.

21. 19.6 Object-Oriented Testing
 Dalam pengembangan perangkat lunak berorientasi objek, konsep unit testing
mengalami perubahan karena adanya konsep encapsulation yang mendorong
definisi kelas dan objek. Artinya, setiap kelas dan setiap instansi dari kelas
tersebut mengemas atribut (data) dan operasi yang memanipulasi data
tersebut. Sebuah kelas terenkapsulasi biasanya menjadi fokus dari pengujian
unit, namun operasi (metode) di dalam kelas adalah unit-unit yang paling kecil
yang dapat diuji.
 Karena sebuah kelas dapat berisi beberapa operasi yang berbeda, dan operasi
tertentu mungkin ada sebagai bagian dari beberapa kelas yang berbeda, maka
taktik yang diterapkan pada pengujian unit harus berubah. Kita tidak lagi dapat
menguji satu operasi secara terisolasi (pandangan konvensional tentang
pengujian unit) tetapi sebagai bagian dari sebuah kelas.

22. 19.6.1 Class Testing
 Class testing dalam pengembangan perangkat lunak berorientasi objek (OO)
adalah setara dengan unit testing pada perangkat lunak konvensional. Namun,
berbeda dengan unit testing pada perangkat lunak konvensional yang lebih
berfokus pada detail algoritma dan data yang mengalir pada antarmuka modul,
class testing untuk perangkat lunak OO didorong oleh operasi yang
terkapsulasi dalam kelas dan perilaku status kelas itu sendiri.
 Untuk memberikan gambaran singkat tentang metode ini, diambil contoh pada
aplikasi perbankan di mana sebuah kelas Account memiliki beberapa operasi
seperti open(), setup(), deposit(), withdraw(), balance(), summarize(),
creditLimit(), dan close(). Setiap operasi tersebut dapat diterapkan pada
Account, namun ada beberapa batasan tertentu yang disebabkan oleh sifat
permasalahan. Meskipun demikian, masih banyak permutasi operasi yang
mungkin terjadi pada sebuah instance dari Account.
 Untuk menguji keadaan tersebut, minimal seju

23. 19.6.2 Behavioral Testing
 Yaitu mengenai penggunaan state diagram sebagai model yang
merepresentasikan perilaku dinamis suatu kelas pada pemrograman
berorientasi objek. State diagram dapat digunakan untuk menghasilkan urutan
tes yang dapat mengeksplorasi perilaku dinamis kelas tersebut dan kelas lain
yang berkolaborasi dengannya. Sebuah contoh kelas Account pada aplikasi
perbankan diberikan, dengan state diagram yang menunjukkan urutan transisi
antara state-state yang mungkin terjadi pada kelas tersebut. Tes-tes yang
dirancang harus mencapai cakupan semua state yang mungkin terjadi. Dalam
kasus kelas yang berkolaborasi dengan beberapa kelas lainnya, beberapa
state diagram digunakan untuk melacak alur perilaku sistem secara
keseluruhan. Pendekatan "breadth-first" dapat digunakan untuk melakukan tes
pada transisi antar state-state. Sebuah contoh kelas CreditCard pada sistem
perbankan diberikan, di mana state-object ini bergantung pada transisi dari satu
state ke state yang lainnya.

24. Chapter 20 : Software Testing— Integration
Level

25. 20.1 Software Testing Fundamentals
1. Tes yang baik memiliki probabilitas tinggi untuk menemukan kesalahan. Untuk
mencapai tujuan ini, pengujinya harus memahami perangkat lunak dan berusaha
untuk mengembangkan gambaran mental tentang bagaimana perangkat lunak
mungkin gagal.
2. Tes yang baik tidak redundan. Waktu dan sumber daya pengujian terbatas.
Tidak ada gunanya melakukan tes yang memiliki tujuan yang sama dengan tes
lainnya. Setiap tes harus memiliki tujuan yang berbeda (meskipun secara halus
berbeda).
3. Tes yang baik harus menjadi "the best of breed". Dalam sekelompok tes yang
memiliki tujuan yang sama, keterbatasan waktu dan sumber daya dapat
menentukan pelaksanaan hanya tes yang memiliki kemungkinan tertinggi untuk
mengungkapkan satu kelas kesalahan.
4. Tes yang baik tidak boleh terlalu sederhana atau terlalu kompleks. Meskipun
terkadang memungkinkan untuk menggabungkan beberapa tes menjadi satu
kasus uji, kemungkinan efek samping yang terkait dengan pendekatan ini dapat
menyembunyikan kesalahan. Pada umumnya, setiap tes harus dilakukan secara
terpisah.

26. Lanjutan….
5. Produk yang telah dirancang dapat diuji dengan dua cara: (1) dengan
mengetahui fungsi yang ditentukan yang harus dilakukan oleh produk, tes dapat
dilakukan yang menunjukkan setiap fungsi beroperasi sepenuhnya sambil mencari
kesalahan pada setiap fungsi. (2) Dengan mengetahui cara kerja internal produk,
tes dapat dilakukan untuk memastikan bahwa "semua gigi terpasang dengan baik",
yaitu operasi internal dilakukan sesuai dengan spesifikasi dan semua komponen
internal telah digunakan dengan baik. Pendekatan tes pertama mengambil
pandangan eksternal dari pengujian dan disebut pengujian kotak hitam. Yang
kedua memerlukan pandangan internal dari pengujian dan disebut pengujian kotak
putih. Kedua jenis pengujian tersebut berguna dalam pengujian integrasi.

27. 20.1.1 Black-Box Testing
 Pengujian kotak hitam mengacu pada pengujian integrasi yang dilakukan
dengan menguji antarmuka komponen dengan komponen lain dan dengan
sistem lain. Ini memeriksa beberapa aspek dasar dari sistem dengan sedikit
memperhatikan struktur logika internal perangkat lunak. Fokusnya adalah
memastikan komponen berfungsi dengan benar dalam bangunan perangkat
lunak yang lebih besar ketika data input dan konteks perangkat lunak yang
ditentukan oleh prasyaratnya benar dan berperilaku sesuai dengan
posyaratnya.
20.1.2 White-Box Testing
 White-box testing adalah filosofi pengujian integrasi yang menggunakan
pengetahuan implementasi dari struktur kontrol yang dijelaskan sebagai bagian
dari desain level komponen untuk menurunkan kasus uji. Pengujian white-box
pada perangkat lunak didasarkan pada pemeriksaan rinci detail implementasi
prosedural dan detail implementasi struktur data. Tes white-box hanya dapat
dirancang setelah desain level komponen (atau kode sumber) ada. Detail logis
dari program harus tersedia. Jalur logis melalui perangkat lunak dan kolaborasi
antara komponen menjadi fokus pengujian integrasi white-box.

28. 20.2 Integration Testing
 Pada pengujian integrasi, tujuannya adalah untuk membangun struktur
program yang telah ditentukan oleh desain dan pada saat yang sama
melakukan pengujian untuk mengungkap kesalahan yang terkait dengan
antarmuka. Pendekatan integrasi noninkremental seringkali menghasilkan
kegagalan, sedangkan pendekatan integrasi inkremental memungkinkan
kesalahan lebih mudah diisolasi dan diperbaiki, serta antarmuka lebih mungkin
diuji secara menyeluruh. Pendekatan ini juga lebih efektif secara biaya.

29. 20.2.1 Top-Down Integration
 Top-down integration testing adalah sebuah pendekatan incremental dalam
membangun arsitektur software. Modul-modul (juga disebut sebagai komponen
dalam buku ini) diintegrasikan dengan cara menuruni hierarki kontrol, dimulai
dari modul kontrol utama (program utama). Modul-modul yang lebih rendah
dalam hierarki kemudian diintegrasikan ke dalam struktur dengan cara yang
disebut depth-first atau breadth-first.
 Pendekatan depth-first mengintegrasikan semua komponen pada jalur kontrol
utama dari struktur program. Sedangkan pendekatan breadth-first
mengintegrasikan semua komponen langsung yang lebih rendah pada setiap
level, dan bergerak secara horizontal pada struktur.

30. Lanjutan….
 Proses integrasi dilakukan dalam lima langkah:
1. Modul kontrol utama digunakan sebagai pengemudi pengujian, dan stub
digunakan untuk semua komponen yang langsung lebih rendah dari modul kontrol
utama.
2. Bergantung pada pendekatan integrasi yang dipilih (yaitu, depth atau breadth
first), stub yang lebih rendah digantikan satu per satu dengan komponen yang
sebenarnya.
3. Pengujian dilakukan setiap kali sebuah komponen diintegrasikan.
4. Setelah menyelesaikan setiap tes, stub lain diganti dengan komponen yang
sebenarnya.
5. Regression testing (dibahas lebih lanjut di bagian selanjutnya) dapat dilakukan
untuk memastikan bahwa kesalahan baru tidak terjadi.
Proses ini berlanjut dari langkah kedua hingga seluruh struktur program selesai
dibangun. Strategi top-down integration testing memverifikasi titik-titik kontrol atau
keputusan utama lebih awal dalam proses pengujian. Pemecahan masalah kontrol
utama penting ditemukan secepat mungkin. Jika pendekatan depth-first dipilih,
maka fungsi lengkap dari software dapat diimplementasikan dan ditunjukkan.

31. 20.2.2 Bottom-Up Integration
 Bottom-up integration testing adalah pendekatan pengujian incremental yang
dimulai dari modul atomik (komponen di tingkat paling bawah dalam struktur
program). Bottom-up integration menghilangkan kebutuhan untuk stub yang
kompleks. Karena komponen diintegrasikan dari bawah ke atas, fungsionalitas
yang disediakan oleh komponen yang lebih rendah dari suatu level selalu
tersedia dan kebutuhan untuk stub dihilangkan.
 Strategi bottom-up integration dapat dilaksanakan dengan langkah-langkah
berikut:
1. Komponen level rendah digabungkan menjadi cluster yang melakukan subfungsi
perangkat lunak tertentu.
2. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasikan input
dan output kasus uji.
2. Cluster diuji.
4. Driver dihapus dan cluster digabungkan, bergerak ke atas dalam struktur
program.

32. 20.2.3 Continuous Integration
 Continuous integration (integrasi terus-menerus) adalah praktik penggabungan
komponen ke dalam increment perangkat lunak yang sedang berkembang,
setidaknya satu kali sehari. Praktik ini umum dilakukan oleh tim yang mengikuti
praktik pengembangan agile seperti XP atau DevOps. Pengujian integrasi harus
dilakukan dengan cepat dan efisien jika tim mencoba untuk selalu memiliki program
yang berfungsi sebagai bagian dari pengiriman kontinu. Namun, kadang-kadang sulit
untuk memelihara sistem dengan menggunakan alat integrasi yang terus-menerus.
Smoke testing adalah pendekatan pengujian integrasi yang dapat digunakan ketika
perangkat lunak produk dikembangkan oleh tim agile menggunakan waktu
pembangunan increment yang pendek. Smoke testing dapat dikarakterisasikan
sebagai strategi integrasi yang bergulir atau terus-menerus. Perangkat lunak
dibangun kembali (dengan penambahan komponen baru) dan diuji setiap hari.
 Pendekatan smoke testing mencakup aktivitas sebagai berikut:
1. Komponen perangkat lunak yang telah diterjemahkan ke dalam kode diintegrasikan
ke dalam build. Sebuah build mencakup semua file data, pustaka, modul yang dapat
digunakan kembali, dan komponen rekayasa yang diperlukan untuk
mengimplementasikan satu atau lebih fungsi produk.

33. Lanjutan….
2. Serangkaian pengujian dirancang untuk mengekspos kesalahan yang akan
menghalangi build agar tidak berfungsi dengan baik. Tujuannya adalah untuk
menemukan kesalahan "show-stopper" yang memiliki kemungkinan terbesar untuk
menjadwalkan proyek perangkat lunak tertunda.
3. Build diintegrasikan dengan build lain, dan seluruh produk (dalam bentuk saat
ini) diuji setiap hari. Pendekatan integrasi dapat berupa top-down atau bottom-up.
Smoke testing memberikan sejumlah manfaat ketika diterapkan pada proyek
perangkat lunak yang kompleks dan kritis waktu:
1. Risiko integrasi diminimalkan.
2. Kualitas produk akhir ditingkatkan.
3. Diagnosis kesalahan dan koreksi lebih mudah.
4. Kemajuan lebih mudah dinilai.

34. 20.2.4 Integration Test Work Products
 Sebuah rencana pengujian harus dibuat untuk mengintegrasikan perangkat
lunak secara bertahap dan menguji fitur-fitur tertentu pada setiap tahapannya.
Pengujian integrasi ini dapat dibagi menjadi beberapa fase seperti interaksi
pengguna, pemrosesan sensor, fungsi komunikasi, dan pemrosesan alarm.
Pada setiap fase pengujian, dilakukan pengujian pada kategori fungsi yang luas
pada perangkat lunak.
 Selain itu, dibuat juga jadwal integrasi, pengembangan perangkat lunak
penyangga (stubs dan drivers), dan lingkungan pengujian. Tahap integrasi dan
pengujian yang sesuai pada setiap tahapannya dijelaskan dan semua kasus
pengujian dicantumkan beserta hasil yang diharapkan. Setelah itu, hasil
pengujian yang sebenarnya dicatat dan dilaporkan agar bisa digunakan dalam
pemeliharaan perangkat lunak.
 Secara keseluruhan, ini membahas tentang pentingnya melakukan pengujian
integrasi secara teratur dan sistematis dalam proses pengembangan perangkat
lunak, serta dokumentasi yang harus dibuat sebagai bagian dari konfigurasi
perangkat lunak.

35. 20.3 Artificial Intelligence and
Regression Testing
 Regression testing adalah proses pengujian ulang sebagian dari test case yang
telah dilakukan sebelumnya untuk memastikan bahwa perubahan yang terjadi
tidak menimbulkan dampak negatif pada fungsi yang telah bekerja dengan baik
sebelumnya. Regression testing harus dilakukan setiap kali ada perubahan
besar pada software, termasuk saat melakukan integrasi dengan komponen
baru. Regression testing dapat dilakukan secara manual atau otomatis dengan
menggunakan capture/playback tools. Regression test suite terdiri dari tiga
kelas test case, yaitu representative sample yang menguji seluruh fungsi
software, additional tests yang fokus pada fungsi yang mungkin terpengaruh
oleh perubahan, dan tests yang fokus pada komponen yang telah diubah.
 Yoo dan Harman mengemukakan bahwa kecerdasan buatan (AI) dapat
digunakan untuk mengidentifikasi test case yang dapat digunakan dalam
regression test suite. Salah satu cara yang mungkin adalah dengan
menggunakan teknik machine learning untuk memilih set test case yang akan
mengoptimalkan penemuan kesalahan kolaborasi komponen. Namun, hal ini
masih memerlukan interaksi manusia yang signifikan untuk meninjau test case
dan urutan eksekusi yang direkomendasikan.

36. 20.4 Integration Testing in the OO
Context
 Ada dua strategi yang berbeda untuk pengujian integrasi sistem berorientasi
objek: thread-based testing dan use-based testing.
 Pendekatan pertama, thread-based testing, mengintegrasikan sekumpulan
kelas yang dibutuhkan untuk merespons satu input atau event pada sistem.
Setiap thread diintegrasikan dan diuji secara individual. Regression testing
diterapkan untuk memastikan tidak ada efek samping yang terjadi. Pendekatan
thread-based testing sangat penting untuk pengujian integrasi perangkat lunak
berorientasi objek. Thread merupakan kumpulan kelas yang merespons pada
satu input atau event.
 Pendekatan integrasi kedua, use-based testing, memulai konstruksi sistem
dengan menguji kelas-kelas independen yang menggunakan sedikit atau tidak
ada kelas server. Setelah kelas independen diuji, lapisan kelas berikutnya,
yang disebut kelas yang bergantung, yang menggunakan kelas independen
diuji. Pengujian lapisan kelas yang bergantung ini dilanjutkan sampai seluruh
sistem terbangun. Tes use-based berfokus pada kelas-kelas yang tidak terlalu
banyak berkolaborasi dengan kelas lain.

37. 20.4.1 Fault-Based Test-Case Design
 Strategi untuk pengujian berbasis kesalahan adalah dengan menghipotesiskan
sekumpulan kesalahan yang masuk akal dan kemudian mendapatkan
pengujian untuk membuktikan setiap hipotesis. Pengujian mencari kesalahan
yang masuk akal (yaitu, aspek dari implementasi sistem yang dapat
menghasilkan cacat). Untuk menentukan apakah kesalahan ini ada, kasus
pengujian dirancang untuk menguji desain atau kode.
 Penting untuk dicatat bahwa pengujian integrasi berusaha menemukan
kesalahan pada objek klien, bukan server. Dinyatakan dalam istilah
konvensional, fokus pengujian integrasi adalah untuk menentukan apakah
kesalahan ada pada kode pemanggil, bukan pada kode yang dipanggil.
Panggilan operasi digunakan sebagai petunjuk, cara untuk menemukan
persyaratan pengujian yang melatih kode pemanggil.

38. 20.4.2 Scenario-Based Test-Case Design
 Pada dasarnya terdapat dua jenis kesalahan dalam pengujian perangkat lunak, yaitu
kesalahan yang terkait dengan spesifikasi yang salah dan interaksi antara subsistem
yang tidak tepat. Kesalahan terkait dengan spesifikasi yang salah terjadi ketika
produk tidak melakukan apa yang diinginkan oleh pelanggan. Ini dapat
menyebabkan produk melakukan hal yang salah atau menghilangkan fungsi penting.
Kesalahan terkait dengan interaksi subsistem terjadi ketika perilaku satu subsistem
menciptakan keadaan (misalnya, peristiwa, aliran data) yang menyebabkan
subsistem lainnya gagal.
 Pengujian berbasis skenario akan mengungkapkan kesalahan yang terjadi ketika
aktor manapun berinteraksi dengan perangkat lunak. Pengujian berbasis skenario
berfokus pada apa yang dilakukan oleh pengguna, bukan apa yang dilakukan oleh
produk. Ini berarti menangkap tugas-tugas (melalui use case) yang harus dilakukan
oleh pengguna dan kemudian menerapkannya sebagai pengujian. Ini sangat mirip
dengan pengujian thread.
 Pengujian skenario mengungkapkan kesalahan interaksi. Namun, untuk mencapai
hal ini, kasus uji harus lebih kompleks dan lebih realistis dibandingkan dengan
pengujian berbasis kesalahan. Pengujian berbasis skenario cenderung melibatkan
beberapa subsistem dalam satu tes (pengguna tidak membatasi diri untuk
menggunakan satu subsistem pada satu waktu).

39. 20.5 Validation Testing
 Validasi software dilakukan untuk memastikan bahwa software berfungsi sesuai
dengan kebutuhan pengguna. Tahap validasi dimulai setelah pengujian integrasi
selesai dan kesalahan antar komponen diperbaiki. Pada tahap validasi, fokus
pengujian adalah pada tindakan yang terlihat oleh pengguna dan keluaran yang
dapat dikenali oleh pengguna dari sistem.
 Validasi software dicapai melalui serangkaian tes yang menunjukkan kesesuaian
dengan persyaratan. Rencana pengujian menjabarkan jenis tes yang akan
dilakukan, dan prosedur pengujian mendefinisikan kasus uji yang dirancang untuk
memastikan semua persyaratan fungsional terpenuhi, karakteristik perilaku dicapai,
semua konten akurat dan ditampilkan dengan benar, semua persyaratan kinerja
tercapai, dokumen benar, dan kebutuhan pengguna lainnya terpenuhi.
 Pada tahap validasi, fokus pada koneksi kelas-kelas hilang dan pengujian dilakukan
pada tindakan dan keluaran yang terlihat oleh pengguna. Untuk membantu dalam
menghasilkan tes validasi, tester dapat menggunakan kasus penggunaan yang
terdapat pada model persyaratan. Metode pengujian kotak hitam juga dapat
digunakan untuk menguji validasi, serta kasus uji yang berasal dari model perilaku
objek yang dibuat sebagai bagian dari analisis berorientasi objek.

40. 20.6 Testing Patterns
 Adalah tentang penggunaan pola sebagai mekanisme untuk menjelaskan solusi
untuk masalah desain tertentu dan dapat juga digunakan untuk mengusulkan
solusi untuk situasi rekayasa perangkat lunak lainnya dalam hal ini pengujian
perangkat lunak. Pola pengujian menggambarkan masalah pengujian umum
dan solusi yang dapat membantu tim pengembang perangkat lunak dalam
berkomunikasi tentang pengujian dengan lebih efektif dan memahami
kekuatan yang mengarah pada pendekatan pengujian tertentu. Pola pengujian
dijelaskan dengan cara yang sama seperti pola desain. Ada banyak pola
pengujian yang telah diusulkan dalam literatur. Beberapa contoh pola
pengujian meliputi PairTesting, SeparateTestInterface, dan ScenarioTesting.
Pembahasan yang komprehensif tentang pola pengujian ada di luar ruang
lingkup buku ini.

41. Chapter 21 : Software Testing— Specialized
Testing for Mobility

42. 21.1 Mobile Testing Guidelines
 Untuk melakukan pengujian MobileApps, beberapa panduan yang perlu
dipertimbangkan antara lain:
1. Memahami lanskap jaringan dan perangkat sebelum melakukan pengujian untuk
mengidentifikasi titik lemah.
2. Melakukan pengujian dalam kondisi real-world yang tidak terkontrol (field-based
testing).
3. Memilih alat pengujian otomatis yang tepat.
4. Menggunakan metode Weighted Device Platform Matrix untuk mengidentifikasi
kombinasi perangkat keras/platform yang paling kritis untuk diuji.
5. Memeriksa alur fungsional end-to-end di semua platform yang mungkin.
6. Melakukan pengujian kinerja, pengujian antarmuka pengguna (GUI), dan
pengujian kompatibilitas menggunakan perangkat aktual.
7. Mengukur kinerja hanya dalam kondisi lalu lintas nirkabel dan beban pengguna
yang realistis.

43. 21.2 The Testing Strategies
 Strategi pengujian aplikasi mobile mengadopsi prinsip dasar dari semua
pengujian perangkat lunak. Namun, karakteristik unik dari MobileApps
menuntut pertimbangan dari beberapa masalah khusus:
1. Pengujian pengalaman pengguna
2. Pengujian kompatibilitas perangkat
3. Pengujian kinerja
4. Pengujian konektivitas
5. Pengujian keamanan
6. Pengujian di lingkungan nyata
7. Pengujian sertifikasi

44. 21.3 User Experience Testing Issues
 Pada pasar yang ramai di mana produk menyediakan fungsionalitas yang
sama, pengguna akan memilih MobileApp yang paling mudah digunakan.
Antarmuka pengguna dan mekanisme interaksinya terlihat oleh pengguna
MobileApp. Oleh karena itu, penting untuk menguji kualitas pengalaman
pengguna yang disediakan oleh MobileApp untuk memastikan bahwa ia
memenuhi harapan penggunanya.
 Beberapa prosedur untuk menilai kegunaan antarmuka pengguna perangkat
lunak yang dibahas dalam Bab 12 dan 13 dapat digunakan untuk menilai
MobileApps. Demikian pula, banyak strategi yang digunakan untuk menilai
kualitas WebApps (Bagian 21.5) dapat digunakan untuk menguji bagian
antarmuka pengguna dari MobileApp. Ada lebih dari membangun antarmuka
pengguna MobileApp yang baik daripada hanya mengecilkan ukuran
antarmuka pengguna dari aplikasi desktop yang ada.

45. 21.3.1 Gesture Testing
 para pengujian perlu membuat program kerangka pengujian yang melakukan
panggilan ke fungsi-fungsi yang mensimulasikan kejadian gerakan. Ini sangat
mahal dan memakan waktu. Pengujian aksesibilitas untuk pengguna dengan
gangguan penglihatan menjadi sulit karena antarmuka gesture biasanya tidak
menyediakan umpan balik secara taktil atau auditori.
 Penting untuk melakukan pengujian kegunaan dan aksesibilitas untuk gesture
pada perangkat mobile seperti smartphone, dan memastikan bahwa gerakan
tersebut sesuai dengan standar dan konteks yang ditetapkan oleh perangkat
mobile atau platform. Selain itu, pengujian harus melibatkan pengguna yang
mewakili dan mencakup semua perangkat yang ditargetkan untuk
memperhitungkan perbedaan layar ketika menguji gesture pada MobileApp.
Idealnya, cerita pengguna atau kasus penggunaan ditulis dengan cukup rinci
sehingga bisa menjadi dasar untuk membuat skrip pengujian.

46. 21.3.2 Virtual Keyboard Input
 Pengujian gestur dan keyboard virtual pada MobileApp dapat dilakukan di
laboratorium maupun di lapangan. Jika terdapat masalah signifikan pada
keyboard virtual, alternatifnya adalah memastikan bahwa MobileApp dapat
menerima input dari perangkat lain seperti keyboard fisik atau input suara.
Dalam melakukan pengujian, penting untuk melibatkan pengguna yang
representatif dan mengambil perbedaan layar antar perangkat untuk
diakomodasi dalam pengujian gestur. Selain itu, perlu memastikan bahwa
gestur dan keyboard virtual MobileApp sesuai dengan standar dan konteks
yang telah ditetapkan untuk perangkat mobile atau platform yang digunakan.

47. 21.3.3 Voice Input and Recognition
 Pengujian kualitas dan keandalan input suara harus memperhatikan kondisi
lingkungan dan variasi suara individu. Kesalahan akan dibuat oleh pengguna
MobileApp dan oleh bagian-bagian sistem yang memproses input. MobileApp
harus diuji untuk memastikan bahwa input buruk tidak akan membuat
MobileApp atau perangkat crash. Sejumlah besar pengguna dan lingkungan
harus terlibat untuk memastikan bahwa MobileApp berfungsi dengan tingkat
kesalahan yang dapat diterima. Penting untuk mencatat kesalahan untuk
membantu pengembang meningkatkan kemampuan MobileApp untuk
memproses input suara.

48. 21.3.4 Alerts and Extraordinary
Conditions
 Bagian dari pengujian MobileApp harus berfokus pada masalah kegunaan terkait
peringatan dan pesan pop-up. Pengujian harus memeriksa kejelasan dan konteks
peringatan, kesesuaian lokasinya di layar perangkat, dan jika melibatkan bahasa asing,
verifikasi bahwa terjemahan dari satu bahasa ke bahasa lain benar.
 Banyak peringatan dan kondisi dapat dipicu secara berbeda pada berbagai perangkat
seluler atau oleh perubahan jaringan atau konteks. Meskipun banyak proses
penanganan pengecualian dapat disimulasikan dengan harness uji perangkat lunak,
Anda tidak boleh hanya mengandalkan pengujian di lingkungan pengembangan. Ini
menekankan kembali pentingnya pengujian MobileApp pada perangkat aktual.
 Pengujian pemulihan adalah tes sistem yang memaksa perangkat lunak gagal dengan
berbagai cara dan memverifikasi bahwa pemulihan dilakukan dengan benar. Jika
pemulihan dilakukan secara otomatis (dilakukan oleh sistem itu sendiri), mekanisme
inisialisasi ulang, checkpointing, pemulihan data, dan restart dievaluasi untuk
kebenarannya. Jika pemulihan memerlukan intervensi manusia, waktu rata-rata
perbaikan (MTTR) dievaluasi untuk menentukan apakah berada dalam batas yang
dapat diterima.

49. 21.4 Web Application Testing
 Berikut adalah langkah-langkah yang merangkum pendekatan tersebut:
1. Model konten untuk WebApp diperiksa untuk menemukan kesalahan.
2. Model antarmuka diperiksa untuk memastikan bahwa semua kasus penggunaan dapat
diakomodasi.
3. Model desain untuk WebApp diperiksa untuk menemukan kesalahan navigasi.
4. Antarmuka pengguna diuji untuk menemukan kesalahan dalam presentasi dan/atau
mekanik navigasi.
5. Setiap komponen fungsional diuji unit.
6. Navigasi di seluruh arsitektur diuji.
7. WebApp diimplementasikan dalam berbagai konfigurasi lingkungan yang berbeda dan diuji
untuk kompatibilitas dengan setiap konfigurasi.
8. Pengujian keamanan dilakukan dalam upaya untuk mengeksploitasi kerentanan dalam
WebApp atau dalam lingkungannya.
9. Pengujian kinerja dilakukan.
10. WebApp diuji oleh populasi pengguna akhir yang terkontrol dan dimonitor. Hasil interaksi
mereka dengan sistem dievaluasi untuk menemukan kesalahan.

50. 21.5 Web Testing Strategies
 Pengujian adalah proses menguji perangkat lunak dengan tujuan menemukan
(dan akhirnya memperbaiki) kesalahan. Filosofi dasar ini, yang pertama kali
disajikan di Bab 20, tidak berubah untuk WebApps. Bahkan, karena sistem dan
aplikasi berbasis web berada di dalam jaringan dan berinteraksi dengan banyak
sistem operasi, browser (atau perangkat komunikasi pribadi lainnya), platform
hardware, protokol komunikasi, dan aplikasi "backroom", pencarian kesalahan
menjadi tantangan yang signifikan.

51. 21.5.1 Content Testing
 Pengujian konten bertujuan untuk menemukan kesalahan dalam isi WebApp
sebelum digunakan oleh pengguna. Kesalahan dalam konten dapat berupa
kesalahan kecil seperti kesalahan pengetikan atau kesalahan dalam organisasi,
atau kesalahan yang lebih serius seperti informasi yang salah atau melanggar
hak cipta. Pengujian konten memiliki tiga tujuan utama: (1) menemukan
kesalahan sintaksis dalam dokumen berbasis teks, representasi grafis, dan
media lainnya; (2) menemukan kesalahan semantik dalam informasi yang
disajikan dalam konten; dan (3) menemukan kesalahan dalam organisasi atau
struktur konten yang disajikan kepada pengguna akhir.

52. 21.5.2 Interface Testing
 Interface testing adalah proses pengujian interaksi antarmuka dan memvalidasi
aspek estetika dari antarmuka pengguna. Strategi keseluruhan untuk pengujian
antarmuka adalah untuk (1) menemukan kesalahan terkait mekanisme
antarmuka tertentu (misalnya, kesalahan dalam pelaksanaan tautan menu atau
cara memasukkan data dalam formulir) dan (2) menemukan kesalahan dalam
cara antarmuka mengimplementasikan semantik navigasi, fungsi WebApp, atau
tampilan konten. Dalam hal ini, kecuali untuk spesifik WebApp, strategi
antarmuka yang dicatat di sini berlaku untuk semua jenis perangkat lunak klien-
server.

53. 21.5.3 Navigation Testing
 membahas tentang pengujian antarmuka (interface testing) dan pengujian
navigasi (navigation testing) pada aplikasi web. Pengujian antarmuka bertujuan
untuk menemukan kesalahan pada mekanisme antarmuka yang digunakan
oleh pengguna, seperti menu link atau pengisian data pada form. Sedangkan
pengujian navigasi bertujuan untuk memastikan bahwa semua mekanisme
navigasi dalam aplikasi web berfungsi dengan baik dan pengguna dapat
mencapai tujuan mereka dengan mudah.
 Pengujian antarmuka dan navigasi harus dilakukan oleh berbagai pihak yang
terlibat dalam proyek, termasuk tim pengembang, tim pengujian independen,
dan pengguna yang bukan ahli teknologi. Hal ini bertujuan untuk memastikan
bahwa pengujian dilakukan secara menyeluruh dan menghasilkan aplikasi web
yang mudah digunakan dan berfungsi dengan baik.

54. 21.6 Internationalization
 Internationalisasi adalah proses menciptakan produk perangkat lunak agar
dapat digunakan di beberapa negara dan dengan berbagai bahasa tanpa
memerlukan perubahan teknis. Lokalisasi adalah proses menyesuaikan aplikasi
perangkat lunak untuk digunakan di wilayah global tertentu dengan
menambahkan persyaratan khusus wilayah dan menerjemahkan elemen teks
ke bahasa yang sesuai. Upaya lokalilasi dapat melibatkan mata uang, budaya,
pajak, dan standar (teknis dan hukum) tiap negara, selain perbedaan bahasa.
Meluncurkan MobileApp di banyak bagian dunia tanpa mengujinya di sana
akan sangat bodoh.

55. 21.7 Security Testing
 membahas pentingnya melakukan pengujian keamanan pada sistem komputer
yang mengelola informasi sensitif atau dapat menyebabkan tindakan yang
dapat merugikan atau menguntungkan individu. Penetrasi keamanan dapat
dilakukan oleh berbagai pihak seperti hacker yang melakukan penetrasi untuk
bersenang-senang, karyawan yang tidak puas yang mencoba melakukan
penetrasi untuk balas dendam, atau individu yang tidak jujur yang mencoba
melakukan penetrasi untuk keuntungan pribadi.
 Pengujian keamanan bertujuan untuk memverifikasi bahwa mekanisme
perlindungan yang dibangun dalam suatu sistem benar-benar dapat
melindunginya dari penetrasi yang tidak sah. Namun, jika diberikan cukup
waktu dan sumber daya, pengujian keamanan yang menyeluruh pada akhirnya
akan dapat melakukan penetrasi pada sistem. Oleh karena itu, peran desainer
sistem adalah membuat penetrasi menjadi lebih mahal daripada nilai informasi
yang akan diperoleh.

56. 21.8 Performance Testing
 Pengujian kinerja digunakan untuk mengungkapkan masalah kinerja yang dapat
diakibatkan oleh kurangnya sumber daya sisi server, bandwidth jaringan yang tidak
sesuai, kapabilitas database yang tidak memadai, kapabilitas sistem operasi yang
rusak atau lemah, fungsionalitas WebApp yang dirancang dengan buruk, dan
masalah perangkat keras atau perangkat lunak lainnya yang dapat menyebabkan
kinerja client-server menurun. Tujuannya adalah dua kali lipat: (1) memahami
bagaimana sistem merespons saat loading (yaitu, jumlah pengguna, jumlah
transaksi, atau volume data secara keseluruhan), dan (2) mengumpulkan metrik
yang akan mengarah pada modifikasi desain untuk meningkatkan kinerja.
 Tes kinerja sering dikaitkan dengan tes stres dan biasanya memerlukan instrumen
perangkat keras dan lunak. Yaitu, seringkali perlu untuk mengukur penggunaan
sumber daya (misalnya, siklus prosesor) dengan cara yang teliti. Instrumen
eksternal dapat memantau interval eksekusi, mencatat acara (misalnya, interupsi)
saat terjadi, dan mengambil sampel status mesin secara teratur. Dengan
menginstruksikan sistem, tester dapat mengungkapkan situasi yang menyebabkan
penurunan dan kemungkinan kegagalan sistem.

57. 21.9 Real-Time Testing
 membahas tentang tantangan dalam melakukan pengujian (testing) pada aplikasi mobile
dan real-time. Pengujian aplikasi mobile dan real-time memerlukan pertimbangan
khusus terhadap elemen waktu dan asinkronisitas karena interaksi dengan lingkungan
hardware yang dapat menyebabkan kesalahan (error) pada pengolahan data oleh
software.
 Beberapa pengembang MobileApp menganjurkan untuk melakukan pengujian di
lingkungan pengguna atau testing in the wild, yang dirancang untuk menjadi responsif
terhadap perubahan seiring evolusi MobileApp. Karakteristik pengujian in the wild
mencakup lingkungan yang tidak terduga, perangkat keras yang unik, dan
keterhubungan yang kurang baik, baik dari sisi konektivitas maupun perangkat itu
sendiri.
 Untuk memastikan cakupan pengujian mencakup berbagai kombinasi perangkat dan
konteks penggunaan, disarankan untuk membuat weighted device platform matrix
(WDPM). Langkah-langkah membangun WDPM termasuk memilih perangkat dan sistem
operasi yang penting, menetapkan peringkat relatif untuk masing-masing perangkat dan
sistem operasi, dan menghitung produk dari setiap pasangan peringkat untuk masuk ke
dalam matriks.
 Meskipun pengujian pada perangkat asli dapat memberikan hasil yang lebih akurat,
pengujian menggunakan emulator atau cloud-based testing dapat memberikan alternatif
yang lebih efisien dan efektif dalam membangun lingkungan pengujian. Namun,
penggunaan cloud-based testing memiliki beberapa tantangan seperti keamanan data
dan kinerja jaringan yang tidak bisa sepenuhnya disimulasikan dalam lingkungan virtual.

58. 21.10 Testing AI Systems
 Kecerdasan buatan (AI) sering digunakan untuk mengadaptasi produk
perangkat lunak terhadap lingkungan pengguna, perilaku pengguna, atau untuk
memberikan karakter NPC yang realistis di dalam game. Teknik AI ini sering
menggunakan machine learning, data mining, statistik, heuristic programming,
atau sistem berbasis aturan yang berada di luar cakupan buku ini. Ada
beberapa masalah umum dalam pengujian sistem ini yang dapat diatasi
dengan teknik yang telah dibahas sebelumnya. Teknik AI menggunakan
informasi yang diperoleh dari para ahli atau disimpulkan dari sejumlah besar
observasi yang disimpan dalam sebuah data store. Data ini perlu diorganisir
dengan baik agar dapat diakses dan diperbarui dengan efisien jika produk
perangkat lunak harus responsif terhadap konteks atau mampu beradaptasi

59. 21.10.1 Static and Dynamic Testing
 Static testing merupakan teknik verifikasi perangkat lunak yang berfokus pada
pengujian melalui review daripada melalui pengujian eksekusi. Teknik ini
penting dilakukan untuk memastikan bahwa para ahli (stakeholders) yang
memahami domain aplikasi setuju dengan cara pengembang
merepresentasikan informasi dan penggunaannya dalam sistem AI. Seperti
halnya teknik verifikasi perangkat lunak lainnya, penting untuk memastikan
bahwa kode program merepresentasikan spesifikasi AI, yang berarti pemetaan
antara input dan output dari use case tercermin dalam kode tersebut.

60. 21.10.2 Model-Based Testing
 Ada lima langkah dalam teknik MBT:
1. Menganalisis model perilaku perangkat lunak yang ada atau membuat yang
baru.
2. Menentukan input yang akan memaksa perangkat lunak melakukan transisi dari
satu state ke state lain.
3. Mencatat output yang diharapkan pada setiap transisi state perangkat lunak.
4. Melakukan eksekusi kasus uji, bisa dilakukan secara manual atau
menggunakan alat pengujian otomatis.
5. Membandingkan hasil aktual dan yang diharapkan, serta melakukan tindakan
korektif jika diperlukan.

61. 21.11 Testing Virtual Environments
 Seorang pengembang perangkat lunak hampir tidak mungkin meramalkan bagaimana
pelanggan akan menggunakan program yang dibuat. Instruksi yang diberikan dapat salah
diinterpretasikan, kombinasi masukan yang aneh dapat digunakan, dan umpan balik yang
tampak jelas bagi tester dapat menjadi tidak jelas bagi pengguna di lapangan. Desainer
pengalaman pengguna sangat menyadari pentingnya mendapatkan umpan balik dari
pengguna sebenarnya pada awal proses prototyping untuk menghindari menciptakan
perangkat lunak yang tidak disukai pengguna.
 Uji penerimaan adalah serangkaian tes spesifik yang dilakukan oleh pelanggan dalam
upaya untuk mengungkapkan kesalahan produk sebelum menerima perangkat lunak dari
pengembang. Dilakukan oleh pengguna akhir daripada insinyur perangkat lunak,
pengujian penerimaan dapat berkisar dari "test drive" informal hingga serangkaian tes
skrip yang direncanakan dan dieksekusi secara sistematis.
 Jika produk perangkat lunak dibangun untuk satu pelanggan, wajar jika orang tersebut
melakukan serangkaian tes untuk memvalidasi semua persyaratan. Jika perangkat lunak
adalah simulasi virtual atau game yang dikembangkan sebagai produk untuk digunakan
oleh banyak pelanggan, tidak praktis untuk membiarkan setiap pengguna melakukan
pengujian penerimaan formal. Sebagian besar pembangun produk perangkat lunak
menggunakan proses yang disebut pengujian alpha dan beta untuk mengungkapkan
kesalahan yang hanya dapat ditemukan oleh pengguna akhir.

62. Lanjutan….
 Pengujian alpha dilakukan di situs pengembang oleh sekelompok pengguna
akhir yang mewakili. Perangkat lunak digunakan dalam pengaturan alami
dengan pengembang "mengawasi" pengguna dan mencatat kesalahan dan
masalah penggunaan. Pengujian alpha dilakukan dalam lingkungan yang
terkendali.
 Pengujian beta dilakukan di satu atau lebih situs pengguna akhir. Tidak seperti
pengujian alpha, pengembang umumnya tidak hadir. Oleh karena itu, pengujian
beta adalah aplikasi "langsung" dari perangkat lunak dalam lingkungan yang
tidak dapat dikontrol oleh pengembang. Pelanggan mencatat semua masalah
(nyata atau dibayangkan) yang ditemukan selama pengujian beta dan
melaporkannya secara berkala. Sebagai hasil dari masalah yang dilaporkan
selama pengujian beta, pengembang melakukan modifikasi dan kemudian
mempersiapkan untuk merilis produk perangkat lunak ke seluruh basis
pelanggan.

63. 21.11.1 Usability Testing
 Pengujian kegunaan (usability testing) mengevaluasi sejauh mana pengguna
dapat berinteraksi dengan aplikasi secara efektif dan sejauh mana aplikasi
dapat memandu tindakan pengguna, memberikan umpan balik yang bermakna,
dan menegakkan pendekatan interaksi yang konsisten. Pengujian kegunaan
difokuskan pada penilaian sejauh mana antarmuka aplikasi dapat
mempermudah hidup pengguna, bukan hanya pada makna objektif
interaktifnya. Pengembang berkontribusi pada desain pengujian kegunaan,
tetapi pada umumnya pengujian dilakukan oleh pengguna akhir. Pengujian
kegunaan dapat dilakukan pada berbagai level abstraksi yang berbeda: (1)
kegunaan mekanisme antarmuka tertentu (misalnya, formulir) dapat dinilai, (2)
kegunaan antarmuka virtual lengkap (yang mencakup mekanisme antarmuka,
objek data, dan fungsi terkait) dapat dievaluasi, atau (3) kegunaan aplikasi
virtual seluruh dunia dapat dipertimbangkan.

64. 21.11.2 Accessibility Testing
 Pengujian aksesibilitas adalah proses memverifikasi sejauh mana semua orang
dapat menggunakan sistem komputer tanpa memandang kebutuhan khusus
pengguna. Kebutuhan khusus yang paling umum dipertimbangkan untuk
aksesibilitas sistem komputer adalah: gangguan visual, pendengaran, gerakan,
dan kognitif. Banyak dari kebutuhan khusus ini berkembang seiring
bertambahnya usia seseorang. Sebagai profesi, pengembangan lingkungan
virtual belum melakukan pekerjaan yang baik dalam menyediakan sistem akses
yang kaya antarmuka grafis yang sangat bergantung pada interaksi sentuhan.
Masalah hanya berpindah dengan beralih ke asisten pribadi yang diaktifkan
suara seperti Alexa® atau Siri®. Bayangkan mencoba mengoperasikan
smartphone Anda tanpa menggunakan semua indera ini: penglihatan,
pendengaran, sentuhan, atau ucapan.

65. 21.11.3 Playability Testing
 Playability adalah tingkat keasyikan dan kegunaan suatu game atau simulasi
yang dimainkan oleh pengguna/pemain dan awalnya dikembangkan sebagai
bagian dari pengembangan video game. Playability game dipengaruhi oleh
kualitas game, yaitu usability, storyline, strategi, mekanika, realisme, grafik, dan
suara. Dengan munculnya simulasi realitas virtual/tertambah yang bertujuan
untuk memberikan hiburan atau kesempatan belajar (misalnya, seperti
pemecahan masalah yang disimulasikan), maka wajar untuk menggunakan
pengujian playability sebagai bagian dari pengujian kegunaan untuk lingkungan
virtual yang dibuat oleh MobileApp

66. 21.12 Testing Documentation and Help
Facilities
 Pengujian dokumentasi dapat dihadapi dalam dua tahap. Tahap pertama,
tinjauan teknis (Bab 16), meninjau dokumen untuk kejelasan editorial. Tahap
kedua, uji langsung, menggunakan dokumentasi bersama dengan program
yang sebenarnya.
 Mengejutkannya, pengujian langsung untuk dokumentasi dapat dihadapi
dengan menggunakan teknik-teknik yang analog dengan banyak metode
pengujian kotak hitam yang dibahas sebelumnya. Pengujian berbasis grafik
dapat digunakan untuk menggambarkan penggunaan program; partisi
kesetaraan dan analisis nilai batas dapat digunakan untuk mendefinisikan
berbagai kelas input dan interaksi yang terkait. MBT dapat digunakan untuk
memastikan bahwa perilaku yang didokumentasikan dan perilaku yang
sebenarnya bersesuaian. Penggunaan program kemudian dilacak melalui
dokumentasi.

67. Chapter 22 : Software Testing— Specialized
Testing for Mobility

68. 22.1 Software Configuration Management
 Keluaran dari proses perangkat lunak adalah informasi yang dapat dibagi
menjadi tiga kategori besar: (1) program komputer (baik dalam bentuk sumber
maupun eksekutabel), (2) produk kerja yang menjelaskan program komputer
(ditujukan pada berbagai pemangku kepentingan), dan (3) data atau konten
(terdapat dalam program atau eksternal terhadapnya). Dalam desain web atau
pengembangan game, mengelola perubahan pada item konten multimedia bisa
lebih menuntut daripada mengelola perubahan pada perangkat lunak atau
dokumen. Item yang menyusun seluruh informasi yang dihasilkan sebagai
bagian dari proses perangkat lunak secara kolektif disebut konfigurasi
perangkat lunak.

69. 22.1.1 An SCM Scenario
 Bagian ini membahas tentang manajemen konfigurasi perangkat lunak. Ada
tiga kategori informasi yang dihasilkan dari proses perangkat lunak yaitu
program komputer, produk kerja yang mendeskripsikan program komputer, dan
data atau konten yang terkandung di dalam atau luar program. Saat mengelola
perubahan pada isi konten multimedia, dapat lebih sulit dibandingkan dengan
mengelola perubahan pada perangkat lunak atau dokumentasi. Semua
informasi yang dihasilkan dalam proses perangkat lunak disebut sebagai
konfigurasi perangkat lunak.

70. 22.1.2 Elements of a Configuration
Management System
 Susan Dart [Dar01] mengidentifikasi empat elemen penting yang harus ada ketika
sebuah sistem manajemen konfigurasi dikembangkan:
1. Elemen komponen. Sebuah set alat yang digabungkan dalam sistem manajemen file
(misalnya, database) yang memungkinkan akses dan manajemen setiap item konfigurasi
perangkat lunak.
2. Elemen proses. Kumpulan prosedur dan tugas yang mendefinisikan pendekatan yang
efektif terhadap manajemen perubahan (dan kegiatan terkait) untuk semua pihak yang
terlibat dalam manajemen, rekayasa, dan penggunaan perangkat lunak komputer.
3. Elemen konstruksi. Sebuah set alat yang mengotomatisasi konstruksi perangkat lunak
dengan memastikan bahwa seperangkat komponen yang divalidasi dengan benar (yaitu,
versi yang benar) telah dirakit
4. Elemen manusia. Sebuah set alat dan fitur proses (meliputi elemen CM lainnya) yang
digunakan oleh tim perangkat lunak untuk menerapkan SCM yang efektif.

71. 22.1.3 Baselines
 Baselines adalah konsep manajemen konfigurasi perangkat lunak yang
membantu Anda mengontrol perubahan tanpa menghambat perubahan yang
dibenarkan. IEEE [IEE17] mendefinisikan baseline sebagai:
 Spesifikasi atau produk yang telah direview secara resmi dan disepakati, yang
selanjutnya berfungsi sebagai dasar untuk pengembangan lebih lanjut, dan
hanya dapat diubah melalui prosedur kontrol perubahan resmi.
 Sebelum item konfigurasi perangkat lunak menjadi baseline, perubahan dapat
dilakukan dengan cepat dan secara informal. Namun, begitu sebuah baseline
ditetapkan, perubahan dapat dilakukan, tetapi prosedur formal yang spesifik
harus diterapkan untuk mengevaluasi dan memverifikasi setiap perubahan.

72. 22.1.4 Software Configuration Items
 Pada dasarnya, Software Configuration Item (SCI) adalah informasi yang
diciptakan sebagai bagian dari proses rekayasa perangkat lunak. Dalam
praktiknya, SCI dapat berupa satu bagian kecil dari spesifikasi atau satu test
case dalam sekumpulan besar test case. Namun, SCI biasanya diorganisir
untuk membentuk objek konfigurasi yang dapat di-katalogkan dalam database
proyek dengan satu nama. Objek konfigurasi memiliki nama, atribut, dan
terhubung dengan objek lain melalui relasi. Objek-objek konfigurasi seperti
DesignSpecification, DataModel, ComponentN, SourceCode, dan
TestSpecification, meskipun didefinisikan secara terpisah, memiliki hubungan
antara satu sama lain yang ditunjukkan dengan panah pada diagram. Panah
melengkung menunjukkan hubungan komposisional di mana DataModel dan
ComponentN merupakan bagian dari objek DesignSpecification. Panah
berganda menunjukkan hubungan antar objek di mana jika terjadi perubahan
pada objek SourceCode, maka hubungan antar objek tersebut memungkinkan
untuk menentukan objek atau SCI lain yang mungkin terpengaruh.

73. 22.1.5 Management of Dependencies
and Changes
 membahas tentang manajemen konfigurasi perangkat lunak, dimulai dengan
definisi dari baseline sebagai konsep manajemen konfigurasi yang membantu
mengontrol perubahan tanpa menghalangi perubahan yang dibenarkan.
Kemudian, dijelaskan bahwa item konfigurasi perangkat lunak (SCI) dapat
berupa bagian dari spesifikasi atau kasus uji. SCI ini dikelompokkan menjadi
objek konfigurasi yang memiliki nama, atribut, dan hubungan dengan objek lain.
Dalam manajemen konfigurasi perangkat lunak, traceability matrix digunakan
untuk memetakan ketergantungan antara persyaratan, keputusan arsitektur,
dan penyebab kegagalan.

74. 22.2 The SCM Repository
 Repository SCM adalah kumpulan mekanisme dan struktur data yang
memungkinkan tim pengembangan software untuk mengelola perubahan
dengan cara yang efektif. Repository ini menyediakan fungsi yang jelas seperti
sistem manajemen basis data modern dengan memastikan integritas data,
berbagi, dan integrasi. Selain itu, repository SCM menyediakan pusat integrasi
alat-alat perangkat lunak, pusat aliran proses perangkat lunak, dan dapat
memberlakukan struktur dan format yang seragam untuk produk kerja rekayasa
perangkat lunak.
 Untuk mencapai kemampuan ini, repository SCM didefinisikan dalam istilah
meta-model. Meta-model menentukan bagaimana informasi disimpan di dalam
repository, bagaimana data dapat diakses oleh alat dan dilihat oleh insinyur
perangkat lunak, bagaimana keamanan dan integritas data dapat
dipertahankan, dan seberapa mudah model yang ada dapat diperluas untuk
menampung kebutuhan baru.

75. 22.2.1 General Features and Content
 Repositori yang kuat menyediakan dua jenis layanan: (1) layanan yang sama seperti
yang diharapkan dari sistem manajemen basis data yang canggih dan (2) layanan
yang khusus untuk lingkungan rekayasa perangkat lunak.
 Repositori yang melayani tim rekayasa perangkat lunak harus juga (1) terintegrasi
dengan atau mendukung langsung fungsi manajemen proses, (2) mendukung aturan
tertentu yang mengatur fungsi SCM dan data yang dikelola dalam repositori, (3)
menyediakan antarmuka ke alat rekayasa perangkat lunak lainnya, dan (4) dapat
menampung penyimpanan objek data yang kompleks (misalnya teks, grafik, video,
audio).

76. 22.2.2 SCM Features
 Toolset repository harus menyediakan dukungan untuk fitur-fitur berikut:
1. Versioning: Repository harus dapat menyimpan semua versi dari produk kerja yang dibuat selama
proyek untuk memungkinkan manajemen rilis produk yang efektif dan memperbolehkan pengembang
untuk kembali ke versi sebelumnya selama pengujian dan debugging.
2. Kontrol objek yang beragam: Repository harus dapat mengontrol berbagai jenis objek, termasuk teks,
grafik, bitmaps, dokumen kompleks, dan objek unik seperti definisi layar dan laporan, file objek, data uji,
dan hasil uji. Repository yang matang melacak versi objek dengan tingkat granularitas yang sembarang.
3. Pelacakan ketergantungan dan manajemen perubahan: Repository mengelola berbagai jenis
hubungan antara elemen data yang disimpan di dalamnya. Ini meliputi hubungan antara entitas dan
proses perusahaan, antara bagian desain aplikasi, antara komponen desain dan arsitektur informasi
perusahaan, antara elemen desain dan deliverables, dan lain-lain. Kemampuan untuk melacak semua
hubungan ini sangat penting untuk integritas informasi yang disimpan di dalam repository dan untuk
menghasilkan deliverables berdasarkan informasi tersebut.
4. Pelacakan persyaratan: Fungsi khusus ini tergantung pada manajemen tautan dan memberikan
kemampuan untuk melacak semua komponen desain dan konstruksi serta deliverables yang dihasilkan
dari spesifikasi persyaratan tertentu (pelacakan ke depan). Selain itu, ini menyediakan kemampuan untuk
mengidentifikasi persyaratan mana yang menghasilkan produk kerja tertentu (pelacakan ke belakang).
5. Manajemen Konfigurasi: Fasilitas manajemen konfigurasi melacak serangkaian konfigurasi yang
mewakili tonggak proyek tertentu atau rilis produk
6. Audit Trails : digunakan untuk mencatat informasi tambahan tentang kapan, mengapa, dan oleh siapa
perubahan dilakukan pada suatu elemen dalam repositori.

77. 22.3 Version Control Systems
 Kontrol versi menggabungkan prosedur dan alat untuk mengelola versi berbeda
dari objek konfigurasi yang dibuat selama proses perangkat lunak. Sistem
kontrol versi mengimplementasikan atau secara langsung terintegrasi dengan
empat kemampuan utama: (1) sebuah database proyek (repository) yang
menyimpan semua objek konfigurasi yang relevan, (2) kemampuan manajemen
versi yang menyimpan semua versi objek konfigurasi (atau memungkinkan
setiap versi dibangun menggunakan perbedaan dari versi sebelumnya), (3)
fasilitas make yang memungkinkan Anda mengumpulkan semua objek
konfigurasi yang relevan dan membangun versi tertentu perangkat lunak.
Selain itu, sistem kontrol versi dan sistem kontrol perubahan sering
mengimplementasikan (4) kemampuan pelacakan masalah (juga disebut
pelacakan bug) yang memungkinkan tim untuk merekam dan melacak status
semua masalah yang belum terselesaikan yang terkait dengan setiap objek
konfigurasi.

78. 22.4 Continuous Integration
 Praktik terbaik untuk SCM meliputi: (1) menjaga jumlah varian kode kecil, (2)
melakukan uji coba secara awal dan sering, (3) melakukan integrasi secara awal dan
sering, dan (4) menggunakan alat untuk mengotomatisasi pengujian, pembuatan, dan
integrasi kode. Integrasi terus-menerus (CI) penting bagi pengembang agile yang
mengikuti alur kerja DevOps. CI juga menambah nilai pada SCM dengan memastikan
bahwa setiap perubahan segera diintegrasikan ke dalam sumber kode proyek,
dikompilasi, dan diuji secara otomatis.
 CI menawarkan beberapa keuntungan konkret bagi tim pengembangan [Mol12]:
1. Umpan balik yang dipercepat. Memberi tahu pengembang segera ketika integrasi
gagal memungkinkan perbaikan dilakukan saat jumlah perubahan yang dilakukan masih
sedikit.
2. Meningkatkan kualitas. Membangun dan mengintegrasikan perangkat lunak kapan
saja yang diperlukan memberikan keyakinan pada kualitas produk yang dikembangkan.
3. Risiko yang berkurang. Integrasi komponen secara dini menghindari risiko tahap
integrasi yang panjang karena kegagalan desain ditemukan dan diperbaiki lebih awal.
4. Pelaporan yang ditingkatkan. Memberikan informasi tambahan (misalnya, metrik
analisis kode) memungkinkan akuntansi status konfigurasi yang lebih akurat.


79. 22.5 The Change Management Process
 Proses manajemen perubahan perangkat lunak mendefinisikan serangkaian
tugas yang memiliki empat tujuan utama: (1) mengidentifikasi semua item yang
secara kolektif mendefinisikan konfigurasi perangkat lunak, (2) mengelola
perubahan pada satu atau beberapa item tersebut, (3) memfasilitasi
pembangunan berbagai versi aplikasi, dan (4) memastikan bahwa kualitas
perangkat lunak dipertahankan seiring evolusi konfigurasi dari waktu ke waktu.

80. 22.5.1 Change Control
 Untuk proyek perangkat lunak yang besar, perubahan yang tidak terkontrol
dapat dengan cepat menyebabkan kekacauan. Untuk proyek seperti itu, kontrol
perubahan menggabungkan prosedur manusia dan alat otomatis untuk
menyediakan mekanisme untuk mengontrol perubahan. Proses kontrol
perubahan diilustrasikan secara skematis dalam Gambar 22.6. Permintaan
perubahan diajukan dan dievaluasi untuk menilai kelayakan teknis, efek
samping potensial, dampak keseluruhan pada objek konfigurasi dan fungsi
sistem, serta perkiraan biaya perubahan. Hasil evaluasi disajikan sebagai
laporan perubahan, yang digunakan oleh otoritas kontrol perubahan (CCA) -
orang atau kelompok yang membuat keputusan akhir tentang status dan
prioritas perubahan. Pesanan perubahan rekayasa (ECO) dibuat untuk setiap
perubahan yang disetujui. ECO menjelaskan perubahan yang akan dilakukan,
kendala yang harus dihormati, dan kriteria untuk tinjauan dan audit.

81. 22.5.2 Impact Management
 Setiap kali perubahan dibuat pada suatu proyek perangkat lunak, ketergantungan
antar produk kerja perangkat lunak harus dipertimbangkan. Manajemen dampak
mencakup pekerjaan yang diperlukan untuk memahami ketergantungan ini dan
mengendalikan efeknya pada SCI lainnya (dan orang-orang yang bertanggung
jawab atas mereka).
 Manajemen dampak dilakukan dengan tiga tindakan. Pertama, jaringan dampak
mengidentifikasi anggota tim perangkat lunak (dan pemangku kepentingan lainnya)
yang mungkin memengaruhi atau dipengaruhi oleh perubahan yang dibuat pada
perangkat lunak. Definisi yang jelas dari arsitektur perangkat lunak (Bab 10) sangat
membantu dalam pembuatan jaringan dampak. Selanjutnya, manajemen dampak
ke depan menilai dampak perubahan sendiri pada anggota jaringan dampak dan
kemudian memberi tahu anggota dampak dari perubahan tersebut. Akhirnya,
manajemen dampak ke belakang mengevaluasi perubahan yang dilakukan oleh
anggota tim lain dan dampaknya pada pekerjaan Anda serta memasukkan
mekanisme untuk mengurangi dampak tersebut.

82. 22.5.3 Configuration Audit
 Identifikasi, pengendalian versi, dan pengendalian perubahan membantu Anda
mempertahankan keteraturan dalam situasi yang sebaliknya akan kacau dan
sangat dinamis. Namun, bahkan mekanisme pengendalian yang paling sukses
hanya melacak perubahan hingga ECO dibuat. Bagaimana sebuah tim
perangkat lunak dapat memastikan bahwa perubahan telah diimplementasikan
dengan benar? Jawabannya adalah dengan dua hal: (1) tinjauan teknis dan (2)
audit konfigurasi perangkat lunak.

83. 22.5.4 Status Reporting
 Configuration status reporting (CSR) merupakan tugas SCM yang menjawab
pertanyaan seperti (1) Apa yang terjadi? (2) Siapa yang melakukannya? (3)
Kapan itu terjadi? (4) Apa yang akan dipengaruhi selain itu? Aliran informasi
untuk CSR ditunjukkan dalam Gambar 22.6. Setiap kali terjadi perubahan pada
suatu konfigurasi, pastikan bahwa setiap orang yang tercantum dalam daftar
"need to know" diberitahu. Setiap kali sebuah SCI diberikan identifikasi baru
atau diperbarui, catatan CSR dibuat. Setiap kali sebuah perubahan disetujui
oleh CCA (yaitu, ECO dikeluarkan), catatan CSR dibuat. Output dari CSR dapat
ditempatkan dalam database online atau situs web, sehingga pengembang
perangkat lunak atau staf pendukung dapat mengakses informasi perubahan
dengan kata kunci tertentu. Selain itu, laporan CSR dihasilkan secara berkala
dan ditujukan untuk menjaga agar manajemen dan praktisi tetap mengetahui
perubahan penting.

84. 22.6 Mobility and Agile Change
Management
 MobileApps, WebApps, dan game development memerlukan metode
pengembangan khusus karena sifatnya yang cenderung selalu berubah.
Developer menggunakan model proses iteratif, inkremental yang sering kali
berprinsip pada agile software development. Setiap inkremen cenderung
mengimplementasikan perubahan yang mengarah pada konten yang lebih baik,
usability, estetika, navigasi, performa, dan keamanan yang lebih kuat. Tim agile
app dan game development harus memeluk perubahan meskipun sering kali
menganggap manajemen konfigurasi perangkat lunak memiliki karakteristik
yang berat dan formal. Namun, prinsip, praktik, dan alat SCM tetap diperlukan
dalam pengembangan mobile projects dengan cara yang sesuai dengan
kebutuhan khusus mereka.

85. 22.6.1 e-Change Control
 Dalam pengembangan aplikasi WebApp dan MobileApp, proses pengendalian
perubahan konvensional terlalu lambat. Oleh karena itu, proses pengendalian
perubahan dapat dimodifikasi dengan membagi setiap permintaan perubahan
ke dalam empat kelas dan dikelola sesuai dengan algoritma yang sesuai
dengan kelas tersebut.
 Kelas 1 dan 2 dapat dikelola secara informal dan dilakukan dengan pendekatan
agile. Sedangkan kelas 3 dan 4 membutuhkan dokumentasi dan prosedur
review formal yang lebih lengkap. Sebuah deskripsi perubahan harus dibuat
untuk kedua jenis kelas perubahan dan didistribusikan ke semua anggota tim
untuk menilai dampak perubahan tersebut.

86. 22.6.2 Content Management
 Content management berkaitan dengan manajemen konfigurasi dalam arti
bahwa sistem manajemen konten (CMS) menetapkan proses (didukung oleh
alat yang sesuai) yang memperoleh konten yang ada (dari berbagai objek
konfigurasi aplikasi dan/atau game), mengatur konten tersebut agar dapat
disajikan kepada pengguna akhir, dan kemudian memberikannya ke lingkungan
sisi klien untuk ditampilkan.

87. 22.6.3 Integration and Publishing
 Sistem manajemen konten (Content Management System/CMS) dapat digunakan
untuk membuat layanan web yang menyadari konteks MobileApps dan
memperbarui adegan tingkat game saat berjalan, serta membangun halaman web
dinamis. Terdapat tiga subsistem terintegrasi dalam CMS: subsistem pengumpulan,
manajemen, dan penerbitan.
 Subsistem pengumpulan berisi semua tindakan yang diperlukan untuk membuat
atau memperoleh konten, serta fungsi teknis yang diperlukan untuk mengubah
konten menjadi bentuk yang dapat direpresentasikan oleh bahasa markup
(misalnya, HTML, XML) dan mengorganisir konten menjadi layar yang dapat
ditampilkan secara efisien di sisi klien.
 Subsistem manajemen digunakan untuk menyimpan konten dalam repositori,
melakukan katalogisasi untuk pengambilan dan penggunaan selanjutnya, dan
memberi label untuk mendefinisikan status saat ini, versi konten yang tepat, serta
objek konten terkait. Subsistem ini juga melaksanakan manajemen konfigurasi.
 Subsistem penerbitan digunakan untuk mengekstrak konten dari repositori,
mengubahnya menjadi bentuk yang cocok untuk penerbitan dan memformat
sehingga dapat ditransmisikan ke layar sisi klien. Subsistem ini mencapai tugas-
tugas ini menggunakan serangkaian template.

88. 22.6.4 Version Control
 Saat aplikasi atau game berkembang melalui serangkaian peningkatan,
beberapa versi yang berbeda dapat ada pada saat yang sama. Salah satu versi
(aplikasi operasional saat ini) tersedia melalui internet untuk pengguna akhir;
versi lain (peningkatan aplikasi selanjutnya) mungkin berada dalam tahap akhir
pengujian sebelum diterapkan; versi ketiga sedang dalam pengembangan dan
mewakili pembaruan utama dalam konten, estetika antarmuka, dan
fungsionalitas. Objek konfigurasi harus jelas didefinisikan agar setiap objek
dapat dikaitkan dengan versi yang tepat. Tanpa beberapa jenis kontrol,
pengembang dan pencipta konten mungkin akan menimpa perubahan satu
sama lain.

89. 22.6.5 Auditing and Reporting
 Dalam pengembangan game atau aplikasi, fungsi auditing dan pelaporan
dihilangkan sedikit demi fleksibilitas. Namun, fungsi-fungsi tersebut tidak
sepenuhnya dihilangkan. Setiap objek yang masuk atau keluar dari repository
direkam dalam log yang dapat diperiksa kapan saja. Laporan log yang lengkap
dapat dibuat sehingga semua anggota tim memiliki kronologi perubahan
selama periode waktu tertentu. Selain itu, pemberitahuan otomatis melalui
email dapat dikirim setiap kali objek masuk atau keluar dari repository, ditujukan
kepada pengembang dan pemangku kepentingan yang tertarik.

90. Terimakasih….