Software Testing

Software testing merupakan proses menganalisis item dari software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang dibutuhkan. Selain itu juga untuk mengevaluasi fitur dari item perangkat lunak.

Pengujian perangkat lunak yang merupakan bagian dari verification dan validation

Verification

Mengevaluasi system atau komponen untuk menentukan apakah produk dari fase pembangunan yang diberikan memenuhi kondisi yang dikenakan pada awal fase itu.

Validation

• Mengevaluasi system atau komponen selama atau pada akhir proses pembangunan untuk menentukan apakah memenuhi persyaratan yang ditentukan.
• Apakah fitur yang telah dibangun ke dalam perangkat kunak memenuhi persyaratan pelanggan dan dapat dilacak dengan kebutuhan pelanggan

6 Type Testing

• Unit Testing
• Integration Testing
• Fungtional dan system testing
• Acceptance Testing
• Regression Testing
• Beta Testing

Contract Review

Contract review merupakan salah satu komponen yang terdapat pada SQA. Komponen ini dimaksudkan untuk memadukan guide review drafts dan dokumen kontrak. Dengan adanya contract review, kontrak yang telah dilakukan dengan mitra proyek dan subkontraktor akan mudah untuk diawasi.

Dua tahapa dalam proses contract review:

a.  Review  untuk perancangan draf proposal sebelum diajukan ke pelanggan

• Customer’s requirement documents
• kebutuhan detail customer dan penjelasan dari persyaratan
• perkiraan biaya dan sumberdaya
• Adanya kontrak atau draft kontrak antara supplier dengan partners and subcontractor

b.  Review draft proposal sebelum penandatanganan

Tujuan dari contract Review

• Customer memiki requirement yang telah diklarifikasi dan telah di  dokumenkan
• Merupakan  aspek normal dalam hubungan antar pelanggan dengan perusahaan yang telah ditetapkan
• Untuk identifikasi resiko dalam pengembangan
• Untuk penyusunan estimasi biaya dan sumberdaya proyek
• Semua pemahaman dapat dicapai antara pelanggan dan perusahaan harus didokumentasikan secara lengkap dan benar
• Tidak ada perubahan, penambahanm atau kelalaian yang belum dibahas dan disepakati harus terdapat pada draf kontrak.

Siapa yang melakukan kontrak review

• Pimpinan atau anggota dari proposal team
• Para anggota dari team proposal
• Seorang team ahli
• Seorang dari luar yang professional atau staf dari perusahaan yang bukan merupakan anggota team proposal.

Contract review untuk Proyek Internal

• Titik utama dari hubungan internal
• Hubungan yang baik dengan adanya pemeriksaan yang cukup pada persyaratan proyek, sumber daya, dan resiko pembangunan.

Formal Design Review dan Peer Review dalam pengembangan software

Dalam sebuah SQA Architecture, yang memastikan langkah pengerjaan software berjalan dengan  baik adalah pada langkah Project Life Cycle. Dalam beberapa tahapan dalam langkah tersebut yang pertama adalah formal design review dan peer review.

                Sebelum membahas lebih lanjut mengenai kedua jenis review tersebut, kita coba melihat terlebih dahulu review dalam konteks pengembangan sebuah software. Review dilakukan saat setelah perencanaan software telah disahkan oleh pihak pengembang dan pelanggan. Setelah itu, dilakukan uji kembali guna melihat design keselurhan dari pengembangan software untuk di verifikasi kemudian di validasi.

                Kemudian dari situ kita bisa memastikan bahwa design dan pengembangan software telah memenuhi syarat yang telah kita inginkan. Dari jenis review yang ada, menurut Galin, ada 2 yakni Formal design review dan peer review, berikut detail penjelasannya :

Formal Design Review :

                Secara umum, Formal Design review atau biasa disebut dengan Design Review (DR) merupakan suatu review yang menjadi syarat mutlak. Tanpa ada persetujuan dari review ini, pengembangan software tidak dapat dilakukan. Menurut Galin, jenis – jenis dari DR antara lain :

