Jawapan ringkas: pengujian perisian dan jaminan kualiti bukan peringkat akhir sebelum penyerahan — ia menentukan berapa banyak sistem anda akan membebankan anda selepas pelancaran. Dua sistem dengan bajet yang sama berpecah pada satu titik: adakah ia dibina dengan liputan ujian yang menangkap kecacatan sebelum pelanggan anda menemuinya, atau pelanggan anda sendiri yang menjadi suite ujian? Dalam keadaan pertama, anda membayar untuk kualiti sekali sahaja semasa pembinaan. Dalam keadaan kedua, anda membayarnya setiap bulan dalam bentuk gangguan perkhidmatan, pembaikan kecemasan dan kepercayaan yang semakin terhakis.

QA bukan "seseorang mengklik di sana sini sebelum penghantaran"

Gambaran umum dalam kalangan pemilik perniagaan ialah kualiti bermaksud seorang individu membuka skrin dan menekan butang pada minggu terakhir projek. Itu hanyalah bahagian yang sangat kecil — dan paling kurang berkesan — daripadanya. Jaminan kualiti sebenar ialah satu sistem yang berjalan sejak hari pertama: keperluan yang ditulis dengan cukup tepat sehingga boleh diuji, kod yang dilindungi oleh ujian automatik yang dijalankan pada setiap perubahan, persekitaran staging yang mencerminkan persekitaran pengeluaran, dan laluan penggunaan yang tidak akan membenarkan sebarang perubahan sampai ke pengeluaran sebelum ia melepasi pintu-pintu kawalan tersebut.

Perbezaan praktikalnya mudah: dalam susunan pertama, kecacatan muncul beberapa minit selepas ia ditulis; dalam susunan kedua, pelanggan anda menemuinya sebulan kemudian, ketika anda sudah membina ciri-ciri lain di atas kesilapan yang sama.

Lapisan ujian yang penting kepada anda sebagai pembuat keputusan

Anda tidak dijangka mengetahui butiran teknikal, tetapi anda dijangka tahu apa yang anda bayar. Inilah lapisan-lapisan yang perlu dinyatakan dalam mana-mana cadangan teknikal yang serius:

  • Ujian unit: mengesahkan kepingan logik terkecil secara berasingan. Ia paling pantas dan paling murah, dan inilah yang menghalang perubahan kecil daripada merosakkan jumlah invois, diskaun atau pengiraan cukai.
  • Ujian integrasi: mengesahkan bahawa bahagian-bahagian sistem berkomunikasi dengan betul antara satu sama lain dan dengan sistem luaran — gerbang pembayaran, penghantaran, platform invois, perkhidmatan pemesejan. Kebanyakan kegagalan di dunia sebenar berlaku di sini, bukan di dalam kod itu sendiri.
  • Ujian hujung ke hujung: menyimulasikan perjalanan pengguna yang lengkap dari awal hingga akhir, daripada membuka halaman hingga mengesahkan pesanan dan menerima pemberitahuan.
  • Ujian prestasi dan beban: menjawab soalan yang tidak dijawab oleh mana-mana ujian lain — apa yang berlaku apabila seribu pengguna tiba dalam minit yang sama dan bukannya sepuluh? Inilah lapisan yang dilangkau oleh pasukan, dan kemudian sistem tumbang pada hari kempen terbesar anda.
  • Ujian keselamatan: mengimbas kelemahan biasa sebelum orang lain menemuinya. Rujukan praktikalnya ialah senarai OWASP Top 10 bagi risiko kritikal aplikasi web; melihatnya disebut dalam pelan ujian ialah petanda kematangan yang jelas.
  • Ujian penerimaan pengguna: anda dan pasukan anda menjalankan sistem berdasarkan senario perniagaan sebenar anda, bukan berdasarkan skrip ideal yang disediakan oleh pembangun. Peringkat ini ialah tanggungjawab anda, dan tiada pengesahan terima harus dibuat sebelumnya.

Mengapa kecacatan menjadi lebih mahal semakin lewat anda menemuinya

