Certified in Software Quality Assurance (CiSQA TPCC) 26, 27, 28 September 2016, TelkomPCC Bandung

Transkripsi

1 Certified in Software Quality Assurance (CiSQA TPCC) 26, 27, 28 September 2016, TelkomPCC Bandung

2 Tujuan Pelatihan & Sertifikasi? Setelah mengikuti pelatihan ini, peserta : Memahami aspek software quality assurance, quality control, dan kualitas software beserta praktik, alat, serta teknik terbaik untuk para pengembang software. Memahami pencapaian kualitas software pada tingkat komponen dan mengeksplorasi kualitas proses dari sudut pandang implementasi. Memahami dasar framework yang digunakan dalam melakukan aktivitas pengujian kualitas software dan mengetahui langkah-langkah yang diperlukan untuk mencapai kesesuaian dengan model-model tersebut. Mampu menyusun dokumentasi aktivitas pengujian software.

3 Proses Sertifikasi? 1) Proses Pendaftaran Peserta Sertifikasi yang dapat dilakukan oleh peserta sertifikasi yang dipandu oleh Marketing 2) Kegiatan Pelatihan Materi Sertifikasi dilakukan oleh tenaga pengajar (Instruktur). 3) Kegiatan Bootcamp Materi Soal Sertifikasi dilaksanakan sebelum kegiatan ujian sertifikasi, dan dilaksanakan oleh tenaga pengajar (Instruktur). 4) Kegiatan Ujian Sertifikasi dilakukan peserta sertifikasi dengan durasi 90 Menit dengan jumlah soal 50 soal. 5) Proses penilaian dilakukan oleh Penguji Sertifikasi 6) Setelah proses penilaian, maka ditentukan hasil kelulusan sertifikasi.

4 Materi Sertifikasi? MODUL 01 : INTRODUCTION TO SOFTWARE QUALITY ASSURANCE MODUL 02 : SOFTWARE QUALITY FACTORS MODUL 03 : DEVELOPMENTS & QUALITY PLANS MODUL 04 : SOFTWARE QUALITY ASSURANCE COMPONENTS MODUL 05 : SOFTWARE TESTING STRATEGY & IMPLEMENTATION

5 MODUL 01 INTRODUCTION TO SOFTWARE QUALITY ASSURANCE

6 Introduction To Software Quality Assurance What is software? Software IEEE definition: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of computer system.

7 Introduction To Software Quality Assurance IEEE Definition is almost identical to the ISO def. ( ISO/IEC ) Computer programs ( Code ) Procedures Documentation Data necessary for operation the SW system.

8 Introduction To Software Quality Assurance Kesimpulan dari dua definisi tersebut diatas : Software quality assurance selalu meliputi : Kualitas Kode Kualitas Dokumentasi Dan Kualitas Data Software yang diperlukan

9 Introduction To Software Quality Assurance SW errors, faults and failures Software error : kegagalan perangkat lunak terletak pada kesalahan software yang dibuat oleh programmer. Kesalahan bisa menjadi kesalahan tata bahasa dalam satu atau lebih dari baris kode, atau kesalahan logis dalam melaksanakan satu atau lebih dari kebutuhan klien.tidak semua Software errors bisa menyebabkan Software faults. Software errors dapat menyebabkan fungsi yang tidak tepat dari perangkat lunak secara umum atau dalam aplikasi tertentu Pada software failures dapat menganggu pengguna software tersebut

10 Introduction To Software Quality Assurance Example : hubungan antara SW Error, Faults, and Failure. Dalam gambar ini, proses pengembangan menghasilkan 17 kesalahan software, hanya 8 yang menjadi kesalahan software. Dari kesalahan tersebut hanya tiga yang dipilih sebagai kegagalan perangkat lunak. pengembang dan pengguna memiliki pandangan yang berbeda dari software. Sementara pengembang tertarik pada kesalahan software dan faults. pengguna software khawatir tentang kegagalan perangkat lunak.

11 Introduction To Software Quality Assurance Hubungan antara Software faults dan Software failures Apakah semua kesalahannya software berakhir dengan kegagalan software? Jawabannya adalah belum tentu Kesalahan software menjadi kegagalan software hanya ketika diaktifkan.

12 Introduction To Software Quality Assurance Klasifikasi penyebab software error : Software errors adalah penyebab jeleknya kualitas software Software errors dapat terjadi dikarenakan Code error Dokumentasi error Data Software error Penyebab dari kesalahan tersebut diatas adalah manusia

13 Introduction To Software Quality Assurance Sembilan penyebab software error : Kesalahan dalam pendefinisian kebutuhan pengembangan Software Kegagalan komunikasi antara klien dan pengembang Penyimpangan yang disengaja dari persyaratan SW kesalahan desain logis kesalahan coding Ketidakpatuhan terhadap dokumentasi dan petunjuk coding Kekurangan dari proses pengujian kesalahan prosedur kesalahan dokumentasi

14 Introduction To Software Quality Assurance Definisi Kebutuhan pengembangan software yang keliru Pendefinisisan yang keliru dari apa yang dibutuhkan dalam pengembangan software Tidak adanya persyaratan/kebutuhan yang vital dalam pengembangan Software Definfi persyaratan/kebutuhan pengembangan software yang tidak lengkap Mencantumkan kebutuhan pengembangan yang tidak perlu

15 Introduction To Software Quality Assurance Kegagalan komunikasi antara klien dan pengembang software Kesalahpahaman akibat jeleknya komunikasi (miskomunikasi) antara klien dengan pengembang Kesalahpahaman perubahan kebutuhan/prasyarat dari klien yang disampaikan pada pengembang o Dalam bentuk tertulis o Melalui komunikasi o Dan respon terhadap kesalahan desain

