V&V tidak berarti balas dendam

Selama enam tahun terakhir, saya telah mengembangkan dan menerima pengujian berbagai aplikasi dalam hal kompleksitas dan ukuran untuk melakukan dan memelihara uji klinis. Data besar, sejumlah besar visualisasi dan tampilan, pergudangan data, ETL dan sejenisnya. Produk ini digunakan oleh dokter, manajemen dan orang-orang yang terlibat dalam kontrol dan pemantauan penelitian.

Untuk aplikasi yang memiliki atau mungkin 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 untuk memproduksi lebih dari tiga puluh aplikasi. Dalam artikel ini, saya akan secara singkat berbicara tentang pengujian penerimaan dan pengembangan alat dalam satu kelompok kecil.

Catatan: Saya tidak berpura-pura menjadi kebenaran tertinggi dan saya mengerti bahwa sebagian besar dari apa yang saya tulis adalah Bukti Monolog dari Kapten. Tetapi saya berharap bahwa yang dijelaskan akan bermanfaat baik bagi entry level dan tim yang menghadapi ini dalam pekerjaan sehari-hari mereka, atau setidaknya menyenangkan mereka yang memiliki proses yang lebih sederhana.

FDA

Studi klinis di seluruh dunia adalah langkah integral dalam pengembangan obat, yang mendahului pendaftaran dan penggunaan medis yang luas. Dalam uji klinis, obat baru dipelajari untuk mendapatkan data tentang efektivitas dan keamanannya. Wikipedia

Dengan kata lain, agar pil “dari kepala” sampai ke meja apotek di suatu tempat di Pantai Brighton, ia melewati 3 fase percobaan manusia, di mana ditentukan berapa banyak zat aktif yang harus terkandung dalam tablet, seberapa aman itu dan apakah itu sembuh sama sekali sakit kepala.

Apa FDA bagi kita dan bagaimana hal itu mempengaruhi proses pengembangan dan siklus rilis?

Administrasi Makanan dan Obat-obatan (FDA, USFDA, surat. "Administrasi Makanan dan Obat-obatan") adalah agen Departemen Kesehatan dan Layanan Kemanusiaan AS, salah satu departemen eksekutif federal. Departemen ini terlibat dalam pengendalian kualitas produk makanan, farmasi, kosmetik, produk tembakau dan beberapa kategori barang lainnya, dan juga memantau kepatuhan terhadap undang-undang dan standar di bidang ini. Wikipedia

FDA praktis tidak memedulikan proses pengembangan itu sendiri, kami bekerja pada SCRUM biasa (atau lebih tepatnya, tidak cukup SCRUM - mereka mengatakan sekarang modis untuk memanggil "SCRUM yang dimodifikasi") dengan siklus rilis non-sprint. Kami tidak pergi ke prod pada akhir sprint (dan bahkan pada akhir tiga sprint, dan bahkan sepuluh jika timeline melibatkan 15 sprint), yaitu, dari sudut pandang pengiriman ke pengguna akhir, kami memiliki sesuatu seperti air terjun.

Pengujian dalam kasus kami dibagi menjadi dua bagian independen, dengan jadwal berbeda, perkiraan berbeda dan proses 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 dan pemeliharaan penerimaan aktual (bila diperlukan). Proses ini dibangun sesuai dengan metodologi V&V: persyaratan pengguna dan fungsional pada input, pengujian dan paket dokumentasi pendukung pada output.

Siklus rilis tergantung pada volume pekerjaan, rilis umumnya tidak melalui iterasi. Setelah rilis, aplikasi dapat tetap tidak berubah untuk waktu yang lama, yaitu jeda antar rilis - dari beberapa bulan hingga satu tahun atau lebih.

V&V

Hewan jenis apa ini, V&V, dan bagaimana hal ini tercermin dalam 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

Terjemahan gratis:

