Menghadapi masa depan: tantangan SQA

SQA akan menghadapi tantangan di masa depan yang telah diuraikan dalam pengamatan tren
rekayasa perangkat lunak:
a) kompleksitas pertumbuhan dan packages perangkat lunak
b) integrasi pertumbuhan dan kebutuhan interface
c) jadwal proyek yang lebih pendek
d) tidak ditoleransinya pertumbuhan produk perangkat lunak yang cacat
Menghadapi masa depan: kemampuan SQA
Kita bisa berharap SQA dapat memenuhi tantangan yang telah diuraikan dalam pengamatan tren
rekayasa perangkat lunak:
a) Perluasan penggunaan CASE tools
b) Perluasan penggunaan standar profesional
c) Perluasan penggunaan pengujian otomatis
d) Perluasan penggunaan kembali perangkat lunak (reuse)

















Gambaran dan tantangan SQA di masa mendatang
Increasing Complexity (Peningkatan Kompleksitas)
Seperti yang kita ketahui kompleksitas meningkat secara eksponensial. Ke depannya
engineers perangkat lunak memahami semua aspek aplikasi . Di masa mendatang engineers
perangkat lunak mungkin akan sedikit kurang memahami dari desain perangkat lunak secara
keseluruhan.Hal ini dapat mempengaruhi kepuasan kualitas dari pelanggan
Disebarnya pengembangan tim secara geografis (Geographically Dispersed Development Teams)
Pengembangan Tim secara geografis mulai terbiasa di tahun 90 an ditandai dengan
munculnya pengembangan dan pengujian off shore .Ini terus berkembang meskipun beberapa
project yang dikerjakan secara off shore mengalami kegagalan. Pengembangan dan pengujian
secara off shore terus berkembang di negara-negara dunia ketiga dengan infrastruktur yang
buruk dan gaji yang rendah.Permasalahan bahasa dan budaya akan menjadi tantangan.Naik dan
turun nya mata uang internasional terhadap dollar juga akan menentukan kelayakan ekonomi
dari keseluruhan usaha. Peningkatan penggunaan tim pengembangan dan pengujian secara
geografis akan menciptakan kesenjangan desain pengetahuan secara signifikan.
Integrasi yang berkesinambungan (Continous integration)
Integrasi yang berkesinambungan dimulai pada tahun 90 an dan pada awalnya meerupakan
proses yang kebanyakan manual.Dan secara terus menerus integrasi proses dan alat akan
berkembang di masa mendatang.Mereka akan menjadi bagian dari pengembangan proyek
perangkat lunak

Pengujian yang berkelanjutan ( Continous Testing)
Bertahun-tahun engineers perangkat lunak kurang antusias dengan pengujian code mereka
dengan cara sistem pertemanan yakni teman anda menguji code yang anda kerjakan dan
sebaliknya dengan diri anda. Ini mengakibatkan beberapa perubahan diantaranya
mengotomatisasi proses pengujian code sehingga dapat secara otomatis dan terus menerus
dengan setiap perubahan code yang dibuat

