Setiap hari di bidang IT ada semakin banyak tugas baru, termasuk di bidang pengujian. Jika sebelumnya seorang tester diperlukan untuk hanya menguji sesuai dengan persyaratan (atau tanpa persyaratan itu), maka sekarang ia harus terlebih dahulu memahami bagaimana hal itu dapat diuji sama sekali, teknologi apa yang diperlukan untuk ini, apa yang dapat diotomatisasi, dan bagaimana memasukkan siklus rilis dalam semua aib ini dan dll. Siapa yang harus menjawab pertanyaan ini? Siapa yang akan berkomunikasi dengan pelanggan dan mengklarifikasi persyaratan? Siapa yang akan membuat pendekatan dan menguji arsitektur, persyaratan?
Bekerja sebagai pemimpin dan koordinator pengujian pada proyek-proyek untuk perusahaan besar dan menyelesaikan semua masalah ini selama tiga tahun, saya menyadari bahwa penting untuk tetap menarik seorang individu yang akan menjawab pertanyaan utama: "Bagaimana melakukan pengujian?"
Saya melakukan penyelidikan kecil dan menemukan bahwa peran seperti itu sudah ada, dan itu disebut Test Solution Architect (TSA), tetapi hanya sedikit orang yang tahu tentang itu. Dan deskripsi lowongan TSA di situs web pengusaha membuat kagum dengan daftar tugas dan keterampilan mereka, tapi saya pikir ini lebih mungkin karena kurangnya pemahaman tentang siapa TSA itu.
Berdasarkan pengalaman saya dalam arah ini, saya memutuskan untuk menunjukkan dengan contoh salah satu proyek nyata siapa TSA dan kapan diperlukan.
Deskripsi Proyek Singkat
Tujuan dari proyek ini adalah untuk mengganti satu database dengan yang lain, lebih tepatnya, Cassandra dan pelengkapnya dalam bentuk FilloDB digantikan oleh SnowFlake, dalam proses bisnis aliran pengiriman dan pemrosesan data harian, setiap jam dan bahkan menit-demi-menit. Ada lebih dari 50 aliran seperti itu, dan seperti yang direncanakan oleh arsitek, ini diharapkan untuk menyelesaikan sejumlah besar masalah yang berkaitan dengan kinerja, kehilangan data, biaya pemeliharaan dan pembelian lisensi tambahan untuk Cassandra, dll. Tapi mana dari harapan ini yang dipenuhi dan mana yang tidak - ini adalah topik dari artikel lain.
Apa peran uji pada proyek?
Secara historis, peran berikut telah dibedakan dalam pengujian: penguji manual atau penguji fungsional, alat otomatisasi pengujian (orang yang menulis kode dan tes), dan manajer pengujian (orang yang menyelesaikan semua masalah lain). Proyek kami tidak terkecuali. Proyek yang terlibat:
- 1 Pemimpin Tes atau Pemimpin Tes
- 40 penguji manual yang bekerja dengan tim scrum (7 tim)
- 2 pengembang (ini agak pengecualian, karena pengembang tidak suka mengerjakan tugas otomasi) dan 2 otomatisasi uji
- 2 penguji yang melakukan stress testing
- 1 tester fungsional untuk menguji produk yang dikembangkan oleh pengembang dan pengujian otomatisasi
Pengujian manual
Tujuan utama dari penguji fungsional adalah untuk menguji aplikasi dan mengatakan apakah itu memenuhi persyaratan pelanggan. Untuk ini, penguji biasanya:
- Buat rencana pengujian.
- Buat strategi uji.
- Buat kasus uji dengan langkah-langkah yang dijadwalkan (dengan hasil yang diharapkan dan saat ini).
- Lakukan uji kasus dan simpulkan kualitas aplikasi.
Kami tidak memiliki persyaratan pelanggan atau deskripsi sistem. Hanya ada sistem lama dan yang baru dan harapan: "Jadikan itu berhasil, tetapi dengan basis baru." Oleh karena itu, kami hanya bisa menggunakan pendekatan suka-suka-suka - membandingkan hasil dari sistem lama dan baru. Semuanya menjadi rumit oleh fakta bahwa kami bekerja dengan sistem produksi dan data harian yang diperbarui. Sayangnya, kami tidak dapat memulai sistem kami pada saat yang sama dengan sistem produksi, dan memulainya kemudian, dan ini menyebabkan fakta bahwa data dalam sistem lama dan baru berbeda.
Pada tahap ini, pertanyaan mulai muncul:
- Bagaimana menyimpulkan bahwa sistem kami bekerja dengan benar jika, karena perubahan waktu, kami mendapatkan hasil yang berbeda dari yang kami dapatkan di sistem yang lama?
- Bisakah kita menjauh dari produksi data dan mengerjakan data stabil? Apa risikonya?
- Dan jika kita tetap datang ke data yang stabil, lalu bagaimana membuktikan bahwa sistem kita akan bekerja dengan benar dengan data yang diperbarui setiap hari?
Ini hanya puncak gunung es dari daftar pertanyaan serupa yang muncul pada proyek selama pengujian fungsional / manual.
Otomatisasi uji
Menguji insinyur otomatisasi (dan pengembang) memiliki tujuan untuk menulis aplikasi yang dapat secara otomatis menguji dan / atau memfasilitasi pekerjaan penguji fungsional:
- swa-uji yang akan diintegrasikan dengan CI / CD;
- aplikasi yang membantu menguji penguji fungsional;
- dan perkembangan lain yang diperlukan untuk kebutuhan internal proyek.
Pada proyek tersebut, semua aplikasi yang dikembangkan untuk pengujian seharusnya merupakan produk terpisah yang mematuhi semua aturan pengembangan dan akan dikirimkan kepada pelanggan sebagai hasilnya. Dan, dengan demikian, muncul pertanyaan:
- Siapa yang bersama pelanggan akan mengembangkan persyaratan non-fungsional untuk menguji aplikasi? Solution Architect mengatakan bahwa ini bukan pekerjaan mereka SA bekerja dengan aplikasi yang dipesan oleh pelanggan.
- Siapa yang akan mengembangkan persyaratan fungsionalitas untuk menguji aplikasi? Ada persyaratan yang jelas, tetapi ada yang tidak jelas. Misalnya, apakah kita perlu menyimpan log aplikasi kita dan menganalisisnya?
- Siapa yang akan mengetahui lingkungan aplikasi dengan klien dan memperbaiki persyaratan ini? Misalnya, khusus pada proyek ini ada batasan pada percikan 1.4, dan ini ditemukan hanya setelah membuat aplikasi.
Dan ini juga jauh dari semua masalah yang muncul pada proyek dalam hal otomatisasi pengujian.
Pemimpin Tes, alias Pemimpin Tes
Test Lead harus mengatur proses pengujian pada proyek. Fungsinya termasuk distribusi tugas, mengadakan pertemuan internal dengan penguji, mengatur pekerjaan dengan pelanggan (mencari tahu rincian, meninjau hasil), dll. Artinya, ia fokus pada proses saat ini dan menyelesaikan masalah / tugas sehari-hari, dan tidak dalam mengerjakan tugas-tugas pendekatan, strategi, pengujian arsitektur.
Jika kita berbicara tentang Uji Timbal teknis, maka itu yang bertanggung jawab atas solusi teknis: mengatur pengembangan aplikasi untuk pengujian sebagai proses menciptakan produk perangkat lunak terpisah yang mematuhi semua aturan pengembangan, misalnya, membuat unit test, mengintegrasikan dengan proses CI / CD dan dll.
Dalam proyek kami, peran ini dimainkan oleh dua orang, dan setiap jadwal terlihat seperti ini:
Dalam kedua kasus, Test Lead sibuk mengerjakan strategi pengujian yang sudah dipilih, tetapi tidak ada yang bertanggung jawab untuk memilih strategi itu sendiri, membenarkan pilihan ini kepada klien, mengadaptasinya terhadap perubahan dan masalah lainnya. Sebagai contoh:
- Pengembangan rencana dengan klien untuk memasuki tahap pengujian penerimaan oleh klien (UAT).
- Mempelajari persyaratan dengan klien ketika dianggap bahwa fungsionalitas dapat ditransfer ke UAT.
- Belajar dengan klien tentang asumsi pengujian pada berbagai jenis lingkungan (titik yang sangat rumit). Karena biasanya lingkungan pengujian tidak sesuai dengan produksi, semua pertanyaan yang berkaitan dengan pengujian pada lingkungan lain harus dikerjakan bersama klien.
- Belajar dengan klien tentang perbedaan metrik yang dapat diterima dalam berbagai jenis pengujian. Misalnya, hasil apa yang diharapkan klien untuk dilihat selama pengujian kinerja? Mungkin itu sudah cukup baginya bahwa sistem bekerja tidak lebih buruk.
- Mengumpulkan semua kemungkinan metrik dalam angka, misalnya, perbedaan data untuk tabel ini diizinkan oleh tidak lebih dari 10%, atau skrip harus berjalan tidak lebih dari delapan jam.
Apa yang salah di sini?
Pertanyaan-pertanyaan di atas biasanya diletakkan di atas bahu Pimpinan Uji, tetapi ada pendekatan yang salah:
- Mereka tidak diajarkan proses di mana Pimpinan Uji harus menyelesaikan semua masalah dengan pelanggan. Paling sering, seorang Pimpinan Tes yang berpengalaman memahami hal ini dan, mungkin, bahkan tahu bagaimana, tetapi kemungkinan besar, bagian penting seperti tujuan bisnis atau perbaikan spesifik tetap berada di luar ruang lingkup pemahamannya. Dengan demikian, prioritas yang salah dapat ditetapkan.
- Test Lead biasanya memasuki proyek ketika pengembangan sudah berlangsung atau baru mulai, yaitu ia dihadapkan pada kondisi bahwa sudah ada beberapa perjanjian atau bahkan semuanya sudah diperbaiki. Sangat beruntung bahwa SA adalah orang yang cukup berpengalaman dan kompeten dan akan menuju pengujian - ini akan membantu untuk menyesuaikan perjanjian awal dengan pelanggan dengan kebutuhan pengujian. Dalam kasus lain, lead harus menemukan kembali roda.
Dan ini tidak semua masalah yang jatuh pada Uji Timbal ketika tidak ada TSA.
Jadi siapa TSA ini dan mengapa itu diperlukan?
Test Solution Architect adalah orang yang mempertimbangkan tugas dari sudut pandang bisnis, informasi dan teknologi, mengoordinasikan dan mengembangkan persyaratan dengan pelanggan, menyusun peta jalan dengan tenggat waktu dan mengembangkan solusi di tingkat antarmuka.
Proyek sekarang menentukan kondisi lain. Proyek menjadi lebih besar, lebih rumit dalam hal teknis dan proses, dapat mencakup beberapa industri dan teknologi. Pengujian tidak hanya menjadi layanan, tetapi juga pemasok (pengembang) perangkat lunak untuk pelanggan. Oleh karena itu, dalam pengujian ada kebutuhan untuk menyoroti peran serupa. Selain itu, orang ini harus memasuki proyek bersama dengan SA, yang terlibat dalam aplikasi produksi, dan mulai mengerjakan semua masalah pada saat yang sama.
Secara khusus, pada proyek kami, peran TSA dimainkan oleh Test Lead, yang bergabung dengan proyek 3 bulan setelah dimulainya pengembangan, dan ini mensyaratkan banyak pekerjaan tambahan pada menyelaraskan persyaratan, lingkungan, mencari tahu visi hasil tes akhir dari pelanggan. Akibatnya, proyek tersebut tidak memenuhi tenggat waktu untuk sebagian besar hidupnya, dan pelanggan tidak senang dengan persediaan dan hasil pengujian. Bukan karena pekerjaannya dilakukan dengan buruk, tetapi karena hasil yang dihasilkan oleh tim tidak memenuhi harapan pelanggan.
Kapan TSA tidak dibutuhkan?
Jelas bahwa peran seperti itu tidak diperlukan pada semua proyek. Di bawah ini saya mengusulkan cara paling sederhana untuk menentukan kebutuhan TSA pada suatu proyek, tergantung pada bagaimana pelanggan melihat pendekatan pengujian.
Jenis proyek pertama - pelanggan memberikan pengaturan proses pengujian atas kebijaksanaan perusahaan yang ia sewa.Dalam hal ini, TSA memasuki proyek sejak mulai bekerja, bersama dengan SA, mengembangkan persyaratan pengujian, mengembangkan skema pengujian tingkat tinggi, memutuskan apa yang akan diotomatisasi / dikembangkan sebagai aplikasi terpisah, menentukan persyaratan untuk aplikasi ini dan, tentu saja, mengkoordinasikan dengan pelanggan, memprioritaskan tujuan proyek sesuai dengan harapan bisnis.
Jenis proyek kedua - pelanggan memiliki pemahaman sendiri tentang pengujian, gambaran yang jelas dan proses yang efisien.Dalam hal ini, TSA mungkin tidak diperlukan, pengujian hanya diperlukan untuk masuk ke dalam gambaran dunia yang ada dan mendukungnya. Tetapi jika pemahamannya dangkal, maka TSA tidak hanya perlu melakukan semua tindakan seperti untuk proyek-proyek jenis pertama, tetapi juga untuk membuktikan kepada pelanggan bahwa ini semua diperlukan.
Jenis proyek ketiga - pelanggan tidak membutuhkan layanan TSA.Alasannya mungkin berbeda:
- Proyek kecil dan jangka pendek dengan fungsi sederhana.
- Pelanggan memiliki TSA sendiri.
- Pelanggan menolak untuk menguji, dll.
Keterampilan TSA
Solusi Praktik Arsitek telah berhasil diterapkan dalam pengembangan untuk waktu yang sangat lama. Berdasarkan pengalaman sukses ini, dan juga dengan mempertimbangkan volume dan kompleksitas proyek, masalah yang melebihi tanggung jawab pimpinan Uji, kita dapat mengatakan bahwa alokasi peran TSA adalah perkembangan alami dari berbagai peristiwa. Selain itu, TSA harus dilatih dalam proses, teknik, dan pendekatan yang sama dengan SA.
Singkatnya, menurut saya, TSA harus memiliki:
- Dengan pengetahuan teknis, baik secara umum maupun di area domain tempat ia bekerja, untuk mengetahui masalah area ini, tipikal kesalahan, masalah dan cara untuk memeriksanya.
- Keahlian komunikasi yang baik, mampu menarik perhatian pelanggan untuk masalah pengujian, menyelesaikan persyaratan pengujian, pendekatan pengujian, melaporkan pengujian dan banyak masalah terkait, seperti lingkungan pengujian.
- Keterampilan kepemimpinan dan menjadi proaktif karena Pengujian sangat sering mencoba untuk pergi nanti.
- Pengetahuan yang baik tentang pengujian secara umum, dokumentasi pengujian, proses pengujian, pelaporan pengujian, pendekatan, dll.
- Pengetahuan yang baik tentang aturan pengembangan perangkat lunak: kebijakan rilis, kebijakan versi, memahami proses CI / CD, dll.
Berdasarkan hal tersebut di atas, TSA harus memiliki semua pengetahuan yang sama dengan SA, tetapi harus fokus pada tugas menyediakan pelanggan dengan produk yang berkualitas. Pekerjaan TSA dipersulit oleh fakta bahwa sering kali perlu mengubah pendapat pelanggan tentang pengujian secara eksklusif tentang dapur internal proyek.
Justru pengetahuan yang saya terima di sekolah Solution Architect yang memungkinkan saya untuk mengembalikan kepercayaan pelanggan pada proyek yang dijelaskan di atas, menyelesaikan banyak masalah pengujian dan berhasil menyelesaikan pengiriman semua fungsi hampir tepat waktu, serta membangun proses dan menandatangani kontrak untuk pekerjaan di masa depan.
Kesimpulan
Industri TI sedang berkembang, tugas-tugas baru muncul (tantangan jika Anda mau), dan dalam hal pengujian, posisi TSA yang disorot telah menjadi mendesak. Secara alami, itu semua tergantung pada proyek, tetapi dalam proyek-proyek di mana TSA diperlukan, Anda harus terlibat dalam pekerjaan pada tahap paling awal, ini akan menghindari masalah di masa depan dan akan membantu pengembangan proyek.