Selama enam tahun terakhir, saya telah bekerja pada pengembangan dan pengujian penerimaan aplikasi untuk melakukan dan mendukung uji klinis. Aplikasi dari berbagai ukuran dan kompleksitas, data besar, sejumlah besar visualisasi dan tampilan, pergudangan data, ETL, dll. Produk ini digunakan oleh dokter, manajemen uji klinis dan orang-orang yang terlibat dalam kontrol dan pemantauan penelitian.
Untuk aplikasi yang memiliki atau dapat memiliki dampak langsung pada kehidupan dan kesehatan pasien, diperlukan proses pengujian penerimaan formal. Hasil tes penerimaan bersama dengan sisa paket dokumentasi diajukan untuk audit ke FDA (Food and Drug Administration, USA). FDA mengizinkan penggunaan aplikasi sebagai alat untuk memantau dan melakukan uji klinis. Secara total, tim saya telah mengembangkan, menguji dan mengirim ke produksi lebih dari tiga puluh aplikasi. Pada artikel ini, saya akan secara singkat berbicara tentang pengujian penerimaan dan peningkatan alat yang digunakan untuk itu.
Catatan: Saya tidak berpura-pura menjadi kebenaran tertinggi dan sepenuhnya memahami bahwa sebagian besar dari apa yang saya tulis adalah monolog Kapten Obvious. Tetapi saya berharap bahwa yang dijelaskan dapat bermanfaat baik bagi entry level dan tim yang menghadapi ini dalam pekerjaan sehari-hari, atau setidaknya itu bisa membuat senang mereka yang memiliki proses yang lebih sederhana.
FDA
Uji klinis adalah percobaan atau pengamatan yang dilakukan dalam penelitian klinis. Studi penelitian prospektif biomedis atau perilaku pada peserta manusia dirancang untuk menjawab pertanyaan spesifik tentang intervensi biomedis atau perilaku, termasuk perawatan baru (seperti vaksin baru, obat-obatan, pilihan makanan, suplemen makanan, dan peralatan medis) dan intervensi yang dikenal yang memerlukan studi lebih lanjut dan perbandingan. Uji klinis menghasilkan data tentang keamanan dan kemanjuran. Wikipedia
Dengan kata lain, agar pil sakit kepala sampai ke konter apotek di Brighton Beach, ia melewati 3 fase uji coba manusia, di mana ditentukan berapa banyak zat aktif yang harus terkandung dalam tablet, seberapa aman dan apakah itu menyembuhkan sakit kepala sama sekali.
Apa FDA dalam hal apa yang kita lakukan dan bagaimana pengaruhnya terhadap proses pengembangan dan siklus rilis?
Food and Drug Administration (FDA atau USFDA) adalah agen federal dari Departemen Kesehatan dan Layanan Kemanusiaan Amerika Serikat, salah satu departemen eksekutif federal Amerika Serikat. FDA bertanggung jawab untuk melindungi dan mempromosikan kesehatan masyarakat melalui kontrol dan pengawasan keamanan makanan, produk tembakau, suplemen makanan, resep dan obat-obatan farmasi (obat) yang dijual bebas, vaksin, biofarmasi, transfusi darah, peralatan medis, radiasi elektromagnetik perangkat pemancar (ERED), kosmetik, makanan hewani & pakan dan produk-produk kesehatan hewan. Wikipedia
Faktanya, FDA secara praktis tidak berkaitan dengan proses pengembangan itu sendiri, kami bekerja sesuai dengan SCRUM biasa (jujur, itu tidak cukup SCRUM - mereka mengatakan sekarang modis untuk memanggil proses seperti "SCRUM yang dimodifikasi") dengan non-SCRUM. siklus rilis sprint. Kami tidak mengirim ke produksi pada setiap sprint akhir (dan bahkan pada akhir sprint tiga, dan bahkan sepuluh sprint jika timeline melibatkan 15 sprint), yaitu, dari sudut pandang pengiriman ke pengguna akhir , kami memiliki metodologi seperti air terjun.
Dalam kasus kami, pengujian dibagi menjadi dua bagian independen dengan jadwal yang berbeda, perkiraan berbeda, dan proses yang berbeda. Bagian pertama adalah pengujian in-dev yang biasa, di mana tester merupakan bagian integral dari tim pengembangan dan menyelesaikan sprint bersamaan dengan pengembangan. Bagian kedua adalah pengujian penerimaan aktual dan pemeliharaan kegiatan terkait (bila diperlukan). Proses ini dibangun sesuai dengan metodologi V&V: persyaratan pengguna dan fungsional pada input, skrip uji dan paket dokumentasi pendukung pada output.
Siklus rilis tergantung pada ruang lingkup proyek, rilis umumnya tidak berulang. Setelah rilis, aplikasi dapat tetap tidak berubah untuk waktu yang lama, jeda antara rilis mungkin bervariasi dari beberapa bulan hingga satu tahun atau lebih.
V&V
Apa itu V&V, dan bagaimana hal ini memengaruhi proses penerimaan.
“Dalam manajemen proyek perangkat lunak, pengujian perangkat lunak, dan rekayasa perangkat lunak, verifikasi dan validasi (V&V) adalah proses memeriksa apakah sistem perangkat lunak memenuhi spesifikasi dan memenuhi tujuan yang dimaksudkan. Ini juga dapat disebut kontrol kualitas perangkat lunak. Biasanya merupakan tanggung jawab penguji perangkat lunak sebagai bagian dari siklus pengembangan perangkat lunak. Secara sederhana, verifikasi perangkat lunak adalah: "Dengan asumsi kita harus membangun X, apakah perangkat lunak kita mencapai tujuannya tanpa bug atau kesenjangan?" Di sisi lain, validasi perangkat lunak adalah: "Apakah X yang seharusnya kita bangun? Apakah X memenuhi persyaratan tingkat tinggi? » Wikipedia
Dengan kata lain:
Verifikasi: Apakah kita melakukan produk dengan benar?
Validasi: Apakah kita membuat produk yang tepat?
Ini berarti bahwa kita harus menguji spesifikasi fungsional dan pengguna dengan kelengkapan yang diperlukan dan memadai. Bagi kami, V pertama berubah menjadi pengujian penerimaan teknis (SIT), yang kedua menjadi dukungan UAT, di mana:
- SIT - Pengujian Integrasi Sistem
- UAT - Pengujian Penerimaan Pengguna
Visualisasi cakupan persyaratan dilakukan dalam Traceability Matrix (tabel reguler di Excel atau Word, saya akan membahasnya nanti), yang memungkinkan penelusuran dari persyaratan hingga pengujian dan sebaliknya. Dalam hal menggunakan manajemen dokumen elektronik, matriks dibangun secara otomatis, tes terkait dengan persyaratan yang disimpan bersama dengan tes (bersama-sama = HP ALM, tentu saja tidak tercampur). Jika persyaratan tidak tercakup dan tidak akan dicakup, kami membenarkan mengapa kami tidak menutupinya.
Kapan cakupan persyaratan tidak diperlukan?
Misalnya, CFR Bagian 11 (
Peraturan FDA untuk Catatan Elektronik dan Tanda Tangan Elektronik ) berisi banyak persyaratan yang telah dicakup dalam Microsoft, jadi jika kita menggunakan Windows AD untuk otentikasi, kita tidak perlu membahas persyaratan itu lagi.
Pada akhirnya, esensi dari pengujian penerimaan datang ke pengujian produk untuk kepatuhan dengan persyaratan dan persyaratan untuk kepatuhan dengan produk.
Peran
Sejumlah besar peran ikut serta dalam proses ini, yang dalam satu bentuk atau lainnya akrab bagi semua orang yang terlibat dalam pengembangan perangkat lunak: Pengembang (Junior, Menengah, Senior, Pimpinan), Unit Tester, SIT Tester, Pemilik Produk Teknis, Pemilik Produk Teknis, Produk Bisnis Pemilik, Master Scrum, Manajer Proyek, Analis Bisnis, Pimpinan Teknis, Pimpinan Tes SIT, Pimpinan Tes UAT, QC Global, Dukungan, Deployment Engineer, dan lainnya.
Peran khusus untuk kami -
Global QC . Ini adalah orang di sisi pelanggan yang bertanggung jawab untuk mengamati dan memenuhi persyaratan untuk proses - Siklus Hidup Perangkat Lunak dan segala macam Prosedur Operasional Standar (SOP) di sisi pelanggan - selama pengembangan dan penerimaan, dan selanjutnya menyediakan paket dokumen untuk audit eksternal.
Dokumentasi Penerimaan
Dalam lingkup rilis produk, kami membuat paket dokumentasi yang mencakup sejumlah besar tingkat bersarang, termasuk dokumentasi yang berkaitan dengan bagaimana produk diuji, mengapa diuji dengan cara ini dan bukan sebaliknya, apa yang secara spesifik berada dalam lingkup pengujian dan apa yang tidak:
Rencana Validasi dan Daftar Tim - PM bertanggung jawab atas pembuatan dan persetujuan dokumen. Dokumen biasanya mencakup deskripsi sistem, daftar artefak pengembangan dan pengujian, strategi validasi, daftar peran dan tanggung jawab.
Strategi Uji - dokumen yang bukan milik aplikasi spesifik tetapi ada untuk cabang produk atau cabang pengujian. Misalnya, bagaimana kita menentukan bagian pengujian mana yang akan otomatis, apa yang kita rencanakan untuk digunakan untuk otomasi, bagaimana kita berencana untuk melakukan pengujian manual, apakah kita berencana untuk menggunakan daftar periksa, skrip pengujian, keduanya atau apa pun lain; bagaimana kami berencana untuk memutuskan apakah akan melakukan pengujian kinerja / beban / volume atau tidak; dan hal-hal seperti ini.
Rencana Tes - umum untuk tim UAT dan SIT, termasuk uraian singkat tentang objek pengujian, kemungkinan pembatasan, persyaratan lingkungan, waktu, ruang uji, dan sebagainya.
Test Suite - satu set tes atau daftar periksa yang dibentuk oleh area fungsional, jenis pengujian atau karakteristik lainnya.
Matriks Lacak - matriks dengan jejak dari persyaratan hingga tes. Menelusuri persyaratan sebagai bukti cakupan merupakan bagian penting dari proses. Dengan menggunakan pengidentifikasi persyaratan apa pun, Anda dapat menemukan langkah spesifik di mana persyaratan ini diuji dan memberikan bukti kepada peninjau (tangkapan layar, file, dll.) Untuk versi aplikasi tertentu (atau untuk setiap versi di mana persyaratan ini dilakukan tertutup secara formal). Oleh karena itu, tautkan, tautkan, dan sekali lagi tautkan pengujian ke persyaratan (tugas), atas dasar di mana Anda mendapatkan hasil yang diharapkan, bahkan jika ini tidak diminta dari Anda, karena itu akan menyederhanakan hidup Anda di masa depan. Jika tidak mungkin karena penggunaan alat non-integrasi yang berbeda, Anda selalu dapat meninggalkan komentar dalam tugas / tes, atau membuat matriks (Excel disebutkan di atas), atau membuat database primitif dari tiga tabel.
PDS - Spesifikasi Desain Produk, Tek Teknologi, atau Arsitek Sistem bertanggung jawab atas pembuatan dokumen. Bahkan, itu adalah semacam kombinasi dokumen arsitektur tingkat tinggi dan rendah (HLA dan LLA).
FRS &
URS atau
BRS - persyaratan fungsional dan pengguna. Biasanya, ada dua dokumen terpisah tetapi kadang-kadang ada Spesifikasi Persyaratan Bisnis yang menggabungkan kedua spesifikasi.
Log Cacat - log bug yang diidentifikasi dalam aplikasi dan / atau persyaratan selama SIT formal.
Minor Issues Log - log perubahan kecil pada skrip uji (kesalahan ketik, persyaratan kiri atau redundan, kesalahan).
Laporan Ringkasan Tes - laporan tentang hasil tahap pengujian, yang meliputi yang berikut:
- Informasi tentang bangunan yang digunakan untuk pengujian (termasuk angka bangunan dan tanggal penempatan dengan informasi tentang alasan penyebaran), jumlah siklus pengujian dan hasil skrip pengujian (lulus / gagal).
- Deskripsi perbedaan SOP.
- Daftar cacat terbuka dengan justifikasi.
- Tautan ke log cacat atau log cacat itu sendiri.
- Tautan ke masalah kecil masuk atau masuk sendiri.
- Rekomendasi tentang penyebaran ke lingkungan produksi.
Deployment Plan - dokumen yang digunakan untuk penyebaran ke produksi, memasukkan deskripsi roll-back.
Laporan Ringkasan Validasi - dokumen penutup untuk Rencana Validasi.
Persetujuan Dokumentasi
Setiap proses persetujuan dokumentasi dapat dibagi menjadi 3 tahap:
- Persiapan dokumen.
- Ulasan
- Persetujuan
Mari kita lihat contoh Test Suite.
Untuk menulis skrip pengujian dan menggabungkannya ke dalam suite pengujian, kami menggunakan templat standar yang disetujui di sisi pelanggan.
Paragraf uji suite:
- Nama proyek dan aplikasi.
- Versi rilis.
- Nama dan pengidentifikasi unik suite.
- Deskripsi (apa yang kami uji dan jenis pengujian apa yang kami gunakan).
- Skrip uji.
- Daftar pemberi persetujuan.
Pada gilirannya, setiap tes terdiri dari:
- Nama dan pengidentifikasi unik dari skrip uji.
- Deskripsi
- Prasyarat.
- Kondisi akhir.
- Referensi Ketertelusuran.
- Instruksi untuk dieksekusi (misalnya instruksi tentang cara menutupi data sensitif).
- Langkah-langkah (prosedur, hasil yang diharapkan dan diamati).
- Hasil skrip pengujian.
- Penguji.
- Peninjau
Siklus hidup normal dari tes menyerupai air terjun dan terlihat seperti ini:
- Menulis
Analisis persyaratan. Definisi dan penerapan teknik desain uji untuk cakupan fungsionalitas yang paling memadai. Langkah-langkah menulis. - Dry run pada lingkungan dev
Pada tahap ini, kami mencoba menemukan bagaimana aplikasi memenuhi persyaratan, dan menemukan kesalahan yang paling mungkin, termasuk kesalahan persyaratan. - Ulasan orang yang bertanggung jawab (Ketua Tim SIT)
Ulasan gaya dan logis. - Kering berjalan di lingkungan duduk
Pada tahap ini, kesalahan yang terkait dengan instalasi, lingkungan, dan konfigurasi lingkungan diketahui (secara default, kami menganggap bahwa lingkungan SIT persis atau hampir sepenuhnya mengulangi PROD). Berhasil menyelesaikan tahap ini berarti bahwa versi yang digunakan adalah stabil dan rilis dapat dianggap sebagai kandidat. - Ulasan pelanggan (Global QC)
Global QC memverifikasi bahwa persyaratan terpenuhi dan bahwa tes tertulis sesuai dengan SOP perusahaan. - Persetujuan (Global QC, PO Teknis, PO Bisnis).
- Eksekusi skrip uji formal pada lingkungan SIT (rilis versi kandidat)
Setelah persetujuan pengujian untuk pelaksanaan (hlm. 6) dan keberhasilan penyelesaian lintasan kering pada lingkungan SIT (hlm. 4), pengujian secara formal dilaksanakan pada lingkungan SIT dengan fiksasi formal hasil. Jika bug yang ditemukan di lintasan lari kering tidak formal dan hanya dimasukkan di Jira sama dengan apa yang terjadi selama proses pengembangan, maka bentuk cacat terpisah dibuat untuk setiap bug yang ditemukan dalam eksekusi formal, yang termasuk dalam dokumentasi output paket untuk produk. - Ulasan eksekusi skrip pengujian (Pimpinan Tim SIT).
Sama dengan poin 3. - Ulasan pelanggan (Global QC)
Global QC memeriksa kebenaran dan kelengkapan pengisian hasil, kemungkinan kesalahan, keberadaan bukti (misalnya, tangkapan layar). Poin penting, karena Global QClah yang bertanggung jawab untuk menyediakan paket dokumen ke audit eksternal (oleh FDA atau pelanggan).
Bekerja dengan Data Pribadi
Mengingat bahwa penelitian dilakukan menggunakan metodologi double-blind *, ini adalah masalah yang lebih kecil. Tetapi data dokter, nama perusahaan, nomor protokol penelitian, dll., Harus diubah. Dari sudut pandang formal, jika kita tidak bisa menghilangkan data sensitif, kita harus menyembunyikannya pada tangkapan layar, tetapi ini adalah situasi yang cukup standar dan dapat dimengerti.
* double-blind - pasien secara acak dibagi menjadi dua kelompok, satu di antaranya menerima obat studi, dan yang kedua plasebo atau obat dengan efektivitas terbukti. Pada saat yang sama, baik dokter maupun pasien tidak tahu ke kelompok mana pasien ditugaskan. Ini menghilangkan bias dokter dan efek plasebo. Dalam konteks bekerja dengan data pribadi, ini berarti bahwa dalam kebanyakan kasus identitas pasien tidak dapat diidentifikasi berdasarkan data yang disimpan dalam database atau dapat diakses oleh pengguna.Tetapi kenyataan bahwa ini adalah yang paling sedikit dari masalah kita tidak berarti bahwa itu tidak dapat membawa masalah. Berikut adalah beberapa garu (bukan untuk menginjak dua kali) yang kami dapatkan di proyek kami:
Mungkin menyenangkan (bukan untuk kita pada saat itu): "The Globe"
Di salah satu aplikasi, untuk membuat efek wow dan tidak hanya, kami benar-benar perlu membuat bola dunia interaktif yang dapat Anda putar dengan mouse, berganti siang / malam, dan sebagainya. Di dunia, ada tanda pada alamat, yang diwarnai tergantung pada nilai dan rentang nilai-nilai ini jatuh (semacam kode warna). Setelah menganonimkan database pada lingkungan demo, dua jam sebelum demo, berkat skrip anonim, kami dibiarkan tanpa kode pos dengan segala konsekuensinya.
Moral: jangan menyentuh data dua jam sebelum demo.
Cerita nomor dua: "Tentang anonimisasi"
Latar Belakang: Data dikumpulkan dalam repositori dari sejumlah besar sumber, data milik domain yang berbeda, tetapi saling berhubungan oleh pengidentifikasi.
Cerita: data diunggah ke database dan dianonimkan sebelum digunakan untuk tujuan pengujian. Ternyata data itu tidak diunduh dari semua sumber yang diperlukan. Kemudian mereka memuat bagian yang hilang. Itu tidak mungkin untuk menghubungkan bagian kedua data (belum dianonimkan) dengan bagian pertama yang sudah dianonimkan. Akibatnya, awal pekerjaan di lingkungan SIT ditunda selama dua minggu, di mana tim penempatan dan dukungan mengoreksi data.
Moral: sebelum dianonimkan, Anda harus memastikan bahwa database berisi segala yang ada di dalamnya, dan pikirkan terlebih dahulu tentang penerapan mekanisme anonimisasi dan kebingungan.
Alur kerja elektronik vs kertas dalam praktiknya
Alur kerja elektronik agak menyederhanakan komunikasi dan proses peninjauan dan perjalanan dari sudut pandang pekerjaan manual, tetapi secara praktis tidak memberikan kemenangan dalam hal waktu untuk persiapan pengujian dan pelaksanaannya. Di bawah ini tercantum pro dan kontra dari alur kerja elektronik versus kertas berdasarkan contoh HP ALM.
Manfaat:
- Mudah didukung.
- Kurang kerja manual.
- Semua anggota tim setiap saat memiliki akses ke kondisi saat ini dari tes tertentu
- Sejarah perubahan.
- Sejarah eksekusi.
- Anda dapat melacak waktu yang dibutuhkan untuk menyelesaikan tes.
- Mudah merencanakan masa depan berjalan.
- Sulit untuk menggunakan versi naskah tes yang salah.
- Tanda tangan elektronik.
Kontra (khusus untuk HP ALM):
- Jumlah besar waktu untuk memformat skrip.
- Masalah berkala dengan alat itu sendiri.
- Bukan pemeriksa ejaan terbaik.
- Antarmuka tidak nyaman.
- Waktu yang dihabiskan untuk menulis dan meninjau tes praktis sama dengan tes di Word.
- Biaya.
Sebuah kisah nyata terkait dengan dokumen dan tanda tangan manual: "A Nightmare Before Release"
Suatu malam, saya menulis 450 kali: “warna titik-titik pada grafik sesuai dengan yang dinyatakan dalam persyaratan. Nama keluarga, nama, tanggal ”dan beri tanda tangan - hanya karena kami mencetak pada printer hitam / putih, dan warna titik-titik pada grafik penting.
Moral: pilihan cara harus konsisten dengan tujuan.
Cerita lain: "Berat itu baik, berat itu dapat diandalkan." ©
Alur kerja kertas adalah tentang kertas (siapa yang akan meragukannya). Fase pengujian penerimaan untuk satu jauh dari aplikasi terbesar mungkin sekitar lima kilogram kertas.
Kesimpulan yang menunjukkan dirinya dari cerita di atas (dan banyak yang tak terhitung): terlepas dari kekurangan alur kerja elektronik yang terdaftar dan tidak terdaftar - jika Anda dapat memilih, maka pasti pilih elektronik, bahkan jika HP ALM (bukan HP lagi).
Otomasi
Sejumlah besar visualisasi tidak memungkinkan aplikasi terotomatisasi secara stabil, oleh karena itu, sebagai bagian dari pendekatan awal, kami membatasi diri pada tes unit (termasuk tes pada sisi database) dan uji API, tanpa ada upaya untuk bergerak menuju E2E.
Bagaimana dan mengapa kita sampai pada otomatisasi parsial setidaknya?
Tugas pertama adalah menjelaskan kepada diri kita sendiri bahwa dalam beberapa kasus kita benar-benar akan mendapatkan waktu. Ya, itu bisa dimengerti: tidak semua orang percaya pada otomatisasi dan sering kali penggunaannya tidak membenarkan dirinya sendiri - karena digunakan dengan cara yang salah, tidak di sana, dan bukan untuk itu, tetapi ini adalah topik untuk diskusi terpisah, di mana ada sedikit kurang dari "otomatisasi harus !!!", tetapi masih banyak.
Hal kedua adalah untuk menjelaskan kepada pelanggan bahwa ia akan mendapatkan waktu dan itu akan cukup andal dan dapat diterima dari sudut pandang formal. Industri ini dikendalikan dan ada alasan untuk ini.
Ketiga, dan utama: untuk menentukan algoritma yang dengannya kita dapat secara sadar membuat keputusan tentang otomatisasi pengujian aplikasi tertentu atau bagian dari aplikasi, dan memperoleh persetujuan untuk otomasi. Ini penting karena jelas bahwa proses otomasi tidak boleh kurang terkontrol daripada proses yang dijelaskan untuk skrip tes manual.
Setelah kami menjelaskan dan membenarkan dua poin pertama untuk diri kami dan pelanggan, kami menulis strategi pengujian, meminta analis bisnis untuk menambahkan bidang tambahan ke persyaratan, dan membentuk serangkaian pertanyaan, tergantung pada jawaban yang kami dapat membentuk satu set untuk otomatisasi.
Daftar pertanyaan dalam kasus kami:
- Apakah mungkin untuk mengotomatisasi pengujian dalam kasus khusus ini?
- Apakah komponen * stabil?
- Seberapa sering kita perlu menjalankan skrip pengujian untuk komponen ini?
- Apakah ini fungsi bisnis-kritis? **
- Seberapa sulit untuk mengotomatisasi pengujian?
* Stable = komponen tidak berubah untuk beberapa waktu dan perubahan komponen tidak direncanakan untuk rilis berikutnya.
** Itu diisi tergantung pada nilai bidang yang ditambahkan ke persyaratan oleh analis bisnis.
Secara umum, proses pengambilan keputusan adalah sebagai berikut:
- Pada input, kami memiliki persyaratan dari FRS.
Kami membuat Desain Matriks, di mana setiap baris adalah persyaratan FRS, dan kolom adalah:
- Deskripsi persyaratan
- Pertanyaan 1-5
- Keputusan tim
- Perkiraan perkiraan
- Persetujuan
- Komentar
- Tim memberikan jawaban atas pertanyaan dan berdasarkan data yang diterima menentukan apakah perlu mengotomatisasi pengujian persyaratan / kelompok persyaratan tertentu secara penuh atau sebagian.
- Pelanggan meninjau solusi yang diusulkan dan menyetujui versi final.
- Setelah persetujuan Matriks Desain, autotests ditulis. Skrip untuk autotest ditulis dalam notasi Gherkin dan menjalani tinjauan yang serupa dengan tes manual (Global QC, Pemilik Teknis, Pemilik Bisnis). Definisi langkah, objek halaman, dan sebagainya, ditinjau berdasarkan permintaan tarikan, termasuk oleh spesialis teknis di pihak pelanggan. Hasil autotest dan laporan yang dihasilkan ditinjau dan disetujui pada sisi Global QC.
Dalam waktu dua tahun sejak saat implementasi, kami beralih ke otomatisasi parsial pengujian penerimaan dua aplikasi yang terkait dengan pengunduhan, konfigurasi dan tampilan data di gudang data, dan dalam waktu dekat kami berencana untuk terus menggunakan pendekatan gabungan pada yang lain produk yang dikembangkan untuk pelanggan, jika memungkinkan.
Kesimpulan
Sebagai kesimpulan, saya ingin mencatat bahwa pengujian penerimaan formal bukanlah sesuatu yang menakutkan atau tidak berguna, seperti yang terlihat oleh banyak orang di industri ini. Hal ini memungkinkan, mengambil keuntungan penuh dari pendekatan pengujian skenario, untuk memfasilitasi pengujian versi masa depan, mengkonfirmasi tingkat kualitas perangkat lunak yang diperlukan dan memadai, dan akhirnya meyakinkan pelanggan. Dan apa, jika bukan ketenangan pikiran pelanggan, yang penting dalam pengembangan outsourcing?