“Dalam manajemen proyek, pengujian dan pengembangan perangkat lunak, verifikasi dan validasi (V&V) adalah proses verifikasi bahwa perangkat lunak yang dikembangkan memenuhi spesifikasi dan memenuhi fungsi yang dimaksudkan. Ini juga dapat dikaitkan dengan kontrol kualitas secara umum. Biasanya, teknisi pengujian bertanggung jawab atas verifikasi dan validasi siklus hidup pengembangan perangkat lunak. Dengan kata sederhana, verifikasi perangkat lunak dapat digambarkan sebagai: "Misalkan kita harus mengembangkan sistem X. Apakah kita telah mencapai tujuan tanpa bug dan asumsi?" Di sisi lain, validasi perangkat lunak adalah "Sistem yang dikembangkan X benar-benar sesuatu Apa yang ingin kita dapatkan? Apakah sistem X memenuhi persyaratan tingkat tinggi? "

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 (SIT), yang kedua menjadi pemeliharaan (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 banyak yang disimpan). Dalam hal persyaratan tidak tercakup dan tidak akan ditanggung, kami jelaskan alasannya.

Kapan persyaratan cakupan tidak diperlukan?

Sebagai contoh, CFR Bagian 11 ( aturan yang dibuat oleh FDA tentang catatan elektronik dan tanda tangan elektronik ) berisi sejumlah besar persyaratan yang sudah dicakup oleh Microsoft dan jika kita menggunakan Windows AD untuk otentikasi, kita tidak perlu menutupinya lagi.

Pada akhirnya, esensi dari pengujian penerimaan datang ke pengujian produk untuk kepatuhan dengan persyaratan dan persyaratan untuk kepatuhan 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 Bisnis, Pemilik Produk Bisnis, Scrum Master , Manajer Proyek, Analis Bisnis, Pimpinan Teknis, Pimpinan Uji SIT, Pimpinan Tes UAT, QC Global, Dukungan, Deployment Engineer, dan lainnya.

Peran khusus kami adalah Global QC . Ini adalah orang di sisi pelanggan yang bertanggung jawab untuk kepatuhan dengan 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

Sebagai bagian dari rilis produk, paket dokumentasi dibuat dengan sejumlah besar tingkat bersarang, termasuk dokumentasi yang berkaitan dengan bagaimana produk diuji, mengapa diuji dengan cara ini dan bukan sebaliknya, dan apa yang secara khusus diuji dan apa yang ditinggalkan:

Rencana Validasi dan Daftar Tim - PM bertanggung jawab untuk menulis dan menyetujui dokumen. Dokumen biasanya mencakup deskripsi sistem, daftar artefak yang akan dibuat selama pengembangan dan pengujian, strategi validasi, dan daftar peran dengan tanggung jawab.

Strategi Pengujian - dokumen yang tidak berlaku untuk aplikasi tertentu, tetapi dibuat untuk cabang produk terpisah atau untuk cabang pengujian terpisah. Misalnya, bagaimana dan mengapa kita menentukan apa yang akan kita otomatisasi dan apa yang tidak. teknologi apa; bagaimana kami akan mengatur pengujian manual (periksa daftar atau skrip pengujian, atau keduanya bersamaan, atau sesuatu yang sama sekali berbeda); bagaimana kita memutuskan apakah kita akan mendorong beban atau tidak; dan seterusnya dan seterusnya.

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 fitur lainnya.

Matriks Ketertelusuran - melacak matriks dari persyaratan hingga pengujian. Menelusuri sebagai bukti peliputan adalah bagian penting dari proses. Dengan menggunakan pengidentifikasi dari persyaratan apa pun, Anda dapat menemukan langkah spesifik di mana pemenuhan persyaratan ini dikonfirmasi dan memberikan bukti kepada peninjau (tangkapan layar, file, dll.) Untuk versi aplikasi tertentu (atau untuk setiap versi di mana persyaratan ini dicakup secara resmi). 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. 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 mengajukan database primitif tiga tabel.