-          DPR – Development Plan Review

-          SRSR – Software Requirement Specification Review

-          PDR – Preliminary Design Review

-          DDR – Detailed 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

Menurut Sauer dan Jeffery (200), diskusi dan focus dalam DR meliputi :

-          The participants

-          The prior preparations

-          The DR session

-          The recommended post-DR activities.

1.       Participant

Participant dalam formal design review terdiri dari :

§  Review leader

Memastikan bahwa review berjalan dengan baik, dengan syarat biasanya telah memiliki pengalaman dalam pengembangan software sebelumnya serta memiliki relasi yang kuat dengan project leader.

§   Review Team

Bagian dari tim yang terdiri dari orang2 yang dipercaya oleh ketua review untuk membantu pelaksanaan review

2.       Preparations

Persiapan yang dapat dilakukan antara lain :

§  Menyiapkan jobdesk untuk review tim serta segala persiapannya

§  Menyiapkan review tools yang dapat digunakan dalam proses review secara keseluruhan

§  Persiapan teknis dan administratif

3.       DR sessions

Merupakan sesi pelaksanaan review yang terdiri dari aktifitas

§  Presentasi design dokumen yang telah dibuat

§  Komentar serta evaluasi dari review team

§  Verifikasi dan validasi berdasarkan dari hasil komentar dan evaluasi yang didiskusikan bersama

§  Keputusan yang berupa :

·         FULL APPROVAL : disutujui semua design yang telah dibuat

·         PARTIAL APPROVAL : ada beberapa bagian yang harus direvisi dan proyek akan berjalan setelah revisi

·         DENIAL OF APPROVAL : penolakan dari design sehinngga development team harus mendesign ulang

4.       Recommended post DR terdiri dari hasil evaluasi dari proses revie

PEER REVIEW

                Sedangkan peer review cenderung lebih kompleks dan menyeluruh dimana terdiri dari beebrapa participant yang lebih yakni :

-          A review leader

-          The author

-          Specialized professional

Yakni ada tambahan review dari professional yang memang ditujukan untuk membantu proses review. Dimana disarankan berupa :

o   A designer : seorang yang mendesain system

o   A coder : yang melakukan code dari pengembang

o   A tester ; seorang tester professional

Sedangkan untuk walkthrough beberapa professional yang disarankan antara lain :

o   A standar enforcer : dimana seorang yang telah berpengalaman dalam penentuan standard an prosedur.

o   A maintenance expert : seseorang yang telah ahli dalam proses maintenance software sehingga bisa didapat masukan untuk proses implementasi software.

o   A user representative : calon user yang telah berpengalaman dalam penggunaan software sejenis

Peer review proses :

Dilaksanakan dalam sebuah dokumen dalam petunjuk2 Appendix C of MIL-STD-498 (DOD, 1994) dimana untuk system penilaian error didasarkan pada penilaian skala berikut :

Severity               Description

5 (critical)                     (1) Prevents accomplishment of essential capabilities.

(2) Jeopardizes safety, security or other critical requirements.

4                                  (1) Adversely affects the accomplishment of essential capabilities,

where no work-around solution is known.

(2) Adversely affects technical, cost or schedule risks to project or

system maintenance, where no work-around solution is known.

3                                  (1) Adversely affects the accomplishment of essential capabilities,

where a work-around solution is known.

(2) Adversely affects technical, cost or schedule risks to the

development project or to the system maintenance, where a work-around solution is known.

2                                  (1) User/operator inconvenience that does not affect required mission

or operational essential capabilities.

(2) Inconvenience for developmentor maintenance personnel, but

does not prevent the realization of those responsibilities.

1                              (minor) Any other effect.