16 Introduction To Software Quality Assurance Penyimpangan dari apa yang dipersyaratkan pengembangan software Pengembang software menggunakan modul yang diambil dari proyek yang sebelumnya Karena tekanan anggaran & waktu Karena perbaikan yang tidak disetujui

17 Introduction To Software Quality Assurance Logical design errors : Kesalahan ini berasal dari sistem arsitektur, sistem analis dan software engginer seperti : Algoritma yang salah Proses definisi yang memuat kesalahan sequencing Definisi yang keliru terhadap batas kondisi Kelalaian definisi mengenai reaksi untuk operasi ilegal

18 Introduction To Software Quality Assurance Coding errors : Kesalahpahaman dalam pendokumentasian desain Proses definisi yang memuat kesalahan sequencing Kesalahan linguistik dalam bahasa pemrograman Kesalahan dalam penerapan Case dan tool development lain

19 Introduction To Software Quality Assurance Beberapa Kelemahan dari proses pengujian: Rencana pengujian yang tidak lengkap Kegagalan dalam pendokumentasian dan laporan error dan fault Kegagalan untuk tidak segera memperbaiki kesalahan software yang terdeteksi akibat dari tidak ada alasan indikasi kesalahan Tidak lengkapnya koreksi kesalahan yang terdetiksi

20 Introduction To Software Quality Assurance SOFTWARE QUALITY - DEFINISI IEEE 1. Sejauh mana sistem, komponen, atau proses memenuhi persyaratan yang ditentukan. 2. Sejauh mana suatu sistem, komponen, atau proses memenuhi kebutuhan pelanggan atau harapan pengguna

21 Introduction To Software Quality Assurance Software Quality Assurance - The IEEE Definition 1. Pola terencana dan sistematis dari semua tindakan yang diperlukan untuk memberikan keyakinan memadai bahwa item atau produk yang dihasilkan sesuai dengan persyaratan teknis yang ditetapkan. 2. Sejauh mana suatu sistem, komponen, atau proses memenuhi kebutuhan pelanggan atau harapan pengguna

22 Introduction To Software Quality Assurance SQA - Perluasan Definisi Sebuah rencana tindakan sistematis, yang diperlukan untuk memberikan keyakinan bahwa proses pengembangan perangkat lunak atau pemeliharaan produk perangkat lunak sistem sesuai dengan yang ditetapkan persyaratan teknis fungsional serta dengan persyaratan manajerial sesuai jadwal dan beroperasi dalam batas-batas anggaran.

23 Introduction To Software Quality Assurance Software Quality Assurance Vs. Software Quality Control Quality Control: seperangkat kegiatan yang dirancang untuk mengevaluasi kualitas dari produk yang dikembangkan atau diproduksi. Ini terjadi sebelum produk dikirim ke klien. Quality Assurance: tujuan utamanya adalah untuk meminimalkan biaya dan menjamin kualitas dengan berbagai kegiatan yang dilakukan di seluruh penyebab kesalahan, dan mendeteksi serta memperbaiki kesalahan dari awal proses pengembangan.

24 Introduction To Software Quality Assurance Discussion Jelaskan perbedaan Software Error, Software Fault, dan Software Failure? jelaskan perbedaan status perangkat lunak yang tidak diinginkan tersebut? Jelaskan perbedaan definisi SQA menurut IEEE dan menurut Definisi perluasan? Menurut definisi IEEE dari SQA, kontrol kualitas (QC) tidak disamakan dengan jaminan kualitas (QA). Mengapa?

25 Introduction To Software Quality Assurance Discussion Seorang programmer mengklaim bahwa karena hanya sebagian kecil dari SW Error berubah menjadi SW Failure, adalah tidak perlu untuk membuat investasi besar dalam pencegahan dan penghapusan kesalahan perangkat lunak? Apakah Anda setuju dengan pandangan ini?

26 Introduction To Software Quality Assurance Discussion George Wise adalah programmer yang luar biasa. Pengujian modul softwarenya mengungkapkan sangat sedikit kesalahan, jauh lebih sedikit daripada rata-rata tim. Dia menjaga selalu jadwalnya, dan sangat jarang ia terlambat dalam menyelesaikan tugasnya. Dia selalu menemukan cara sendiri untuk memecahkan kesulitan pemrograman, dan menggunakan gaya pengkodean versi sendiri. Dia tidak suka mempersiapkan dokumen yang diperlukan, dan jarang menggunakan template dokumen pada tim. Sehari setelah menyelesaikan tugas yang berat, namun diselesaikan tepat waktu, ia dipanggil ke kantor kepala departemen perangkat lunak. Bukannya dipuji karena prestasi (seperti yang ia harapkan), dia diperingatkan oleh chief engineer software bahwa ia akan dipecat kecuali dia mulai sepenuhnya mematuhi coding dan dokumentasi petunjuk yang ada pada tim

27 Introduction To Software Quality Assurance MODUL 02 SOFTWARE QUALITY FACTORS

28 Introduction To Software Quality Assurance Klasifikasi Software Requirements yang menjadi faktor kualitas software Menurut Mc Call Kualitas Software dibagi menjadi 3 bagian yaitu : 1. Product Operation 2. Product Revision 3. Product Transition

