Software Testing Implementation (by Galin's book)

Berikut adalah ringkasan yang saya buat mengenai SOFTWARE TESTING - IMPLEMENTATION dari buku buku Galin...

- Determining the test methodology phase :
Isu utama metodologi pengujian HARUS BERLAWANAN dengan :
a. Appropriate requuired software quality standard
b. Software testing strategy

Decision dari 2 isu di atas harus mendasat dan dibuat sebelum perencanaan dimulai.

a. Determining the test methodology
Menentukan standar kualitas yang sesuai level dari quality sebuah proyek tergantungpada karakteristik aplikasi software.

PEER REVIEWS

Apa yang dimaksud dengan PEER REVIEW?

Dikutip dari wikipedia :
Adalah suatu proses pemeriksaan atau penelitian suatu karya atau ide pengarang ilmiah oleh pakar lain di bidang tersebut. Orang yang melakukan penelaahan ini disebut peer reviewer.

Menurut sumber yang saya dapatkan di sini :
Peer review adalah proses regulasi oleh sebuah profesi atau proses evaluasi yang melibatkan individu-individu yang berkualitas dalam bidang yang relevan. Metode peer review bekerja untuk mempertahankan standar, meningkatkan kinerja dan memberikan kredibilitas. Dalam dunia akademis peer review sering digunakan untuk menentukan kesesuaian sebuah makalah akademis untuk publikasi

Tugas : BLACK BOX TESTING Aplikasi Tugas Akhir

Saya dan teman sekelompok mendapatkan tugas untuk mereview Tugas Akhir senior kami. Tugas Akhirnya harus APLIKASI, karena kami harus melakukan testing terhadap aplikasi tersebut.

Setelah salah memilih berkali-kali, akhirnya saya mendapatkan 1 yang paling PAS untuk melakukan testing.

Terima kasih kepada senior kami yang telah membuat aplikasi tersebut. :)

Saya tidak akan menyuguhkan file dokumen buatan saya, jadi saya hanya akan menampilkan slide PPT yang dibuat untuk presentasi. Kira-kira seperti inilah isinya...

DEVELOPMENT -- 9 KNOWLEDGE AREAS and QUALITY PLAN

"Pengembangan dan Rencana Kualitas"
Yap, kualitas memang harus selalu direncanakan untuk mendapatkan hasil terbaik.

DEVELOPMENT
Dalam software development dikenal ada 9 knowledge areas, yaitu :
1. Time
2. Cost
3. Scope
4. Human Resource
5. Risk
6. Quality
7. Procurement
8. Communication
9. Integration

Apa itu knowledge area?
sering pula disebut dengan elemen manajemen proyek (the element of project management) adalah cakupan bahasan atau bidang pengetahuan yang terdapat di dalam manajemen proyek. Tentunya bidang pengetahuan yang dimaksud di sini adalah bidang pengetahuan yang berkaitan dengan manajemen. (sumber)

Penjelasan 9 knowledge area :

CONTRACT REVIEW

Sebelumnya saya sudah menjelaskan mengenai SLA dan Kontrak Proyek, di situ saya hanya menyinggung soal arti dan perbedaannya. Sekarang saya akan menjelaskan lebih mengenai REVIEW KONTRAK. Tentu saja tentang kontrak proyek IT. :)

Jadi, apa itu KONTRAK?
Kontrak adalah kesepakatan antara klien dan developer (yak, kira-kira itulah inti arti dari kontrak yang mampu saya catat di kelas),

Contract Review adalah tahapan pertama dari pelaksanaan proyek, di mana kita menggali tentang apa saja kebutuhan si klien, lalu apa saja batasan-batasan kita, apa saja kesepakatan, hukum dan peraturan yang berlaku seperti apa, dan lain lain lainnya...
Contract review adalah requirement oleh ISO 900 1 da ISO 9000 -3 guidelines.
Jadi menurut saya kebutuhan akan kontrak ini sangat tinggi, kontrak adalah sangat penting dalam pelaksanaan proyek. Karena kalau misalkan terjadi apa-apa nanti kita tinggal melihat kontrak yang telah kita setujui sebelumnya seperti apa. Misalnya... terjadi perselisihan antara klien dan tim proyek, maka itu sudah diatur dalam kontrak apa yang harus dilakukan.