PDS - Spesifikasi Desain Produk, dokumen yang dikembangkan oleh penasihat teknis atau arsitek proyek, pada dasarnya merupakan kombinasi dari arsitektur aplikasi tingkat tinggi dan tingkat rendah (HLA dan LLA).

FRS & URS atau BRS adalah persyaratan fungsional dan pengguna, biasanya dalam bentuk dua dokumen terpisah, tetapi kadang-kadang digabungkan dalam Spesifikasi Persyaratan Bisnis.

Log Cacat - log cacat yang terdeteksi selama pengujian (cacat dan persyaratan aplikasi).

Minor Issues Log - log kesalahan kecil dalam pengujian (kesalahan ketik, persyaratan yang hilang / tidak perlu, dan sebagainya - kesalahan apa pun yang secara mendasar tidak mengubah arti pengujian).

Laporan Ringkasan Tes - laporan hasil pengujian. TSR adalah dokumen penutup untuk rencana pengujian dan berisi:

• Informasi tentang majelis yang diuji (termasuk nomor build dan tanggal penempatan), jumlah siklus tes dan hasil tes.
• Deskripsi pelanggaran yang dilakukan terkait rencana pengujian dan prosedur pengujian (SOP) yang disetujui untuk dieksekusi oleh perusahaan.
• Daftar cacat terbuka yang menjelaskan alasan pemindahan ke rilis berikutnya.
• Tautan ke log cacat atau log itu sendiri.
• Tautan ke log kesalahan pengujian atau log itu sendiri.
• Rekomendasi untuk keputusan untuk menginstal dalam produksi.

Rencana Penerapan - dokumen yang bertanggung jawab atas dukungan dan integrasi, dikompilasi selama instalasi di lingkungan SIT dan selanjutnya digunakan untuk menyebarkan versi produksi.

Laporan Ringkasan Validasi - dokumen penutup untuk rencana validasi.

Persetujuan dokumen

Segala proses persetujuan dokumentasi secara kondisional dibagi menjadi 3 tahap:

• Persiapan dokumen.
• Ulasan
• Pernyataan

Pertimbangkan contoh Test Suite.

Untuk menulis skrip pengujian dan menggabungkannya ke dalam suite pengujian, kami menggunakan templat standar yang disetujui di sisi pelanggan.

Komponen-komponen dari test kit:

• Nama proyek dan aplikasi.
• Versi rilis.
• Nama dan pengidentifikasi unik set.
• Deskripsi (apa yang kami uji, jenis pengujian apa yang kami gunakan).
• Tes.
• Daftar pemberi persetujuan.

Pada gilirannya, setiap tes meliputi:

• Nama dan pengidentifikasi unik dalam set.
• Deskripsi
• Prasyarat.
• Kondisi akhir.
• Tracing (nomor persyaratan yang tercakup dalam tes).
• Fitur eksekusi (misalnya, instruksi untuk menutupi data sensitif).
• Langkah-langkah (tindakan yang diperlukan, hasil yang diharapkan dan aktual).
• Hasil tes.
• Sudah selesai
• Revuever.

Siklus hidup normal suatu tes menyerupai air terjun umpan balik dan terlihat seperti ini:

1. Ejaan
   Analisis persyaratan. Definisi dan penerapan teknik desain uji untuk cakupan fungsionalitas yang paling memadai. Langkah-langkah menulis.
2. Tes perikop / petikan tentang gadis
   Pada tahap ini, dinilai seberapa banyak aplikasi memenuhi persyaratan, dan sebagian besar kemungkinan bug, termasuk bug persyaratan, disingkirkan.
3. Ulasan Manajer Proyek (Pimpinan Tim SIT)
   Ulasan gaya dan logis.
4. Tes jalur / lintasan pada lingkungan SIT
   Pada tahap ini, kesalahan yang terkait dengan instalasi, lingkungan dan konfigurasi lingkungan tertangkap (secara default diyakini bahwa lingkungan SIT persis atau hampir sepenuhnya mengulangi PROD). Berhasil menyelesaikan tahap ini berarti bahwa versi yang dikelilingi stabil dan rilis dapat dianggap sebagai kandidat.