29 Introduction To Software Quality Assurance Product operation Correctness (Kebenaran), tingkat pemenuhan program terhadap kebutuhan yang dispesifikasikan dan memenuhi tujuan/ misi konsumen. Biasanya outputnya memiliki dimensi satuan yang pasti. Reliability (Keandalan), tingkat kemampuan program yang diharapkan dapat menampilkan fungsi yang dimaksud dengan presisi yang ditetapkan. persyaratan keandalan berurusan dengan kegagalan untuk menyediakan layanan. Mereka menentukan maksimum yang diizinkan tingkat kegagalan sistem perangkat lunak, dan dapat merujuk pada seluruh sistem atau untuk satu atau lebih fungsi yang terpisah. Efficiency (Efisiensi), jumlah sumberdaya yang diproses dan kode yang diperlukan oleh program untuk melaksanakan fungsi tersebut Integrity (Integritas), tingkat kemampuan pengawasan akses terhadap data atau software oleh orang-orang tertentu. Usability (Kegunaan), usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan masukan dan mengartikan keluaran oleh program

30 Introduction To Software Quality Assurance Product Revision 1. Maintainability, usaha yang diperlukan untuk menetapkan dan memperbaiki kesalahan dalam program. 2. Flexibility, usaha yang diperlukan untuk memodifikasi program operasional 3. Testability, usaha yang diperlukan untuk menguji program untuk memastikan bahwa program melaksanakan fungsi yang ditetapkan

31 Introduction To Software Quality Assurance Product Transition Portability, usaha yang diperlukan untuk memindahkan program dari hardware/ lingkungan sistem software tertentu ke yang lainnya. Reusability, tingkat kemampuan program/ bagian dari program yang dapat dipakai ulang dalam aplikasi lainnya, berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh program Interoperability, usaha yang diperlukan untuk menggabungkan satu sistem dengan yang lainnya.

32 Overview Komponen Sistem SQA - Arsitektur SQA Komponen sistem SQA dapat diklasifikasikan ke dalam enam kelas: 1. Pre-project quality components 2. Project life cycle quality components 3. Infrastructure error preventive and improvement components 4. Software quality management components 5. Standardization, certification and SQA assessment components 6. Organizing for SQA the human components

33 Pre-project quality components Harus dapat dipastikan bahwa : (a) Komitmen proyek telah cukup didefinisikan dengan mempertimbangkan sumber daya yang diperlukan, jadwal dan anggaran. (b) Perencanaan pengembangan dan kualitas telah benar - benar ditentukan.

34 Project life cycle quality components Siklus hidup proyek terdiri dari dua tahap: Tahap pengembangan Software Pada tahap ini mendeteksi kesalahan desain dan pemrograman. Komponen-komponennya dibagi menjadi empat sub-kelas berikut: - Review - Opini ahli - Pengujian software. Tahap pengoperasian dan pemeliharaan Pada tahap ini kulitas yang diperhatikan adalah kualitas proses pengoperasian software tersebut dan kualitas pemeliharaan software

35 Software quality management components Komponen ini memiliki beberapa tujuan. Salah satu tujuan utamanya adalah kemampuan mengendalikan kegiatan pengembangan dan pemeliharaan serta memperkenalkan dukungan awal manajemen yang biasanya mencegah atau meminimalkan kesalahan dalam penentuan jadwal, penetapan anggaran dan hasil yang diperoleh

36 Standardization, certification and SQA assessment components Tujuan utamanya adalah : (a) Pemanfaatan pengetahuan profesional internasional, (b) Peningkatan koordinasi sistem kualitas organisasi dengan organisasi lain (c) Penilaian prestasi sistem kualitas sesuai dengan skala umum. Berbagai standar tersebut dapat diklasifikasikan menjadi dua kelompok utama: (a) Standar manajemen kualitas (b) Standard proses proyek.

37 Organizing for SQA The Human Components SQA basis organisasi meliputi: 1. Manajer 2. Personil pengujian 3. Unit SQA dan praktisi SQ. Tujuan utama adalah: Memulai dan mendukung pelaksanaan komponen SQA Mendeteksi penyimpangan prosedur SQA dan metodologi perbaikan

38 Discussion Dokumen persyaratan SW untuk tender pengembangan "Super-lab", Sistem Software untuk mengelola laboratorium rumah sakit, terdiri dari point2 sesuai dengan faktor kualitas yang dibutuhkan, Manakah faktor yang sesuai dengan kalimat2 dibawah : (correctness, reliability, efficiency, integrity, usability, maintainability, flexibility, testability, portability, reusability & interoperability.)?? 1. probabilitas bahwa system "Super-lab" akan ditemukan keadaan kegagalan saat jam sibuk (09:00-04:00) supaya dibawah 0,5%?? 2. software "Super-lab" yang akan dibangun dapat diadaptasi untuk penggunaan laboratorium privat di lokasi lain.?? 3. software "Super-lab" yang dikembangkan untuk sistem operasi linux harus kompatibel untuk aplikasi dalam lingkungan Windows NT?? 4. Pelatihan teknisi laboratorium, tidak memerlukan lebih dari tiga hari, dan memungkinkan teknisi untuk mencapai tingkat C dari pengguna "Superlab" yaitu mampu mengelola penerimaan 20 pasien per jam??

39 MODUL 03 DEVELOPMENT AND QUALITY PLANS

40 Development and Quality Plans Rencana pengembangan dan rencana kualitas adalah elemen utama yang diperlukan untuk memenuhi proyek sesuai dengan standar ISO 9000,3 dan ISO / IEC 2001 serta IEEE 730. Hal ini juga merupakan elemen penting dalam Capability Maturity Model (CMM) untuk penilaian kematangan Pengembang Prangkat Lunak Proyek pengembangan software membutuhkan rencana pengembangan dan kualitas untuk memastikan bahwa : 1. Pengembangan Perangkat lunak didasarkan pada bahan usulan yang telah kaji ulang dan benar-benar diperbarui 2. Lebih komprehensif dari proposal yang telah disetujui, terutama berkenaan dengan jadwal, sumber daya, perkiraan, dan evaluasi risiko pengembangan 3. Mencakup permintahan tanbahan yang tidak tercakup pada proposal yang telah disetujui