Itu baru tentnag kontrak. Nah, seperti yang telah saya jelaskan sebelumnya, kontrak itu adalah persetujuan, berarti kalau ada pihak yang kurang setuju atau nggak sreg, kontrak bisa saja berubah. Inilah yang namanya CONTRACT REVIEW.
Jadi Contract Review adalah komponen SQA yang bertujuan untuk membimbing review draft proposal dan dokumen kontrak.
Intinya tujuannya adalah mencapai kemufakatan pihak-pihak terkait. Berarti review kontrak dapat terjadi karena beberapa kondisi :

1. Participation in a tender
2. Submission of a proposal according to the customer's request for proposal (RFP)
3. Receipt of an order from a company's customer
4. Receipt of an internal request or order from another department in the organization

Tahapan dalam contract review :
1. Review of the proposal draft prior to submission to the potential customer.
2. Review of the proposal draft prior to signing

Jadi dalam melakukan contract review, jangan lupa untuk membuat checklist prosesnya.

Tujuan contract review :

Service Level Agreement (SLA) vs Kontrak Proyek

Kali ini saya akan membahas mengenai SLA dan Kontrak Proyek.
Apa bedanya kedua hal itu?
Apa itu SLA?
Apa itu Kontrak Proyek?

Sebenarnya ini adalah tugas yang pernah diberikan oleh dosen di awal-awal perkuliahan. Tapi saya tidak ingat dosen kami ingat untuk meminta tugas ini. Tapi biarlah, ini tetap bagian pembahasan dari software quality management, yaitu pada tahap CONTRACT REVIEW.
Sepemahaman saya, ini adalah fase paling awal, yaitu di mana tim proyek pembuat software melakukan penandatanganan kontrak untuk melakukan proyek yang menandakan kesepakatan antara dua belah pihak.

Nah, sebelumnya kita bahas dulu satu persatu artinya apa.
SERVICE LEVEL AGREEMENT (SLA)
Biar gampang, saya akan mencontohkan hal yang paling sering kita alami. Ingat nggak, sewaktu kita mendaftar sesuatu di internet, atau ketika kita menginstal sebuah aplikasi/software di komputer kita, selain kita mengisi data, kita suka dihadapkan para "TERMS and SERVICE" atau "TERMS and CONDITION" (yang biasanya nggak pake baca langsung next next next...nneeeeexxxtttt~).
Itulah salah satu contoh paling sederhana SLA.
Jadi, apa itu SLA? SLA itu semacam persetujuan akan layanan apasaja yang akan kita dapat. Yap, kurang lebih bahasa paling sederhananya seperti itu. Bentuk layanannya tidak melulu menguntungkan kita lho! Bentuk layanannya juga kadang adalah batasan-batasan. Misalnya,

Software Quality Mc Call

Dari kemarin saya sudah terus-terusan menjelaskan mengenai kualitas software. Pertanyaannya adalah :
Apa yang menentukan kualitas sebuah software?

Pertama, tentu saja scope requirementnya terpenuhi atau tidak. Menurut saya, kalau requirement seharusnya A, B, dan C, tapi ternyata yang C cuma hoax belaka, itu udah bisa dibilang, "nggak bagus". Itulah yang pernah saya singgung soal trade off, scope requirement dapat dihilangkan tapi kualitas menjadi korban.

Kedua, adakah kelengkapan-kelengkapan seperti yang saya singgung di sini? Kelengkapan-kelengkapan seperti itu diperlukan, karena tidak hanya untuk pihak lain yang akan mengembangkan software kita, tetapi juga klien kita. Saya mendapatkan soal ini sewaktu UTS lisan.

Jadi ceritanya ada sebuah kasus, saat kita telah meluncurkan sebuah software, kurang lebih kita sudah percaya diri banget deh sama software tersebut, wah pasti software ini bagus, klien pasti suka, pasti diterima. Tapi ternyata sewaktu klien menggunakan, mereka justru kebingungan. Mereka tidak bisa menggunakan software yang sudah kita bangga-banggakan. Kenapa bisa begitu?

6 Tipe Software Testing

Setelah membahas mengenai black box dan white box testing, sekarang saya akan menjelaskan mengenai 5 tipe software testing.

