Sebutkan alasan mengapa kualitas perangkat lunak harus tetap dijaga

Setiap sistem manajemen memiliki keinginan tinggi terhadap kualitas. Sebagai contoh penerapan Total Quality Management (TQM) dan Six Sigma di perusahaan selalu berbicara bagaimana kita bisa membuat terobosan untuk meningkatkan kualitas layanan melalui perbaikan-perbaikan. Kenapa kualitas ini menjadi penting bagi bisnis Anda?

1. Meningkatkan reputasi perusahaan
Dengan menciptakan produk yang berkualitas, perusahaan akan mendapatkan predikat yang bagus di mata pelanggan. Bahkan tidak menutup kemungkinan produk akan cepat berekspansi ke pasar global.

2. Kesempatan mewujudkan cost reduction
Dengan menghasilkan produk yang berkualitas, berarti perusahaan mampu melakukan kegiatan produksi dengan efektif dan efisien. Produk yang dihasilkan sesuai dengan kebutuhan dan harapan pelanggan sehingga jumlah produk defect atau barang cacat dapat ditekan sekecil mungkin (zero waste)

3. Menjadi kunci untuk mendapat loyalitas pelanggan
Kualitas menjadi kunci utama agar produk dikenal dan dipercaya masyarakat luas. Jika ingin meningkatkan loyalitas ke level yang lebih tinggi pastikan Anda meningkatkan kualitas terlebih dahulu. Baik kualitas produk maupun kualitas pelayanan.

Anda sebagai pengusaha, pastinya ingin bisnis yang berkelanjutan dengan meluncurkan lebih dari satu produk bukan? Mulai pikirkan produk dan kualitas seperti apa yang akan diminati pasar. Karena pada akhirnya, kualitas lah yang dinilai konsumen, bukan yang lain. Mungkin konsumen tidak peduli bagaimana Anda melakukannya, tetapi mereka hanya peduli pada kualitas apa yang mereka dapatkan dengan produk atau layanan Anda.

Saat ini konsumen cenderung memilih sebuah produk karena kelebihan, baik itu fitur yang lebih komplit atau pun pelayanan pelanggan yang lebih baik. Anda harus bisa mewujudkan itu. Berikan sesuatu yang selalu berbeda, yaitu apa yang tidak dimiliki oleh kompetitor. Jadikan kualitas menjadi hal utama.

shiftindonesia

Dalam konteks rekayasa perangkat lunak, ukuran kualitas software bagaimana perangkat lunak baik dirancang (kualitas desain), dan seberapa baik perangkat lunak sesuai dengan desain (kualitas kesesuaian),  meskipun ada beberapa definisi yang berbeda. Hal ini sering digambarkan sebagai ‘kesesuaian untuk tujuan’ dari software.

Penjelasan :

 Explicit (Explicit): didefinisikan secara jelas dan didokumentasikan
 Implicit(Implisit): tidak didefinisikan secara jelas dan didokumentasikan tetapi secara tidak langsung disarankan
 Requirements (Persyaratan): kebutuhan bisnis / produk / perangkat lunak
 Expectations (Harapan): terutama pengguna akhir harapan

Dua cara pendekatan kualitas perangkat lunak yang umum:

  • Defect Management Approach (Pendekatan Manajemen yang cacat)

Kekurangan pada  perangkat lunak dapat dianggap sebagai kecacatan untuk mengatasi kebutuhan pengguna akhir (end-user requirements). Biasanya terjadi karena kesalahpahaman  persyaratan dan kesalahan dalam desain, logika fungsional, relasi data, waktu proses, pengecekan validitas, coding, dll

Pendekatan manajemen yang cacat didasarkan pada penghitungan dan  mengelola kekurangan(managing defects). Biasanya dikategorikan berdasarkan tingkat keparahan, dan angka dalam setiap kategori yang digunakan untuk perencanaan. Organisasi pengembangan perangkat lunak yang profesional biasanya menggunakan alat-alat seperti defect leakage matrics (untuk menghitung jumlah error yang melewati tahapan pembangunan (development) sebelum dideteksi) dan kontrol grafik untuk mengukur dan meningkatkan kemampuan proses pembangunan(development).

  • Quality Attributes Approach (Kualitas dari atribut pendekatan)