41 Development and Quality Plans Tujuan Perencanaan Pengembangan & Kualitas Penjadwalan kegiatan-kegiatan pengembangan Merekrut anggota tim dan mengalokasikan sumber daya pengembangan Menyelesaikan resiko pengembangan. Mengimplementasikan kegiatan SQA yang diperlukan. Menyediakan manajemen dengan data yang diperlukan untuk pengendalian proyek.

42 Development and Quality Plans Elemen-elemen pada perencanaan pengembangan Project products Project interfaces Project methodology and development tools SW development standards and procedures The mapping of the development process.( proj. mgt. Gant ) 6. Project milestones ( documents, code, report ) 7. Project staff organization ( org. stru., prof. req., no of team mem., names of team leaders ) 8. Development facilities ( SW, HW tools, space, period req. for each use ) 9. Development risks 10. Control methods 11. Project cost estimation

43 Development and Quality Plans Elemen-Elemen Perencanaan Kualitas 1. Tujuan Kualitas : mengacu pada kebutuhan substansi kualitas pengembangan software Harus sesuai dengan kebutuhan konsumen 2. Perencanaan Kegiatan Review o Type o penjadwalan ( prioritas ) o Prosedur sepesifik yang akan diaplikasikan o Siapa yang bertanggung jawab untuk melkasanakan review tersebut. 3. Perencanaan pengujian Software ( Daftar lengkap perencanaan Pengujian harus disediakan) termasuk pengujian o Unit, Integrasi atau sistem yang akan di uji o Type pengujian dan aktifitas yang akan dilaksanakan o Rencanaan jadwal pengujian o Prosedur khusus o Siapa yang bertanggung jawab

44 Development and Quality Plans Elemen-Elemen Perencanaan Kualitas 4. Merencanakan Acceptance Tests, terutama software yang dibuat oleh pihak luar 5. konfigurasi manajemen alat konfirmasi manajemen dan prosedur, termasuk prosedur-prosedur perubahan kontrol yang akan untuk diterapkan di seluruh proyek

45 CERTIFIED IN SOFTWARE QUALITY ASSURANCE (CiSQA TPCC)

46 Development and Quality Plans - Discussion PENTING! Kegiatan Software Quality Assurance, seperti design review and software tests, harus dimasukkan kedalam jadwal aktivitas proyek, bersamaan dengan aktivitas perbaikan perancangan dan perbaikan code. Kegagalan untuk penjadwalan kegiatan ini dapat menyebabkan keterlambatan yang tak terduga pada proyek software.

47 Development and Quality Plans - Discussion Jelaskan tujuan Development Plan? Tujuan perencanaan adalah untuk memberikan dasar untuk: Penjadwalan kegiatan-kegiatan pengembangan Merekrut anggota tim dan mengalokasikan sumber daya pengembangan Menyelesaikan resiko pengembangan. Mengimplementasikan kegiatan SQA yang diperlukan. Menyediakan manajemen dengan data yang diperlukan untuk pengendalian proyek.

48 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (1) Project products Dokumen Desain yang menentukan tanggal penyelesaian, menunjukkan item-item apa saja yg di serahkan kepada pelangan Software (Ditentukan tanggal penyelesaian dan lokasi instalasi) Pelatihan (tanggal, peserta dan lokasi).

49 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (2) Project interfaces Antarmuka proyek meliputi: Antarmuka dengan paket perangkat lunak yang ada (antarmuka software) Antarmuka dengan perangkat lunak lain dan / atau tim pengembangan hardware yang bekerja pada sistem yang sama atau proyek (misalnya, kerja sama dan koordinasi) Antarmuka dengan perangkat keras yang ada (hardware interface).

50 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (3) Project methodology and development tools: Metodologi proyek dan alat-alat untuk pengembangan digunakan dalam setiap fase proyek. Ketika mengevaluasi kesesuaian metodologi proyek yang diusulkan dan development tools, kita juga harus memperhitungkan pengalaman professional yang digunakan, termasuk personil subkontraktor, bahkan tenaga kerja sementara yang dibutuhkan proyek.

51 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (4) Software development standards and procedures : Sebuah daftar harus disiapkan dari standar pengembangan perangkat lunak dan prosedur yang harus diterapkan dalam proyek. (5) The mapping of the development process : Pemetaan proses pembangunan melibatkan penyediakan definisi rinci dari masing-masing tahapan proyek. Deskripsi ini meliputi definisi input dan output, dan kegiatan khusus yang direncanakan. deskripsi kegiatan meliputi: a) Perkiraan durasi kegiatan ini. Bisa dilihat pada pengalaman yang diperoleh dalam proyek-proyek sebelumnya. b) Urutan logis dimana setiap kegiatan yang akan dilakukan, c) jenis sumber daya profesional yang diperlukan dan perkiraan bagaimanabanyak sumber daya ini diperlukan untuk setiap kegiatan.

52 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (6) Project milestones Untuk setiap milestone (Target setiap step), waktu penyelesaian dan hasil step proyek (dokumen dan kode) harus didefinisikan. (7) Project staff organization struktur organisasi: definisi tim proyek dan tugas-tugas mereka, termasuk tim yang terdiri dari pekerja sementara atau subkontraktor. Persyaratan profesional: sertifikasi profesional, pengalaman dalam bahasa pemrograman tertentu atau development tools tertentu, pengalaman dengan Jenis software tertentu, dan sebagainya. Sejumlah anggota tim dibutuhkan untuk setiap periode, tergantung kegiatan yang dijadwalkan. Diharapkan tim akan mulai bekerja pada waktu yang berbeda, dan ukuran tim dapat bervariasi dari satu periode ke periode berikutnya tergantung pada kegiatan yang direncanakan.