Kalau di penjelasan saya menjelaskan mengenai 2 tipe testing, sekarang testing yang saya jelaskan adalah bagian dari 2 testing tersebut. Testing-testing ini adalah yang paling umum digunakan. Sebenarnya saya pernah menemukan hingga 100 tipe software testing di sini. Tetapi kebetulan yang saya pelajari, dan umumnya, hanya ada 6.

1. UNIT TESTING
Tergolong dalam WHITE BOX TESTING, adalah pengujian terkecil dari pembuatan software. Istilahnya adalah 'compile' kalau lagi ngoding. Yang melakukan testing ini tentu saja orang atau tim yang sedang membuat softwarenya. Karena namanya ngoding itu harus rajin-rajin di-compile biar segera terdeteksi kalau-kalau ada yang error.

2. INTEGRATION TESTING
Tergolong dalam WHITE BOX TESTING dan BLACK BOX TESTING, adalah testing yang dilakukan oleh pihak pengembang maupun oleh klien. Testing ini maksudnya, misalnya dalam software terdapat beberapa modul, testing ini adalah untuk mengecek integrasi modul-modul tersebut. Jadi bisa dilakukan oleh orang yang benar-benar mengerti tentang software tersebut maupun tidak.

White Box and Black Box Testing

Kali ini saya akan menjelaskan tentang macam-macam software testing.
Umumnya, software testing itu diholongkan menjadi 2, yaitu WHITE BOX TESTING dan BLACK BOX TESTING.

Apa itu white box-black box testing?

WHITE BOX TESTING adalah testing yang dilakukan dengan mengetahui proses, coding, dll di dalamnya. Jadi, si penguji mengetahui seluk beluk aplikasi yang diuji. Menurut saya pribadi, ini dilakukan oleh tim pengembang aplikasi yang bersangkutan.
Kalau dari sumber yang saya dapatkan, artinya seperti ini :

White Box Testing merupakan cara pengujian dengan melihat ke dalam modul untuk meneliti kode-kode program yang ada, dan menganalisis apakah ada kesalahan atau tidak. Jika ada modul yang menghasilkan output yang tidak sesuai dengan proses bisnis yang dilakukan, maka baris-baris program, variabel, dan parameter yang terlibat pada unit tersebut akan dicek satu persatu dan diperbaiki, kemudian di-compile ulang.

SQA ARCHITECTURE

Soal ini pernah keluar sewaktu ujian post test, dan saking banyak dan ruwetnya catatan saya, saya sampai-sampai cuma menggambarkan kuil yunani. Itu pun penjelasannya terbalik. -____-"
Tapi memang benar, menurut saya ketimbang dibilang berbentuk rumah, lebih mirip dengan Greek Temple.

Berikut inilah yang dimaksud dengan SQA Architecture :

Kalau yang ini SQA Architecture versi coret-coretan saya :

Pembuatan Software Berdasarkan Manajemen Kualitas

Berikut adalah hasil catatan saya selama di kelas, mencoba memahami apa yang diterangkan dosen sekaligus dengan cepat mencatat sebelum slide PPT diganti. :O
Kali ini saya akan membahas tentang pembuatan software berdasarkan manajemen kualitas.

Karena saya tidak sempat mencatat terlalu banyak, jadi saya akan membuatnya menjadi poin-poin.

1. Dalam pembuatan software diperlukan :
a. Code
Ya pastilah ya, namanya membuat software pasti diperlukan kode yang biasanya kita sebut dengan mengoding (sesuatu yang dihindari secara masal oleh banyak orang di jurusan saya--sumber : pengalaman pribadi). Karena dari kode-kode yang dirangkai menjadi perintah-perintah maka jadilah sebuah software. Selain itu kode juga dibutuhkan untuk memudahkan ketika seseorang ingin mengembangkan software yang kita buat.
b.  Data
Menurut saya, aplikasi tidak akan dapat berjalan tanpa data. Namanya aplikasi membutuhkan input data. Bahkan aplikasi sederhana, misalnya kalkulator pun membutuhkan data untuk dihitung.
c. Dokumentasi
Kata dosen saya, banyak sekali mahasiswa yang membuat aplikasi tetapi tidak membuat dokumentasi. Termasuk beliau, maksudnya. Bahkan beliau terheran-heran kenapa dulu bisa sehebat itu membuat aplikasi tanpa dokumen. Yap, membuat dokumen adalah hal yang amit-amit ampun bosannya. Tapi dokumen itu dibutuhkan lho. Sangat dibutuhkan malah. Karena dokumen itu nantinya akan dibaca orang lain yang sekedar ingin mempelajari aplikasi anda, atau mengembangkan aplikasi anda. Dengan gaya mengoding yang berbeda-beda, pemahaman setiap orang pun berbeda-beda. Nah, dokumen dibutuhkan untuk menyamakan pikiran agar si pembaca mengerti alur pikiran si pembuat software/aplikasi.
d. Prosedur
Setuju dong, tanpa prosedur orang pasti bakal acakadut kebingungan apa yang harus dilakukan atau diperbuat, tidak tahu arah, dan segala macam. Di sinilah fungsi dari prosedur.