Mengenal SQA architecture

                Dalam sebuah pengembangan perangkat lunak atau biasa kita sebut software, tentunya diperlukan suatu pengelolaan kualitas agar dapat memenuhi tuntutan dan juga kebutuhan akan software tersebut. Pengelolaan kualitas tersebut biasa disebut quality manajemen atau software quality manajemen (SQA). SQA yang sebenarnya adalah Software Quality Assurance merupakan suatu tatanan dan tahapan – tahapan yang ditempuh guna mendapatkan kualitas dari software yang diinginkan.

                SQA menuurut Galin, memberikan suatu pedoman dalam suatu proyek pengembangan software. Jadi focus dari SQA adalah memberikan tatanan dalam proses proyek pengembangannya. Struktur dalam SQA sendiri telah diatur jelas dalam SQA Architecture berikut :

Secara umum, SQA architecture terdiri dari 5 proses utama :

1.       Pre project components

Adalah proses persiapan dalam memulai proyek pembuatan software, yang terdiri dari contract review dan project development plan dan quality plan

2.       Project life cycle components

Pada proses ini adalah tahapan dalam proses pengembangan software nya yang memastikan kualitas saat proyek berjalan yang terdiri dari :

o   Formal desain review

o   Peer reviews

o   Expert opinion

o   Software testing

o   Software maintenance

o   Sqa of external participant

3.       Quality infrastucture components

4.       Quality management

5.       Standart serta Organizational base

Untuk detail lebih lanjut tiap proses akan dibahas detail lebih lanjut.

Project progress control in SQA

Setelah membahas pentingnya sebuah pendokumentasian dalam sebuah proyek perangkat lunak, maka disini akan diulas tentang langkah focus pada progress. Project progress control menjadi salah satu bagian penting dalam memastikan kualitas pernagkat lunak dalam sebuah proyek. Dimana Project Progress Control atau bisa disebut PPC ini meliputi :

-          Memastikan pada kebutuhan fungsional teknis

-          Memastikan penjadwalan dan pendanaan

-          Proses pengembangan dan proses pembuatan

Yang dirangkum dalam beberapa komponen utama yakni :

1.       Pengelolaan resiko

                Merupakan tahapan identifikasi resiko – resiko yang mungkin timbul selama proses pengerjaan perangkat lunak. Beberapa standar yang sering dipakai IEEE (2001), Jones (2004), dimana melalui dokumen ini, manajer proyek akan lebih mudah dalam mengantisipasi dan melakukan perencanaan pengembangan

2.       Project schedule control

Merupakan pengelolaan yang focus pada penjadwalan pengerjaan. Berdasarkan milestone yang telah direncakan, terdapat aktivitas dalam identifikasi keberhasilan pengerjaan ataupun identifikasi masalah serta keterlambatan

3.       Project resource control

Seringkalinya keluar masuk anggota team membuat pengelolaan sumberdaya terutama manusia sangatlah penting. Kita harus memastikan setiap anggota tim memiliki tujuan yang sama dengan manajer proyek.

4.       Project budget control.

Seringkalinya proyek terhambat, ataupun terlambat, itu disebabkan oleh pendanaan. Manajemen keuangan sangatlah penting dalam sebuah proyek. Karena semua menyangkut kepada uang, yakni beberapa aspek dibawah :

§  Human resources

§  Development and testing facilities

§  Purchase of COTS software

§  Purchase of hardware

§  Payments to subcontractors.

Berikut contoh dari progress report menurut Galin :

Document Control in SQA

Sebuah pengembangan suatu aplikasi atau perangkat lunak bukanla hal yang singkat dan mudah. Butuh sumberdaya berupa waktu, manusia serta berbagai kebutuhan. Tidak jarang perangkat lunak yang kompleks membutuhkan banyak tenaga manusia yang pastinya juga membutuhkan manajemen yang baik pula.

                Permasalahan yang sering timbul selama masa pengembangan perangkat lunak adalah masalah waktu pengerjaan, orang – orang yang keluar dan masuk dalam tim, budgeting, dsb. Salah satu factor utama yang menjadi kesulitan utama adalah perihal pendokumentasian. Dokumentasi yangtidak teratur menjadi penyebab utama molornya pengerjaan, tidak adanya progress, bahkan ketidaksesuaian antara code dan design serta permintaan pelanggan.

                Dokumentasi sangatlah penting dalam proses pembuatan suatu perangkat lunak karena selain memberikan informasi serta data, dapat pula menjadi alat untuk control proses pengerjaan perangkat lunak. Dalam penyusunan dokumen control yang baik pun perlu dipertimbangkan beberapa standar yang umum digunakan yakni :