Pendekatan ini untuk kualitas perangkat lunak yang terbaik dicontohkan oleh model kualitas tetap, seperti ISO / IEC 25010: 2011. Standar ini menjelaskan 8 hirarki kualitas karakteristik, masing-masing terdiri dari sub-ciri:

o Kesesuaian Fungsional(Functional Suitability)
o Keandalan(Reliability) o Operability

o Efisiensi Kinerja(Performance Efficiency)


o Keamanan(Security)
o Kompatibilitas(Compatibility)
o Perwatan(Maintainability)
o Transferability

Selain itu, standar mendefinisikan kualitas dalam penggunaan model yang terdiri dari lima karakteristik:

o Efektivitas(Effectiveness)
o Efisiensi(Efficiency)
o Kepuasan(Satisfaction)
o Keselamatan(Safety)
o Usability

7 langkah untuk meningkatkan kualitas perangkat lunak

  1. Menentukan kualitas secara seimbang untuk kebutuhan Dampak terhadap Kualitas: Memenuhi kebutuhan bisnis, mencapai pengalaman pengguna yang memuaskan. Manfaat: Kemampuan Anda untuk mencapai kualitas ditingkatkan karena tim pengembangan aplikasi tidak dibebankan dengan harapan tidak realistis sempurna. Sebaliknya, itu disewa dengan definisi kualitas yang sesuai dengan keterbatasan waktu, sumber daya, dan anggaran yang diberikan.

    Peran yang relevan: stakeholder Bisnis, seluruh tim pengembangan aplikasi.

  2. Broadcast Kualitas Metrik Secara Sederhana Dampak terhadap Kualitas: Mengurangi cacat atau kekurang atau kegagalan. Manfaat: metrik Sangat terlihat menjaga kualitas top of mind bagi seluruh tim dan mengekspos ketika upaya gagal.

    Peran yang relevan: Seluruh Tim pengembangan aplikasi.

  3. Fine-Tune Tim Dampak terhadap Kualitas: Memenuhi kebutuhan bisnis, mencapai pengalaman pengguna yang memuaskan dan mengurangi kekurangan atau kegagalan. Manfaat: Anggota tim melakukan sesuai dengan insentif mereka, membuat peningkatan kualitas bagian dari tujuan mereka memperkuat perilaku yang diinginkan.

    Peran yang relevan: Manajemen.

  4. Dapatkan Persyaratan yang Tepat Dampak terhadap Kualitas: Memenuhi kebutuhan bisnis, mencapai pengalaman pengguna yang memuaskan. Manfaat: Mengurangi pengulangan berarti lebih sedikit pengujian ulang dan siklus yang lebih sedikit, yang sangat mengurangi upaya menyeluruh.

    Peran yang relevan: Manajer, analis bisnis, pengalaman pengguna desainer, arsitek.

  5. Menguji Secara Cerdas untuk mengurangi Pengujian. Dampak terhadap Kualitas: Mengurangi cacat atau kegagalan. Manfaat: Fokus pada pengujian daerah risiko yang paling penting dan memastikan bahwa mereka menerima bagian terbesar dari sumber daya pengujian dan bahwa setiap bug yang lolos kemungkinan akan terbatas pada fitur paling penting.

    Peran yang relevan: Jaminan kualitas, manajer.

  6. Desain Aplikasi untuk Mengurangi Risiko Bug Dampak terhadap Kualitas: Mengurangi cacat atau kegagalan. Manfaat: Sederhana, desain bersih menghasilkan kode yang lebih sederhana, lebih bersih, dan lebih mudah untuk menguji dan ulang yang berarti bahwa kode akan memiliki lebih sedikit bug dan bug akan lebih mudah untuk mendiagnosa dan memperbaiki.

    Peran yang relevan: Arsitek, pengembang.

  7. Optimalkan Penggunaan Alat Pengujian Dampak terhadap Kualitas: Mengurangi cacat atau kegagalan. Manfaat: Otomasi membebaskan sumber daya dari pengujian biasa untuk fokus pada tes prioritas tertinggi dan meningkatkan pengulangan tes siklus.

    Peran yang relevan: Jaminan kualitas, pengembang

Apa strategi uji dalam pengujian perangkat lunak?

Pilihan uji pendekatan atau strategi uji merupakan salah satu faktor yang paling kuat dalam keberhasilan upaya uji dan keakuratan rencana uji dan perkiraan. Faktor ini berada di bawah kendali para penguji dan pemimpin tes.