53 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (8) Development facilities Fasilitas pengembangan diperlukan meliputi hardware, software dan hardware alat pengembangan, ruang kantor, dan barang-barang lainnya. Untuk setiap fasilitas, periode waktu yang dibutuhkan untuk penggunaannya harus ditunjukkan pada jadwal. (9) Development risks Resiko pengembangan melekat dalam setiap proyek. Untuk memahami besarnya pengaruh mereka dan bagaimana mereka dapat dikontrol, pertama kita harus mendefinisikan konsepnya. kesenjangan teknologi - Kurang memadai & personil kurang pengalaman untuk melaksanakan tuntutan proyek kekurangan Staf - kekurangan yang tidak terantisipasi dari staf profesional. Elemen yang mundul dari organisasi lain yang tidak dapat diduga Kemungkinan bahwa pemasok perangkat keras atau perangkat lunak Misalnya, tidak akan memenuhi kewajiban mereka sesuai jadwal.

54 Development and Quality Plans - Discussion Software risk management process

55 Development and Quality Plans - Discussion 11 Elemen-elemen Development Plan? (10) Control methods Untuk mengendalikan pelaksanaan proyek, manajer proyek dan manajemen setiap departemen terkait menerapkan serangkaian prektek pemantauan saat mempersiapkan laporan kemajuan proyek dan rapat-rapat koordinasi tim proyek. (11) Project cost estimation Perkiraan biaya proyek didasarkan pada usulan biaya perkiraan, diikuti oleh tinjauan menyeluruh dari estimasi sumber daya manusia, nego-nego kontrak dengan subkontraktor dan pemasok, dan sebagainya. Misalnya, suatu bagian dari proyek direncanakan akan dilakukan oleh tim pengembang internal, sebagian yang lain dilakukan oleh subkontraktor karena tidak tersedianya tim internal yang cukup. Sebuah perubahan ini biasanya melibatkan anggaran tambahan yang cukup besar.

56 MODUL 04 SOFTWARE QUALITY ASSURANCE COMPONENTS

57 Integrating Quality activities in the project life cycle Classic and Other SW development Methodologies: SDLC ( Req. def., Analysis, Design, Coding, sys. Tests, install and conversion, op. and maintenance ) - -

58 Prototyping

59 Spiral Model Adalah penggambungan antara model SDLC dan Prototye. Digunakan untuk proyek dengan skala besar dan komplek

60 Object Oriented Model

61 Faktor yang mempengaruhi intensitas kegiatan jaminan mutu dalam proyek Pengembangan 1. Aktifitas quality assurance akan terintegrasi kedalam perencanaan pengembangan yang akan di implementasikan pada satu atau lebih model pengembangan perangkat lunak 2. Perencana quality Assurance pada proyek diperlukan untuk menentukan : Daftar aktifitas QA yang dibutuhkan proyek Untuk masing-masing aktifitas QA: Waktu Tipe kegiatan quality assurance yang akan ditetapkan Siapa yang akan melakukan kegiatan dan sumber daya yang dibutuhkan Sumber daya yang diperlukan untuk menghilangkan kerusakan dan melakukan perubahan.

62 Faktor yang mempengaruhi intensitas kegiatan jaminan mutu dalam proyek Pengembangan 3. Faktor Proyek Besarnya proyek Kompleksitas teknis dan kesulitannya Tingkat penggunaan ulang komponen software Keparahan hasil kegagalan jika proyek itu gagal 4. Faktor Tim Kualifikasi profesional anggota tim Pengetahuan tim dan pengalaman Ketersedian tim profesional Keakraban anggota tim

63 Tiga Aspek Jaminan Kualitas Produk Perangkat Lunak Verifikasi : Proses evaluasi sistem atau komponen untuk menentukan apakah produk yang diberikan tahap pengembang, kondisinya memuaskan berkenaan dengan tahap awal Validasi : Proses evaluasi sistem atau komponen selama atau pada akhir proses pengembangan untuk menentukan apakah memuaskan persyaratan yang dispesifikasikan Kualifikasi : Proses yang digunakan untuk menentukan apakah sistem atau komponen cocok untuk penggunaan operasional

64 Reviews Review (peninjauan) adalah: "Sebuah proses atau pertemuan selama pengerjaan sebuah produk atau seperangkat produk. Peninjauan dilakukan terhadap personil proyek, manajer, pengguna, pelanggan, atau pihak lain yang berkepentingan untuk mendapatkan komentar atau persetujuan." Metodologi yang dapat diimplementasikan pada kegiatan review dokumen Review desain formal Rekan review (pemeriksaan dan penelusuran) Pendapat ahli.

65 Tujuan Reviews Tujuan langsung 1. Untuk mendeteksi kesalahan analisis dan desain. 2. Untuk mengidentifikasi risiko baru yang dapat mempengaruhi penyelesaian proyek. 3. Untuk menemukan penyimpangan dari template dan prosedur gaya dan konvensi 4. Menyetujui analisis atau desain produk.

66 Tujuan Reviews Tujuan tidak langsung : 1. Untuk menyediakan tempat pertemuan informal untuk pertukaran pengetahuan profesional tentang metode pengembangan, alat dan teknik. 2. Untuk merekam kesalahan dalam analisis dan desain yang akan berfungsi sebagai dasar bagi tindakan perbaikan di masa depan.

67 Formal Design Reviews Formal design review, Disebut juga Design reviews ( DRs ) Formal technical reviews ( FTR ) Tanpa persetujuan FDr ini, Pengembang tidak dapat melanjutkan ke phase berikutnya pada proyek pengembangan perangkat lunak Formal Design Review dapat dilakukan setiap tahap pembangunan yang membutuhkan penyelesaian analisis atau desain dokumen, apakah dokumen itu adalah spesifikasi kebutuhan atau rencana instalasi.