-          ISO 9000-3

-          ISO (1997)

-          ISO/IEC (2001)

-          IEEE / EIA

Berbicara mengenai dokumen control adalah juga salah satu aspek pengelolaan kualitas dari perangkat lunak itu sendiri, Karena dokumentasi memastikan semua berjalan sesuai dengan rencana. Berikut beberapa tujuan utama dari pengelolaan dokumen control :

1.       Memastikan kualitas dari dokumentasi proyek

2.       Memastikan kelengkapan dan kebenaran struktur dokumen, prosedur, serta instruksi

3.       Mendukung investigasi dan pendeteksian kesalahan dalam pengembangan

4.       Memberikan kemudahan dalam maintenance, pengembangan perangkat lunak kedepan

Ada beberapa jenis dokumen control yang biasa digunakan dalam proses pendokumentasian, yakni

-          Pre-project document :

o   Contract review

o   Software development contract

o   Software development plan

-           Project life cycle documents

o   System requirements document

o   Software requirements document

o   Preliminary design document

o   Critical design document

o   Database description

o   Software test plan

o   Design review report

o   Follow-up records of design review action items

o   Software test procedure

-          SQA infrastructure documents :

o   SQA procedure

o   CAB meeting minutes

-          Quality management

o   Progress report

o   Software metrics report

-          Customer documents

o   Project tender dokumen

o   Change request

Berikut beberapa tahapan dalam merencakan dan membuat dokumen control :

1.       Memutuskan tipe – tipe dokumen mana saja yang kita butuhkan untuk quality record yakni dokumentasi kualitas

2.       Mendefinisikan level dari control

3.       Follow up kebenaran dari pengerjaan dengan perencanaan, bisa berupa quality audits plan

4.       Analisa adanya update, change dan perubahan apapun

Development and Quality Plans

Development Plan dibutuhkan sebagai penjadwalan untuk aktivitas development, mulai dari completion time, budget, resources. Dibutuhkan dalam menyelesaikan resiko dan sebagai proyek control. Adapun 11 elements dari Development Plan yaitu:

1.       Project products

2.       Project interfaces

3.       Project methodology and development tools

4.       SW development standards and procedures

5.       The mapping of the development process

6.       Project milestones

7.       Project staff organization

8.       Development facilities

9.       Development risks

10.   Control methods

11.   Project cost estimation

Quality Plan merupakan  proses sistematis yang menerjemahkan kebijakan mutu ke dalam tujuan yang terukur dan menetapkan urutan langkah-langkah untuk mewujudkannya dalam jangka waktu yang ditentukan. Adapun 5 element dari Quality Plan yaitu:

Quality goals

Tujuan kualitas (quality goals), dapat dilihat sebagai tingkatan kinerja yang hendak dicapai.

Planned review activities

Pada tahapan ini terdapat tahap-tahap yang harus dilakukan untuk menghasilkan rencana yang berkualitas yaitu:

• Menentukan scope
• Menentukan jenis kegiatan yang dilakukan
• Menentukan jadwal kegiatan proses proyek
• Menentukan prosedur yang akan diterapkan
• Menentukan siapa yang bertanggung jawab untuk melakukan kegiatan review.

Plan SW test

Plan testing software yang harus dilakukan meliputi:

• Unit, integrasi atau sistem untuk diuji.
• Jenis kegiatan pengujian yang akan dilakukan.
• Jadwal direncanakan uji.
• Siapa yang bertanggung jawab untuk melaksanakan ujian.
• Spesifik prosedur yang harus diterapkan.

Planned acceptance tests for externally developed software

Configuration management