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.