Menguji di perusahaan besar, di perusahaan, sering kali merupakan tugas yang rumit dan tidak berterima. Kesenjangan antara divisi bisnis dan TI sangat besar: ketika seorang pengembang memiliki visi di tingkat kode, dan verifikasi di tingkat pengujian unit, dan pelanggan berpikir bekerja atau tidak bekerja bahkan tidak dengan layanan, tetapi dengan seluruh proses yang melampaui satu tim pengembangan, atau bahkan keseluruhan divisi \ perusahaan. Dan dia meminta untuk mengadakan pengujian bisnis, atau pengujian ujung ke ujung, atau pengujian berdasarkan skenario dari awal hingga akhir (ujung 2 ujung).
Mari kita mulai dari awal - dari dua pilar dari mana "pengujian bisnis end-to-end" terkenal ini berasal, yaitu dari piramida pengujian dan standar ISO9000.
Menguji Piramida
Piramida pengujian mungkin akrab bagi setiap penguji yang telah mahir dalam profesinya dan telah menumpuk gundukan ketika berkomunikasi dengan unit terkait. Terutama sering diperlukan untuk menarik ketika mendukung otomatisasi uji. Tes mana yang lebih murah dan lebih penting untuk dikembangkan? Dan lari?
Inti dari piramida pengujian tidak rumit: pengujian harus didasarkan pada tes yang paling sederhana dan tercepat dalam penulisan dan tes unit eksekusi. Tentu saja, memeriksa antarmuka kelas dan fungsi bukanlah hal yang dapat ditunjukkan kepada pelanggan, tetapi tanpa fondasi yang kuat, monolitik, dan bebas masalah ini, hampir tidak mungkin untuk membangun sesuatu yang lebih tinggi. Sebagai aturan, beberapa lusin fungsi, metode, dan kelas menerapkan beberapa jenis fungsi untuk pelanggan, dan pada kenyataannya, selusin tes unit dapat dikurangi menjadi beberapa tes tingkat atas. Pelanggan sudah membutuhkan apartemen yang indah dengan dekorasi, tetapi tidak mungkin ia akan puas ketika jendela miring di apartemennya berhenti dibuka, dan lantai dan langit-langit menjadi retak karena angin sepoi-sepoi pertama yang bertiup. Namun, pelanggan sendiri untuk pergi ke apartemen dan memeriksa kualitasnya mungkin bukan ide terbaik. Setuju, sulit bagi pengguna untuk memeriksa kualitas beton di fondasi, dan mereproduksi semua kondisi cuaca. Jadi, dalam pengujian, tentu saja, pengujian tingkat atas diperlukan, maka hanya ketika kami telah mengerjakan pengujian unit, demikian pula pengujian tingkat yang lebih tinggi.
Lebih sulit untuk mengembangkan dan lebih lama melakukan tes tingkat yang lebih tinggi - tes integrasi, yang memverifikasi operasi yang benar dari modul yang bekerja secara bersamaan yang bekerja di seluruh tim, melepaskan produk (sistem) mereka. Artinya, integrasi kode diperiksa, sistem diuji tanpa memperhitungkan interaksi akun dengan sistem eksternal. Tes semacam itu sudah menyiratkan pemeriksaan tingkat tinggi, kemungkinan besar melalui panggilan ke sistem melalui sistem API atau bahkan GUI (depan). Bekerja dengan jenis tes ini lebih sulit - untuk mencakup semua cabang dan nuansa kode, Anda kemungkinan besar perlu menggunakan sejumlah besar cek yang tumpang tindih pada berbagai data uji, dan selama otomasi sering mengembangkan sejumlah kondisi dan cabang dalam skrip. Artinya, di satu sisi, kami sudah mendekati pengguna, membuat hidup jadi sulit, tetapi di sisi lain, masih sulit bagi kami untuk menemukan bahasa yang sama, harganya lebih mahal, dan kualitas cek masih belum cukup. Artinya, kita bisa meluncurkan pelanggan ke apartemen baru, dia bisa memeriksa semuanya, tetapi tanpa memperhitungkan interaksi dengan penghuni lain, kondisi cuaca, dan utilitas. Setuju, arti dari dunia ideal, model, dalam kehidupan nyata, sebagai aturan, tidak banyak.
Jika kita menambahkan kondisi ini, kita akan melihat bagaimana sistem kita berinteraksi dengan sistem eksternal - pemasok dan konsumen, dengan lingkungan kita, yaitu, kita melakukan pengujian sistem, maka kita dapat dengan mudah melihat bahwa kompleksitas pengujian juga akan meningkat. Kita perlu mencapai operabilitas simultan dari semua sistem yang berinteraksi, meskipun tanpa keterlibatan spesialis di dalamnya. Untuk saat ini, cukup bagi kami untuk hanya menerima beberapa data dari pemasok kami dan mentransfer data kami ke konsumen kami. Dalam urutan dan format yang benar. Nasib lebih lanjut dari data tidak mengganggu kita. Yang utama adalah bahwa sistem kami bekerja dengan benar di lingkungan yang tepat. Dan semuanya akan baik-baik saja di sini - bagi pelanggan kami, kami sudah dapat melakukan demonstrasi skala penuh, tetapi hanya dalam kehidupan nyata tidak semua kriteria keberhasilan untuk pengembangan kami. Tentu saja baik bahwa pelanggan mendapatkan apartemennya di rumah yang kokoh, tetapi jika Anda perlu mendapatkannya, memanjat kawat berduri, lalu berkano di sepanjang danau dengan buaya ke gubuk-gubuk yang dipenuhi ular, maka mungkin kita tidak benar apakah disana?
Oleh karena itu, di sini ide pertama untuk pengujian end-to-end adalah untuk memeriksa tidak hanya lingkungan kita, tetapi juga semua sistem yang saling terhubung melalui mana data yang diterima atau dikirim oleh sistem kita lewat. Dan ini, pada gilirannya, berarti kita harus menggabungkan beberapa "piramida uji" ini satu sama lain. Pembangunan jembatan rapuh tempat kami akan menyimpan data yang berharga bagi pengguna oleh pegangan.
Satu-satunya pertanyaan adalah bagaimana melakukan ini? Siapa yang harus melakukan ini? Bagaimana cara menyatukannya?
ISO9000
Serangkaian standar yang menggambarkan sistem manajemen mutu, termasuk fakta bahwa setiap proses dalam organisasi harus dijelaskan, didokumentasikan, bahkan jika itu adalah proses mengeluarkan penggaruk pada musim gugur ke petugas kebersihan. Dan jika demikian, itu bukan proses tunggal yang terjadi di dalam perangkat lunak yang digunakan dan dikembangkan dalam organisasi dapat dijelaskan. Pertanyaannya adalah bagaimana melakukan ini? Tentu saja, deskripsi terbaik, dari sudut pandang BDD, adalah deskripsi perilaku dengan tes, di mana piramida pengujian akan terletak. Tapi kami akan segera kembali ke dilema kami dengan menggabungkan beberapa piramida dengan tali tipis dari atas ke atas, di mana tali pejalan kaki kami dan penggunanya akan berjalan tanpa asuransi.
Pendekatan proses adalah strategi manajemen yang mengharuskan organisasi untuk mengelola prosesnya dan interaksi di antara mereka. Dengan demikian, Anda perlu mempertimbangkan setiap proses utama perusahaan dan proses pendukungnya.
Oleh karena itu, paling mudah menggunakan abstraksi - membuat setidaknya diagram proses, dan menunjukkan input dan outputnya, membuat proses terkontrol dan terukur, memastikan interkoneksi dengan proses induk dan anak, seperti yang disyaratkan oleh ISO9000
Semua proses memiliki:
• input;
• keluaran;
• kontrol operasional;
• pengukuran & pemantauan yang tepat.
Setiap proses akan memiliki proses pendukung yang mendukung dan memungkinkan proses menjadi terwujud
Diagram bisnis paling cocok untuk tujuan ini, dan standar seperti UML, BPMN, ARIS, dll paling sering digunakan, dan proses itu sendiri menjadi diagram alur dengan "kubus" digantung di atasnya. Ada interaksi antara "kubus", dalam standar BPMN itu adalah aliran tindakan dan aliran pesan. Dan inilah yang kita butuhkan!
Setiap perusahaan yang ingin memiliki sertifikat dan mengikuti standar ISO9000, kemungkinan besar, telah memperoleh skema semacam itu, dan mereka merupakan bagian integral dari persyaratan tingkat atas. Jika perusahaan memiliki analis yang baik, maka, kemungkinan besar, tautan ke persyaratan untuk tindakan individu dari skema akan turun ke persyaratan tingkat rendah. Kami membutuhkan mereka.
Pada kenyataannya, pada diagram kita dapat melihat keseluruhan proses, dan memahami skenario mana yang perlu kita bangun, dan sistem / tim mana yang harus dijalankan dengan data apa pada saat apa.
Saya tidak meremehkan pekerjaan pengembang yang menulis kode kompeten yang mengirim pesan antara berbagai bagian perangkat lunak dan sistem perangkat keras, tetapi tidak mungkin untuk mengingat semuanya. Dan ketika proses tersebut digunakan dalam banyak proses lainnya, lebih baik memiliki "kartu" seperti itu dengan Anda untuk melakukan pengujian yang kompeten, dan terlebih lagi untuk membangun model pengujian.
Apa yang dalam praktek
Jadi, kami memiliki dua yang pengantar - setiap tim \ sistem harus memiliki piramida tes yang disiapkan - dari yang terkecil, unit test, hingga tes sistem yang kompleks, serta fakta bahwa dalam organisasi, kami harus menggambarkan persyaratan dalam bentuk bisnis -proses. Fakta ini akan memungkinkan kami untuk dengan cepat menjawab pelanggan proses bisnis bagaimana cara kerjanya, dan pada titik mana ia rusak, dan kami sendiri, ketika menerima cacat dari operasi industri, dengan cepat melakukan analisis akar penyebab (analisis akar penyebab cacat). Secara teori.
Namun dalam praktiknya, semuanya kembali jatuh ke penguji - bagaimana, dari setumpuk tes, terutama tes asing, untuk memilih yang tepat, untuk membangunnya dalam sebuah rantai, dan pada input dari masing-masing sistem untuk mengirimkan data yang diperlukan dan membandingkan dengan hasil yang diharapkan yang ditentukan dengan benar?
Opsi termudah adalah mengembangkan tes berdasarkan model bisnis, dan membagi tim menjadi proyek yang menerapkan proses bisnis tertentu. Untuk ini, dalam beberapa alat manajemen pengujian, sudah dimungkinkan untuk memuat skema BPMN (misalnya, untuk HPE ALM - memuat dalam format XPDL didukung). HP ALM sendiri akan memecah skema menjadi serangkaian persyaratan (tindakan), dan jika diinginkan, membuat hierarki persyaratan (modul Persyaratan-> Model Bisnis). Selanjutnya, bisnis kami adalah untuk memenuhi persyaratan dengan pengujian, dan kemudian membangun persyaratan, dan karenanya pengujian dalam rantai yang mencakup proses bisnis kami. Rantai ini dalam HPE ALM disebut “jalur,” dan memungkinkan Anda untuk melihat semua kombinasi urutan. Jika diinginkan, rantai dapat segera dikonversi ke tes.
Tetapi bahkan jika Anda tidak menggunakan alat pengujian, Anda masih harus membuat rantai dari proses bisnis. Terutama mengingat ketidaksempurnaan alat (tidak semuanya begitu cerah), serta fakta bahwa, kemungkinan besar, model uji perlu dirakit setelah facto, dan dieksekusi dalam bentuk regresi oleh "tim bersama" yang tidak terjebak pada proyek-proyek baru.
Berapa banyak cara tupai dapat mencapai tonjolan?Dalam hal ini, kita perlu membuka tes masing-masing tim, menemukan yang terkait dengan persyaratan yang muncul dalam model bisnis, dan membangun rantai dari mereka, menyimpannya di "ruang bersama". Menciptakan ruang bersama adalah semacam pengganti, tetapi dalam hal apa pun itu harus, bahkan dalam bentuk buku gudang, excel, atau area proyek dalam alat manajemen pengujian. Jika kita berbicara tentang HPE ALM lagi, maka modul BPT (Pengujian Proses Bisnis) bertanggung jawab untuk fungsi ini, yang pada saat yang sama memungkinkan Anda untuk mentransfer hasil dari satu pengujian ke parameter yang lain. Namun, jika Anda ingin dan bekerja keras pada HPE ALM, dimungkinkan untuk menerapkan ini dengan membangun kembali set tes (set Tes) dalam aliran eksekusi (Execution flow). Kemudian, ketika memulai set lengkap, penguji yang bertanggung jawab untuk melewati masing-masing komponen skrip ujung-ke-ujung akan dipanggil secara bergantian.
Dan, sayangnya, pengujian saja tidak cukup. Dari praktik saya, hampir semua alat memiliki beberapa kesalahan fatal, dan karena itu, jika Anda sampai pada tahap pengujian otomasi dalam proses bisnis, Anda akan sampai pada pembuatan skrip yang akan melakukan pengujian dalam urutan yang benar.
Akibatnya, dua kesimpulan dapat dibuat:
1) untuk skenario ujung ke ujung, sangat mungkin bahwa tes yang dikembangkan sebelumnya digunakan untuk masing-masing sistem yang termasuk dalam rantai proses bisnis (skenario)
Dimungkinkan untuk menyajikan semua suite uji lengkap perusahaan dalam bentuk matriks jarang, di mana tes untuk setiap sistem didistribusikan dalam kolom (untuk kesederhanaan - tes sistem), dan proses bisnis dalam baris. Artinya, untuk proses bisnis tertentu, Anda harus memilih \ membuat tes yang mencakup proses bisnis, menjalin hubungan. Jika tidak ada jangkauan, ini adalah kesempatan untuk mengisi kesenjangan dalam model pengujian, atau untuk memastikan bahwa kualitas dipastikan oleh tingkat pengujian lainnya (pengujian integrasi, pengujian unit, tinjauan kode dan menjalankannya melalui analisis).
2) Alat diperlukan untuk memantau, melacak, dan memperbarui proses bisnis untuk sinkronisasi dengan model uji.
Dan jika alat pengujian kurang lebih dapat mengatasi pembuatan model uji, maka semuanya benar-benar buruk dengan memperbarui, sering kali lebih mudah untuk menciptakan kembali model daripada mencoba melihat perubahan dalam proses dan model pengujian. Dan pengalaman tim nyata menunjukkan bahwa lebih baik untuk membuat visualisasi arsitektur secara langsung. Cara termudah untuk melakukan ini adalah di area umum, menggunakan papan penanda sederhana dan stiker. Kemudian, tim yang berpartisipasi dalam proses bisnis dapat dengan jelas melihat bagaimana proses tersebut sedang dimodifikasi (koneksi dihapus dan ditambahkan, tindakan dihapus dan ditambahkan). Yang utama adalah bahwa setiap orang memiliki akses ke papan tulis. Plus, perhatikan bahwa jika proses tersebut melibatkan pesan antar sistem, maka, sebagai aturan, setidaknya harus ada dua tes dari masing-masing sistem - untuk mengirim dan menerima data. Namun, alih-alih stiker, Anda dapat menggunakan seluruh kota Lego (dari balok besar), atau sesuatu yang bahkan lebih kreatif. Hal utama di sini adalah satu bahasa dan satu ruang informasi, yang sangat kurang di perusahaan.
Kesimpulannya
Mengorganisir pengujian visual dan proses bisnis yang benar adalah hal yang kompleks dan sangat mahal. Harap dicatat bahwa pengujian E2E bukan hanya penerimaan, pengujian pengguna yang akan dilakukan pelanggan, itu adalah membangun jembatan, dengan mempertimbangkan semua situasi yang mungkin terjadi bahwa pelanggan akan mengikuti dan memimpin pengguna berjalan kaki.
Sekali lagi - E2E - ini bukan jalan di Lada Kalina melintasi jembatan, dan bahkan tidak ada dua bagian kamaz. Ini adalah pekerjaan teknik yang rumit, menimbang jembatan dengan sensor dan melakukan semua kemungkinan pemeriksaan dan situasi - setidaknya deskripsi dari skenario ini.
Apakah perusahaan Anda memerlukan penyelesaian akhir yang ideal adalah masalah khusus untuk tujuan dan kebutuhan Anda. Selalu, seperti halnya pengujian apa pun, Anda harus mengevaluasi risiko potensial dari cacat yang hilang pada tahap ini, serta biaya persiapan dan pelaksanaan pengujian ujung ke ujung. Untuk mengevaluasi apa yang akan dikenakan biaya lebih banyak dari ini dan hanya kemudian bertindak. Tetapi dalam kasus pengujian end-to-end pada proses bisnis, harus diingat bahwa itu tidak masuk akal tanpa dasar yang kuat dalam bentuk 100% lulus unit test (~ cakupan 90-100%), tanpa tes integrasi (~ cakupan 60-80%, 90- 100% passrate), tanpa tes sistem (cakupan 20-40%, 80-100% passrate). Menetapkan kriteria untuk sukses (gerbang mutu) lebih merupakan persyaratan untuk kualitas produk, hal utama yang perlu diingat di sini adalah bahwa volume tes E2E hanya bagian atas piramida (cakupan 1-2%, ~ 99% laju gerak), yang tidak boleh lebih besar dari dasarnya, tidak pada saat yang sama menjadi sumbat lubang dari langkah sebelumnya. Ini adalah suplemen yang dianggap tertutup pada tahap sebelumnya.
Organisasi pengujian semacam itu terutama pekerjaan mempersiapkan dan menyinkronkan kasus uji dan data (analitik pengujian), serta seperangkat tindakan organisasi, menyinkronkan tim di satu tempat pada saat yang sama di lokasi pengujian yang dapat diterapkan. Dengan mengingat hal ini, seseorang tidak boleh mencoba untuk menunjukkan kepada pelanggan "pengujian end-to-end" lebih cepat dari jadwal agar tidak membuang waktu sekaligus sejumlah besar orang tanpa semua komponen kerja berkumpul bersama.
PS menggambarkan alat, serta praktik - murni misalnya, penulis tidak menetapkan sendiri tujuan produk iklan dan menyatakan pendekatan ini untuk pengujian ujung-ke-ujung satu-satunya cara yang benar.