Mari kita survei jenis utama dari strategi tes yang umum ditemukan:

  • Analitis: Mari kita ambil contoh untuk memahami hal ini. Strategi berbasis risiko melibatkan melakukan analisis risiko dengan menggunakan dokumen proyek dan masukan dari stakeholder, maka perencanaan, memperkirakan, merancang, dan memprioritaskan tes berdasarkan risiko. Strategi lain tes analitis adalah strategi persyaratan berbasis, di mana analisis persyaratan spesifikasi membentuk dasar untuk perencanaan, estimasi dan merancang tes. Menguji strategi analitis memiliki kesamaan penggunaan beberapa teknik analisis formal atau informal, biasanya selama persyaratan dan tahapan desain proyek.
  • Model-based: Mari kita ambil contoh untuk memahami hal ini. Anda dapat membangun model matematika untuk loading dan respon untuk server e-commerce, dan tes berbasis pada model tersebut. Jika perilaku sistem yang diuji sesuai dengan yang diprediksi oleh model, sistem ini dianggap bekerja. Menguji strategi model berbasis memiliki kesamaan penciptaan atau pemilihan beberapa model yang formal atau informal untuk perilaku sistem yang penting, biasanya selama persyaratan dan tahapan desain proyek.
  • Metodis: Mari kita ambil contoh untuk memahami hal ini. Anda mungkin memiliki daftar yang telah Anda mengumpulkan selama bertahun-tahun yang menunjukkan bahwa bidang utama pengujian untuk menjalankan atau Anda mungkin mengikuti standar industri untuk kualitas perangkat lunak, seperti ISO 9126, untuk outline Anda daerah ujian besar. Anda kemudian metodis merancang, melaksanakan dan menjalankan tes berikut garis besar ini. Menguji strategi metodis memiliki kesamaan kepatuhan terhadap pra-direncanakan, sistematis pendekatan yang telah dikembangkan di rumah, dirakit dari berbagai konsep yang dikembangkan in-house dan dikumpulkan dari luar, atau diadaptasi secara signifikan dari ide-ide luar dan mungkin memiliki titik awal atau akhir dari keterlibatan untuk pengujian.
  • Proses – atau standar-compliant: Mari kita ambil contoh untuk memahami hal ini. Anda mungkin mengambil sumber dari standar IEEE 829 untuk pengujian Anda, menggunakan buku-buku seperti [Craig, 2002] atau [Drabick 2004] untuk mengisi kekosongan metodologis. Atau, Anda mungkin mengambil sumber dari  salah satu metodologi tangkas seperti Extreme Programming. Strategi pemrosesan atau standar-compliant miliki ketergantungan umum pada pendekatan eksternal dikembangkan untuk pengujian, seringkali dengan sedikit – jika ada – customization(kostumisasi) dan mungkin memiliki titik awal atau akhir dari keterlibatan untuk pengujian.
  • Dinamis: Mari kita ambil contoh untuk memahami hal ini. Anda dapat membuat satu set ringan dari garis panduan pengujian yang berfokus pada adaptasi cepat atau kelemahan yang dikenal dalam perangkat lunak. Strategi dinamis, seperti pengujian eksplorasi, memiliki kesamaan berkonsentrasi pada menemukan banyak cacat mungkin selama pelaksanaan tes dan beradaptasi dengan realitas sistem yang diuji seperti saat dikirim, dan mereka biasanya menekankan tahap akhir pengujian. Lihat, misalnya, pendekatan berbasis serangan [Whittaker, 2002] dan [Whittaker, 2003] dan pendekatan eksplorasi [Kaner et al., 2002].
  • Konsultatif atau diarahkan: Mari kita ambil contoh untuk memahami hal ini. Anda mungkin bertanya pengguna atau pengembang sistem untuk memberitahu Anda apa yang harus menguji atau bahkan bergantung pada mereka untuk melakukan pengujian. Strategi konsultasi atau diarahkan memiliki kesamaan ketergantungan pada kelompok non-penguji untuk membimbing atau melakukan upaya pengujian dan biasanya menekankan tahap akhir pengujian hanya karena kurangnya pengakuan dari nilai tes awal.
  • Regresi-menolak(Regression-averse): Mari kita ambil contoh untuk memahami hal ini. Anda mungkin mencoba untuk mengotomatisasi semua tes fungsi sistem, sehingga jika perubahan apa-apa, Anda dapat menjalankan kembali setiap tes untuk memastikan tidak ada yang rusak. Strategi regresi-averse memiliki kesamaan satu set prosedur – biasanya otomatis – yang memungkinkan mereka untuk mendeteksi cacat regresi. Strategi regresi-menolak mungkin melibatkan mengotomatisasi tes fungsional sebelum melepaskan fungsi, dalam hal ini memerlukan pengujian awal, tapi kadang-kadang pengujian hampir seluruhnya berfokus pada fungsi pengujian yang sudah dirilis, yang dalam beberapa hal bentuk keterlibatan uji rilis pasca.