68 Daftar pada Formal Design Reviews DPR - development plan review SRSR- Software requirement specification review PDR Preliminary design review DDR Detail design review DBDR Data base design review TPR Test plan review STPR Software test procedure review VDR Version description review OMR operator manual review SMR Support manual review TRR Test readiness review PRR Product release review IPR Installation Plan review

69 Mengapa Formal Design Reviews Penting? Review pada tahapam / fase pengembangan adalah penting, karena proses review yaitu meninjau kembali terhadap persyaratan, dengan tujuan untuk memverifikasi hasil dari kegiatan sebelumnya dan agar dapat mengidentifikasi masalah sebelum dilanjutkan. Pelaksanaan review adalah wajib sebagai bagian dari kontrol fase pengembangan, ketika sedang dalam proses mengembangkan produk. Menurut definisi, tentunya review harus melibatkan orang-orang yang berada diluar tim pengembang pada setiap fase-fase tersebut.

70 Formal Design Reviews terfokus pada : Partisipan Persiapan sebelum Sesi Design Review Rekomendasi Setelah Aktifitas Design Review Peserta Design Reviews : Semua Design Review dilaksanakan Oleh: Review Leader Tim Review Rekomendasi Setelah Aktifitas Design Review

71 Karakteristik seorang review leader: Mempunyai Pengetahuan dan pengalaman dalam pengembangan proyek dengan jenis yang sama dengan yang direview. Senioritas, sama atau lebih tinggi dari pemimpin proyek. Mempunyai hubungan baik dengan pemimpin proyek dan timnya. Bukan anggota tim proyek. Jadi, kandidat yang tepat untuk pemimpin review tim termasuk manajer departemen pengembangan, para kepala engginer perangkat lunak, para pemimpin proyek lain, kepala unit jaminan kualitas perangkat lunak, atau kepala insinyur perangkat lunak dari sisi pelanggan.

72 Tugas Review Leader di tahap persiapan Design Review Menunjuk anggota tim Membuat jadwal sesi-sesi review Mendistribusikan dokumen desain antar anggota tim (hard copy, file elektronik, dll).

73 Agenda sesi Design Review Presentasi singkat dari dokumen desain. Komentar yang dibuat oleh anggota tim review. Verifikasi dan validasi di mana setiap komentar dibahas untuk menentukan tindakan yang diperlukan (koreksi, perubahan dan penambahan) yang harus tim proyek lakukan. Keputusan tentang desain produk (dokumen), yang menentukan kemajuan proyek.

74 Infrastruktur Desain Review Mengembangkan checklist untuk setiap jenis dokumen desain, atau setidaknya untuk dokumen yang bersifat umum. Melatih para profesional senior tentang masalah teknis serta masalah proses suatu review. Para profesional yang terlatih berfungsi sebagai reservoir untuk tim DR. Secara berkala menganalisis efektivitas DR terakhir sehubungan dengan cacat yang terdeteksi untuk meningkatkan metodologi DR. Menjadikan jadwal DR sebagai bagian dari rencana kegiatan proyek dan mengalokasikan sumber daya yang dibutuhkan sebagai bagian integral dari prosedur standar operasi pengembangan perangkat lunak organisasi.

75 MODUL 05 SOFTWARE TESTING STRATEGY & IMPLEMENTATION

76 Software Testing Strategy & Implementation Definisi Testing: Testing adalah proses eksekusi program dengan maksud menemukan kesalahan. Definisi Testing menurut IEEE : 1. Proses operasi sistem atau komponen di awah kondisi yang ditentukan, mengamati atau merekam hasil, dan membuat evaluasi beberapa aspek dari sistem atau komponen. 2. Proses menganalisis software untuk mendeteksi perbedaan antara kondisi yang ada dan diperlukan (yaitu, bug) dan mengevaluasi fitur item perangkat lunak.

77 Software Testing Strategy & Implementation Tujuan Software Testing Mengidentifikasi dan mengungkapkan sebanyak mungkin kesalahan pada Software yang ditesting. Proses perbaikan dan testing, dimaksudkan untuk meningkatkan kualitas software yang di test ke level yang dapat di terima user. Untuk melakukan test yang dibutuhkan secara efisien dan efektif dalam batasan anggaran dan waktu. Untuk mengkompilasi catatan error software untuk tindakan error prevention (lewat tindakan perbaikan dan pencegahan)

78 Software Testing Strategy & Implementation Strategi Umum Testing Software Big Bang Test: Test software setelah keseluruhan paket software selesai Incremental Test: Test software dilakukan per modul, dilanjutkan ke keterkatannya dengan modul lainnyag yang sudah diselesaikan. Proses ini terus dilakukan sampai semua modul dalam paket di test. Saat semua modul sudah diselesaikan, maka dilakukan test lagi secara keseluruhan.

79 Software Testing Strategy & Implementation Incremental testing dapat dilakukan dengan 2 startegi: Bottom-Up ( 4 stages ) Top-down ( 6 stages ) The incremental pathes: Horizontal sequence ( breadth first ) Vertical sequence ( Depth first )

80 Software Testing Strategy & Implementation Bottom Up

81 Software Testing Strategy & Implementation Top Bottom

82 Software Testing Strategy & Implementation Klasifikasi Pengetesan Software

83 Software Testing Strategy & Implementation White Box Testing Proses testing yang berfokus pada mekanisme dan alur logika program saat memproses input.

