Apa itu kualitas? Apa yang dimaksud dengan pengujian? Dan bagaimana kita dapat membuat para pemangku kepentingan dan anggota tim peduli? Ini mungkin pertanyaan-pertanyaan dasar yang Anda miliki saat bertanya-tanya tentang pendekatan metodis untuk rekayasa kualitas sistem Teknologi Informasi (TI).
Di dunia saat ini banyak orang dan organisasi yang bergantung pada sistem TI, banyak hal yang tidak mungkin dilakukan tanpa sistem TI. Jadi, kita harus dapat mempercayai bahwa sistem TI tersebut bekerja dengan baik untuk mendukung proses bisnis. Ini berarti kualitasnya harus berada pada tingkat yang sesuai dengan tujuan dan memberikan nilai bisnis.
Definisi - kualitas
Kualitas adalah totalitas fitur dan karakteristik produk atau layanan yang berpengaruh pada kemampuannya untuk memuaskan kebutuhan yang dinyatakan atau tersirat.
Kualitas yang tepat paling baik dicapai dengan pendekatan integral. Kami menyebutnya rekayasa kualitas.
Definisi - rekayasa kualitas
Rekayasa Kualitas adalah tentang anggota tim dan pemangku kepentingan yang bertanggung jawab bersama untuk terus memberikan sistem TI dengan kualitas yang tepat pada saat yang tepat kepada para pebisnis dan pelanggan mereka. Ini adalah prinsip rekayasa perangkat lunak yang berkaitan dengan penerapan ukuran kualitas untuk memastikan kualitas sistem TI.
Inti dari rekayasa kualitas adalah orang-orang yang bertanggung jawab bersama untuk memberikan kualitas yang tepat dengan menerapkan berbagai ukuran kualitas. Langkah-langkah kualitas ini dapat berupa “pencegahan” (seperti penyempurnaan cerita pengguna atau pemrograman pasangan), “detektif” (seperti pengujian statis dan pengujian dinamis) dan “korektif” (seperti memperbaiki masalah, tidak hanya pada produk tetapi juga pada proses dan / atau keterampilan orang).
Dalam model pengiriman TI DevOps, ada fokus berkelanjutan pada rekayasa kualitas. Sebenarnya, pada umumnya tim DevOps mencoba untuk menerapkan “segala sesuatu yang berkelanjutan”, yang berarti mereka berusaha untuk mengotomatisasi sebanyak mungkin tugas dan aktivitas. Hal ini mengarah pada, antara lain, Integrasi Berkelanjutan dan Penerapan Berkelanjutan (biasanya disingkat CI/CD).
Untuk menerapkan rekayasa kualitas berkelanjutan, di mana pengujian berkelanjutan merupakan bagiannya, tim DevOps harus menggunakan alat canggih yang didukung oleh kecerdasan buatan dan pembelajaran mesin. Hal ini akan memungkinkan mereka untuk menghasilkan kualitas dengan cepat, misalnya dengan memperkirakan masalah kualitas dan menyelesaikannya sebelum ada yang mengalami kegagalan.
Jika kita ingin mengetahui apakah sistem TI kita memang memenuhi kebutuhan, kita harus mengukur kualitasnya. Kita perlu mendefinisikan indikator kualitas dan mengukur indikator ini. Sebagian besar pengukuran ini adalah tugas pengujian. Karena dalam Scrum atau DevOps, kualitas adalah tanggung jawab seluruh tim, pengukuran indikator ini dapat dilakukan oleh setiap anggota tim yang memiliki keterampilan rekayasa kualitas yang diperlukan.
Definisi - pengujian
Pengujian terdiri dari kegiatan verifikasi, validasi, dan eksplorasi yang memberikan informasi tentang kualitas dan risiko terkait, untuk menetapkan tingkat kepercayaan bahwa objek uji akan dapat memberikan nilai bisnis yang dikejar.
Sumber: tmap.net
Definisi pengujian
Pengujian adalah salah satu dari banyak langkah jaminan kualitas dan sering kali dilihat sebagai satu-satunya langkah jaminan kualitas seperti yang diilustrasikan di bawah ini. Sejak dimulainya Teknologi Informasi, kualitas sistem informasi telah menjadi topik yang sering dibahas.
Pengujian adalah bagian dari jaminan kualitas dan proses penyampaian TI secara keseluruhan
Ketika ada kesalahan pada produk TI (mulai dari spesifikasi kebutuhan yang salah hingga kode program yang salah dan perangkat keras yang rusak), kegagalan dapat terjadi, dan orang tidak akan mendapatkan layanan yang mereka butuhkan. Pengujian membantu mendeteksi kesalahan dan kegagalan sehingga dapat diperbaiki sebelum menyebabkan masalah bagi pengguna. Dan sebagai bagian dari semua tindakan kualitas, pengujian mendukung pencegahan, identifikasi, dan penghapusan pemborosan. Pengujian harus fokus pada pengujian fungsional dan non-fungsional.
Pemantauan adalah langkah jaminan kualitas lainnya. Pemantauan mengamati indikator sistem TI yang sedang beroperasi. Pengujian mengamati indikator terutama sebelum sistem TI beroperasi.
Jangan menerapkan “fase perbaikan”
Sumber: tmap.net
Pendekatan awal tim TI hingga tahun 1980-an, ketika menghadapi kualitas yang tidak memadai, adalah mencoba menemukan semua kesalahan dengan menguji dan kemudian memperbaikinya. Untuk menyadarkan orang akan kekeliruan ini, istilah “fase perbaikan” sangat membantu [Weinberg 2008]. Istilah ini dimaksudkan untuk membuat orang sadar bahwa pengujian tidak dapat menyisipkan kualitas di akhir, dan tim juga tidak dapat memperbaiki masalah apa pun di akhir.
Pengujian tidak boleh diimplementasikan sebagai fase perbaikan di akhir.
Pada tahun 1980-an dan 1990-an, orang-orang menemukan bahwa tidak mungkin mendeteksi semua kesalahan dalam sistem yang kompleks; tidak akan pernah ada sistem yang sempurna dengan melakukan pengujian di akhir dan mencoba menemukan dan memperbaiki semua kesalahan. Oleh karena itu, serangkaian ukuran kualitas yang seimbang di seluruh siklus hidup perlu menjamin kualitas.
Sumber: tmap.net
Jaminan kualitas dan pengujian penting di seluruh siklus hidup.
Persyaratan, Desain, Pengembangan, dan Operasi mengacu pada tugas, bukan pada fase atau tahapan, dan dalam konteks DevOps, tugas-tugas ini dapat dilakukan secara bersamaan. Dan karena menurut prinsip DevOps ketiga dari DASA [DASA 2019] tim memiliki tanggung jawab menyeluruh, maka jaminan kualitas dan pengujian harus diimplementasikan sebagai fokus yang berkelanjutan di seluruh siklus hidup.
Tidak perlu dikatakan, tidak adanya fase perbaikan berlaku untuk setiap jenis model pengiriman TI, baik Anda bekerja secara berurutan (misalnya waterfall), berkinerja tinggi (misalnya DevOps), atau hibrida (misalnya SAFe) (untuk informasi lebih lanjut, lihat bagian tentang model pengiriman TI).
Dengan menerapkan jaminan kualitas dan pengujian di seluruh siklus hidup penyampaian TI, kami mencapai pengujian berkelanjutan yang sering dipuji.
Perlu diingat: tidak semua kesalahan perlu diperbaiki. Orang-orang ingin terus memiliki wawasan tentang tingkat kualitas dan risiko yang tersisa, dan bila perlu meningkatkan kualitas di sepanjang siklus hidup. Jika ini berarti masih ada beberapa kesalahan yang tersisa, tidak masalah selama para pemangku kepentingan mengetahuinya dan memiliki solusi yang diperlukan. Kesalahan yang perlu diperbaiki nanti, dapat dimasukkan ke dalam daftar pekerjaan tim.
Contoh
Sebuah perusahaan asuransi membuat sistem asuransi baru untuk produk baru. Karena perusahaan ini adalah yang pertama di pasar dengan produk ini, mereka mengharapkan pangsa pasar yang besar. Ketika tenggat waktu untuk menjalankan produk baru semakin dekat, sistem baru dapat membuat entri baru ke dalam sistem. Selain itu, penghapusan entri sebelumnya juga dimungkinkan. Namun, memperbarui entri yang sudah ada tidak mungkin dilakukan. Hal ini tampak seperti menjadi masalah: pelanggan produk baru tidak dapat pindah rumah, atau mengubah artefak yang diasuransikan. Namun demikian, sistem asuransi tetap diluncurkan, berdasarkan pangsa pasar yang diharapkan dan nilai bisnis yang diharapkan berdasarkan pangsa pasar ini.
Sebagian dari pendapatan yang direalisasikan digunakan untuk mengurangi masalah tersebut. Entri pelanggan yang pindah rumah dihapus dari sistem, dan entri baru berdasarkan alamat baru mereka dibuat. Staf tambahan dipekerjakan untuk memastikan tidak ada surat yang dibuat secara otomatis mengenai pembatalan, atau surat mengenai asuransi baru, yang dikirim.
Dengan demikian, nilai bisnis tidak setinggi yang diproyeksikan pada awalnya, namun masih sedikit lebih tinggi daripada nilai yang seharusnya jika perusahaan asuransi tersebut tidak menjadi yang pertama di pasar.
Mengukur kualitas memberikan informasi untuk membangun kepercayaan
Sumber: tmap.net
Selama bertahun-tahun, orang-orang yang bekerja di proyek dan operasi TI belajar bahwa tingkat kualitas dan jumlah risiko yang tersisa tidak secara langsung berkaitan dengan keputusan apakah sebuah sistem informasi harus ditayangkan atau tidak.
Tingkat kualitas ditentukan dengan mengukur berbagai indikator, misalnya berdasarkan karakteristik kualitas. Ketika kualitas sesuai dengan ekspektasi, hal ini menegaskan bahwa kualitas untuk aspek tertentu baik-baik saja, yang berkontribusi pada keyakinan bahwa sistem TI akan mampu memberikan nilai bisnis yang dikejar.
Anomali yang terdeteksi menunjukkan bahwa kualitasnya mungkin tidak cukup baik. Setelah menganalisis penyebab anomali, kesimpulannya mungkin ada kesalahan. Kesalahan seperti itu dapat diperbaiki, atau didaftarkan sebagai kesalahan yang diketahui, ketika tingkat kualitas, meskipun ada kesalahan seperti itu, masih cukup baik.
Terkadang sistem TI dengan tingkat kualitas yang rendah (yaitu dengan banyak kesalahan yang diketahui dan/atau risiko yang tersisa) tidak menghentikan para pemangku kepentingan untuk memutuskan menggunakan sistem informasi tersebut, karena mereka masih dapat mencapai nilai bisnis mereka. Dalam kasus lain, sebuah sistem informasi tidak mengandung kesalahan sama sekali, tetapi karena tidak berkontribusi pada nilai bisnis, sistem tersebut tetap tidak digunakan (“sistem yang baik dalam proses yang salah”).
Saat ini, nilai bisnis adalah tujuan dari semua aktivitas TI. Dan kegiatan yang berkaitan dengan kualitas dan pengujian bertujuan untuk menetapkan tingkat kepercayaan sehingga para pemangku kepentingan dapat memutuskan apakah sistem TI tersebut dapat memberikan nilai bisnis yang dikejar atau tidak. Berdasarkan gagasan keyakinan ini, orang-orang yang terlibat akan memutuskan untuk menempatkan sistem TI dalam operasi langsung atau tidak.
Informasi tentang kualitas dan risiko kualitas terkait (juga disebut risiko produk) adalah masukan utama bagi para pemangku kepentingan untuk membangun kepercayaan diri mereka.
Definisi - risiko kualitas
Risiko kualitas adalah peluang tertentu bahwa produk gagal sehubungan dengan dampak yang diharapkan jika hal ini terjadi. Peluang kegagalan ditentukan oleh peluang kesalahan dan frekuensi penggunaan. Dampaknya terkait dengan penggunaan operasional produk.
Saat menentukan tingkat risiko, tim melakukan semacam analisis risiko kualitas, seperti yang dijelaskan dalam Blok Bangunan “Analisis risiko kualitas & strategi pengujian”. Peluang terjadinya kesalahan tergantung pada karakteristik TI, misalnya ketika teknologi baru digunakan, peluang terjadinya kesalahan lebih tinggi dibandingkan dengan teknologi lama. Frekuensi penggunaan aplikasi pada ponsel cerdas jauh lebih tinggi daripada fungsi operasi yang menyesuaikan beberapa parameter sistem, dan dengan frekuensi penggunaan yang tinggi, risiko kegagalan menjadi lebih tinggi. Dampaknya dapat berhubungan dengan banyak konsekuensi negatif; sering kali, kerusakan pada citra perusahaan dari organisasi yang bertanggung jawab dipandang sebagai dampak yang tinggi.
Pengujian mengukur indikator yang terkait dengan nilai yang dikejar
Proses penjaminan kualitas dan pengujian bertujuan untuk mengumpulkan dan melaporkan semua informasi yang dibutuhkan oleh para pemangku kepentingan untuk menetapkan tingkat kepercayaan mereka tentang nilai bisnis dari sistem TI. Hal ini dilakukan dengan menetapkan tujuan yang terkait dengan nilai bisnis dan menentukan indikator untuk tujuan tersebut. Indikator-indikator tersebut diukur dengan pengujian, dan langkah-langkah jaminan kualitas lainnya. Sebagai contoh, pengujian dapat mengukur perilaku sistem TI ketika digunakan oleh target audiens tertentu, yang memberikan informasi tentang kegunaan. Pemantauan akan mengukur perilaku dalam operasi langsung, misalnya untuk melihat apakah penggunaan memori cenderung melampaui batas, yang memerlukan tindakan korektif.
Risiko kualitas, tingkat risiko dan kemungkinan dampaknya, ditentukan dalam analisis risiko kualitas. Risiko-risiko ini merupakan bagian dari indikator yang akan diukur dengan pengujian. Bersama dengan pengukuran indikator lainnya, kegiatan pengujian akan memberikan informasi yang dibutuhkan oleh para pemangku kepentingan untuk membangun keyakinan mereka bahwa nilai bisnis yang dikejar dapat dicapai.
Sumber: tmap.net
Informasi tentang kualitas dan risiko dibagikan melalui beberapa jenis pelaporan, baik dalam dokumen, di papan tim, di dasbor otomatis, atau melalui komunikasi lisan (sebaiknya hanya untuk mendukung komunikasi lainnya).
Untuk mendukung lebih lanjut dalam membangun tingkat kepercayaan mereka, para pemangku kepentingan sering kali ingin menyaksikan kegiatan pengujian atau melakukan pengujian sendiri.
Pengujian terdiri dari verifikasi, validasi, dan eksplorasi
Anda mungkin bertanya-tanya: apa sebenarnya pengujian itu? Kami telah memberikan definisi pengujian di awal halaman ini. Dalam definisi ini, Anda dapat melihat sejumlah istilah yang mungkin memerlukan penjelasan. Pengujian umumnya disebut sebagai satu kegiatan, tetapi ketika Anda melihat lebih dekat, pengujian adalah kombinasi dari kegiatan verifikasi, validasi, dan eksplorasi.
Verifikasi memeriksa apakah objek pengujian sesuai dengan persyaratan yang ditentukan (misalnya dari cerita pengguna). Validasi menguji apakah objek uji sesuai dengan tujuan, yaitu apakah memenuhi kebutuhan pengguna dan berkontribusi pada nilai bisnis. Karena verifikasi dan validasi hanya dapat berfokus pada apa yang diketahui, maka harus dilengkapi dengan eksplorasi untuk mengumpulkan informasi tentang hal-hal yang belum diketahui.
Verifikasi berfokus pada “Apakah kita membangun sistem TI dengan benar?”. Validasi berfokus pada “Apakah kita membangun sistem TI yang tepat?” Eksplorasi berfokus pada “Bagaimana sistem TI dapat (salah) digunakan?” Bersama-sama, verifikasi, validasi, dan eksplorasi memberikan pandangan yang lengkap tentang kualitas dan risiko sistem TI.
Ikhtisar istilah-istilah yang terkait dengan pengujian.
Sumber: tmap.net
- Definisi - verifikasi
Verifikasi adalah konfirmasi melalui pemeriksaan dan melalui penyediaan bukti obyektif bahwa persyaratan yang ditentukan telah dipenuhi.
- Definisi - validasi
Validasi adalah konfirmasi melalui pemeriksaan dan melalui penyediaan bukti objektif bahwa tuntutan untuk penggunaan tertentu telah terpenuhi.
- Definisi - eksplorasi
Eksplorasi adalah kegiatan menyelidiki, dan menetapkan kualitas dan risiko penggunaan sistem TI melalui pemeriksaan, penyelidikan, dan analisis.
Anda mungkin bertanya-tanya, mengapa eksplorasi menambah manfaat bagi verifikasi dan validasi? Jika verifikasi dan validasi adalah tentang hal-hal yang sudah kita ketahui, eksplorasi juga menyelidiki hal-hal yang tidak diketahui.
Pada bulan Juli 2019, Michael Bolton mengatakan di Twitter: “Eksplorasi bukanlah sesuatu yang kita lakukan di akhir siklus pengujian. Hal ini sangat penting dalam cara kita mengembangkan perangkat lunak - ya, dalam pemrograman juga, bukan hanya dalam pengujian. Jika kita ingin melakukan pekerjaan formal yang sangat baik, itu harus berasal dari pekerjaan informal, mandiri, dan eksplorasi.” [Bolton 2019]
Pengujian adalah tentang menyediakan berbagai tingkat informasi
Sumber: tmap.net
Tragedi dalam pengujian adalah sebagian besar pemangku kepentingan jarang dapat melihat produk apa pun yang dihasilkan dari aktivitas pengujian (seperti rencana pengujian, skenario pengujian, log pengujian, dan perangkat pengujian lainnya). Secara umum, sebagian besar pemangku kepentingan hanya tertarik pada satu hal yang disediakan oleh pengujian: informasi yang diperlukan untuk memutuskan apakah mereka dapat membawa sistem TI ke dalam operasi langsung (keputusan go/no-go). Dengan kata lain: yang diinginkan oleh para pemangku kepentingan adalah semacam laporan atau dashboard. Namun untuk mengisi sumber informasi seperti itu, banyak aktivitas yang harus dilakukan dan banyak testware yang harus dibuat.
Sangat penting untuk membedakan informasi terhadap audiens yang berbeda. Pada gambar berikut, kotak-kotak berwarna cerah menunjukkan tiga tingkat pelaporan dan bagaimana mereka berhubungan dengan berbagai lapisan ekspektasi, spesifikasi, dan testware yang relevan untuk membuat tingkat pelaporan ini.
[Catatan: Pada gambar ini, kotak yang diarsir dimaksudkan hanya sebagai ilustrasi. Kotak-kotak tersebut terlihat jelas dan dijelaskan secara rinci di bagian “Desain Pengujian”, di mana juga dijelaskan mengapa tingkat pelaporan dibaca dari kanan ke kiri].
Ketiga level ini (dari kanan ke kiri) berkisar dari yang paling detail hingga yang paling tinggi. Orang-orang dalam tim pengiriman TI akan membutuhkan informasi yang sangat rinci untuk mengetahui tentang kualitas objek baru dan perubahan yang mereka kirimkan dan untuk menyelidiki anomali dalam sistem TI dan mengambil tindakan korektif jika diperlukan. Pemilik produk, pebisnis, manajer tingkat proyek, dll. akan membutuhkan laporan ikhtisar untuk melacak status dan kemajuan yang memungkinkan mereka untuk mendukung tim untuk menyesuaikan prioritas atau cara kerja kapan pun diperlukan. Manajemen tingkat tinggi hanya membutuhkan informasi yang sangat singkat untuk mengawasi proses penyampaian TI atau untuk mendukung keputusan go/no-go.
Ketika beberapa tim bekerja bersama dalam satu sistem TI, mereka harus berhati-hati dalam mengumpulkan informasi. Terutama laporan ikhtisar dan laporan tingkat tinggi yang perlu berisi informasi yang disediakan oleh beberapa tim untuk memberikan gambaran umum tentang status sistem TI secara menyeluruh.
Pengujian statis dan dinamis
Pengujian umumnya terdiri dari dua kelompok aktivitas utama.
Sumber: tmap.net
Pengujian statis
Yang pertama adalah pengujian statis, yang juga dikenal sebagai peninjauan. Hal ini dapat dilakukan tanpa menjalankan objek pengujian, misalnya dengan meninjau persyaratan atau dokumen desain, kode sumber, panduan pengguna, rencana proyek dan pengujian, serta kasus pengujian.
Dalam model pengiriman IT berkinerja tinggi, seperti Scrum dan DevOps, sebagian besar kegiatan pengujian statis dilakukan selama penyempurnaan cerita pengguna, sehingga tidak diimplementasikan sebagai aktivitas terpisah, tetapi tetap membutuhkan fokus khusus. Selanjutnya, analisis statis terhadap kode dilakukan untuk memenuhi standar pengkodean. Pengujian statis sebisa mungkin didukung oleh alat bantu. Sebenarnya saat ini sudah ada tools yang tidak hanya melakukan analisis statis tetapi juga mampu melakukan refactoring kode berdasarkan pola refactoring standar. Namun, secara umum, pengujian statis adalah kombinasi dari kecerdasan manusia dan kekuatan alat.
Definisi - pengujian statis
Pengujian statis adalah pengujian dengan memeriksa produk (seperti spesifikasi kebutuhan, manual atau kode sumber) tanpa program yang dieksekusi.
Pengujian dinamis
Ketika kita menjalankan pengujian, dengan kata lain, mengeksekusi objek pengujian (yang dapat bervariasi dari satu modul program tunggal hingga proses bisnis menyeluruh di berbagai organisasi), itulah yang kita sebut sebagai pengujian dinamis. Pengujian dinamis dapat dilakukan secara manual, namun untuk berbagai jenis pengujian, dukungan dari alat otomatisasi pengujian sangat disarankan.
Definisi - pengujian dinamis
Pengujian dinamis adalah pengujian dengan eksekusi objek uji, yaitu menjalankan aplikasi.
Selalu gunakan campuran pengujian statis dan dinamis
Dalam pengaturan pengujian dan jaminan kualitas yang baik, pengujian statis dan dinamis sangat penting. Gagasan tentang kualitas awal diimplementasikan dengan pengujian statis terhadap semua hasil kerja pada tahap yang sangat awal. Misalnya, saat meninjau cerita pengguna, tim mungkin menemukan bahwa beberapa pernyataan dalam cerita pengguna tidak jelas atau ambigu; pemilik produk dapat menjelaskan atau menyelidiki hal ini dengan segera dan memperbaikinya. Dengan cara ini, tidak ada penundaan di kemudian hari dalam proses pengembangan. Aspek kualitas lainnya hanya dapat diuji secara dinamis ketika (bagian dari) sistem TI sudah siap.
Pengujian adalah tentang menilai kualitas berdasarkan kriteria
Sumber: tmap.net
Dalam pengujian, kita menggunakan kriteria untuk menentukan apakah objek uji sesuai dengan ekspektasi tentang kualitas dan risiko. Uraian di bawah ini didasarkan pada satu tim, namun hal yang sama juga berlaku ketika ada beberapa tim yang memberikan sistem TI secara bersama-sama. Dalam hal ini, upaya ekstra mungkin diperlukan untuk menyelaraskan berbagai kriteria dan untuk mengukur apakah kriteria tersebut telah terpenuhi.
Definisi - kriteria masuk
Kriteria entri adalah kriteria yang harus dipenuhi oleh sebuah objek (misalnya, dokumen dasar pengujian atau objek pengujian) agar siap digunakan dalam aktivitas tertentu.
Kriteria entri mendefinisikan apa yang kita harapkan dari suatu produk sebelum dapat digunakan untuk aktivitas tertentu. Sebagai contoh, spesifikasi kebutuhan seperti cerita pengguna harus memenuhi persyaratan masuk yang spesifik sebelum aktivitas dapat dimulai yang menggunakan spesifikasi kebutuhan tersebut sebagai masukan. Dalam Scrum, kita menyebutnya sebagai Definition of Ready (DoR).
Jika kita ingin menentukan apakah pengujian sudah siap, kita menggunakan kriteria keluar, yang merupakan bagian dari Definisi Selesai (DoD) dalam Scrum.
Definisi - kriteria keluar
Exit criteria adalah kriteria yang harus dipenuhi oleh sebuah objek (misalnya, dokumen dasar pengujian atau objek pengujian) agar siap di akhir aktivitas atau tahap proyek tertentu (misalnya, iterasi).
Dengan kriteria keluaran, ada sesuatu yang spesifik yang harus diperhatikan, yaitu apa yang telah disepakati oleh tim untuk disampaikan. Sebuah tim lintas fungsi, yang biasa terjadi di lingkungan Scrum dan DevOps, akan setuju untuk memberikan produk TI dengan tingkat kualitas tertentu. Tingkat kualitas ini didefinisikan dalam kriteria penerimaan dan segera setelah produk memenuhi kriteria, produk tersebut “diterima”. Tim menggunakan hasil dari pengujian untuk mendapatkan informasi tentang perubahan yang diperlukan untuk meningkatkan kualitas. Tim sekarang dapat memberikan tingkat kualitas yang telah disepakati. Dalam penyampaian TI berkinerja tinggi, tim biasanya akan menyampaikan sistem TI dengan cara yang berulang; mereka akan menyampaikan bagian-bagian dari sistem TI dan memastikan setiap bagian memiliki tingkat kualitas yang disepakati.
Definisi - kriteria penerimaan
Kriteria penerimaan adalah kriteria yang harus dipenuhi oleh objek pengujian agar dapat diterima oleh pengguna, klien, atau pemangku kepentingan lainnya.
Dalam kasus tim penguji independen - yaitu tim yang tidak terlibat dalam kegiatan pengembangan apa pun tetapi hanya mengatur dan melakukan pengujian, yang lebih umum dalam model pengiriman TI berurutan tradisional - tim tidak dapat dimintai pertanggungjawaban atas kualitas produk TI karena mereka memberikan informasi tentang kualitas, tetapi mereka tidak memiliki pengaruh apa pun terhadap kualitas itu sendiri. Satu-satunya kriteria yang dapat mereka setujui adalah kriteria penyelesaian, yang menentukan kapan tim telah melakukan pengujian dengan baik. Ketika mereka telah melakukan semua yang mereka janjikan dan memberikan informasi yang diminta, maka pekerjaan mereka telah selesai, terlepas dari apakah produk TI tersebut diterima atau tidak.
Definisi - kriteria penyelesaian
Kriteria penyelesaian adalah kriteria yang harus dipenuhi oleh tim untuk menyelesaikan sebuah (kelompok) aktivitas.
Kriteria penerimaan didefinisikan dalam hal karakteristik kualitas dan risiko kualitas. Kriteria penyelesaian didefinisikan dalam hal informasi yang disampaikan dan upaya yang dikeluarkan.
Disadur dari: tmap.ne