Distributed Source Code Control
Pengontrolan source code selalu menjadi sumber masalah utama terutama ketika tim
terpisah secara geografis. Untuk keberhasilan di masa mendatang tim ini akan bergantung pada
distributed source code tools yang membantu mengelola code yang terus berubah.
Continuous Deployment
Di masa lalu organisasi pengembangan perangkat lunak banyak tersiksa dengan seberapa
sering organisasi tersebut merilis produk baru bagi para pelanggan.Salah satu yang sangat
ekstrim pada sebuah organisasi perangkat lunak yakni jarang nya merilis versi baru sebuah
produk. Di lain pihak extreme areorganizations merilis versi baru setiap harinya.Strategi
deployment tergantung pada banyak faktor dan tidak sedikit tergantung pada kemampuan untuk
mengembangkan dan mengujinya dengan cepat.
Virtualization (Virtualisasi)
Menyiapkan laboratorium uji selalu menjadi tantangan baik secara teknis maupun secara
finansial. Memelihara konfigurasi uji laboratorium sangat memakan waktu. Di masa yang akan
datang akan terlihat penggunaan laboratorium uji virtual dimana platform virtual yang berbeda
dapat mudah diatur dan dikonfigurasi untuk lebih cocok dengan keinginan pelanggan
Test Automation Tools and Frameworks
Test Automation tools akan terus berkembang dan akan terus meningkat di masa yang akan
datang.Test automation tools yang baru akan membutuhkan ketrampilan pemrograman dan akan
mencakup beberapa fitur yang mendukung diantaranya
Keyword-driven testing
Model-driven testing
GUI-driven testing
Test Automation Tools selalu menjadi kerangka yang komprehensif yang mendukung test
development life cycle mulai dari initial test planning, test prototyping, test development, test
execution, defect reporting and tracking, and test reporting, metrics, and trending.kemungkinan
akan menjadi integrasi yang lebih kuat antara test automation tools yang biasanya digunakan
oleh SQA engineers dan continuous test tools yang digunakan oleh para developers
Balanced Test Teams (Uji Team yang seimbang)
Test team masa depan mungkin akan lebih seimbang dan mencakup pengujian baru diantaranya
Test Architect dianalogikan dengan seorang arsitek. seorang arsitek perangkat lunak
menentukan apa jenis tes yang diperlukan, apa alat uji akan sangat tepat, dan apa tes
keterampilan tim yang diperlukan. biasanya akan memiliki pelatihan dalam rekayasa
perangkat lunak dan pengujian. Test Architect biasanya akan memiliki pelatihan dalam
rekayasa perangkat lunak dan pengujian.
Test Developer-di analogikan dengan seorang engineers perangkat lunak .Test developer
akan terampil dalam bahasa scripting dan Test Automation Tools. Test Developer akan
menciptakan test otomatis yang berkolaborasi dengan Architect dan engineer test.Test
Developer biasanya akan memiliki pelatihan dalam rekayasa perangkat lunak dan
pengujian.
Test Engineer -- memiliki pengetahuan domain dan keterampilan pengujian untuk
membuat tes manual. Bekerja dengan Architect dan Developer tes untuk memastikan
bahwa pengetahuan domain diterapkan dalam semua berbagai jenis tes yang
dikembangkan. Membuat dan menjalankan tes manual dan otomatis. Menyiapkan
laporan pengujian dan statistik. Test Engineer biasanya akan memiliki pelatihan teknik
pengujian yang efektif.
Safety Cases
Ketergantungan perangkat lunak ini diperburuk oleh kurangnya bukti tentang dan tingkat
keparahan kegagalan perangkat lunak. Kegagalan perangkat lunak adalah sering tidak dilaporkan
dan tingkat keparahan kegagalan-kegagalan yang dilaporkan sering tidak dimengerti.
sistem akan bisa diterima aman dalam beberapa konteks tertentu diantaranya
High Level Arguments
Argumen ini merupakan penjelasan tentang bagaimana bukti yang tersedia dapat
menunjukkan keamanan yang dapat diterima biasanya dengan menunjukkan kepatuhan
terhadap persyaratan, mitigasi yang cukup dan / atau menghindari bahaya dll
Supporting Evidence (Bukti Pendukung)
Bukti ini sering kali berisi hasil observasi, analisis, pengujian, simulasi dan memperkirakan
sifat-sifat sistem yang menyediakan informasi mendasar mengenai dari mana keamanan dan
kehandalan dapat disimpulkan.

Daftar Pustaka
Food for Thought, an e-newsletter from Software Quality Consulting.
Gokulakrishnan Jagadeesan , Hariharan Mathrubutham , Rajesh Kumar Kumaresan and Anuradha
R,Service Level Based Automated Software Quality Assurance Model
Jeff Tian Southern Methodist University Dallas, Texas, USA,Software Quality Assurance,Meeting New
Challenges
Emanuel R. Baker,Which Way, SQA?
http://fortunelazone.blogspot.com/2012/02/quality-management-challenges.html
http://adel96.wordpress.com/2012/06/12/the-future-of-sqa/