84 Software Testing Strategy & Implementation Data Processing and Calculations Correctness Test Correctness tests and path coverage Pengetesan dengan cara membuat kondisi agar setiap jalur percabangan pada perintah IF/WHILE/DO UNTIL terpenuhi setidaknya 1x. Correctness tests and line coverage Pengetesan dengan cara membuat kondisi agar setiap baris program di eksekusi setidaknya 1x. McCabe s cyclomatic complexity metrics Mengukur kompleksitas program atau modul bersamaan dengan menentukan jalur independen yang diperlukan untuk mengeksekusi semua baris program

85 Software Testing Strategy & Implementation Software Qualification Testing Memastikan bahwa software bisa memberikan respon positif untuk pertanyaan berikut: Apakah kode program memenuhi spesifikasi struktur yang disepakati? Apakah gaya penulisan kode sesuai dengan ketentuan? Apakah komentar pada kode program cukup jelas?

86 Software Testing Strategy & Implementation Software Reusability Testing Memastikan apakah modul pada program memiliki bagian yang bisa dipakai ulang untuk pengembangan selanjutnya

87 Software Testing Strategy & Implementation Keuntungan White Box Testing Sebagai Software engineer yang memiliki akses ke source code, hal ini menjadi sangat mudah untuk melakukan skenario pengujian secara efektif. Membantu Software engineer untuk mengoptimalkan source code. Baris kode yang tidak efisien dapat dihilangkan agar mencegah bugs pada program.

88 Software Testing Strategy & Implementation Kerugian White Box Testing Butuh banyak resource dan waktu dibutuhkan dibandingkan black box testing Tidak memungkinkan untuk dilakukan pengetesan response time, reliability, load durability.

89 Software Testing Strategy & Implementation Black Box Testing Proses testing dimana mekanisme internal program diabaikan dan memfokuskan testing pada analisa hasil output software berdasarkan data yang diinput dan kondisinya Testing dilakukan untuk meningkatkan kompatibilitas sistem atau komponen dengan spesifikasi kebutuhan

90 Software Testing Strategy & Implementation Equivalence classes Pengetesan untuk uji kebenaran output berdasarkan inputnya. Kategori Pengetesan Berdasarkan Revision Factor Maintainability tests Flexibility tests Testability tests

91 Software Testing Strategy & Implementation Kategori Pengetesan Berdasarkan Transition Factor Portability tests Reusability tests Software interoperability tests Equipment interoperability tests

92 Software Testing Strategy & Implementation Kategori Pengetesan Lain: Documentation tests Availability tests Reliability tests Stress tests Software system security tests Training usability tests Operational usability tests

93 Software Testing Strategy & Implementation Keuntungan Black Box Testing Cocok dan efisien untuk source code dengan skala besar. Menguji program dari sudut pandang user. Software tester dalam jumlah yang banyak dapat menguji program tersebut tanpa harus memiliki pengetahuan tentang programming.

94 Software Testing Strategy & Implementation Kerugian Black Box Testing Software tester hanya menjalankan beberapa skenario pengujian yang dipilih. Pengujian yang tidak efisien karena Software tester memiliki pengetahuan yang terbatas tentang program. Pengujian yang tidak spesifik karena Software tester tidak memiliki akses ke source code.

95 Software Testing Strategy & Implementation Software testing Implementation The testing process Test case design Automated testing Alpha and beta site testing programs

96 Software Testing Strategy & Implementation THE TESTING PROCESS (PROSES PENGUJIAN) Perencanaan Perancangan dan pelaksanaan pengujian dilakukan pada seluruh proses pembangunan perangkat lunak. Kegiatan ini terdiri dari beberapa fase yang diawali dengan tahap design dan diakhiri lunak di instal pelanggan. Proses Pengujian Perangkat lunak digambarkan pada gambar sebagai berikut

97 Software Testing Strategy & Implementation Determining the test methodology phase Isu Utama dalam menentukan metode pengujian perangkat lunak harus dapat bersaing dengan : Standar Kualitas Perangkat lunak yang diperlukan Tingkat standar mutu yang dipilih untuk proyek tergantung padakarakteristik dari aplikasi perangkat lunak. Strategi Pengujian Perangkat lunak.isu-isu yang harus memutuskan antara lain: Strategi pengujian: harus big bang atau strategi pengujian tambahan yang akan diadopsi? Jika pengujian incremental adalah lebih baik, harus pengujian dilakukan bottom-up atau top-down? Bagian mana dari rencana pengujian harus dilakukan sesuai dengan model pengujian white box Bagian mana dari rencana pengujian harus dilakukan sesuai dengan model pengujian otomatis?

98 Software Testing Strategy & Implementation Planning The Tests Pengujian yang akan direncanakan meliputi: Unit tes Integrasi tes Sistem tes. Adalah tugas perencana untuk mempertimbangkan hal-hal berikut sebelum memulai rencana spesifik pengujian: Apa yang akan diuji? Source mana yang digunakan untuk uji kasus? Siapa yang melakukan pengujian? Dimana akan melakukan pengujian? Kapan pengujian dihentikan?