5. Ulasan Pelanggan (Global QC)
   Global QC memverifikasi bahwa persyaratan terpenuhi dan bahwa tes SOP tertulis telah dilakukan dengan perusahaan.
6. Persetujuan (Global QC, PO Teknis, PO Bisnis).
7. Eksekusi pengujian formal pada lingkungan SIT (versi kandidat rilis)
   Setelah persetujuan pengujian untuk lintasan (hlm. 6) dan keberhasilan penyelesaian tes lulus pada lingkungan SIT (hlm. 4), pengujian secara formal dilakukan pada lingkungan SIT dengan penetapan formal hasil. Jika bug yang ditemukan dalam test pass tidak diformalkan dan hanya dimasukkan di Jira sama dengan apa yang terjadi selama proses pengembangan, maka form cacat terpisah dibuat untuk setiap bug yang ditemukan di pass formal, yang termasuk dalam paket dokumentasi output untuk produk.
8. Tinjau hasil dari bagian yang bertanggung jawab untuk proyek (Ketua Tim SIT).
   Sama halnya dengan poin 3, gaya pengisian diperiksa dan hasilnya dianalisis.
9. Ulasan Pelanggan (Global QC)
   Global QC memeriksa kebenaran dan kelengkapan mengisi hasil, kemungkinan kesalahan, keberadaan konfirmasi (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 dengan menggunakan metodologi double blind *, ini lebih sedikit dari masalah kita. 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 - metode 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 yang kami gunakan untuk menginjak proyek kami:

A Pretense of Fun: A Globe

Di salah satu aplikasi untuk menciptakan efek wow dan tidak hanya kami benar-benar diperlukan untuk membuat bola dunia interaktif yang dapat Anda putar dengan mouse, beralih siang / malam dan sebagainya. Di dunia ada tanda pada alamat, yang diwarnai tergantung pada nilai dan rentang di mana nilai-nilai ini jatuh (seperti pengkodean 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.

Sejarah: data diunggah ke repositori 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 menautkan 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 menganonimkan, Anda harus memastikan bahwa basis data berisi segala yang ada di dalamnya, atau berpikir terlebih dahulu tentang penerapan mekanisme anonimisasi dan kebingungan.

Alur kerja elektronik vs kertas dalam praktiknya

Orang yang bekerja dengan HP ALM tidak menertawakan sirkus.

Manajemen dokumen elektronik agak menyederhanakan komunikasi dan proses peninjauan dan perjalanan dari sudut pandang pekerjaan manual, tetapi secara praktis tidak memberikan waktu yang habis dalam konteks waktu persiapan untuk pengujian dan pelaksanaannya. Di bawah ini tercantum pro dan kontra dari alur kerja elektronik versus kertas berdasarkan contoh HP ALM.

Pro:

• Mudah untuk memperbarui versi terbaru.
• Lebih sedikit buatan tangan.
• Semua anggota tim setiap saat memiliki akses ke kondisi saat ini dari tes tertentu.
• Ubah riwayat.
• Bagian sejarah.
• Anda dapat melacak waktu yang dibutuhkan untuk menyelesaikan tes.
• Lebih mudah untuk merencanakan waktu untuk operan lebih lanjut.
• Kita harus mencoba menggunakan versi tes yang salah untuk bagian ini.
• Tanda tangan elektronik.

Kontra (khusus untuk HP ALM):

• Banyak waktu dihabiskan untuk memformat tes.
• Masalah berkala dengan alat itu sendiri.
• Kurangnya pemeriksa ejaan normal.
• Antarmuka tidak nyaman.
• Waktu yang dihabiskan untuk menulis dan meninjau tes praktis sama dengan tes di Word.
• Biaya.

Studi kasus terkait dengan dokumen dan tanda tangan manual: "The Nightmare Before Release"

Untuk satu malam, saya menulis 450 kali, "warna titik-titik pada grafik sesuai dengan yang dinyatakan dalam persyaratan, nama keluarga adalah nama tanggal" dan meletakkan tanda tangan - hanya karena kami mencetak pada printer b / w, dan warna titik-titik pada grafik penting.



Moral: pilihan cara harus konsisten dengan tujuan.

Cerita nomor dua: "Gravitasi baik, keparahan dapat diandalkan"

Alur kerja kertas adalah kertas (siapa yang akan ragu). Untuk penerimaan satu jauh dari aplikasi terbesar, itu bisa berubah di wilayah lima kilogram.



Kesimpulan yang menunjukkan dirinya dari cerita di atas (dan banyak yang tak terhitung): meskipun ada kelemahan dan tidak terdaftar dalam manajemen dokumen elektronik - jika Anda dapat memilih, maka pasti memilih 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 pada sisi dasar) 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 seringkali penggunaannya tidak membenarkan dirinya sendiri - karena digunakan dengan cara yang salah, tidak ada, dan bukan untuk itu, tetapi ini adalah topik untuk laporan terpisah, yang ada sedikit kurang dari “otomatisasi harus dimiliki !!!” ", Tapi masih dalam kuantitas.

Yang kedua adalah menjelaskan kepada pelanggan bahwa ia akan memperoleh waktu dan itu akan cukup andal dan dapat diterima dari sudut pandang formal. Industri ini dikendalikan karena suatu alasan.

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 mengingat proses persetujuan dokumentasi yang dijelaskan di atas menggunakan Test Suite manual sebagai contoh, menjadi jelas bahwa proses otomasi tidak boleh kurang terkontrol.

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 Anda dapat bentuk satu set untuk otomatisasi.

Daftar pertanyaan dalam kasus kami:

1. Apakah mungkin untuk mengotomatisasi pengujian dalam kasus khusus ini?
2. Apakah pengujian komponen * agar otomatis menjadi stabil?
3. Seberapa sering kita harus menjalankan tes yang ditulis untuk suatu komponen?
4. Apakah fungsi ini penting untuk bisnis? **
5. Seberapa sulitkah untuk mengotomatisasi pengujian?

* Stable = komponen tidak berubah untuk beberapa waktu dan perubahan komponen tidak direncanakan untuk rilis mendatang.
** Ini ditempelkan tergantung pada nilai bidang yang ditambahkan ke persyaratan oleh analis bisnis.


Secara umum, proses pengambilan keputusan adalah sebagai berikut:

1. Input menerima persyaratan FRS.
   Matriks Desain dikompilasi, di mana setiap baris merupakan persyaratan dari FRS. Sebagai kolom:
   
   • Deskripsi Persyaratan
   • Pertanyaan 1-5
   • Keputusan tim
   • Perkiraan Waktu Penulisan
   • Persetujuan
   • Komentar
2. Tim memberikan jawaban atas pertanyaan dan berdasarkan data yang diterima menentukan apakah perlu mengotomatisasi pengujian persyaratan / kelompok persyaratan tertentu secara penuh atau sebagian.
3. Pelanggan meninjau solusi yang diusulkan dan menyetujui versi final.
4. Setelah disetujui oleh Matriks Desain, autotest ditulis. Skrip untuk autotests dijelaskan pada Gherkin dan menjalani ulasan yang serupa dengan tes manual (Global QC, Pemilik Teknis, Pemilik Bisnis). Definisi langkah, objek halaman, dan sebagainya, ditinjau pada kumpulan permintaan, termasuk oleh spesialis teknis di pihak pelanggan. Hasil autotest dan laporan yang dihasilkan diantisipasi di sisi Global QC.

Selama dua tahun sejak pendahuluan, kami beralih ke otomatisasi parsial dari 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 produk lain 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 tampaknya bagi banyak orang. Ini memungkinkan, mengambil keuntungan penuh dari pendekatan berbasis skenario untuk pengujian, 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 kebiasaan?