Sesiapa yang pernah mengendalikan projek perisian tahu peraturannya: kecacatan yang dikesan semasa menulis keperluan dibaiki dengan menyunting satu ayat. Kecacatan yang sama jika dikesan selepas pelancaran memerlukan diagnosis, pembaikan, ujian semula, penggunaan semula — biasanya ditambah dengan pemulihan data yang rosak sepanjang proses dan permohonan maaf kepada pelanggan yang terjejas. Masalahnya, jurang ini tidak pernah muncul dalam sebut harga, maka pembekal yang memotong pengujian daripada skop kelihatan lebih murah. Hakikatnya, mereka hanya menangguhkan invois, dan menambahkannya.

Ujian automatik berbanding manual: bila menggunakan setiap satu

Ujian manual amat diperlukan untuk menilai pengalaman pengguna, kes-kes luar biasa dan apa sahaja yang memerlukan pertimbangan manusia. Namun ia tidak boleh berfungsi sebagai jaring keselamatan kekal, kerana tiada sesiapa akan menyemak semula dua ratus skrin secara manual selepas setiap perubahan kecil. Ujian automatiklah yang menjadikan pembangunan berterusan mungkin: anda menulis ujian sekali, ia dijalankan beribu-ribu kali, dan dalam beberapa minit ia memberitahu anda sama ada perubahan hari ini merosakkan sesuatu yang dibina oleh pasukan anda setahun yang lalu. Peraturan praktikalnya: automasikan semua perkara berulang yang melibatkan wang atau data, dan serahkan kepada pertimbangan manusia semua perkara yang melibatkan rasa penggunaan produk.

Berhati-hati dengan data ujian anda

Satu isu terlepas daripada perhatian banyak pasukan tanpa diteliti: menyalin pangkalan data pengeluaran ke persekitaran staging supaya pembangun boleh menguji dengannya. Ini bermakna nama, nombor telefon dan alamat pelanggan anda kini berada dalam persekitaran yang mempunyai akses lebih luas dan perlindungan lebih lemah. Undang-undang Perlindungan Data Peribadi Arab Saudi, yang diselia oleh Pihak Berkuasa Data dan Kecerdasan Buatan Saudi (SDAIA), mengawal selia pemprosesan data peribadi tanpa mengira apa nama yang anda berikan kepada persekitaran yang menyimpannya. Penyelesaiannya mudah dan terkenal: data yang dijana secara sintetik, atau data sebenar dengan medan sensitif disamarkan sebelum disalin.

Apa yang perlu diminta daripada pembekal sebelum menandatangani

  • Pelan ujian bertulis di dalam skop kerja, bukan janji lisan bahawa "sistem akan diuji".
  • Ujian yang berjalan secara automatik pada setiap perubahan melalui saluran paip integrasi berterusan, dengan penggunaan disekat apabila sesuatu ujian gagal.
  • Persekitaran staging yang berasingan daripada persekitaran yang digunakan oleh pelanggan, dengan kenyataan yang jelas tentang dari mana datanya datang.
  • Laporan liputan berkala, dibaca sebagai peratusan dan juga sebagai arah aliran: adakah liputan meningkat apabila sistem berkembang, atau menurun?
  • Tempoh jaminan selepas pelancaran yang menentukan apa yang dikira sebagai kecacatan yang dibaiki secara percuma berbanding permintaan pembangunan baharu.

Tanda-tanda kualiti diabaikan dalam projek anda

Anda tidak memerlukan latar belakang teknikal untuk mengesannya: setiap pembaikan merosakkan perkara lain, setiap penggunaan didahului oleh ketegangan yang ketara dalam pasukan, tiada sesiapa berani menyentuh modul lama "kerana ia berfungsi dan kami tidak tahu apa kesannya", dan gangguan perkhidmatan dilaporkan oleh pelanggan anda dan bukannya oleh sistem pemantauan anda. Ini bukan masalah yang berasingan — semuanya ialah simptom ketiadaan jaring ujian yang akan membolehkan pasukan membuat perubahan dengan yakin.

Di Origami, kami menganggap liputan ujian sebagai sebahagian daripada produk, bukan item sokongan: sistem yang tidak boleh diubah suai dengan selamat selepas dua tahun bukanlah sistem yang berjaya, walau sebaik mana pun rupanya pada hari penyerahan.

Sumber