99 Software Testing Strategy & Implementation Siapa yang Melakukan Pengujian Siapa yang melakukan pengujian ditentukan pada tahap perencanaan : Pengujian Integrasi, terutama pengujian unit umumnya dilakukan oleh tim pengembang perangkat lunak. Dalam beberapa kasus unit pengujian yang melakukan pengujian Pengujian sistem dilakukan oleh timm uji independen (tim pengujian internal atau tim eksternal konsultan pengujian. Dalam kasus perangkat lunak besar, lebih dari satu tim pengujian dapat digunakan untuk melakukan pengujian sistem. Keputusan prasyarat yang akan dibuat padan kasus seperti alokasi tes sistem antara internal dan tim pengujian eksternal.

100 Software Testing Strategy & Implementation Test Implementation Tahap pelaksanaan pengujian terdiri dari serangkaian tes. Koreksi kesalahan terdeteksi dan dilakukan pengujian ulang (uji regresi). Tahap pelaksanaan pelaksanaan pengujian dapat dilihat di gambar berikut :

101 Software Testing Strategy & Implementation TEST CASE DESIGN UJI KASUS KOMPONEN DATA Uji kasus adalah sekumpulan dokumentasi data input dan kondisi operasi yang dibutuhkan untuk menjalankan sebuah item pengujian dengan hasil yang diharapkan pada saat pengujian berlangsung. Penerapan uji kasus akan menghasilkan satu atau lebih jenis hasil yang diharaapkan sebagai berikut : 1. Numeric 2. Alphabet 3. Pesan kesalahan, hasil standarad yang menginformasikan pengguna tentang data yang hilang atau salah

102 Software Testing Strategy & Implementation Automated testing Pengujian otomatis merupakan langkah tambahan dalam integrasi alat komputerisasi dalam proses pengembangan perangkat lunak. Beberapa faktor yang memotivasi pengambangan alat pengujian otomatis; Antisipasi penghematan biaya Mempersingkat durasi pengujian Tingkat ketelitian yang tinggi pada pengujian yang dilakukan Perbaikan akurasi pengujian Peningkatan hasil laporan serta pengolahan satatistik dan laporan keuangan

103 Software Testing Strategy & Implementation Automated testing Pengujian Otomatis meliputi bagian : 1. Proses Pengujian Otomatis Pengkaujian perangkat lunak otomatis memerlukan perencanaan pengujian, desain pengujian, persiuapan pengujian, kinerja pengujian, log pengujian dan persipan laporan, pengujian ulang setelah koreksi kesalahan terdeteksi (pengujian regresi), dan log pengujian final dan penyusunan laporan termasuk laporan perbandingan

104 Software Testing Strategy & Implementation Automated testing 2. Jenis-Jenis pengujian otomatis Audit Kode Cakupan Monitoring Pengujian Fungsional Load Test Uji manajemen

105 Software Testing Strategy & Implementation Automated testing 3. Keuntungan dan kerugian Tes Otomatis Keuntungan Pengujian otomatis adalah : Akurasi dan kelengkapan kinerja Akurasi hasil log dan ringkasan laporan Kelengkapan Informasi Hanya dibutukan berapa sumber daya tenaga kerja untuk melakukan pengujian Durasi pengujian lebih pendek Kinerja Uji regresi lengkap

106 Software Testing Strategy & Implementation Automated testing Kelemahan utama pengujian otomatis adalah: Dibutuhkan biaya investasi yang tinggi untuk pembelian paket dan pelatihan Tingginya biaya investasi pengembangan paket Tingginya tingkat kebutuhan tenaga kerja untuk persiapan pengujian

107 Software Testing Strategy & Implementation Alpha and beta site testing programs Pengujian situs alpha dan Beta digunakan untuk memperoleh komentar tentang kualitas paket dari pengguna potensial Pengujian Situs Alpha adalah metode dimana pelanggan menguji paket perangkat lunak yang baru di tempat pengembang Pengujian situs beta adalah metode yang oleh sekolompok pengguna atau pelanggan menerima versi lanjuta dari perangkat lunak yang dipasang ditempat mereka dan melaporkan kesalahan yang ditemukan dalam proses eksperimen pada penggunaan program

108 Software Testing Strategy & Implementation Alpha and beta site testing programs Keuntungan utama dari pengujian situs beta adalah : Identifikasi kesalahan tidak terduga Lingkup pencarian kesalahan sangat luas Biaya Rendah Kelemahan utama menggunakan pengujian situs beta adalah : Kurangnya pengujian sistematis Laporan kesalahan berkualitas rendah Banyak menggunakan usaha manusia yang dikeluarkan untuk memeriksa laporan partisipan

109 Software Testing Strategy & Implementation Discussion Untuk menguji perangkat lunak secara keseluruhan, setelah paket selesai tersedia dikenal sebagai "big bang test". Untuk menguji perangkat lunak sedikit demi sedikit, dalam modul, pada saat modul2 selesai dibuat adalah unit test, kemudian untuk menguji kelompok modul dengan tujuan menguji integrasinya disebut integration test. Proses ini berlanjut sampai semua modul paket telah diuji. Setelah fase ini selesai, Seluruh paket diuji secara keseluruhan (System test). Strategi keseluruhan pengujian ini biasanya disebut "incremental testing".

110 Software Testing Strategy & Implementation Discussion White Box Testing & Black Box Testing : IEEE Definition Black Box Testing (1) Pengujian yang mengabaikan mekanisme internal sistem atau komponen dan hanya berfokus pada keluaran yang dihasilkan sebagai respon terhadap input yang dipilih dan kondisi eksekusi. (2) Pengujian dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional yang ditentukan. White Box Testing Pengujian yang memperhitungkan mekanisme internal sistem atau komponen.

111 Software Testing Strategy & Implementation Discussion

112 Software Testing Strategy & Implementation Discussion

113 Software Testing Strategy & Implementation Discussion

114 Final Discussion Discussion Executive Management Decision Prasyarat yang paling penting bagi keberhasilan pelaksanaan setiap inisiatif jaminan kualitas adalah komitmen dari manajemen eksekutif. Adalah tanggung jawab manajemen untuk menetapkan tujuan strategis dan membangun infrastruktur yang strategis sejalan dengan tujuan tersebut. Karena proses manajemenlah yang digunakan untuk membangun fondasi dari lingkungan yang berkualitas yang dikelola, termasuk konsep kepemimpinan, infrastruktur manajemen mutu, dan kualitas lingkungan.

115 Wassalamualaikum Insan Ardiansyah ( 2016, Dilarang melakukan duplikat dan menyebarkan dokumen ini tanpa seijin TelkomPCC)