Beberapa strategi ini lebih preventif,untuk orang lain yang lebih reaktif. Sebagai contoh, strategi uji analitis melibatkan analisis dimuka dari dasar pengujian, dan cenderung untuk mengidentifikasi masalah dalam dasar pengujian sebelum pelaksanaan tes. Hal ini memungkinkan awal – dan murah – penghapusan cacat. Itu adalah kekuatan pendekatan preventif.

Strategi uji dinamis fokus pada periode pelaksanaan ujian. Strategi tersebut memungkinkan lokasi cacat dan kelompok cacat yang mungkin sulit untuk mengantisipasi sampai Anda memiliki sistem yang sebenarnya di depan Anda. Itu adalah kekuatan pendekatan reaktif.
Tidak ada satu cara terbaik. Kami menyarankan agar memilih tes apa pun pendekatan yang paling masuk akal dalam situasi tertentu, dan merasa bebas untuk meminjam dan berbaur.

Bagaimana Anda tahu strategi  untuk memilih atau mencampur(blend) untuk kesempatan terbaik untuk sukses?

Ada banyak faktor yang harus dipertimbangkan, tetapi marilah kita menyoroti beberapa yang paling penting

  • Risiko: Manajemen risiko sangat penting selama pengujian, jadi pertimbangkan risiko dan tingkat risiko. Untuk aplikasi mapan yang berkembang perlahan-lahan, regresi merupakan risiko yang penting, sehingga strategi regresi-menolak masuk akal. Untuk aplikasi baru, analisis risiko dapat mengungkapkan risiko yang berbeda jika Anda memilih strategi analitis berbasis risiko.
  • Keterampilan: Pertimbangkan keterampilan yang Anda miliki penguji dan kurangnya karena strategi tidak hanya harus dipilih, mereka juga harus dijalankan . Sebuah strategi sesuai standar adalah pilihan yang cerdas ketika Anda tidak memiliki waktu dan keterampilan dalam tim untuk membuat pendekatan Anda sendiri.
  • Tujuan: Pengujian harus memenuhi kebutuhan dan persyaratan dari stakeholder, kepentingan untuk menjadi sukses. Jika tujuannya adalah untuk menemukan banyak cacat(error) mungkin dengan jumlah minimal waktu dan usaha yang diinvestasikan – misalnya, di laboratorium uji yang khas independen – maka strategi dinamis yang masuk akal.
  • Peraturan: Kadang-kadang Anda harus memenuhi tidak hanya kepentingan stakeholder, tetapi juga regulator. Dalam hal ini, Anda mungkin perlu untuk merencanakan strategi uji metodis yang memenuhi regulator  bahwa Anda telah memenuhi semua persyaratan mereka.
  • Produk: Beberapa produk seperti, sistem persenjataan dan perangkat lunak kontrak pengembangan cenderung memiliki persyaratan yang ditentukan. Hal ini menyebabkan sinergi dengan strategi analisis persyaratan berbasis.
  • Bisnis: pertimbangan bisnis dan kelangsungan bisnis sering dianggap penting. Jika Anda dapat menggunakan sistem warisan sebagai model untuk sistem baru, Anda dapat menggunakan strategi model berbasis.

Anda harus memilih menguji strategi terhadap faktor-faktor yang disebutkan sebelumnya, jadwal, anggaran, dan kendala fitur proyek dan realitas organisasi dan politiknya.

Sumber Materi:

Video yang berhubungan

Postingan terbaru

LIHAT SEMUA