2. TRADE OFF
Kalau menurut saya, trade off itu istilahnya seperti 'tumbal menumbal'. Iya, soalnya menurut saya segala sesuatu yang dilakukan akan mengorbankan yang lainnya.

Kalau dari wikipedia sih artinya :

A trade-off (or tradeoff) is a situation that involves losing one quality or aspect of something in return for gaining another quality or aspect. It often implies a decision to be made with full comprehension of both the upside and downside of a particular choice; the term is also used in an evolutionary context, in which case the selection process acts as the "decision-maker".

Kalau digambarkan bentuknya seperti ini :

Software Quality Assurance & Software Quality Control

Saya pernah menyinggung sebelumnya mengenai Software Quality Control di sini. Yap, Saya sering sekali mendengar dosen menyinggung-nyinggung baik Software Quality Control (SQC) dan Software Quality Assurance (SQA).

Apa yang dimaksud dengan keduanya?

Pada postingan saya sebelumnya tentang PLC saya menjelaskan mengenai tahapan-tahapan PLC yang isinya adalah :

- Inisiasi (Requirement Analysis)
- Planning (Design)
- Implementation
- Testing
- Closing

Berada di manakah SQC dan SQA ini pada PLC?
Poinnya hanya 2 :

Project Life Cycle & Software Development Life Cycle

Materi pertama yang saya dapatkan di hari pertama kuliah manajemen kualitas adalah (plus tes yang berujung pada keputusan dosen untuk membuat kelompok dengan minimal 1 perempuan di setiap kelompok) mengenai PROJECT LIFE CYCLE (PLC) dan SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC).

2 hal keramat itu terus menerus diulang-ulang dalam mata kuliah ini. Mengapa? Karena majajemen kualitas rasanya tidak akan pernah lepas dari 2 hal tersebut.

Jadi PLC dan SDLC itu apa???

Software Quality Management (Manajemen Kualitas)

Jadi, apa itu Manajemen Kulitas ????
Apa itu Software Quality Management???

"KUALITAS" dalam kerangka ISO 9000 didefinisikan sebagai “ciri dan karakter menyeluruh dari suatu produk atau jasa yang mempengaruhi kemampuan produk tersebut untuk memuaskan kebutuhan tertentu”.

"MANAJEMEN KUALITAS" sendiri adalah

WELCOME, READERSS!!!

Hello, there~!
So, it's some new blog I made dedicated for Software Quality Management subject. :D
Blog ini akan terisi catatan-catatan harian saya selama di kelas Manajemen Kualitas TI (MKTI).

Sssoooo...., who am I???
I'm one of ordinary student in one of Technology Institute in Surabaya. Right now I'm on my 7th semester *I can still remember the day I came here for the first time, suddenly BAM, 'Tugas Akhir' is waiting for me next semester*

Jadi, akan berisi tentang apakah blog ini nantinya? Blog ini akan berisi semua catatan-catatan, sumber-sumber pendukung, dan pengetahuan-pengetahuan yang *semoga* bisa membantu teman-teman yang lain untuk belajar tentang manajemen kualitas.

BUT PLEASE!!!
RESPECT AUTHORITY!!!
NO COPY-PASTE, pleasee??? Ayo saling menghargai karya tulisan dengan tidak lupa mencantumkan referensi authority. :D
Jadi untuk menghindari plagiarisme atas tulisan saya, saya sudah menonaktifkan fungsi copy-paste.
Sorry guys... But I write these all by myself, I rewrite all my notebook in class, I won't take any risk to get my writing copied without my authority. Sorry, but you guys give me no choice.

Let's have a nice time~